From ram-bounces@iab.org Mon Jul 02 10:13:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MeU-0000EV-Mf; Mon, 02 Jul 2007 10:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MeR-0000DY-Mh for ram@iab.org; Mon, 02 Jul 2007 10:13:15 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Mdk-0008Gb-Kg for ram@iab.org; Mon, 02 Jul 2007 10:13:15 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 49DE1212C51 for ; Mon, 2 Jul 2007 17:12:31 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 160B5212C3F for ; Mon, 2 Jul 2007 17:12:31 +0300 (EEST) Message-ID: <468907CE.4070405@nomadiclab.com> Date: Mon, 02 Jul 2007 17:12:30 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: RAM Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [RAM] Six/One: A (Different) Solution for Routing and Addressing in IPv6 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Folks, the main existing routing and addressing proposals are based on an indirection between the addressing spaces of edge and transit domains. The strength of indirection is that it contains the size and the update frequency of the global routing table. This can happen transparently to hosts and edge networks, enabling new traffic engineering practices and reduced rehoming costs for edge networks. The drawback of indirection is that it requires a distribution of address translation information across the Internet. Little analytical insight is currently available on how this be done in fast, scalable, and secure manner. And where indirection requires support of both sides of a communication, no smooth transition path exists either. http://users.piuha.net/chvogt/pub/2007/draft-vogt-rrg-six-one-00.txt The routing and addressing solution proposed at the foregoing link, Six/One, avoids the problems of indirection. - It uses a single addressing space of IPv6 addresses, and hence - works without a distribution of address translation information. - Hosts can suggest a packet be routed via a preferred provider, yet - edge networks can overwrite this suggestion according to traffic engineering policies. - Hosts adapt to the provider selection of an edge network in that subsequent packets include the right addresses directly. - This adaption happens within 1 RTT w/o packet loss or delay. - Edge network reconfiguration during rehoming is small if access network operators obey recommended operational practices. - A smooth transition path exists, driven by incentives for early adopters. - Deployment will foster global protection against IP spoofing. Your feedback will be appreciated. Regards, - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 02 10:32:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MwZ-0003x4-9A; Mon, 02 Jul 2007 10:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MwY-0003wz-6p for ram@iab.org; Mon, 02 Jul 2007 10:31:58 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Mvi-00061e-A2 for ram@iab.org; Mon, 02 Jul 2007 10:31:58 -0400 Received: from [10.0.0.9] (dell.firstpr.com.au [10.0.0.9]) by gair.firstpr.com.au (Postfix) with ESMTP id E10E959DA1; Tue, 3 Jul 2007 00:30:58 +1000 (EST) Message-ID: <46890CEB.6030807@firstpr.com.au> Date: Tue, 03 Jul 2007 00:34:19 +1000 From: Robin Whittle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Subject: [RAM] 1 Ivip ITR strategies, including in the host X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here are some ideas in 5 messages, which will make most sense if read in this order. I wrote multiple messages so any discussion can be specific to each one. 1 Ivip ITR strategies, including in the host 2 Ivip ETR strategies, including in the host 3 Database & ITR update rates, mobility etc. 4 User-interface and delegation tree for central database (LISP/Ivip) 5 Database <--> ITR push, pull and notify Here is an idea for combining numerous caching (pull) ITRs with one or a few full-database (push) ITRs, to achieve generally optimal paths whilst not delaying the first packets - as would usually be the case with a caching ITR. I also discuss having a caching ITR function as part of host operating systems, to reduce the load on ITRs in the edge network or beyond. Probably a lot of what I write would also apply to LISP, however I will only refer to Ivip, since I still don't have a clear idea of what LISP 1.5 involves. Most of the people on this list know vastly lot more about running routers, networks etc. than I do, so please point out any things I seem to be missing. In Ivip I do not anticipate the ITRs having any built-in Traffic Engineering functions, such as would be required by the LISP I-D's Priority and Weight (p15) variables. That would be very costly to implement. An Ivip ITR can map any IPv4 address to any other IPv4 address (subject to config file limitations), or to having the packet dropped. This should mean the encapsulation can be done by conventional FIB mechanisms, without involving the router's central CPU at all. Traffic engineering, in the form of load balancing, could be done for a group of IP addresses using two links by mapping some addresses so their packets are tunneled to the ETR which belongs to one ISP and the others to be tunneled to the ETR of the other ISP, with two links to the two ISPs thereby having a chosen load, depending on the traffic of each mapped IP address. Let's say there is an edge network which wants to be totally hip to Ivip. Ideally, there would be ITRs all over the network. Ideally, each ITR would have a full copy of the database, which it needs to get via a push mechanism. However this will be costly in terms of traffic flow to the ITR and in terms of its ability to decode the updates, store them, and write them to its FIB (which must have a huge capacity) as they arrive. Let's say the edge network is rather large, and the operators only want to have a single full database ITR. The operators want to have a few hundred pull ITRs, all over their edge network. These query some internal or external system - as I explore in message "5 Database <--> ITR push, pull and notify". I am trying to find a way that these caching (pull) ITRs can pass packets in the mapped address ranges (meaning they are addressed to one of the "master-subnets" which the Ivip system handles by encapsulating and tunneling to ETRs) if it doesn't already have some mapping information. If it does have mapping for the address of the packet, the caching ITR's FIB will encapsulate the packet and send it on its way to the ETR, wherever this may be. Let's say these caching ITRs have some mechanism for detecting the fact that a significant number of packets are being sent to an address range which is covered by the Ivip mapping system, but for which it has not yet asked for mapping information about. Ideally this would be a counter per IP address, but that would be extremely unwieldy or impossible, so perhaps some simpler system such as a sampling scheme which examines 1% of the incoming packet's destination addresses (when the router's CPU has nothing else to do). Then an algorithm searches for two packets in the last few minutes which are within the Ivip mapped range but which the ITR has not yet asked for mapping information. Then the ITR can ask for the mapping information for this address and update its FIB whenever it arrives. If the address is part of a larger subnet which has the same mapping, the response will say so and so the FIB response for that subnet will be in place for future packets. A distributed system for handling mapping requests such as that of draft-meyer-lisp-cons could take many seconds to get a reply back to this ITR. Even with the snappier system I describe in Message 5, I think we don't want to delay the packets for which the caching ITR doesn't yet have mapping information for. Nor we do want to insist the caching ITR encapsulates every packet. For now, we can assume that the delay in getting mapping via query and response is so long that it will be unacceptable to delay all packets which require mapping for this time. The task then is to organise the ITRs so that every packet gets handled by an ITR, with the "novel" ones (those the caching ITR - the first ITR the packet is handled by - doesn't have mapping for) being handled by some probably longer path than is ideal, while the bulk of the traffic has no path delays, because the local caching ITRs have already got mapping data for the destination addresses of these "bulk" packets. Conceptually, what I am thinking of is thousands of hosts which are sending packets. Some of these packets need to be handled by an ITR because they are to addresses within the Ivip-mapped "master-subnets". There are two classes of ITR for this part of the discussion: ITRC With cache of mapping data derived from responses to queries of the database by some means. (Pull.) ITRD Full copy of the database, because it receives a continual stream of updates. (Push.) IR Ordinary internal router. BR Border router - connects to the global BGP system. I assume these functions are performed by routers which also do all the other things routers are expected to do in such a location. This plan is all inside the edge network: ................ . Edge network . . ITRD . } / \ . / } H--\ / \ . / } \ / \ ./ } H----ITRC0--------BR--- } / | \ / .\ } H--/ | \ / . \ } | \ / . \ } | IR . } | / \ . / } H--\ | / \ . / } \ | / \ ./ } BGP transit & H----ITRC1--------BR--- } border routers / | \ / .\ } of the Internet H--/ | \ / . \ } | \ / . \ } | IR . } | / \ . / } H--\ | / \ . / } \ | / \ ./ } H----ITRC2--------BR--- } / | \ / .\ } H--/ | \ / . \ } | \ / . \ } | IR . } | / \ . / } H--\ | / \ . / } \ | / \ ./ } H----ITRC3--------BR--- } / .\ } H--/ . \ } . \ } . } .................. } Fig 1. Plan A for Fig 1. is that every caching ITRC has its FIB set up so that packets addressed to every IP address in the "master-subnets" it does Ivip mapping for will either be encapsulated and tunneled to the ETR near the host with the mapped address, or will be encapsulated and tunneled to a single IP address of the full database ITRD (at the top of the diagram). This way, all packets are Ivip mapped, but those which are "novel" to the first ITR they reach will probably go on a longer than optimal path via ITRD, before being encapsulated and tunneled to the proper ETR. ITRD needs to be expecting encapsulated packets arriving on one of its IP addresses, but it would be easy for it to pop off the IP-in-IP header and then put the packets through its FIB. Ideally, this will be a pretty small proportion of traffic to Ivip-mapped addresses - and the main traffic flows through the internal routers (in this example, the first internal routers are all ITRCs but these ITRCs don't need to be the closest router to the hosts - as I depict in Fig 2.) and then out via the nearest border router. Plan B is for the edge network's routing system to correctly handle each ITRC spitting out a packet it knows is addressed to part of an Ivip "master-subnet" but which it doesn't yet have mapping data for - and the network forwarding that packet to the one ITRD. The internal routing system needs to ensure these "novel" packets are always forwarded towards ITRD. It would be acceptable or desirable if they pass through one or more further ITRCs on their way to ITRD. If a packet did reach an ITRC which had mapping for it, then that would be fine, because it would be tunneled from there. Maybe it would work fine if each IRTC accepts packets addressed to the Ivip master-subnets and forwards those which were not mapped and encapsulated by its FIB on a link which leads them closer to ITRD - which advertises these master-subnets. For this to work, it would be vital for none of the border routers to announce paths for these master-subnets (unless border router sent the packets towards the IRTD rather than out to the Internet). The border routers would announce paths for all the BGP announced prefixes other than the Ivip master-subnets and those prefixes for which this edge network is the destination. So any packet sent from inside the network would eventually find its way to an ITR. Fig 1 could be applied to LISP. Fig 2 can't be, because as far as I know, LISP doesn't involve EIDs being part of prefixes which are advertised in BGP. Alternatively, in Fig 2. the edge network could have no full database ITR and would rely on the closest ITR(s) (presumably an ITRD) in the BGP system to handle packets which its local ITRCs let pass without encapsulation. This would be cheaper for the edge network, and would not require a constant inflow of update data for an ITRD. (See message 5 for how the ITRCs need some Query Server to request mapping information from, and how this one or more Query Servers needs to lead to a Query Server which has a full copy of the database - ideally somewhere close, best of all in the edge network.) ................ . Edge network . . . . / H--\ . / / \ ./ / H----ITRC0--------BR-----TR / | \ / .\ \ H--/ | \ / . \ \ | \ / . \ \ | IR . TR-----ITRD--- | / \ . / H--\ | / \ . / \ | / \ ./ BGP transit & H----ITRC1--------BR--- border routers / | \ / .\ of the Internet H--/ | \ / . \ | \ / . \ | ITRC2 . TR---- | / \ . / H--\ | / \ . / / \ | / \ ./ / H-----IR BR-----ITRD--- / | \ / .\ / H--/ | \ / . \ / | \ / . \ / | ITRC3 . TR | / \ . / H--\ | / \ . / \ | / \ ./ H-----IR BR--- / .\ H--/ . \ . \ . .................. Fig 2. This shows how all paths taken by packets generated by hosts will need to pass through at least one ITRC before exiting a border router. Each ITRC needs to have a way of querying a copy of the central database, probably via some caching proxy, or perhaps by querying a nearby ITRD's internal database. However, I think any ITRD is probably going to be busy and it would be better to have a simple server, not a router, to take a feed of the update stream, decode it into an up-to-date copy of the database, and then respond to queries from the ITRCs. A feature of both Fig 1 and Fig 2 is that there are a large number of ITRCs. The difference is the location of the IRTD is which packets go to which are not mapped by the ITRCs, because the ITRC hasn't yet made a query or received a response yet. If an internal IRTD gets a feed of database updates, a local query server or network of query servers could handle queries from local ITRCs. A smaller network which doesn't want to have either an ITRD (expensive, because of its huge RAM and massive FIB capabilities) or a query server receiving the full database updates, will need to rely on some external system to answer the queries of its ITRCs. Ideally, there would be a way that every ITRC could automatically discover: 1 - Two or more addresses to which mapping queries should be sent. 2 - How to handle packets for which it has not yet cached any mapping information. For instance, what IP address to tunnel them to so they reach an ITRD, or some other way of handling them. The ITRC would need to be able to discover how these change after boot time too, so perhaps the information could come with a caching time. ITR function in hosts --------------------- In other messages I refer to this as: ITFH Ingress Tunnel Function in Host This function is not really a router, since the host still only has one interface. It is just a function which encapsulates packets so they are forwarded to the ETR. To reduce the load on the edge networks ITRC routers, it would be desirable for some, many or ideally all hosts to perform their own ITRC function. This is not such an onerous task, unless the host is a server with a massive number of destination addresses for its packets in recent minutes. The ITRC could be added to the operating system, especially if there was an IETF standard way it could find where to send queries and what to do with packets it hasn't yet got mapping for. This is not at all essential for Ivip (or LISP) to work - but it would remove the load on the edge network's ITRCs and ensure that packets travelled on the completely optimal path towards the ETR. ITRCs in the edge network cost money because they are routers, with CPU, RAM and FIB resources devoted to Ivip mapping. An ITFH function in host operating software, or even in some of the application software, would cost nothing and would be the fastest and most efficient approach. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 02 10:33:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Mxz-0002Nk-4F; Mon, 02 Jul 2007 10:33:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Mxx-0002Ha-1T for ram@iab.org; Mon, 02 Jul 2007 10:33:25 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Mwj-0006TZ-8l for ram@iab.org; Mon, 02 Jul 2007 10:33:25 -0400 Received: from [10.0.0.9] (dell.firstpr.com.au [10.0.0.9]) by gair.firstpr.com.au (Postfix) with ESMTP id 9447259DA1; Tue, 3 Jul 2007 00:32:07 +1000 (EST) Message-ID: <46890D2F.8010903@firstpr.com.au> Date: Tue, 03 Jul 2007 00:35:27 +1000 From: Robin Whittle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 Subject: [RAM] 2 ETR strategies, including in the host X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here are some thoughts on the various ways the ETR function can be implemented. I am thinking about Ivip but probably a lot of this would work for LISP too. ETRs in general don't need to be linked to the Ivip system itself (ITRs, the central database, however users control the central database and however ITRs keep up with the central database), so they are freewheeling devices - or simply functions, such as an ETR function in a host. I will give these strategies or scenarios names so I can refer to and compare them. In keeping with the diagrams in my previous message regarding ITRs, I generally assume the sending host is on the left, in some other edge network, and that the host with the Ivip-mapped address is on the right. If the hosts on the left have Ivip-mapped addresses, then there would be a similar process occurring for packets going in the return path, but using ITRs in or near the right edge network and ETRs within the left edge network. IR Ordinary internal router. BR Border router - connects to the global BGP system. ETR Egress Tunnel Router H Hosts with ordinary BGP-routable IP addresses, either PI or PA. For instance desktop machines and servers. IH Hosts with one or more IP addresses which are mapped by the LISP/Ivip system. These could be routers too. ETR-internal ------------ ............................. . Internet . Edge network . \ . H IH H \ . / / / \ . / / / ------BR-----IR---IR--IH . \ / \ / . \/ \ / . IR---ETR1---IH . \ . \ . IH .............................. There are one or more ETRs inside the edge network. Hosts with Ivip-mapped addresses may be connected directly or via other internal routers. The ETR function is probably performed in a router, but in principle it could also be done in a server which has a single connection to the local network. These could be very cheap - just a PC motherboard with a Core2 Duo CPU or its AMD equivalent, running Linux, BSD etc. and some suitable ETR software, using the gigabit Ethernet interface(s) on the motherboard. ETRs in general, probably need to be administered so that when they decapsulate a packet, they check the destination address of the resulting packet is within a list (list of IP addresses and prefixes) prepared by the administrators of Ivip-mapped addresses of hosts in the local network. Otherwise, the ETR can be a cause of annoyance, security risks etc. Administering all the ETRs in an edge network in this manner would be a significant chore and a likely cause of trouble. Any automatic discovery system by which hosts could find ETRs, or some edge network management system, by which they could tell the local system of their Ivip-mapped address(es), would need to be secure. Probably each host needs a username and password so it can log into the network management system and tell the system the one or more IP addresses it has via Ivip. Then the system would tell the host one or more IP addresses of ETRs to use, with a "lease time" or some other mechanism by which the local network can tell these hosts that an ETR is down, or that they should use another one. Then the ETRs would be to forward decapsulated packets which have the destination address(es) which the host registers. However, only in the case of a singlehomed scenario should the edge network's local routing system forward packets by their Ivip-mapped address (I mean the original IP address by which the host is reached worldwide) to the host. In this case the ETR and host (or link to the remote host, client site router etc.) need not be directly connected, if the local routing system routes all "raw" packets to the host. In a multihomed or mobile situation, the routing system must never attempt to route raw packets to the host, destination router etc. I explain this below in the section "Multihoming and Mobile Maxim regarding ITRs". So in multihoming scenarios, the ETR must be directly connected to the host or the link to the host, customer site router etc. In mobile scenarios, the ETR function is performed by a TTR which has a two-way tunnel to the mobile host at its care-of address, so there is no need for the edge network's routing system to be aware of the mobile host's Ivip-mapped IP address. Back to the question of how an ETR or a management system for an ETR or an ETR management system in the edge network can know whether it is reasonable or not when a host requests that ETRs decapsulate packets to the Ivip-mapped address the host tell it. It wouldn't help to require the ETR or the local system to ensure that these addresses were currently mapped in the Ivip system to be tunneled to this ETR, or any other - because maybe the host already has a link and a working ETR on ISP-A and this is ISP-B, with which it is setting up a link and an ETR, so it can switch over to this one if the ISP-A arrangement fails. It is not feasible to have the ETRs ensure that encapsulated packets arrive from "ITRs", because there could be hundreds of thousands of ITRs in the Internet. Furthermore, it is likely and desirable that many hosts will act as their own ITRs (ITFH), sending encapsulated packets directly to the ETR address. Having one or more internal ETRs takes the load off the border router, which may be the conceptually neatest place to decapsulate packets. However, except for a multihoming situation, there needs to be a way that each ETR can get packets directly to the destination host, without relying on general support from the routing system. Maybe the ETR can be made to send the packets with some kind of explicit routing arrangement, which won't cause other packets with these raw Ivip-mapped addresses to be sent along the same path. If there are hosts in this edge network doing their own ITFH (Ingress Tunnel Function in the Host) function, that function is unlikely to be smart enough to realise when the destination host is actually in this edge network, so the packets could ideally be sent without encapsulation. To be this smart, the ITFH would need to be kept up to date with all the Ivip-mapped IP addresses in the local network, which is unrealistic and also arguably a leak of information about those other hosts. Such knowledge, to save encapsulation and to rely on a suitably configured edge network routing system, would only be valid in a singlehomed scenario. So the ITFH function should always encapsulate the packets and let them be forwarded to the nearest ITR. Only the ITR really knows which ETR the packets should be tunneled to. Let's say an end-user has a host or a router with one or a bunch of IP addresses, multihomed by two ISPs ISP-A and ISP-B. In both networks, the ETR needs to be ready to send decapsulated packets to the link which leads to the user's site. Normally, one might think, this would be done by the ETR being somewhere in the edge network and the edge network's routing system forwarding the packets appropriately. That would be OK for a singlehomed situation, where if the destination with the Ivip-mapped address(es) goes down, the host isn't any other way that destination could be reached. It is not OK for multihoming. Let's say the end-user is currently using ISP-A. ISP-B's network has already been set up to forward packets to the link to the customer, from ISP-B's ETR (or multiple ETRs) and from any hosts in ISP-B's network. So far, everything is fine provided the end-user's host or router accepts incoming packets on both links at once. But what if the link to ISP-A fails? Some automatic system outside these edge networks would detect this and switch the Ivip-mapping to ISP-B's ETR. After the switchover, what about packets to the Ivip-mapped address which were generated by hosts in the edge network of ISP-A? They would be forwarded to the dead link. The only way I can see of resolving this is what I will call the Multihoming and Mobile Maxim regarding ITRs ------------------------------------------- Except in single-homed settings (where any change to another ISP's ETR will be slow and accompanied by change in the old ISP's internal routing system) all packets addressed to Ivip-mapped addresses - except those exiting an ETR to be sent directly to the destination host or router - MUST pass through an ITR: ITRD, ITRC or ITFH. from which it follows that: In all but a single-homed situation, the ISP's internal routing system MUST NOT try to forward packets addressed to the Ivip-mapped address directly to the host, because the link to the host may be dead, and the ITRs will soon know how to tunnel the packet to an ETR with a good link. Only the ITRs have the up-to-date knowledge of which ETR and therefore which link to use in a multihoming situation. It may well be that the ITR is also the ETR, in which case the packet would not need to be encapsulated, but could simply be forwarded to the destination host or router. But it this should be done only when the Ivip-mapping says that this same router is currently the ETR. Assuming a multihoming scenario, this situation of encapsulated packets being generated in the same edge network, either by nearby ITRs or directly in the sending hosts with ITFH, is a good argument for there being multiple ETRs all over the edge network, and the host choosing one which it is close to. If the edge network only has one ETR, far away from the host, then packets tunneled from ITFH hosts and ITRs near the host would have to traverse the edge network to get to the ETR. So except for singlehoming (where there could easily be multiple ETRs in the edge network with the edge network's local routing system forwarding encapsulated packets to the destination host), the local routing system must not attempt special treatment of packets which are addressed to Ivip-mapped addresses which the local network is configured to support - because maybe the link to the host is dead and the packets need to be tunneled to an ETR in another edge network. Back to the characteristics of ETR-internal: Host requirements: The host has only (or at least needs only) its Ivip-mapped address. There is no need for any special software. (The host could perform its own ITR functions, but that is a separate issue.) Local routing system: Unless the edge network administrators know for sure the host or the link to the remote host, router etc. is single homed, the edge network must not attempt to route packets directly to that host. It should always treat them like the rest of the packets addressed to Ivip-mapped master-subnets: forward them to the nearest ITR (ITRC or ITRD). Only the ITRs really know what to do with the packet. It is probably easier to forget the idea of local routing system support for the Ivip-mapped addresses of even singlehomed hosts or links to customer sites. How is the edge network to know the customer doesn't have another link? Creating two classes of host would be a pain, and anyway the local routing system already has its hands full, without catering to a large and perhaps rapidly changing set of addresses and small subnets which are used by Ivip-mapped hosts. The local routing system, or at least the border router, does need to recognise packets sent from the host using its Ivip-mapped address, and allow them to be forwarded internally, or to the BGP system, in either case to the nearest ITR if the destination address is within an Ivip-mapped master-subnet. ETR - host relationship: Assuming no special exceptions are to be made for singlehomed hosts or links to customer sites, the ETR needs a direct way of sending packets to the destination host. Therefore, the ETR should be close to the destination host. If there are alternative ETRs so the mapping can be changed to select a different ETR if the first one fails, then both ETRs need a direct way of getting packets to the destination host. ETR-border ---------- ............................. . Internet . Edge network . \ . H IH H \ . / / / \ . / / / -----ETR1----IR---IR--IH . \ / \ / . \/ \ / . IR---IR-----IH . \ . \ . IH .............................. This differs from ETR-internal in the following ways: The border router has yet another pile or work to do - this is probably only acceptable for smaller networks where the border router is not so busy. Unless the destination host is directly connected to the ETR border router, then the ETR-border router needs some robust, independent, way of sending packets to the host. It cannot rely on the local routing system, because as described above, the local routing system must forward all packets addressed to any Ivip-mapped address to the nearest ITR. If the edge network has a single ITR function and a single ETR function, both integrated in the border router, then this simplifies the whole system. ETR-host -------- ............................. . Internet . Edge network . \ . H *IH H \ . / / / \ . / / / ------BR-----IR---IR--*IH . \ / \ / . \/ \ / . IR---IR-----*IH . \ . \ * = Host OS . *IH ETR function .............................. Assuming Ivip or similar becomes widely deployed, it may make sense to add a little piece of IETF-standardised ETR functionality to host operating systems. This would decapsulate packets and drop all packets which were not for the one or more of this host's Ivip-mapped addresses. So this is not to be an ETR for any host but the host it runs on. This in some ways resembles mobile-IP because the host needs a care-of address, which is a public, BGP routed, address (not behind NAT - though mobile-IP can work with the host behind NAT), to which the ITRs tunnel the packets. ETR-internal and ETR-border do not require the destination host to be changed in any way. The destination host only has its own (Ivip-mapped) IP address(es). This has a number of advantages: 1 - Less - or no - need for ETRs in the edge network. 2 - No extra packet handling or longer paths to go via the ETR. 3 - No need for one or more ETRs to have pipes, tunnels or whatever to traverse the local network to get packets to the destination host. 4 - CPU power and OS functionality in the host is free, which is not the case in routers! (However, an ETR could be built with a standard Linux box with suitable software, for very low cost.) As with ETR-internal, unless there is some other arrangement, the edge network's routing system does need to allow packets out of the host, with the source address being the Ivip-mapped address, to be forwarded to: 1 - A host in the edge network. 2 - An ITR if the destination address is Ivip-mapped - which would be covered by the next point if there is no ITR in the edge network. 3 - Out through the border router into the BGP system. "Some other arrangement" could mean a one way tunnel from the host to some router somewhere else (that is, to a TTR - Translating Tunnel Router, as I mentioned in messages starting on 17 June) which would decapsulate the packets tunneled from the host, be happy with this sending address and so forward them to wherever they needed to go. That would resemble an Ivip-mobile arrangement in some ways. Normal Ivip-mobile: Mobile host, with care-off address, perhaps behind NAT, creates 2-way tunnel to TTR. Sending host --------->----ITR~~~~~~~~TTR===<===>==IH / <------/ By the way, even if the mobile node was on an Ivip-mapped address, or behind a NAT which uses an Ivip-mapped address, it can still make a tunnel to any TTR it chooses, and have its own Ivip-mapped IP address via the ITRs beaming packets to whichever TTR it, or some central monitoring system, chooses. ETR-host with second tunnel to another router for outgoing traffic - the second router is probably outside the edge network the host has its care-of address in. * = ETR function in host. Host also care-of address, but can't be behind NAT. Sending host --------->----ITR~~~~~~~~~~~~~~~~>~~~~*IH / <----"2nd router"~~~~~<~~~~~/ Host creates one-way tunnel to 2nd router, probably outside the edge network, so it can get its packets out without having permission from the edge network. This is good for simplicity but bad for efficiency if the destination address is within the same edge network. In both cases, there is no need for support from the local network. The second router needs to be prepared to forward packets to the Net with the source address which is an Ivip-mapped address. ETR-host only works if the host has a normal, globally reachable, BGP-routed IP address. It won't work if the host is behind NAT. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 02 10:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5N0P-00024H-Jk; Mon, 02 Jul 2007 10:35:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5N0O-00021N-U0 for ram@iab.org; Mon, 02 Jul 2007 10:35:57 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5MzZ-0007PH-W8 for ram@iab.org; Mon, 02 Jul 2007 10:35:56 -0400 Received: from [10.0.0.9] (dell.firstpr.com.au [10.0.0.9]) by gair.firstpr.com.au (Postfix) with ESMTP id 6491759DA1; Tue, 3 Jul 2007 00:35:04 +1000 (EST) Message-ID: <46890DE0.4090406@firstpr.com.au> Date: Tue, 03 Jul 2007 00:38:24 +1000 From: Robin Whittle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Subject: [RAM] 3 Database - ITR update rates, mobility etc. X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here are some thoughts about user requirements for how quickly and how often the mapping of an IP address or prefix will be, and some technical and administrative approaches to achieving this. I will write about my Ivip ideas, but much of this probably applies to LISP too. I can think of these broad purposes for which Ivip is used to map individual IP addresses or prefixes. 1 - Portability of single IP addresses (singlehomed) For end-users with a single link to an ISP or a single host which physically resides in the ISP's building, I think that portability of a single IP address shouldn't be a strong requirement, because any host or user network which depends on only one IP address should be easy to configure to another address when they use a different ISP. There is no need to worry about continuity of communications etc. It is just a matter of having one stable PA address or another and updating a zone file in a nameserver somewhere. I suppose if they ran a hundred websites from that IP address, there would be a hundred zone files to change. However, maybe there is a company with a thousand branch offices. Each one has a single IP address. The company wants them to be portable IP addresses because it would be costly and disruptive reconfiguring all the routers for different IP addresses in other sites every time one of them changed to another ISP. Overall, I don't think this is an important goal of Ivip, except perhaps to support the branch-office scenario. Promptness: Within a few minutes would probably be fine. Frequency: Very low - once every year or two. Activation: Manual. Traffic: Potentially high - a single IP address could be for a whole home or office LAN behind NAT. 2 - Portability of a prefix (singlehomed) There is more justification for portability with a prefix or a larger number of IP addresses (not necessarily on binary boundaries) because the user may face considerable cost and risk of disruption having to renumber routers and hosts when they move to a new ISP. I think this should be an important goal. Promptness: Within a few minutes would probably be fine. Frequency: Very low - once every year or two. Activation: Manual. Traffic: Potentially very high. Could be an entire university, hospital, corporation etc. or at least part of their total system, if there are multiple sites, each with their own subnet of Ivip-mapped addresses. 3 - Multihoming of a single IP address or prefix This goal implies portability, but requires rapid responses, ideally within a few seconds. The shorter the better, but many networks can probably cope if there is a minute or two of down time in the rare (say every 6 months to a year) times when a link or some equipment fails and they need to switch the mapping to point to a second ETR in another ISP. I think this is the most important goal. If we can achieve this reliably, then it will remove most of the pressure for tens to hundreds of thousands (ultimately millions) of businesses and other organisations to get an ASN, PI space, a multihomed BGP router, expertise etc. for the sole purpose of achieving multihoming so their network is always available and at the same addresses. Promptness: Ideally, a few seconds or within a minute. Frequency: Very low - once every year or two. Activation: Probably some separate system, distributed in multiple edge networks, or in some really solid site in the "core", which constantly monitors connectivity and is able to change the database the moment one link, ETR, ISP, fails. Traffic: Potentially very high. 4 - Mobility, ideally with continuity I am thinking of a device like a laptop or 3G cellphone which get either a singe IPv4 address or a complete IPv6 /64 and have a variety of links to the Net, in different edge networks, with periods of no connection and with periods of having two or more connections. For instance, a laptop could be plugged in with an Ethernet cable, including behind NAT, and this would be a link to the Net (via finding the nearest TTR) without any prior arrangement with the edge network. At the same time, it could be using 802.11 to do the same via multiple edge networks, though I guess one at a time. It would find another TTR, which is near to the mobile host's location in that edge network. Meanwhile, it could be using UMTS or GPRS to connect to a 2.5G/3G cellular network. All these links are likely to be via completely different edge networks, and in each case, the device needs to find a nearby TTR and make a two-way tunnel to it. Some central controller system orchestrates by telling the mobile host which TTR to tunnel to, and by telling the TTR to expect it. (These TTR systems do not need to be part of the Ivip system - they are just ETRs as far as Ivip is concerned.) The central control system for the particular commercial TTR network the mobile host is using will monitor connectivity through each of the currently active TTRs and controls the mapping of the Ivip-mapped address or prefix to one of the currently active TTRs. In principle, the same approach should also work when the mobile node has a connection to an edge network using the ETR-border, ETR-eternal or ETR-host scenarios, where the mobile host doesn't need a TTR, since the edge network supports its outgoing packets. The TTRs may or may not be in the edge network with which the mobile node has gained a temporary care-of address. If they are not in the edge network, then the end-user will need to pay for access to them. There is no need for TTRs or commercial global systems of TTRs to be coordinated with the Ivip system. So there can be competing commercial TTR systems, with secure access to their TTRs. TTRs in an edge network could be open to all devices connected to that edge network, probably without any extra fee. Promptness: Ideally, fractions of a second or a few seconds. Smooth handover when leaving a 3G cell and switching to a home 802.11 link would be ideal. In practice, I doubt that any general purpose global, publicly run Ivip system is going to be so responsive for glitch-free handover to support VoIP to moving handheld devices. The best place to handle that sort of agility is in the mobile network itself. I am not suggesting that every time some all singing all dancing cellphone, MP3 player, laptop, games machine (whatever) works best from WiFi and then from 3G and then from WiFi again that the Ivip database and all the world's ITRDs need to know about it ASAP ~unless~ the mobile user wants to pay for every such change! Maybe there could be multiple competing commercial networks of ITRs and TTRs which are optimised for this very fast switching. They could also tunnel traffic to ordinary ETRs, and not all the TTRs they use need to be owned by the same operator. Assuming there was a consistent technical standard for TTRs, the commercial system could use its own TTRs or TTRs in edge networks. When the mobile node loses all its links, which will be a frequent occurrence, the system needs to be able get packets to a newly chosen TTR within a few seconds, and ideally, the newly connected mobile node needs to be able to contact a central control system within a few seconds and set up a tunnel to a TTR within a few seconds. Ideally, 5 to 10 seconds after gaining any kind of care-of IP address, IPv4 or IPv6, the mobile node should be fully connected via a nearby TTR. Frequency: Potentially very frequent. The end-user must pay per change. Activation: Probably some separate system, distributed in multiple edge networks, or in some really solid site in the "core", which constantly monitors connectivity and is able to change the database the moment one link, ETR, ISP etc. fails to cause the traffic to be tunneled to an alternative ETR. Traffic: Presumably lower than the above scenarios since highly mobile devices generally use 3G or 802.11 links and are not servers or sites full of servers. There is no difference for the ITR whether it is tunneling packets to an ETR, a TTR or a host which does its own ETR functions. So there's no reason regarding the ETR/TTR why a single Ivip system can't be used for all the above purposes at once. However, there are big differences in requirements for Promptness, Frequency and Traffic. All but the single-homing purposes ideally need a Promptness time of a few seconds or less. Since multihoming is the most important purpose, I think the Ivip system needs to be able to change its mapping in a few seconds, even when there is no anticipation that a change might be required. For instance, a multihomed site might work fine for months or years on a link to ISP-A and its ETR, but if that fails, the Ivip system should ideally respond within seconds - or at least within a minute or so. In principle, a push-ITR can respond very rapidly to database changes. Depending on the system of servers which replicates the stream of updates, I guess a few seconds may elapse between the command being made to the central database and all the ITRDs switching their tunnels to a new ETR. In message 5 I discuss cache-based ITRs, with pull and notify, rather than push. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 02 10:37:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5N1o-0003ah-BU; Mon, 02 Jul 2007 10:37:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5N1m-0003T5-HC for ram@iab.org; Mon, 02 Jul 2007 10:37:22 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5N1Z-0007xn-OC for ram@iab.org; Mon, 02 Jul 2007 10:37:22 -0400 Received: from [10.0.0.9] (dell.firstpr.com.au [10.0.0.9]) by gair.firstpr.com.au (Postfix) with ESMTP id 50AA459DA1; Tue, 3 Jul 2007 00:37:08 +1000 (EST) Message-ID: <46890E5C.5040409@firstpr.com.au> Date: Tue, 03 Jul 2007 00:40:28 +1000 From: Robin Whittle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Subject: [RAM] 4 User-interface and delegation tree for central database (LISP/Ivip) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here are some ideas about how a central database of mapping information might be controlled. This is different from keeping the authoritative data in multiple locations and having to work backwards to find the authoritative server, as in the DNS, and as described in draft-meyer-lisp-cons. Nonetheless, the authority to change the mapping for the IP addresses is delegated in a distributed fashion similar to the DNS. The initial action which leads to the database being changed is a user generated (manually or by the user's equipment or by a system authorised by the user) "Update Command". For authorising and feeding Update Commands to the central database, I think there needs to be some kind of tree-structured system similar to the DNS in the way that the authority is delegated. However, this tree structure involves data flowing back towards the root of the tree as well. The idea is that the single Ivip central database system would delegate control of one or more of its ranges of addresses to some other system, which in turn would delegate control to other systems. There would be no absolute limit on the depth of this. Ultimately, from the point of view of the end-user, there needs to be a username and password (or some crypto private key challenge response system) by which they manually (via a web interface), or some automated way, can control the mapping of their one or more Ivip-mapped addresses. The servers which handle the end-user interaction needs to be the leaves of this tree structure, so as not to burden the central database servers themselves with this messy stuff. This enables various companies to give different kinds of control for the Ivip-mapping of the IP addresses their branch of the tree controls. It would be especially important for multihoming that some reasonably trusted company could run an automated monitoring system, and have the credentials (username, password, key etc.) stored in their system so their system can change the mapping of one or more IP addresses the moment one link seems not to be working. Also, the company which controls a particular range of the Ivip-mapped space may offer such a multihoming monitoring system itself. Theoretically, the multihomed end-user's host or router could detect that the link to ISP-A was dead and send one or more packets out the ISP-B link to whatever server controlled the mapping of its IP address. However, this would probably be a one-way transition, because at that time, the Ivip-mapping for its IP address is pointing to the ETR in ISP-A. However, maybe the server which handles such packets could be smart enough to send a reply by encapsulating it to the ETR of ISP-B . . . Two way challenge response exchanges are typically required to stop replay attacks which would be possible with a single-packet command to do something as crucial as changing the Ivip-mapping of an IP address. Here is a rough diagram of a tree of servers, which could be physically separate servers, or could be implemented on the one machine. I assume, but don't show, that each such server is actually two or more servers, geographically distributed, like the DNS, so the whole system is robust. The tree in this example controls the address range 20.0.0.0 to 20.3.255.255. This is what I would call a "master-subnet", because it is a prefix of address space which is advertised in BGP and controlled by the Ivip system, so all ITRs advertise this prefix. Over time, it may be joined by other prefixes, such as 20.4.0.0 to 20.7.255.255, and so it may be advertised as part of a larger subnet (shorter prefix). Maybe that second range would be controlled by the same company and so be part of this tree of authority, or maybe it would be controlled by another company, with its own tree of delegation. Let's say company X has authority (direct from the Ivip system, perhaps because it assigned this space which it got from an RIR to the Ivip system) over the entire range 20.0.0.0 to 20.3.255.255. It sublets to Y a quarter of this: 20.1.0.0 to 20.1.255.255. I am making these examples on binary boundaries, but there is no reason why the divisions should be like this. It would be just as possible for X to delegate to Y an arbitrary subset of the whole range, or the entire range, or just one IP address. X's Update Authorisation Server (UAS) has a private key for signing all the update messages it sends to the central database system. That central system trusts any message with such a signature. However the central database system neither knows nor cares about company Y or Z. All it knows about is the various instances like X, each an organisation with a public key for authenticating update messages, for a given subset of the total Ivip-mapped address space. This could be any arbitrary subset, but for simplicity I will assume that X only has authority over this one subnet 20.0.0.0 to 20.3.255.255. Let's say Y delegates control of some of its space to company Z, and that Z has an end-user U, who needs to control the mapping of one or more IP addresses in Z's range. Z has various interfaces by which U can do this, with its own arrangements for authentication, for monitoring a multihoming system and making changes automatically etc. Hopefully there would be one or more automated, host-to-server, IETF-standardised protocols so all end users could have standardised software for talking to whichever company's servers they use to control the mapping of their IP address(es). User-R User-S User-T User-U Multihoming \ \ | | Monitoring \ \ | | Inc. \ ................. / \----. Web interface .---/ . other protocols . . etc. . ....UAS-Z........ | Other companies | like Y and Z | /-----<----/ | | \ | / | | \|/ | | UAS-Y \ | | \ | /----<-----/ \ | / \|/ UAS-X | | V | | | Tree-structured system of delegated | authority and servers which at its | leaves, have the facilities for end-users | to securely control the Ivip-mapping of | their one, few or many IP addresses. \ \ \ \ | | | / \ | | | / \ | | | / \ | | | | | | | | | V V V V V ............... . . . CDSB1---------CDSB2 . Distributed, . \ / . redundant, . \ / . central . \ / . database. . \ / . . \ / . . CDSB3 . . . ............... | | | | | | | Generates periodic | | | | | | | complete database / | | | | | \ files and a stream / / | | | \ \ of second-by-second / / / | | \ \ updates. Let's say User-U wants to change the mapping of their IP address via a web interface. User-U does this via Z's website, authenticating him-, her- or it-self, by whatever means Z requires, and and gives the command to map to a new IP address (typically the address of another ETR). This causes UAS-Z to sign an update command message (according to some future IETF standard, of course) and to send it to UAS-Y. In fact there would be two or more UAS-Zs and likewise two or more UAS-Ys. I guess they use TCP and ensure they get a response from whichever UAS they are sending the signed command to. UAS-Y trusts this update command because of Z's signature. It strips off the signature and adds its own. UAS-X plays the same game and within a fraction of a second, the central database system receives the update command. Authority is delegated up the tree, because UAS-Y will only accept update commands if they are signed by one of its branch UASes, and for the particular address range that UAS has been authorised to control. User-U may have given their username and password etc. to Multihoming Monitoring Inc. so this company can monitor their multihoming links and change the mapping as soon as one link goes down. UAS-Z doesn't know or care who actually makes the change - as long as they can authenticate themselves for whatever address or addresses they want to change the mapping of. There is no need for PKI in any of this, I think. I think there really needs to be a central database system and some kind of distributed input system like this. Without a centralised control system (for instance the distributed CARs in draft-meyer-lisp-cons) there is no way of producing a unified stream of second-by-second updates, or a snapshot of the database for a freshly booted ITRD to load. I am convinced that a pure "pull" system such as draft-meyer-lisp-cons will be too slow to respond. (draft-meyer-lisp-cons has "push" elements, but that is not pushing data towards ITRs, just information about where the authoritative CAR can be found.) I guess it may be possible for there to be multiple separate "central database" systems, each with their own trees of delegated update input control. Each such separate system could cover a subset of the entire Ivip-mapped space. Then each ITRD would need to get update streams from all these systems. Alternatively, there needn't be a single ITRD which handles every Ivip mapped IP address. This could be an important scaling consideration, reducing the amount of RAM and FIB capacity in each ITRD, and performing the entire ITRD function with several routers (or just plain servers with a gigabit Ethernet link to a router) each handling a subset of the total range of Ivip-mapped address space. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 02 10:39:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5N3Y-0004hO-HT; Mon, 02 Jul 2007 10:39:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5N3X-0004hJ-FR for ram@iab.org; Mon, 02 Jul 2007 10:39:11 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5N3P-0000VF-Cl for ram@iab.org; Mon, 02 Jul 2007 10:39:11 -0400 Received: from [10.0.0.9] (dell.firstpr.com.au [10.0.0.9]) by gair.firstpr.com.au (Postfix) with ESMTP id D7AFD59E44; Tue, 3 Jul 2007 00:39:01 +1000 (EST) Message-ID: <46890ECE.2030309@firstpr.com.au> Date: Tue, 03 Jul 2007 00:42:22 +1000 From: Robin Whittle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 713965ef965c5660ee5d9a664a73ef4a Subject: [RAM] 5 Database <--> ITR push, pull and notify X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here are some thoughts on how three classes of ITR function might best get up-to-date information about the contents of the central database. Also some thoughts on the very simple nature of the Ivip mapping database and how it could be compactly conveyed. The first two types of ITR function are performed in routers, or a PC running special software to do the encapsulation, but connected as a stub to a BGP router and behaving as BGP router, and anycast advertising the Ivip-mapped master-subnets. ITRD Gets the full Database in real-time via push. ITRC Queries database by some means and Caches results. It would also receive notifications. The third is not really a router, but we think of it as being like an ITR: ITFH Encapsulating Tunneling Function in a Host. It behaves like an ITRC, but only for the packets the host is sending. I envisage some kind of redundant, multi-server, database which holds the entire mapping data, which is subject to updates from various sources, which I discuss in the previous message. I will depict this as three actual Central Database Servers CDBS1, CDBS2 and CDBS3. I know virtually nothing about databases, but lets say these servers compare notes and keep themselves up to date, with the entire system still able to take updates and feed out a stream of change data to the ITRs, even if one or two of these servers are dead. In practice, there would be an expandable number of these servers, in different locations. I envisage this central system would periodically generate a complete file of its contents, and then ever second or so spit out one or more packets containing all the changes to that data. How to get that information to the ITRs is a major challenge. As I wrote in the previous message: I guess it may be possible for there to be multiple separate "central database" systems, each with their own trees of delegated update input control. Each such separate system could cover a subset of the entire Ivip-mapped space. Then each ITRD would need to get update streams from all these systems. Alternatively, there needn't be a single ITRD which handles every Ivip mapped IP address. This could be an important scaling consideration, reducing the amount of RAM and FIB capacity in each ITRD, and performing the entire ITRD function with several routers (or just plain servers with a gigabit Ethernet link to a router) each handling a subset of the total range of Ivip-mapped address space. For now, I will assume that each ITRD needs to get a single update stream from a single central Ivip database, and that it handles all Ivip-mapped addresses. The great thing about an ITRD is that its FIB is updated instantly it receives the updates, so the router is always tunneling packets to the correct IP address (of an ETR, TTR or ETR-host). This means it can be used as a "final line of defense" to catch packets addressed to Ivip-mapped address space which an ITRC or ITFH lets through (or tunnels explicitly to this ITRC) because it doesn't yet have the mapping information for that packet's Ivip-mapped destination address. (See message 1 today.) As the number of Ivip-mapped addresses and prefixes grows, and as the update rate grows, the burden on an ITRD becomes more and more intense, irrespective of the actual number of packets flowing through it. However, the major router manufacturers will surely be able to make such devices, for a suitable price. I wonder about making a DIY ITRD with software on a suitably gutsy server. The idea would be to be able to provide full handling of a limited data-rate stream of packets, with ITRCs and ITRHs handling most of the load, but to do it without using a router. Classifying, encapsulating and sending packets in software will be pretty slow compared to a router's FIB, but it would be easy to create such servers for very little cost. A dual or quad CPU chip running in 64 bit mode, with 8 gigs of RAM and one or two gigabit Ethernet interfaces on the motherboard, boot from a USB stick. Total cost: well under USD$1k. There's not even a hard disc required. To match the traffic to the capacity of these DIY ITRDs, there could be at least two strategies, both potentially used at the same time. 1 - Split the entire Ivip-mapped address space over several DIY ITRDs. 2 - Plant more of them around the edge network, so each one gets less packets. This approach of having an ITRD work with only a subset of the Ivip-mapped address space is likely to be a crucial scaling technique in the future. Therefore, there needs to be some way that the stream of updates, and the periodic database copies, can similarly be split. For now, I won't consider this. I will assume every ITRD handles the full range of Ivip-mapped addresses. I see three major tasks which need to be performed so the ITRDs, ITRCs and ITFHs get what they need. Since ITFHs are caching ("pull") ITRs like ITRCs, their needs are similar. They don't get a continual stream of updates - they need a fast response to their queries. I also propose a system of notifications, to instantly push updated mapping information to those ITRCs and ITFHs which need it. Distributing the update stream to ITRDs --------------------------------------- The most obvious way to do this is have the central database put out N streams of updates, one to each of N replicators. Each replicator sends the same stream to further replicators etc. Eventually, each ITRD gets a stream from one replicator. This could all work pretty quickly, with maybe a few seconds elapsing between the end-user changing their mapping and the ITRDs all over the world changing their FIB to tunnel packets to the new address. This pure tree-structured system suffers from single-point of failure problems and, if TCP is used, will frequently get stuck for a moment when a packet goes missing. I am trying to imagine a more diffuse system, which has some tolerance for lost packets, but still delivers most of the updates on time, and copes with those in lost packets either by getting the same packet via another source, or by having some (admitted rather painful sounding) system where a replicator can ask its some distant replicator for a missing packet. Exactly how the updates would be compressed and packed, or coded in a way which is suitable for splitting to multiple ITRDs with different subsets of the Ivip-mapped address space, I haven't considered. I don't know much about Google's internal operations, but I like their idea of throwing lots of cheap PCs at the problem and making the system work reliably at a very high speed by sending out more requests and generally getting more answers than is required for success. Lets say the first level of replicators take the stream from the central database (the three or more servers which act as a team and somehow generate one or more streams, all the same). The streams probably need to be protected by occasional hashes, signatures or whatever so each replicator can detect it if is being fed something crooked by an impostor. Then each of the second level of replicators gets streams from at least two of the first level. However, each replicator can receive one stream and put out, say, 16 streams. Somehow, these replicators form a meshed, downward packet-sending "fanning out net across the Net", structure where they send their streams to ITRDs. Maybe each ITRD gets two streams from two replicators, via two links, so it is still in business if one link or replicator fails. Tree-structured system of delegated authority and servers which at its leaves, have the facilities for end-users to securely control the Ivip-mapping of their one, few or many IP addresses. \ | | | / \ | | | / \ | | | / \ | | | | | | | | | V V V V V ............... . . . CDSB1---------CDSB2 . Distributed, . \ / . redundant, . \ / . central . \ / . database. . \ / . . \ / . . CDSB3 . . . ............... | | | | | | | Generates periodic | | | | | | | complete database / | | | | | \ files and a stream / / | | | \ \ of second-by-second / / / | | \ \ updates. V | Replicator (Level 1) |||||||||| / |||||||| \ / / |||||| \ \ / / / |||| \ \ \ / / / / || \ \ \ \ From another / / / / / | \ \ \ \ Level 1 V Replicator | / | / | / | / | / | /------<-------/ | / | / |/ Replicator (Level 2) |||||||||| / |||||||| \ / / |||||| \ \ / / / |||| \ \ \ / / / / || \ \ \ \ / / / / / | \ \ \ \ etc. etc. etc. Two or more streams from different replicators perhaps at different levels. | / | / |/ ITRD The ITRD could itself be a replicator - but I think it is best to leave its CPU and links to routing, and let some cheap servers be the replicators. This diagram is for the continual update streams. Once an ITRD has a complete copy of the database, the streams will keep it totally up to date. But how does it get that way? It would be possible to distribute by the same system a separate Hourly Database Dump stream, in parallel with the real-time update stream. The Hourly Database Dump could be ignored by (and not sent by a replicator to) those ITRs which didn't want it. Lets say the dump only took 20 minutes to send. Exactly how big the Ivip database is going to be, I am not sure. But there are ways of splitting the whole Ivip system into parallel systems which are within scaling limits, such as by having a cluster of ITRDs in one site which each handle a subset of the whole address space. I anticipate the database contents would be very simple. For IPv4, each IP address or prefix or whatever with a single ETR address will be described by: 32 bits: Start address. 16 bits: Span. 0 means a single IP address. 32 bits: Address to tunnel packets to. (We could use more than 16 bits for the span, but very few swaths of Ivip address space with the same mapping will be more than 65,636 long. So it is better to keep the data compact and specify any such long contiguous spans, including areas which are not mapped to anything (0) with a few repetitions of the above with a span = 65,535.) These would probably compress pretty well too, since the span will generally contain 38, 30 and often 32 zeros in a row. ** There may also need to be a caching time with this data, so ** that when a query is made to a QSD (defined below) which has ** its own copy of the database, that the response contains a ** "time to cache". When sending the whole database, all that is needed for each master-subnet is the starting address and then repetitions of, for instance: 8 bits: Span 0 means one IP address 255 means 256 addresses. 32 bits: Address to tunnel packets to. (0x0000 means not mapped - drop the packet. 0xFFFF means end of this master subnet.) ** Also maybe a caching time. The whole database could then be specified in segments, one for each non-contiguous range (a "master-subnet"). For instance, there is a 32 bit number to specify the start, then a sequence of 8+32 bits like this. When there are more than 256 addresses to be mapped to the same address, simply use multiple such sequences. There won't be many of those compared to the large number of single IP addresses and smaller ranges. Note there is no requirement here for binary boundaries, aggregation etc. A worst-case scenario is to map N IPv4 addresses, completely independently, would be 5*N bytes. (For IPv6, with Ivip working to a /64 granularity, it would be 8 bits plus 64, so 9 bytes.) So when the Ivip system handles a billion IPv4 addresses, it takes 5 gigabytes at worst case, probably 2 or so gigabytes, after compression and allowing for some of the space being mapped as prefixes (or any arrangement of contiguous addresses with the same ETR address). Allowing for inefficiencies, over a 1 Gbps link with 100Mbps devoted to receiving or sending the database dump, this would take (3 Gigabytes) about five minutes. So lets make it the "Ten minute database dump"! Lets say every ten minutes, the central system sends to the replicators this dump, in parallel with real-time updates. Then when an ITRD boots up, it waits for the start of the dump, stores the whole thing as it comes in, while storing real time updates. When the whole dump arrives, it decodes it into RAM, applies the realtime updates so far received, and keeps on updating the data in RAM from then on. From that moment on, it can start crunching the data into whatever form drives its FIB. Maybe, this periodic dump system would be a good enough way of coping with occasional lost packets in the real-time updates. But then, we would need a more solid arrangement so the periodic dumps are not corrupted or slowed much by lost packets. Replicators and missing packets ------------------------------- Lets say the one or more update streams have packets with sequential 64 bit numbering, so any replicator which receives it can easily tell which stream it belongs to, and at what point in that stream. Then these packets can be sent as UDP. With two separate feeds from two separate replicators, generally each replicator is going to get at least one copy of all the packets. But what about the rare occasion when it doesn't . . . This is a little tricky. Maybe the ITRDs can be made to cope gracefully, with some identifiable gap in their data, but not actually wrong information. Lets say there were gaps in the "10 minute database dump" with which the ITRD booted. It would carry on, simply dropping packets to that range of addresses it doesn't have any mapping information for. Ideally, this would be a small range of addresses, and maybe no-one is sending packets to that range through this ITR. The problem should be fixed with the next 10 minute database dumps. For gaps in subsequent 10 minute database dumps, the ITRD could quite reasonably keep the mapping it had from the previous cycle, since in principle, the 10 minute database dump is providing identical data to that which the ITRD had figured out for itself based on the last dump and ten minutes worth of updates. So maybe the odd missing packet is not such a lot of fuss in this system. Below, I will assume it can't be tolerated. A replicator C receives two or more streams from two other replicators A and B. If it doesn't get a particular packet (with a particular sequence number) from either A or B, there are several possible causes. One is that both A and B sent the packets but they were both lost in transit. In that case, the C could request from either A or B to resent this one, or multiple, packets. A single message could request quite a number of packets to be sent, and the A or B could dutifully send them all, several times with a few seconds between them, just to be sure. But maybe A or B didn't get the packets either. In that case, it would be best if a packet with a sequence number was always sent by A or B, but with a flag to say that the replicator sending this packet has not yet received its data - so "stay tuned" and there will be another such packet, with the same sequence number, but the correct data, sent ASAP. Maybe C needs to be able to talk to some rather distant replicators, which are not on the upstream path of A or B, to ask it to send the desired packets. If it sends out two such requests to two topologically different replicators, it will have a good chance of getting the right data. If no response comes in a second or two, it can always try again. A response may also come back: "This replicator doesn't yet have the packet in question but will send you a copy if and when it gets a copy." The rolling "10 minute database dump" system, the checks on the integrity of the data before it is used, the configuration of ITRs so they can't tunnel packets to certain ranges of addresses (for instance to protect critical infrastructure such as the DNS) may be enough to allow a low level of holes in the dump and update data. Another approach is to use Reed-Solomon Forward Error Correction and interleaving so that even with some lost packets, the data gets through, with an overhead of say 30 or 40% extra packets required. But I think these algorithms are probably really difficult to do on ordinary CPUs. Query Servers ------------- There could be an IETF protocol for querying a server about Ivip mapping for a particular IP address. (The ITRC and ITFH only requests how to encapsulate individual packets addressed to a single Ivip-mapped address, but maybe it would be good to extend the protocol to cover a range of addresses . . . I won't think about that now.) The client asks "What is the Ivip mapping for this IP address?" The server responds with either: 1 - I don't know but am finding out . . . and will respond with another packet soon. (Actually - this is probably not necessary in the scheme below.) 2 - This address is not within one of the master-subnets which the Ivip system covers. (Ideally, the ITRs should already know this, and the list of master-subnets will change, so each ITR needs to get it securely from somewhere.) 3 - This address is not mapped at present, so drop packets sent to this address, or to any address M to N inclusive. (Or M with a span.) Cache this information for S seconds. 4 - This address is mapped to address Z and so are all the addresses from M to N inclusive. (Or M with a span.) Cache this information for S seconds. There are two types of query servers: QSD Has a full copy of the Database, gained just like an ITRD does - from one or two or more streams of packets sent from replicators. This function could be implemented in a router which is an ITRD, or in a replicator, but I think it is better to have a dedicated server for this purpose. Again, the QSD server doesn't need a hard drive - just booting from a USB stick and doing its work in RAM. QSC Caching Query Server. Doesn't have a copy of the database, but has at least one link to either a QSD or a QSC which does link (through potentially multiple levels) to one or more QSDs. The QSC function could be implemented in a server or perhaps in a router which is performing the ITRC function. Each decent edge network would have one or two QSDs, probably each also being a little Replicator to feed data to its one or two ITRDs. These may be fairly low-volume ITRDs, implemented on cheap servers, because I plan that most traffic would be handled by proper routers, with hardware FIBs, which implement the ITRC function, for some level of traffic and number of concurrently mapped IP addresses or prefixes. (Unless the edge network was a web-server farm in which case it would make sense for all the servers to have their operating systems upgraded to perform ITFH, rather then rely on expensive routers to do the work.) The low-volume ITRDs are there to instantly tunnel the packets which the ITRCs and ITFHs don't yet know how to handle. They don't know how to encapsulate a packet when its destination address is within the Ivip-mapped range but which the ITRC or ITFH has no cached data about. Maybe it is just a one-off packet, so the ITRC or ITFH either lets it pass, and be forwarded to a low-volume ITRD, or alternatively the ITRC or ITFH explicitly tunnels the "novel" packets to the nearest ITRD. It is best not to launch a query for every novel packet, because that would allow an attacker with a scattergun set of short packets to tie up a lot of resources in the edge network. Meanwhile, the ITRC and ITFHs decide for themselves whether or not enough novel packets have an address it currently doesn't have the mapping information for. Whenever that decision is positive, an ITRC or an ITFH sends a request to one or more upstream QSDs or QSCs. Both the QSD and the QSC behave in the same way to queries and the idea is that the ITRC and ITFHs get a response, from a fresh (a few seconds old at most) copy of the database, within a fraction of a second. Two or more streams from different replicators perhaps at different levels. Internet | / | / ....................|/....................................... Replicator Edge network &QSD (Query Server with a local which is /|\ copy of the Database.) hip to Ivip / | \ / | \-----------\ / QSC QSC ITRD /|\ /|\ / | \ / | \ / | \ / | \ / | ITRC ITRC QSC \ / ITRC /| ITFH / / | ITFH / ITRC ITRC Notification of changed mapping ------------------------------- There is a fundamental problem with the mismatch of the needs of multihoming end-users with the idea of cached ITRs. A multihomed edge network might run like a charm from ISP-A and its ETR for months or years - but the moment something goes wrong, no-one wants the Ivip system to dawdle in changing the mapping. Meanwhile, no-one wants the ITRCs and ITFHs to get responses saying "cache this result for ten seconds" so they have to keep asking again and again, with the result never changing for months or years. Maybe the system could operate on a different basis from variable caching times. Maybe there could be a fixed caching time, to simplify things. I will explore a fixed caching time of 10 minutes (assuming a 10 minute full database dump cycle to all the QSDs), but there could be arguments for other times and for each response having a user-defined caching time. Let's say that if a client of a QSD or QSC (which means the client could be a QSC, an ITRC or an ITFH) makes a query about an IP address, it gets back a response of this set, which is a modification of the 1 to 4 above: 1 - (We don't need the response 1 above.) 2 - This address is not within one of the master-subnets which the Ivip system covers. (ITRs shouldn't ask this - they should already know.) 3 - This address is not mapped at present, so drop packets sent to this address, or to any address M to N inclusive. (Or M with a span.) (No cache time - the client is assumed to cache it for 10 minutes.) 4 - This address is mapped to address Z and so are all the addresses from M to N inclusive. (Or M with a span.) If this changes in the next ten minutes, you will get a notification. If you still want to know the mapping of this address in ten minutes time, ask again. Now, the chain of 0 or more QSCs and the final query server, the QSD, can retain a record, for a standard 10 minute period (should be easy to implement if the whole database dump cycle is 10 minutes) and if the QSD gets a real-time update of an address or prefix changing, it sends a message to that client, which passes it on to every client that needs it. Lets say an ITRC7 asks QSC5 about 20.0.10.34. (Exactly the same behavior applies for a host-based ITFH function.) Maybe QSC5 already has cached an answer about this, so it responds immediately. Alternatively, QSC5 asks its upstream query server QSC2 which then asks the QSD1, which knows the answer. The responses go back down to QSC2, QSC5 and then to ITRC7: This address is mapped to 33.55.66.77 So is the range 20.0.10.32 to 20.0.10.37 inclusive. There is an implicit 10 minute caching time for this information, after which each of these devices can forget the information unless there is some subsequent request. But lets say after 7 minutes, a change arrives which affects the validity of this response. Maybe the change doesn't affect the IP address for which the query was made. Still, a notification needs to be sent. For instance: The range 20.0.10.37 to 20.0.10.37 inclusive is now mapped to 33.55.88.99. Each QSC maintains a list of recent queries from its downstream QSCs, ITRCs and ITFHs (it doesn't need to know what they are) and it sends a Notification packet to them with the above updated information. This way, ITRCs and ITFHs don't need to keep bugging their QSCs, or at least not more than once every 10 minutes. However, within a few seconds, a change in the database filters through to every ITRD in the Net, and to all the caching ITRs which need it. There probably needs to be some small charge for these changes, because they do burden the entire Ivip system - the databases, the replicators, the ITRs (which are mainly run by and located within edge networks). That charge won't be a problem for multihoming end-users, but it would give physically mobile mobile-IP end-users some incentive not to chop and change too much, whilst being made to financially contribute to the Ivip system with these fees - which I guess would be charged back to the various companies which control the various master-prefixes. So maybe we can make the cashed up road-warrior Mobile IP folks pay for the whole Ivip system! The global network of ITRs beaming their packets to whatever TTR they choose is probably their dream come true. The mobile IP users still need to have their independent networks of TTRs, but they would have great mobility, access by any host, and generally highly optimal packet paths in both directions. They would literally be able to plug their laptop, phone, whatever these things are combined into and called at the time, into any old Ethernet socket with DHCP, or have its WiFi system connect to any open Access Point, and the host software and the centralised management system would automatically keep the device well connected, always on its own IP address, with highly optimal paths for most of the the packets - without any prior arrangement with edge networks. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 02 20:10:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Vyc-0005vb-19; Mon, 02 Jul 2007 20:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Vya-0005tR-AT for ram@iab.org; Mon, 02 Jul 2007 20:10:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5VyU-0000Ij-I7 for ram@iab.org; Mon, 02 Jul 2007 20:10:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2007 17:10:34 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEcwiUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,489,1175497200"; d="scan'208"; a="499562935:sNHT38966244" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l630AXkP012569; Mon, 2 Jul 2007 17:10:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l630AUvx023817; Tue, 3 Jul 2007 00:10:30 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, 2 Jul 2007 17:10:30 -0700 Received: from [192.168.0.5] ([10.21.113.235]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 17:10:30 -0700 In-Reply-To: <46860642.2080606@firstpr.com.au> References: <20070629175414.GA4939@1-4-5.net> <46860642.2080606@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11A5F613-2314-491F-8B76-C42977D18503@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Just posted: draft-meyer-lisp-cons-00.txt Date: Mon, 2 Jul 2007 17:10:28 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Jul 2007 00:10:30.0472 (UTC) FILETIME=[9112A480:01C7BD06] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9390; t=1183421433; x=1184285433; 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[RAM]=20Just=20posted=3A=20draft-meyer-lisp-cons-00.t xt |Sender:=20; bh=V9s/F/A+eTGkT3ce3Q4RFlnm7bAZxCJFAjjPq10lmJM=; b=DibmQtixOroxTZMK8EO6eAWuUceANVaCQq967BTGXUV39xbV49g5diNDdXiKlBYSB8UNE5kz a9VqaSzEqnUX2/oWRiu7xXnSG3rjifjrR9AVJYkCcvqo+ejYvmWyZWIN; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: sbrim@cisco.com, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Hi Dave, > > I read your I-D and have some questions, observations, suggestions > etc. Thanks for the quick turnaround Robin. > In the Map Reply message, I think there needs to be some information > on how long to cache the results for. That is what the "Record TTL" is for. Look again at the packet format section. > Likewise, in the "Unreachable" message. Not clear at this point that a Record TTL is needed. It all depends on if the CAR/ITR will cache a negative entry. We'll know more when we get the implementation done and start testing CONS. > I understand the "Unreachable" message means that the EID in the > request > is not within any prefix which any CAR known to the system is > currently > authoritative for. Ideally, the requester would be told to cache this Or not in the CONS database at all. > result for some period of time. Also, ideally, the system would be > smart enough to know what the nearest addresses above and below this > were for which there was a CAR with authoritative mapping information. > There is no mechanism for this in your proposal, as far as I can see, > but I think the "Unreachable" message should contain something like: We could do this if the CARs are configured with the same mask- length. But again, we need deployment experience before just adding stuff like this. > The system has no CARs which have mapping information for > this address, or for addresses below it to XXX inclusive, or > for addresses above it to YYY inclusive. > > That will save the ITRs and caching CARs from bugging any CDRs in the > near future with mapping requests for nearby addresses. Right, understand your suggestion. > Perhaps this "Unreachable" reply could be renamed, because it does not > imply anything about reachability of any host which might be using a > mapped address - just that while an ITR enquired about this address > because it assumed it might be part of the LISP system, that as far as > the system knows at present, the address is not mapped by the LISP > system. Noted. > I am not sure at what point such a reply would be generated. I > understand it should be generated when a CDR gets a request and then > decides it couldn't pass it on to another CDR. (Sect 5.2 para 5.). > But > how did the request get that far, unless this is the very first CDR? It got that far because there was a more-specific in a CAR that was aggregated and the CDR has the aggregate and matches the request EID against it. > I understand a CAR sending the request on to the one or more CDRs it > connects to. Maybe that first CDR (or multiple such CARs) would > find it > had no entry in its EID-prefix database, so it has no parent or > sibling > CDR to send the request on to - so the first CDR would always be > the one > which generates this "Unreachable" reply. We believe that the Map-Requests will go all the way to an aggregating/replying CAR since we are proposing aggressive aggregation. > What if a CAR is authoritative for mapping the EID range: > > 11.0.0.0 > to 11.0.255.255 > > but there is a whole range: > > 11.0.27.3 > to 11.0.27.127 > > which currently does not map to any RLOC. There would probably be > many > such ranges with no current mapping. That is right. And the replying CAR will reply with an Unreachable. > Let's say this CAR gets a request for the mapping of an EID > 11.0.27.16. > Not only should it reply that there is no mapping, with a cache time, > but I think it should also include in the reply something to the > effect: > > "The requested EID is part of a range 11.0.27.3 to 11.0.27.127 for > which there is no mapping at present." > > Then the requesting ITR and its CAR(s) can cache this and stop bugging > the system with further requests when it gets a packet addressed to > other addresses in this range, for as long as the cache time says so. The only way to solve this is to hole-punch the aggregate with a more- specific. And we know what that does to the Internet. ;-) So we are not going to do this. > I don't understand how you make each CAR's data become replicated > somewhere else, so the system still works when the CAR is down. I was > looking in your I-D to see how you implemented something like what is > done with nameservers, with one being the master and others slaves, > but > all being authoritative to answer queries. We don't replicate it everywhere. The mappings stay at the level-0 CAR level. And the Requests hunt for the mapping by following an aggregated and reaggregated path in a strict hierarchy. > I don't understand why the devices which are authoritative for mapping > information for a particular prefix of EID space also have to be the > first point of call for requests from ITRs, other perhaps than your > plan > of making something like a three layer model for the whole system: The functionality of a Requesting-CAR and a Replying-CAR can be separated. And a Replying CAR does not need to peer with ITRs. We present it this way to show you that both are at level-0 of the hierarchy. > 1 - Caching devices which one or more ITRs talk to, and which > interface > to the CDR core by one or more links to CDRs. This is a CAR that sends Requests. We have received comments from others about this and in the next rev we will call them "Requesting CARs" and "Replying CARs" to differentiate the functionality. And, of course, the 2 pieces of functionality can be co-located in the same device. > In two places your I-D states: > > This case could arise when source-site is LISP-enabled (i.e., > there is an ITR deployed), . . . > > This confirms my original understanding that all LISP variants require > an ITR in the edge network of any host which will successfully send a > packet to a host with EID address. It doesn't require it. We envision it will be deployed this way. An ITR could go into a PE device at an ISP that is serving multiple customer connections from that device. > When I wrote of Ivip (originally ViP) on 15 June, the key difference > from LISP is that the mapped addresses (EIDs in LISP terminology) are > part of advertised BGP prefixes, and so packets with destination > addresses matching these prefixes will be forwarded out of edge > networks > which lack ITRs, ultimately to be encapsulated by one of the many Ivip > ITRs in the core of the Net. This makes Ivip much more easy to > incrementally deploy, since all senders will have their packets sent, > whereas with LISP, only those senders in edge networks with ITRs will > have their packets sent. And I have mentioned to you that you don't want PI addresses to be routeable and hence "BGP prefixes". So what you propose can work for PA addresses but if you apply them to PI prefixes, then the routing table cannot get smaller. > I have asked for clarification of what LISP 1.5 involves, since Dino > stated that what I was proposing was in fact LISP 1.5. So far I have > had no clarification or examples. Can you give any explanation of > what > LISP 1.5 entails, regarding the location of ITRs inside or outside > edge > networks, and whether prefixes for which the system does EID-to-RLOC > mapping are routed by the current BGP system? LISP 1.5 entails having a separate topology. Either tunneled or physical. You can run BGP on it. The namespace advertise in this instance of BGP are EID-prefixes. Think of it as another VRF on the Internet. The LISP probe packets (packets that are encapsulated by an ITR with the inner DA equal to the outer DA) are sent on this topology so the data can be used as a Request for the ETR to return a data-triggered mapping. Think of a data-triggered mapping an instance of LISP 1.5. Think of a control-plane mapping an instance of LISP 3. CONS is an example of a LISP 3 variant. So is NERD. > Page 10: > > Each CAR will also have a /32 EID assigned to it from each of its > configured blocks. This /32 EID is used in a Map-Request > message so > a replier can get the Map-Reply back to this requesting CAR in the > event that no CAR has been configured with the the requested EID > block. This case could arise when source-site is LISP-enabled > (i.e., > there is an ITR deployed), but the destination-site has not > deployed > LISP yet so there is no ETR. This is old text we forgot to remove. We will fix it. The design passes an originator prefix which is the one the CAR is aggregating. So we don't need to assign a /32 EID to a CAR. > This text just seems to confirm my understanding of this IP > address, but > doesn't help me understand why such a mechanism is needed or desired. Just a bug in the spec. Sorry for the confusion. > Finally, when I read the title of the I-D "... Content Distribution > Overlay ..." I thought this would be for a fancy use of the LISP > network > to efficiently transport video, sound etc. multicast or on-demand > media > files, which are widely referred to as "content" by those who own the > pipes and packaging systems. Well we had to use the name CONS. ;-) Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 05:24:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ebr-0003FG-0I; Tue, 03 Jul 2007 05:23:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ebq-0003C3-8i for ram@iab.org; Tue, 03 Jul 2007 05:23:46 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5ebk-0002MG-Sz for ram@iab.org; Tue, 03 Jul 2007 05:23:45 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4D25C212C63; Tue, 3 Jul 2007 12:23:39 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1A6F4212C51; Tue, 3 Jul 2007 12:23:39 +0300 (EEST) Message-ID: <468A159A.0@nomadiclab.com> Date: Tue, 03 Jul 2007 12:23:38 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Michael Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <01d601c7ba23$d96560f0$820c6f0a@china.huawei.com> In-Reply-To: <01d601c7ba23$d96560f0$820c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Fast provider fail-over requires a very agile mapping function, >> however. To me, it is not clear how either a pull or a push model, >> or a trade-off between the two, can support this in a scalable >> manner. > > This is the key part of the mapping mechanism. I believe that at the > first step some prototype systems based on DNS (pull model) and DHT > (Push model) or some hybrid model respectively must be deployed and > test their performance, then decide which mechanism is a good one. Michael, you are certainly right. The point I am making is that, from a delay perspective, a pure pull model won't support efficient provider fail-over. A push model might; it depends on the actual mechanism. But still, for one edge network to update the mapping, it will have to push the update to a large set of ingress tunnel routers. This holds for LISP, and for Ivip at a later transition stage. OTOH, from a signaling overhead perspective, the pull model is more favorable than the push model. So there will be a trade-off, and this does not seem easy to effect. > The mobility support has some impact on which model will be adopted. Right. Edge network mobility and provider fail-over are the same in terms of objectives and requirements IMO. - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 05:35:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5en1-0000YT-OB; Tue, 03 Jul 2007 05:35:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5en0-0000YG-Jn for ram@iab.org; Tue, 03 Jul 2007 05:35:18 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5emv-0005TM-R7 for ram@iab.org; Tue, 03 Jul 2007 05:35:18 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2007 11:35:03 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALS0iUaQ/uCLh2dsb2JhbACBS41YAgkOLA X-IronPort-AV: i="4.16,492,1175464800"; d="scan'208"; a="147089896:sNHT29902883680" 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 l639Z2BS015590; Tue, 3 Jul 2007 11:35:02 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp4136.cisco.com [10.61.80.39]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l639YxTC002231; Tue, 3 Jul 2007 09:35:01 GMT Message-ID: <468A1835.1000806@cisco.com> Date: Tue, 03 Jul 2007 11:34:45 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Michael Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <01d601c7ba23$d96560f0$820c6f0a@china.huawei.com> In-Reply-To: <01d601c7ba23$d96560f0$820c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=921; t=1183455302; x=1184319302; 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[RAM]=20Re=3A=20the=20separation=20of=20ID/RLOC |Sender:=20; bh=vRhiuv3USnXQfitkHvmpaSD/lsx0zNwnTxQsk5LKVxM=; b=CD+gluSU3w/CBEH9UrvQTXpa05cnQLw1ypd0ScYNPMKa1IjkCmks68n7oWAPmhIxfcJ+Z4Sh W75RuMdJxFZtzLEYyA5FpJJlstRhBtoddZq0tTznPy/oWNE15i/wexq3; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Christian Vogt , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Michael, > The mobility support has some impact on which model will be adopted. > I think a reasonable question to ask is at what layer mobility should be provided. When mobility is provided in HIP, for instance, one needs to handle caching concerns within DNS and of course have appropriate bonafides available to authorize an appropriate record update. In effect, a DNS server becomes the initial home agent, and that responsibility is subsequently transfered to the mobile node as handoffs are made. This of course assumes that two devices don't move at the same time but that seems quite reasonable. If we place mobility in LISP, the caching semantics of LISP-CONS would need to support it and whatever mapping binding would of course need to be secured, or an update would need to be made to NERD (NERD simply doesn't do mobility, quite frankly). Just some thoughts. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 06:10:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5fLM-0003oY-6z; Tue, 03 Jul 2007 06:10:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5fLL-0003ip-7y for ram@iab.org; Tue, 03 Jul 2007 06:10:47 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5fLK-0004BR-QI for ram@iab.org; Tue, 03 Jul 2007 06:10:47 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 96B13212C63; Tue, 3 Jul 2007 13:09:41 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5C63F212C51; Tue, 3 Jul 2007 13:09:41 +0300 (EEST) Message-ID: <468A2065.1060200@nomadiclab.com> Date: Tue, 03 Jul 2007 13:09:41 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> In-Reply-To: <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dino: >> update speed and reliability of the mapping function are not just needed >> for access network mobility. Its also needed for provider fail-over. > > It is needed as well for regular packet forwarding when nodes are > stationary. Exactly. You might allow for a bit more delay in the mapping update if a provider change is not critical because the old provider still works. But for fail-over, you really want to be quick. >> Access network operators want to be able to switch providers quickly >> when one goes down. This is one of the main goals for multi-homing. > > For what value of "quickly"? Please quantify. I am looking at this from the perspective of a pair of communicating hosts. A provider change initiated by either host's edge network operator will lead to delay and packet loss, and both should be small. Let's take a look at the typical case of a TCP connection. Here we will see substantial throughput degradations after a provider change if the delay is more than 1 RTT: Since TCP's retransmission timeout period is 1 RTT (plus variability), the sending TCP will run into two successive retransmission timeouts. This means that the congestion window and slow-start threshold will be set to 1 and 2 packets, respectively. TCP then cannot recover in slow-start mode (which would be efficient), but only in congestion avoidance mode (which is highly inefficient, especially if you start with a congestion window of 1). If the delay caused by a provider change can be limited to 1 RTT, then TCP will run into only a single retransmission timeout, and it will efficiently recover in slow-start mode afterwards. So my preferred definition of "quickly" is 1 end-to-end RTT. Whether or not long update delays are an issue depends, as you say, on the change frequency and granularity. However, any assumptions that we make in this regards should be very careful. Our goal is to give edge networks more freedom in traffic engineering and provider selection. And it would be great if we could reach this goal without restrictions -- such as in terms of change frequency or granularity. Best, - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 06:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5fSl-0004vI-1u; Tue, 03 Jul 2007 06:18:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5fSk-0004vD-Ej for ram@iab.org; Tue, 03 Jul 2007 06:18:26 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5fSg-0006BM-4V for ram@iab.org; Tue, 03 Jul 2007 06:18:26 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 62909212C63; Tue, 3 Jul 2007 13:18:21 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 290D5212C51; Tue, 3 Jul 2007 13:18:21 +0300 (EEST) Message-ID: <468A226C.9020908@nomadiclab.com> Date: Tue, 03 Jul 2007 13:18:20 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <01d601c7ba23$d96560f0$820c6f0a@china.huawei.com> <468A1835.1000806@cisco.com> In-Reply-To: <468A1835.1000806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Eliot, I think Michael was talking about "edge network mobility", AKA rehoming or provider fail-over. Host mobility support is not a primary goal for indirection mechanisms such as LISP or Ivip. - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 07:28:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5gXb-00073h-1c; Tue, 03 Jul 2007 07:27:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5gXZ-0006vn-Fb for ram@iab.org; Tue, 03 Jul 2007 07:27:29 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5gXU-00011D-0B for ram@iab.org; Tue, 03 Jul 2007 07:27:29 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l63BOQDA076956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2007 13:24:27 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <4665108F.5040609@gmail.com> References: <4665108F.5040609@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <310441DC-CB2C-42B4-9173-FF11C25B3CC8@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] Date: Tue, 3 Jul 2007 13:26:04 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 5-jun-2007, at 9:28, Brian E Carpenter wrote: > Title : General Identifier-Locator Mapping Considerations > Author(s) : B. Carpenter > Filename : draft-carpenter-idloc-map-cons-01.txt The trouble I keep having with all of this is as follows. We have identifiers in the form of fully qualified domain names. There doesn't seem to be a wide-scale dissatisfaction there. Then we have locators in the form of the values found in the destination address field of IP packets. Although not everyone is completely happy about how those work, we've managed to build infrastructures that work with these locators very effictively. The problem is in the relationship between the FQDNs and the addresses in IP packets. For reasons we all know (and probably a few that we haven't stumbled on yet) it has proven very hard to remap an FQDN to a new IP address if, when and as fast as required. So fundamentally, the problem that we have won't be solved by another layer of identity somewhere in the middle. The only thing that that does is hide what we need to do from layers that may be hard to change. This means that such a layer is an engineering compromise rather than an architectural first class citizen. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 07:59:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5h2M-00053o-TM; Tue, 03 Jul 2007 07:59:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5h2K-00053i-G9 for ram@iab.org; Tue, 03 Jul 2007 07:59:16 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5h2B-0006T3-Az for ram@iab.org; Tue, 03 Jul 2007 07:59:16 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l63Bu1wI077336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2007 13:56:02 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <466FFEB8.9080701@cisco.com> References: <466FFEB8.9080701@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] draft-lear-lisp-nerd-01 Date: Tue, 3 Jul 2007 13:57:39 +0200 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 13-jun-2007, at 16:27, Eliot Lear wrote: > I've put together an internet draft that talks about a push-based > distribution method for LISP. I call it NERD (Not-so-novel EID- > RLOC Database). Hm, is it worth the effort to do push and: In order to specify a mapping it is important to understand how it will be used, and the nature of the data being mapped. In the case of LISP, the following assumptions are pertinant: o The data contained within the mapping changes only on provisioning or configuration operations, and is not intended to change when a link either fails or is restored. Some other mechanism (via LISP or other) handles healing operations, particularly when a tail circuit within an service provider's aggregate goes down. With this limitation, ALL encapsulation devices must somehow track the reachability status of locators. In my opinion, you're solving the easy problem here and leaving the hard one. A better way to avoid solving the hard problem is to do pull and cache for some amount of time. That's probably not good enough for multihoming, but it is good enough for portable address space. This memo does not specify who the database authority is. That is because there are several possible operational models. In each case the number of database authorities is meant to be small so that ITRs need only keep a small list of authorities, similar to the way a name server might cache a list of root servers. o A single database authority exists. o Each region runs a database authority. o Each country runs a database authority. I REALLY don't like this. Whenever stuff comes together in a central place, that means the people that run that place are important, there need to be policies, arbitrary restrictions pop up etc etc. The size figures don't seem to include data structure overhead. Depending on the allocation policies, these could be negligible or huge. I.e., a routing table for 2^32 /32s could be a 4 GB array, but a routing table for 200k prefixes of all possible sizes requires a good deal of overhead to accommodate varying prefix sizes and to compress unused holes in the address space. with 10% daily change spread over 24 hourly updates This is a dangerous assumption if there are no mechanisms to enforce it. Last but not least, doing the crypto for hundreds of megabytes worth of information that is signed could easily be a bottleneck. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 08:47:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5hnH-0003sX-DO; Tue, 03 Jul 2007 08:47:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5hnG-0003sS-PY for ram@iab.org; Tue, 03 Jul 2007 08:47:46 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5hnB-0007bO-JQ for ram@iab.org; Tue, 03 Jul 2007 08:47:45 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2007 14:47:39 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGjiiUaQ/uCKh2dsb2JhbACBS41ZAgkOLA X-IronPort-AV: i="4.16,492,1175464800"; d="scan'208"; a="147114280:sNHT3370066244" 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 l63Cld0M024879; Tue, 3 Jul 2007 14:47:39 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp4136.cisco.com [10.61.80.39]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l63ClTTC004544; Tue, 3 Jul 2007 12:47:38 GMT Message-ID: <468A4554.5030105@cisco.com> Date: Tue, 03 Jul 2007 14:47:16 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] draft-lear-lisp-nerd-01 References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> In-Reply-To: <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3459; t=1183466859; x=1184330859; 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[RAM]=20draft-lear-lisp-nerd-01 |Sender:=20; bh=+Ym4xk1HekEy28oZARauGoheFuT1GYSu9CzxROVqF7k=; b=MmbYt3wCnFdsIu+qJp28jAKbM1KV5KMNA/1W8kKp3Ug1lQtLxCZWvcu4NrE4g8feVLm2wdAi Pt4QEhSMEckV8Iso1vM8AvAjyiqurlLUdBb5MxOqH6jswErk4oQut0gM; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Iljitsch van Beijnum wrote: > With this limitation, ALL encapsulation devices must somehow track the > reachability status of locators. In my opinion, you're solving the > easy problem here and leaving the hard one. In part I'd have to say, "Guilty as charged", but I am thinking about the other problem. We'll need some sort of feedback mechanism between ETR and ITR to indicate when an ETR is or is not available. Dino has posited some form of ICMP unreachable message. Some people don't like ICMP. Another approach is simply a periodic acknowledgment of some form built into the tunneling mechanism, where one would expect an acknowledgment initially and then periodically. But I heartily agree this area needs more work. > > A better way to avoid solving the hard problem is to do pull and cache > for some amount of time. That's probably not good enough for > multihoming, but it is good enough for portable address space. > > This memo does not specify who the database authority is. That is > because there are several possible operational models. In each case > the number of database authorities is meant to be small so that ITRs > need only keep a small list of authorities, similar to the way a name > server might cache a list of root servers. > > o A single database authority exists. > o Each region runs a database authority. > o Each country runs a database authority. > > I REALLY don't like this. Whenever stuff comes together in a central > place, that means the people that run that place are important, there > need to be policies, arbitrary restrictions pop up etc etc. You live with these already from the context of the RIRs. However, I think it would be quite possible for these things to not be regionally based at all, and so you could shop for an authority whose policies you trust and like. I still maintain, however, that you want to keep the number relatively small or life gets ugly. > > The size figures don't seem to include data structure overhead. The only overhead not included is database header, which is insignificant. > Depending on the allocation policies, these could be negligible or > huge. I.e., a routing table for 2^32 /32s could be a 4 GB array, but a > routing table for 200k prefixes of all possible sizes requires a good > deal of overhead to accommodate varying prefix sizes and to compress > unused holes in the address space. This seems overly complex. We know how to store this stuff today. > > > with 10% daily change spread over 24 hourly updates > > This is a dangerous assumption if there are no mechanisms to enforce it. Remember: this is a provisioned database. Show me a day in the last twenty years when the Internet's connectivity changed more than 1%. > > Last but not least, doing the crypto for hundreds of megabytes worth > of information that is signed could easily be a bottleneck. > You're not doing it that often such that it would matter. The only time you check the entire database is when you have none to start with. Otherwise you have an incremental update. However, suppose you didn't want to check the entire database. It would be possible to have signatures and versions of each EID entry. That would involve a fair amount more storage overhead, of course, and one would have to wonder if it were worth it. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 09:05:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5i4f-0002yW-82; Tue, 03 Jul 2007 09:05:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5i4d-0002tH-V6 for ram@iab.org; Tue, 03 Jul 2007 09:05:43 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5i4Z-0004f5-GF for ram@iab.org; Tue, 03 Jul 2007 09:05:43 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l63D2e1H078185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2007 15:02:40 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <468A4554.5030105@cisco.com> References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> <468A4554.5030105@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A4F0F70-6404-4AAB-A1D6-50C6DECE5893@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] draft-lear-lisp-nerd-01 Date: Tue, 3 Jul 2007 15:04:18 +0200 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 3-jul-2007, at 14:47, Eliot Lear wrote: >> With this limitation, ALL encapsulation devices must somehow track >> the reachability status of locators. In my opinion, you're solving >> the easy problem here and leaving the hard one. > In part I'd have to say, "Guilty as charged", but I am thinking > about the other problem. We'll need some sort of feedback > mechanism between ETR and ITR to indicate when an ETR is or is not > available. Dino has posited some form of ICMP unreachable > message. Some people don't like ICMP. Another approach is simply > a periodic acknowledgment of some form built into the tunneling > mechanism, where one would expect an acknowledgment initially and > then periodically. But I heartily agree this area needs more work. Actually not as much work as you may think: http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- detection-08.txt This does pretty much what's needed here. It would have to be adapted to run between middleboxes and to make sure that only active communication is monitored which means you don't detect a failure until you first try to communicate. But I guess that's a reasonable limitation. >> I REALLY don't like this. Whenever stuff comes together in a >> central place, that means the people that run that place are >> important, there need to be policies, arbitrary restrictions pop >> up etc etc. > You live with these already from the context of the RIRs. Hence my reluctance... >> The size figures don't seem to include data structure overhead. > The only overhead not included is database header, which is > insignificant. In transit, but in the systems it must be easily searchable, which means there will be additional overhead. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 10:25:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jJs-0000L1-TN; Tue, 03 Jul 2007 10:25:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jJr-0000EF-JK for ram@iab.org; Tue, 03 Jul 2007 10:25:31 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5jJr-0003ES-By for ram@iab.org; Tue, 03 Jul 2007 10:25:31 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AB11D872D8; Tue, 3 Jul 2007 10:24:26 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Re: the separation of ID/RLOC Message-Id: <20070703142426.AB11D872D8@mercury.lcs.mit.edu> Date: Tue, 3 Jul 2007 10:24:26 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Christian Vogt > from a delay perspective, a pure pull model won't support efficient > provider fail-over. A push model might; it depends on the actual > mechanism. In a way I would have thought just the opposite, actually - but in actuality I'm not sure it makes any difference. Here's why. First, I would think pull might be faster, because in the push model, when the binding from identifier (in the sense 'location-independent name') I to locator (in the sense 'location-dependent name') L changes from L1 to L2, that knowledge starts near L1/L2 and has to propogate across the network. My sense in that in a push system, which has to propogate that binding to everyone in the network, that might happen slower than a pull system, in which only people who want the updated binding have to get it. Second, I'm not sure that matters, though, because when that binding is updated from I->L1 to I->L2, a lot of boxes out on the far side of the network are going to have the old I->L1 binding cached, and ongoing traffic is going to be trying to use it - and of course it won't work. So, just as in any caching scheme, you have to have a mechanism to invalidate cache entries when they are outdated. I suspect that that cache-invalidation mechanism will be the dominant one, in the sense that most entities which are communicating with I are going to find the new binding through the cache-invalidation mechanism (whatever that is), rather than through the normal distribution mechanism (whether push or pull). So my sense is that the push/pull difference is not going to be significant. Now, you do have an interesting question on the cache-invalidation issue; do you depend on an explicit detection-update mechanism (i.e. distant box D sends packet to I, arrives at L1, I is no longer there, L1 sends an error message to D with L2, and D updates its cache), or whether you use a push mechanism to update everyone (which is basically what classical routing does). Pull plus cache-invalidation probably has less total signalling overhead than push, but push has the advantage of not having the resolution latency when a new communication starts. (Push plus cache-invalidation probably has the fastest response of all, but the highest signalling overhead.) Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 10:27:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jLp-0004Xe-6f; Tue, 03 Jul 2007 10:27:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jLo-0004Va-6N for ram@iab.org; Tue, 03 Jul 2007 10:27:32 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5jLo-0004Gp-0A for ram@iab.org; Tue, 03 Jul 2007 10:27:32 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B9982872D9; Tue, 3 Jul 2007 10:27:31 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] Message-Id: <20070703142731.B9982872D9@mercury.lcs.mit.edu> Date: Tue, 3 Jul 2007 10:27:31 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Iljitsch van Beijnum > We have identifiers in the form of fully qualified domain names. > ... > Then we have locators in the form of the values found in the > destination address field of IP packets. The problem is that those "locators" are used in lots of other places, places where you *don't want* a locator - e.g. TCP pseudo-checksums (for example - there are lots more). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 10:29:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jNd-0006jI-FP; Tue, 03 Jul 2007 10:29:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jNc-0006fh-H3 for ram@iab.org; Tue, 03 Jul 2007 10:29:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5jNE-0002w1-Mu for ram@iab.org; Tue, 03 Jul 2007 10:29:24 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 03 Jul 2007 07:29:00 -0700 X-IronPort-AV: i="4.16,492,1175497200"; d="scan'208"; a="6337195:sNHT20943894" 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 l63ET077026722; Tue, 3 Jul 2007 07:29:00 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l63ESxmo023150; Tue, 3 Jul 2007 14:28:59 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); Tue, 3 Jul 2007 07:28:57 -0700 Received: from [192.168.0.5] ([10.21.92.232]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 07:28:57 -0700 In-Reply-To: <468A4554.5030105@cisco.com> References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> <468A4554.5030105@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] draft-lear-lisp-nerd-01 Date: Tue, 3 Jul 2007 07:28:56 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Jul 2007 14:28:57.0178 (UTC) FILETIME=[7D7643A0:01C7BD7E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=895; t=1183472940; x=1184336940; 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[RAM]=20draft-lear-lisp-nerd-01 |Sender:=20; bh=QV+S3wHtti00T9FoHjI+JWSfzXJ+5vxiJleLqFYqNtE=; b=Md4mjqlgrkLY5HJntFR83e0ZqnL4QNVS02RYtEPGwR9cY0gSpnWnbI0vjWuxdbN4SwkBrf8H m07RllgAeybbE2UL96lOfN1YQ8xvV4DyO54/G0nn3mC5nqV1sLILxerg; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > In part I'd have to say, "Guilty as charged", but I am thinking > about the other problem. We'll need some sort of feedback > mechanism between ETR and ITR to indicate when an ETR is or is not > available. Dino has posited some form of ICMP unreachable > message. Some people don't like ICMP. Another approach is simply > a periodic acknowledgment of some form built into the tunneling > mechanism, where one would expect an acknowledgment initially and > then periodically. But I heartily agree this area needs more work. ICMP unreachable messages are not what the LISP-01 draft solely depends on for Locator reachability. We have put "Locator Reachability Bits" in the encapsulation header to piggyback Locator status for returning packets. The LISP-01 draft should be in the ID directory today. If people can't wait, I can post it here. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 15:19:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ntz-0003Zr-0C; Tue, 03 Jul 2007 15:19:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ntw-0003WH-BA for ram@iab.org; Tue, 03 Jul 2007 15:19:04 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5ntw-000711-4q for ram@iab.org; Tue, 03 Jul 2007 15:19:04 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2007 15:18:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAE49ikZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,493,1175486400"; d="scan'208"; a="125168246:sNHT27727502" 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 l63JItih005146; Tue, 3 Jul 2007 15:18:55 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l63JIY6w007194; Tue, 3 Jul 2007 19:18: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); Tue, 3 Jul 2007 15:18:50 -0400 Received: from [192.168.0.101] ([10.82.210.213]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 15:18:50 -0400 In-Reply-To: <468A2065.1060200@nomadiclab.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Re: the separation of ID/RLOC Date: Tue, 3 Jul 2007 12:18:49 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Jul 2007 19:18:50.0463 (UTC) FILETIME=[FCAAEEF0:01C7BDA6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=839; t=1183490335; x=1184354335; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20the=20separation=20of=20ID/RLOC |Sender:=20 |To:=20Christian=20Vogt=20; bh=4/xsS7E/0rCtlazpwlXy9U0anxyeF5kpVAR+TV7tbVM=; b=PTptviAaMwo+qkgl32fBq0SQXb2fCW6UPv+d1RdGIvVrZ2gRbeoHIP3lFkhssaIgYZjKAV43 UrHP+49JR6kplzuC/IGT7RZbtQmrad8oR+4or5W86rRNkHDQieTMjdsp; Authentication-Results: rtp-dkim-1; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jul 3, 2007, at 3:09 AM, Christian Vogt wrote: > If the delay caused by a provider change can be limited to 1 RTT, then > TCP will run into only a single retransmission timeout, and it will > efficiently recover in slow-start mode afterwards. So my preferred > definition of "quickly" is 1 end-to-end RTT. > > Whether or not long update delays are an issue depends, as you say, on > the change frequency and granularity. However, any assumptions > that we > make in this regards should be very careful. Our goal is to give edge > networks more freedom in traffic engineering and provider selection. > And it would be great if we could reach this goal without restrictions > -- such as in terms of change frequency or granularity. Isn't this issue easily resolved by advertising more than one locator? Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 15:27:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5o1v-0001Xr-U6; Tue, 03 Jul 2007 15:27:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5o1t-0001ST-B9 for ram@iab.org; Tue, 03 Jul 2007 15:27:18 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5o1s-0007y2-Vf for ram@iab.org; Tue, 03 Jul 2007 15:27:17 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l63JOGZG084515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2007 21:24:16 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20070703142731.B9982872D9@mercury.lcs.mit.edu> References: <20070703142731.B9982872D9@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] Date: Tue, 3 Jul 2007 21:25:54 +0200 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 3-jul-2007, at 16:27, Noel Chiappa wrote: >> Then we have locators in the form of the values found in the >> destination address field of IP packets. > The problem is that those "locators" are used in lots of other > places, places > where you *don't want* a locator - e.g. TCP pseudo-checksums (for > example - > there are lots more). Sure. And the right engineering tradeoff may be to invent something that allows all of this to remain unchanged so we can implement the stuff that we need to implement more easily / deploy it faster. But adopting that as an architectural starting point seems strange. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 03 17:55:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5qL0-0005eU-CX; Tue, 03 Jul 2007 17:55:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5qKz-0005eK-PL for ram@iab.org; Tue, 03 Jul 2007 17:55:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5qKv-0003e0-Fd for ram@iab.org; Tue, 03 Jul 2007 17:55:09 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2007 17:55:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAApjikZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,494,1175486400"; d="scan'208"; a="125180270:sNHT29183308" 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 l63Lt4wh014182; Tue, 3 Jul 2007 17:55:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l63Lsus0015072; Tue, 3 Jul 2007 21:54:56 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, 3 Jul 2007 17:54:56 -0400 Received: from [10.86.240.97] ([10.86.240.97]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 17:54:55 -0400 Message-ID: <468AC57A.6040206@employees.org> Date: Tue, 03 Jul 2007 17:54:02 -0400 From: Scott W Brim Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Eliot Lear Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <01d601c7ba23$d96560f0$820c6f0a@china.huawei.com> <468A1835.1000806@cisco.com> In-Reply-To: <468A1835.1000806@cisco.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2007 21:54:55.0920 (UTC) FILETIME=[CAEA4300:01C7BDBC] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Christian Vogt , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 07/03/2007 05:34 AM, Eliot Lear allegedly wrote: > I think a reasonable question to ask is at what layer mobility should be > provided. When mobility is provided in HIP, for instance, one needs to > handle caching concerns within DNS and of course have appropriate > bonafides available to authorize an appropriate record update. In > effect, a DNS server becomes the initial home agent, and that > responsibility is subsequently transfered to the mobile node as handoffs > are made. This of course assumes that two devices don't move at the > same time but that seems quite reasonable. You've just pointed out the problems with making DNS the HA. DNS is for resolving name to identifier. HAs are for resolving identifier to current locator. The authorization needed to make a DNS change should be different in scope from the one required to change state in a HA. It's good to have the two different phases of the process somewhat decoupled. > If we place mobility in LISP, the caching semantics of LISP-CONS would > need to support it and whatever mapping binding would of course need to > be secured, or an update would need to be made to NERD (NERD simply > doesn't do mobility, quite frankly). The caching that needs to be done in LISP for (fast) mobility) is luckily just in the ITRs. See you ... Scott _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 04 05:56:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61av-0001Sr-FE; Wed, 04 Jul 2007 05:56:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61au-0001Sm-TQ for ram@iab.org; Wed, 04 Jul 2007 05:56:20 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I61aq-0001rq-IX for ram@iab.org; Wed, 04 Jul 2007 05:56:20 -0400 Received: by ug-out-1314.google.com with SMTP id c2so284641ugf for ; Wed, 04 Jul 2007 02:56:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=L0+vWG00m1OIx/H/WzzCp2vVCFiFdj0oyeLxPat01x9Oh92Wtjyg1nfEeFClt/n4VByj5p/2qXyXChUYgdosLS/0pmFCmLc77XcaTPU1ehe8n+ZWm2StVo9PbQm3baC830CTRnHCiod7JCvHRi+CVLuQsTCuvATD5Qo92eY5uzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=sT0Ae0Zr5O+BN9Lds4zSDHqK8E6tL/Zq25FzIlEP0eRD2MLh04BrhXNWxPpqFvt/cD0ntiAmvY1BmpDmc5tsjk2JkDeNOD01E3/GQb5KJCQ8cjyOmvWxkubLultJn8igXmYTl6SvrVyz/evIDqOvmoaLl4pbR5zsLXMo2/9vGhE= Received: by 10.78.200.20 with SMTP id x20mr4016261huf.1183542975312; Wed, 04 Jul 2007 02:56:15 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id h7sm6643077nfh.2007.07.04.02.56.13 (version=SSLv3 cipher=RC4-MD5); Wed, 04 Jul 2007 02:56:14 -0700 (PDT) Message-ID: <468B6EB7.4040505@gmail.com> Date: Wed, 04 Jul 2007 11:56:07 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [RAM] Question about lisp-cons aggregation X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, draft-meyer-lisp-cons doesn't seem to have made it through the system yet, but I have some points. I'm probably being stupid, but it seems that you don't actually define what you mean by an aggregate, or describe the algorithm for forming an aggregate. Now that may be well known within routing protocols, but I think you need to either explain it in this draft or give a precise reference. Specifically, in section 4 just after Fig. 2 you say > The CARs aggregate these EID-prefixes, and I think that needs an algorithmic description. In 5.3.1 you say > If the CAR finds a match, it next checks to see if the EID-prefix is > the last prefix in an aggregate or is the only EID-prefix in an > aggregate. I think you need to define what "the last prefix in an aggregate" means; otherwise this description is also not algorithmic. I also don't understand how this process (removing an EID-prefix) fails to create black holes. Incidentally, I noticed two cases of IPv4ism in section 5.1: a reference to /32 (instead of "/32 or /128") and a default prefix of 0.0.0.0/0 (instead of "0.0.0.0/0 or 0::/0"). Overall I like this approach more than NERD. Although it requires more innovation, it seems to match the problem and minimize dependencies. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 04 05:59:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61eM-0004X0-7M; Wed, 04 Jul 2007 05:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61eK-0004Wi-LG for ram@iab.org; Wed, 04 Jul 2007 05:59:52 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I61eB-0002RH-M6 for ram@iab.org; Wed, 04 Jul 2007 05:59:52 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 67D48212D1E; Wed, 4 Jul 2007 12:59:42 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2E8DD212D16; Wed, 4 Jul 2007 12:59:42 +0300 (EEST) Message-ID: <468B6F8D.7080807@nomadiclab.com> Date: Wed, 04 Jul 2007 12:59:41 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] Re: the separation of ID/RLOC References: <20070703142426.AB11D872D8@mercury.lcs.mit.edu> In-Reply-To: <20070703142426.AB11D872D8@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Noel, I was thinking of the "mapping function" as a mechanism that encompasses both, the initial distribution of mapping information and subsequent mapping updates (including cache invalidations). I was looking at it at a higher abstraction level. When it comes to concrete, technical approaches, I fully agree with you that a solution could realize the initial mapping set-up in a different way than subsequent mapping updates. First of all, this is because requirements are different: One may want to minimize signaling overhead for the initial set-up, but minimize update delays, in particular in case of provider fail-overs. The solution spaces are different as well: E.g., current traffic patterns may allow you to prioritize mapping updates for those remote edge networks with which a lot of traffic is being exchanged. Mapping updates could also be realized in-band with regular traffic. OTOH, for the initial set-up, neither prioritization nor in-band signaling seems to be feasible to the same extent. Where I don't agree with you is that the pull-push trade-off would only apply to the initial mapping set-up. I think the pull and push paradigms are technical approaches that can be used for both, the mapping set-up /and/ mapping updates. Kind regards, - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 04 06:02:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61h4-0006TH-J5; Wed, 04 Jul 2007 06:02:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61h3-0006TC-Ix for ram@iab.org; Wed, 04 Jul 2007 06:02:41 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I61gz-0002n7-0K for ram@iab.org; Wed, 04 Jul 2007 06:02:41 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKN00MXJFRJWV@szxga02-in.huawei.com> for ram@iab.org; Wed, 04 Jul 2007 17:59:43 +0800 (CST) Received: from m50376k ([10.111.12.130]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKN00J1RFRDWC@szxga02-in.huawei.com> for ram@iab.org; Wed, 04 Jul 2007 17:59:43 +0800 (CST) Date: Wed, 04 Jul 2007 17:59:36 +0800 From: Michael Subject: Re: [RAM] revised draft proposed definitions To: Tony Li , Brian E Carpenter Message-id: <02ef01c7be22$0ac4e5b0$820c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <466D69FC.3010003@cisco.com> <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> <466E5B78.4090501@gmail.com> <538E4FBC-D624-4221-945C-7D1BACBB481A@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, Tony, ----- Original Message ----- From: "Tony Li" To: "Brian E Carpenter" Cc: "RJ Atkinson" ; Sent: Wednesday, June 13, 2007 2:21 AM Subject: Re: [RAM] revised draft proposed definitions > >> Identifier: A binary quantity (not necessarily an IP Address) that >> can be used by a Stack "A" to uniquely identify another Stack "B" >> both for bilateral communication and for informing a third Stack >> "C" >> that it should communicate with Stack "B". (Note that there is an >> assumption in this definition that a Stack is the entity we require >> to identify; in this era of virtualized servers with failover >> capabilities, and of mobile clients, this seems to be a reasonable >> assumption.) > > Brian, > > I have a minor quibble with this, in that it's really defining a > stack identifier, not a generic identifier. > > Any given proposal may choose to have identifiers at many levels > (e.g. transport connection identifiers, interface identifiers, host > identifiers, etc.) and the definition needs to either be sufficiently > abstract so as to encompass all of these, or the term being defined > needs to be qualified. I agree with you, when we talk about identifier, which layer the entity an identifier denotes belongs to must be specified. I think the ID in LISP trys to denote an entity at IP layer. I perfer this definition " an identifier denotes an entity belonging to some layer of network, it is unique at the specified layer". Michael > > Tony > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 04 06:15:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61tL-0005Z3-J3; Wed, 04 Jul 2007 06:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61tJ-0005Yj-Ri for ram@iab.org; Wed, 04 Jul 2007 06:15:21 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I61tE-0004Pw-SB for ram@iab.org; Wed, 04 Jul 2007 06:15:21 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 2F23F5A68D; Wed, 4 Jul 2007 20:15:15 +1000 (EST) Message-ID: <468B7327.2060603@firstpr.com.au> Date: Wed, 04 Jul 2007 20:15:03 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org References: <20070703142426.AB11D872D8@mercury.lcs.mit.edu> In-Reply-To: <20070703142426.AB11D872D8@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Noel Chiappa Subject: [RAM] Detecting multihoming failures X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org In "Re: the separation of ID/RLOC" Noel Chiappa wrote, in part: > . . . because in the push model, when the binding from > identifier (in the sense 'location-independent name') I to > locator (in the sense 'location-dependent name') L changes from > L1 to L2, that knowledge starts near L1/L2 and has to propagate > across the network. I imagine that for multihoming, there needs to be a detection system implemented well away from either L1 or L2, ideally as some kind of distributed system with no single point of failure. That system would probably be a commercial service, and the end-user would pay them and give them the credentials to alter the mapping of their IP address or prefix in the LISP or Ivip system automatically as soon as the system detected something was amiss. > Now, you do have an interesting question on the > cache-invalidation issue; do you depend on an explicit > detection-update mechanism (i.e. distant box D sends packet to > I, arrives at L1, I is no longer there, L1 sends an error > message to D with L2, and D updates its cache), . . . Assuming the D detector system is monitoring how well the end-user's host or router can be reached via the ETR at L1, D can't rely on that ETR to report every source of trouble, because perhaps that ETR at L1 will die or become unreachable. I think D needs to be well outside whatever provider networks or AS-end-user edge networks the ETRs L1 or L2 are located in, so it can detect if those networks become unreachable. There is a SHIM6 failure detection I-D: http://tools.ietf.org/html/draft-ietf-shim6-failure-detection but that is where there is a remote correspondent host on the scene. A remote multihoming failure detection and mapping changing system for LISP or Ivip would be independent of all corresponding hosts etc. Regarding "cache-invalidation", perhaps this is similar to what I call "Notification". I discuss that in a recent message "1 Ivip ITR strategies, including in the host" and in a message I will send soon. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 04 06:16:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61uh-00074i-DO; Wed, 04 Jul 2007 06:16:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61ug-00074d-89 for ram@iab.org; Wed, 04 Jul 2007 06:16:46 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I61ub-0004Wy-Bo for ram@iab.org; Wed, 04 Jul 2007 06:16:46 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BB330212D1E; Wed, 4 Jul 2007 13:16:40 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7A763212D16; Wed, 4 Jul 2007 13:16:40 +0300 (EEST) Message-ID: <468B7388.3020306@nomadiclab.com> Date: Wed, 04 Jul 2007 13:16:40 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> In-Reply-To: <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Whether or not long update delays are an issue depends, as you say, on >> the change frequency and granularity. However, any assumptions that we >> make in this regards should be very careful. Our goal is to give edge >> networks more freedom in traffic engineering and provider selection. >> And it would be great if we could reach this goal without restrictions >> -- such as in terms of change frequency or granularity. > > Isn't this issue easily resolved by advertising more than one locator? Tony, if you want to an enable edge network to decide through which provider ingress packets are received, then the edge network must be able to tell remote edge networks one specific transit locator to which they should send packets. If an edge network advertises more than one transit locator, then it is up to remote edge networks to select one of those. This takes away the ability for edge networks to select an ingress provider. Additionally, you still need a locator selection mechanism for the remote edge network -- which may involve its own signaling overhead, delay, and packet loss. With Six/One [1], edge networks can select both their ingress and egress providers, and they can change them within 1 RTT without signaling. There is also no packet loss if the old provider is still operational at the time of the change. And the granularity of provider selection (both ingress and egress) is on a per-communication-session level. [1] http://users.piuha.net/chvogt/pub/2007/draft-vogt-rrg-six-one-00.txt - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 04 09:45:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I65AB-0006vE-O1; Wed, 04 Jul 2007 09:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I65AA-0006tQ-Gg for ram@iab.org; Wed, 04 Jul 2007 09:44:58 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I65A3-0003hv-Te for ram@iab.org; Wed, 04 Jul 2007 09:44:58 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l64DflcX004509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jul 2007 15:41:47 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <468A4554.5030105@cisco.com> References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> <468A4554.5030105@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6111F123-2A87-4B6C-84FE-B2A29D28BFFA@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] draft-lear-lisp-nerd-01 Date: Wed, 4 Jul 2007 15:43:25 +0200 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 3-jul-2007, at 14:47, Eliot Lear wrote: >> With this limitation, ALL encapsulation devices must somehow track >> the reachability status of locators. In my opinion, you're solving >> the easy problem here and leaving the hard one. > In part I'd have to say, "Guilty as charged", but I am thinking > about the other problem. We'll need some sort of feedback > mechanism between ETR and ITR to indicate when an ETR is or is not > available. Hm, what if we create a rather static mapping database. Then, when an ITR sees traffic towards a given destination, it retrieves the latest ETR reachability info and expresses an interest in receiving updates when this reachability info changes. So we flood the static info and pull the reachability stuff. If we engineer this right, this should be very fast but still much lighter than doing end-to-end reachability checks between the cartesian product of the sets of ITRs and ETRs with active communication between them. I.e., if you want to subscribe to Google's reachability status, you'd just ask the next upstream mapping server. But if you want to know the reachability status of some obscure destination, you'll probably have to talk to a mapping server fairly close to that destination. Extra credit: DHT so any given mapping server only has to talk to a limited number of other mapping servers. And/or deltas to reachability information can be highly compressed since the static mapping info is known. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 04 09:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I65Fg-0007fa-26; Wed, 04 Jul 2007 09:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I65Ff-0007fS-LC for ram@iab.org; Wed, 04 Jul 2007 09:50:39 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I65FZ-0005HV-4l for ram@iab.org; Wed, 04 Jul 2007 09:50:39 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id AF45D59DA1; Wed, 4 Jul 2007 23:50:31 +1000 (EST) Message-ID: <468BA59B.2060404@firstpr.com.au> Date: Wed, 04 Jul 2007 23:50:19 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org References: <20070703142426.AB11D872D8@mercury.lcs.mit.edu> In-Reply-To: <20070703142426.AB11D872D8@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Cc: Christian Vogt , Noel Chiappa Subject: [RAM] ITR/ETR functions in hosts, NATs & servers - not in routers? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I assumed that LISP/Ivip would always involve expensive routers with large central memories and fast ASIC-based FIBs, but now I can imagine a way the whole thing might be done, in principle, in the longer term, without any routers at all. I am not suggesting routers won't in practice be needed - just that once something like this becomes a normal part of the Internet, most of the ITR and ETR work can probably be done without routers. To support unaltered hosts, I think caching "pull" ITR routers will be required to handle most of their outgoing packets. To support unaltered hosts in unaltered provider or AS-end-user edge networks, I think some high volume push ITR routers will be needed in the core (not inside, or at the border of, provider or AS-end-user edge networks). But see point 8 for how such a fast full database "push" ITRD might be made with a bunch of servers. With 8 gigs of RAM, even a single server running full database "push" ITRD code could use just 2 memory cycles to look up the mapping for individual IPv4 addresses when 1 to 1.5 billion addresses are handled by LISP/Ivip - so maybe this is the best way to do it, forgetting about caching ITRCs. Short version: 1 "Notify" (AKA "cache-invalidation"?) as an addition to a pull system. 2 Using a first line of pull ITRs which let through the small number of packets they haven't got mapping for so these "novel" packets are handled instantly by a full database ITR. Caching ITRs are going to be a lot cheaper than high bandwidth pull ITRs, so this would save money without allowing any packets to be delayed. 3 A caching ITR function in sending hosts, so the host doesn't need a caching ITR. This would be in a NAT router, not in hosts behind NAT. 4 Then, if the pull ITR only handles a small load, maybe implement it in software running on a cheap PC box. 5 If all the hosts/NATs were upgraded to include a caching ITR in their operating system software, maybe there wouldn't need to be an actual router for caching ITR work at all. 6 ETR functions can easily be performed in a server, so there's no absolute need to have a router for this. Also ETR functions can be done in the receiving host, provided the host has a local "care-of" address. A NAT device can perform ETR functions for all packets it receives for its hidden hosts. 7 Maybe a high performance "core-ITR" can be made without routers by implementing a bunch of high-volume caching ITRCs and lower volume push ITRDs on a bunch of Linux/BSD boxes. 8 So with modest upgrades to hosts (not behind NAT) and to NAT devices (DSL and cable modems etc.), maybe an entire provider or AS-end-user edge network can be made to do high-performance LISP/Ivip sending and receiving with a bunch of special servers and no LISP/Ivip functions in router$. In "Re: the separation of ID/RLOC", Christian Vogt wrote: CV > Fast provider fail-over requires a very agile mapping CV > function, however. To me, it is not clear how either a pull CV > or a push model, or a trade-off between the two, can support CV > this in a scalable manner. M > This is the key part of the mapping mechanism. I believe that M > at the first step some prototype systems based on DNS (pull M > model) and DHT (Push model) or some hybrid model M > respectively must be deployed and test their performance, M > then decide which mechanism is a good one. > > Michael, > > you are certainly right. The point I am making is that, from a > delay perspective, a pure pull model won't support efficient > provider fail-over. A push model might; it depends on the > actual mechanism. But still, for one edge network to update the > mapping, it will have to push the update to a large set of > ingress tunnel routers. This holds for LISP, and for Ivip at a > later transition stage. In my recent message "5 Database <--> ITR push, pull and notify" I propose a push system to get the full database with second-by-second updates out to large numbers (~100,000?) of ITRDs ("push" ITRs with the full Database) and to QSDs, which are Query Servers (not routers) which also have the full Database. Then I propose that ITRCs ("pull" ITRs which Cache the result of queries, and don't have the full database) query these QSDs either directly or via one or more levels of QSC (proxy Query Servers with Cache). In addition to this basic "push" system, with locally available responses for "pull" queries, I also propose a "Notify" function - which might be similar to what Noel called "cache-invalidation". "Notify" means that when a QSD gets a real-time database update for a mapping which it has recently (some caching time) been asked about, it sends a notification to whatever device sent the query. That device will be either an ITRC - which therefore receives the update within seconds of the database changing - or a QSC, which does the same thing to whichever device sent it the query. Within a fraction of a second of the QSD getting a mapping update, all the ITRCs which recently queried that mapping are notified of the change. I guess this sort of approach has been used in other settings. The example I give assumes a fixed 10 minute caching time, which should make it relatively simple to implement the timers in the QSDs and QSCs. However the principle could be extended to work with variable caching times which are specified in each response. In that message I also propose an Ingress Tunnel Function in Host (ITFH) - to encapsulate and tunnel just that host's outgoing packets, but not if the host is behind NAT. This would be like an ITRC, making queries to a QSD or QSC. It would be an operating system upgrade and have no real cost, whilst taking a great load off ITRCs. ITFH only works on hosts or NAT devices which have a normal BGP-reachable IP address or an address which is mapped by LISP/Ivip. It won't work on hosts behind NAT. It could be an operating system upgrade for hosts, and would be especially valuable in web servers and the like which are pumping out large numbers of packets. It would cost nothing financially and involve only a small CPU load (compared to the rest of the server stuff) to implement the caching ITR function in the host itself. ITFH could be implemented as a firmware upgrade for DSL and Cable modem NAT routers. However, there really needs to be a standardised autodiscovery system for the one or more QSDs or QSCs to direct queries to. Also, ideally, there should be an auto discovery system so the ITFH function knows one or more addresses of full push ITRDs to tunnel packets to when it hasn't got the mapping for them at that moment. The ITRCs and ITFH functions could have two or more upstream QSDs or QSCs to query. In "1 Ivip ITR strategies, including in the host" I suggest having these two types of caching ITR (ITRC and ITFH) only make queries and do mapping for the main volume of packets, letting "novel" packets pass, whilst analysing traffic patterns to see which destination addresses show up in more than a few novel packets, so a query can be made about the mapping of that address. Those packets which the ITRC or ITFH don't currently have mapping for can either be forwarded normally so the local routing system can forward them to a full database ITRD - or the ITRC/ITFH could tunnel these packets explicitly to an ITRD. This way, there would be no delay in tunneling any packet - and the ITRD would only handle a generally low volume of "novel" packets the ITRCs and ITFHs haven't got mapping for yet. The path lengths would be optimal or close to optimal for packets handled by a local ITRC. The path length would be perfectly optimal for all packets encapsulated by the ITFH in the host or NAT device. The path length would be longer for those "novel" packets which need to go to a full ITRD. The ITRD could be in the same network (provider or AS-end-user edge network) or (with Ivip) could be outside the network. This would mean that each network either doesn't absolutely need a full push ITRD, since it is acceptable for the novel packets to use one outside the network, or that the full push ITRD the network does have will be handling a relatively low volume of packets. If the volume of packets going to this one ITRD is low enough - or if there are enough of these ITRDs in the network so the load on them is low enough - then the ITRD function could be implemented in a standard PC with suitable software, saving on the high expense of a router with its very large FIB requirements etc. The full push ITRD needs a lot of memory for its copy of the database (~RIB) and its FIB data - and lots of CPU power to handle incoming updates, crunch them to be the database and then to crunch the database and changes to it to create the FIB data and changes to the FIB data. A device like a dual-core 64 bit CPU Linux/BSD server with 8 Gigabytes of more of RAM can also do relatively simple table-based lookups to classify packets. A billion individually mapped Ivip addresses for IPv4 would need 4 gigabytes of RAM, since all that is needed is a 32 bit address for where to tunnel them to. Ordinary motherboards have one or two gigabit Ethernet interfaces on board, the whole thing could boot from a USB stick or flash drive, and wouldn't need a hard drive. Its capacity to receive, classify, encapsulate and send packets would be primarily limited by the CPU's ability to shovel packet data around the place and to perform the FIB packet classification process. This could be simpler than usual, because there is lots of RAM. Memory latency is likely to be the bottleneck, since ordinary motherboard memory systems, DDR RAM etc. is not optimised for fast random access, but for slower access to a bunch of words which are pumped into the cache, even if the software only needs to read a byte. I guess memory latency is 40 to 60 nsec. It might take, say, 5 random memory accesses to classify a packet and find the address to tunnel it to. This is pessimistic, since with the 1 gig x 32 bit system described above it would take two accesses, one to find the starting point of the correct table for that master-prefix and the second to to read the 32 bit "LOC" address. So if the CPU was doing nothing more than this, it would be able to classify several million packets a second. There is plenty to do, so the packet rate would be significantly less than this. I will continue as if the ITRD is a really onerous task, and that generally an ITRC would handle more packets per second - but I am not so sure this is the case. If there were a billion addresses in the Ivip system, then there is no need for a rule-based FIB function which is separate from the local copy of the master database. The updates would simply be applied to the appropriate 32 bit locations in each array, and the same arrays would be used for classifying packets. It could hardly be simpler. For a single "master-subnet" such as a 13.0.0.0/8 (assigned to Xerox in 1991 and currently unadvertised) was assigned to the Ivip system, this is represented as an array of 16,777,216 32 bit locations. When an update arrives: 13.12.11.10 to 13.12.11.22 are now mapped to 77.77.77.77 all that is needed is 13 writes to memory, which will be cached and be written out in probably 100 nsec. When a packet comes in addressed to 13.12.11.13, the software firstly finds from an array indexed by the most significant 24 bits whether this address is in an Ivip-mapped /24 of the address space. If it is, the array contains a 32 bit starting address for the array just mentioned above, and a starting address for that master-subnet. Then by subtracting the master subnet, shifting the result left by two bits and adding it to the start address of this master-subnet's array, the CPU can read the mapping data. With enough memory, this is so fast and simple that it may be better to simply do all the ITR functions like this - forgetting about ITRCs and their need for query servers. However, an ITFH function in a host can't devote 4 gigs of RAM and a lot of CPU power to run their own full database ITRD. Doing most of the encapsulation in the sending host would be best, and that requires the ITFHs to be able to query QSDs or QSCs. IPv6 ITRs wouldn't work so well with a table-based system, because there are so many bits in play to get to a /64 granularity. They would need a recursive table lookup scheme, using three or four bits of destination address at a time, until eventually finding a match result, and then reading a 128 bit address to tunnel the packet to. A full database ITRD in a 64 bit 8gigabyte host, even with two gigabit Ethernet ports, would be slower than a full ITRD implementation in the FIB of a high-end router, but the whole thing would only cost USD$1000 or so. Maybe a single server with two gigabit Ethernet ports could have a high enough throughput to make the cluster idea below unnecessary. In that case, just have one or more such servers as peers with a stub connection to any conventional BGP or internal router where a full ITR function is needed - assuming the router could load-balance packets between multiple such servers. Here are some ideas about creating a relatively high-speed ITR to handle raw packets from multiple unmodified networks, which a conventional transit router has fished out and sent on a gigabit Ethernet link. In Ivip, the router would advertise all the prefixes of the "master-subnets" and forward the packets it receives whose destination addresses match any of these prefixes, to this gigabit link. The router would get back from the link encapsulated packets, which it would forwarded to its peers for their trips to the ETRs all over the world. Here I assume we need a bunch of caching ITRCs with a single ITRD to handle packets they don't have mapping information for. But perhaps it would be easier to make one server the replicator (see my recent message: 5 Database <--> ITR push, pull and notify) for the rest of the servers which are simply direct table-lookup ITRDs, as described above. Then there's no need for a QSD and the whole thing is a lot simpler. The router can presumably farm out packets to the various IP addresses of each of the ITRDs, or maybe one of them can do the the farming out. BGP peers - border & transit routers \ | / Gigabit stub replicator and \ | / ITR cluster - 7 plain diskless | | | Linux/BSD servers \ RRRRRRRRRRRRR \---R R R Conven- R 1G Ethernet -----R tional R ---------------\ R R | -----R Transit R EEEEEEEEEEE | R Router R E E | /---R R E E--/ / R R E 8 E ..................... RRRRRRRRRRRRR E E----. Replicator & QSD . | | | E P E ..................... / | \ E o E / | \ E r E ..................... E t E----. ITRD push . E E ..................... E S E E w E ..................... E i E----. ITRC1 pull cache . E t E ..................... E c E E h E ..................... E E----. ITRC2 pull cache . E E ..................... E E E E ..................... E E----. ITRC3 pull cache . E E ..................... E E E E ..................... E E----. ITRC4 pull cache . E E ..................... E E E E ..................... E E----. Spare . E E ..................... EEEEEEEEEEE Some motherboards have two gigabit Ethernet ports, so the whole system could use two links where I show one, including perhaps to and from the router. The servers would be identical and boot from a USB stick or flash IDE/SATA drive. They would all have the same software and assume roles depending on what was needed. They would probably have 8 (or in the future 16) gigs of RAM. The router could distribute the raw packets to the five ITRCs which would handle most of the packets, pretty quickly. Their FIB code would be optimised for relatively low number of rules and fast classification. Packets which don't match are forwarded to the ITRD which has a full copy of the database and an FIB which classifies all packets to every possible prefix in the Ivip system, including to /32 for IPv4 or /64 for IPv6. This would involve a lot more RAM and slower classification, so the packet rate of the ITRD would be less than for each ITRC, but it could instantly classify, encapsulate and forward any packet, without needing to query the QSD query server, which the ITRCs would be very frequently querying. The top server is that full database query server, and a replicator, receiving two or more streams of database update information and pumping out ten or more streams to other sites, as well as feeding a stream to its QSD function and to the ITRD. Probably a little server cluster is not what everyone wants in their data centre, but it would be a cheap alternative to buying a new router with special ITR functions. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 04 22:47:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6HN1-0000Tk-NC; Wed, 04 Jul 2007 22:47:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6HN0-0000OZ-TR for ram@iab.org; Wed, 04 Jul 2007 22:47:02 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6HMw-00020v-0a for ram@iab.org; Wed, 04 Jul 2007 22:47:02 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKO00HDGQCOLS@szxga01-in.huawei.com> for ram@iab.org; Thu, 05 Jul 2007 10:46:01 +0800 (CST) Received: from m50376k ([10.111.12.130]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKO0010YQCMXN@szxga01-in.huawei.com> for ram@iab.org; Thu, 05 Jul 2007 10:46:00 +0800 (CST) Date: Thu, 05 Jul 2007 10:45:58 +0800 From: Michael Subject: Re: [RAM] draft-lear-lisp-nerd-01 To: Eliot Lear , Iljitsch van Beijnum Message-id: <004a01c7beae$9df2f200$820c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> <468A4554.5030105@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, Eliot, Iljitsch, Another approach is simply a periodic acknowledgment of some form > built into the tunneling mechanism, where one would expect an > acknowledgment initially and then periodically. This would have some scalability issue, like RSVP soft state. Michael ----- Original Message ----- From: "Eliot Lear" To: "Iljitsch van Beijnum" Cc: Sent: Tuesday, July 03, 2007 8:47 PM Subject: Re: [RAM] draft-lear-lisp-nerd-01 > Iljitsch van Beijnum wrote: >> With this limitation, ALL encapsulation devices must somehow track the >> reachability status of locators. In my opinion, you're solving the >> easy problem here and leaving the hard one. > > In part I'd have to say, "Guilty as charged", but I am thinking about > the other problem. We'll need some sort of feedback mechanism between > ETR and ITR to indicate when an ETR is or is not available. Dino has > posited some form of ICMP unreachable message. Some people don't like > ICMP. Another approach is simply a periodic acknowledgment of some form > built into the tunneling mechanism, where one would expect an > acknowledgment initially and then periodically. But I heartily agree > this area needs more work. > > >> >> A better way to avoid solving the hard problem is to do pull and cache >> for some amount of time. That's probably not good enough for >> multihoming, but it is good enough for portable address space. >> >> This memo does not specify who the database authority is. That is >> because there are several possible operational models. In each case >> the number of database authorities is meant to be small so that ITRs >> need only keep a small list of authorities, similar to the way a name >> server might cache a list of root servers. >> >> o A single database authority exists. >> o Each region runs a database authority. >> o Each country runs a database authority. >> >> I REALLY don't like this. Whenever stuff comes together in a central >> place, that means the people that run that place are important, there >> need to be policies, arbitrary restrictions pop up etc etc. > > You live with these already from the context of the RIRs. However, I > think it would be quite possible for these things to not be regionally > based at all, and so you could shop for an authority whose policies you > trust and like. I still maintain, however, that you want to keep the > number relatively small or life gets ugly. > > >> >> The size figures don't seem to include data structure overhead. > > The only overhead not included is database header, which is insignificant. > >> Depending on the allocation policies, these could be negligible or >> huge. I.e., a routing table for 2^32 /32s could be a 4 GB array, but a >> routing table for 200k prefixes of all possible sizes requires a good >> deal of overhead to accommodate varying prefix sizes and to compress >> unused holes in the address space. > > This seems overly complex. We know how to store this stuff today. > >> >> >> with 10% daily change spread over 24 hourly updates >> >> This is a dangerous assumption if there are no mechanisms to enforce it. > > Remember: this is a provisioned database. Show me a day in the last > twenty years when the Internet's connectivity changed more than 1%. > >> >> Last but not least, doing the crypto for hundreds of megabytes worth >> of information that is signed could easily be a bottleneck. >> > You're not doing it that often such that it would matter. The only time > you check the entire database is when you have none to start with. > Otherwise you have an incremental update. However, suppose you didn't > want to check the entire database. It would be possible to have > signatures and versions of each EID entry. That would involve a fair > amount more storage overhead, of course, and one would have to wonder if > it were worth it. > > Eliot > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 05 00:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Iw0-0003XH-IZ; Thu, 05 Jul 2007 00:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Ivz-0003XC-Ry for ram@iab.org; Thu, 05 Jul 2007 00:27:15 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Ivu-000478-Sq for ram@iab.org; Thu, 05 Jul 2007 00:27:15 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 04 Jul 2007 21:27:03 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGoQjEarR7O6h2dsb2JhbACPKgEBCQ4s X-IronPort-AV: i="4.16,501,1175497200"; d="scan'208"; a="383640608:sNHT145027904" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l654R2Nf024715; Wed, 4 Jul 2007 21:27:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l654Qvmo007028; Thu, 5 Jul 2007 04:26:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 21:26:55 -0700 Received: from [192.168.0.5] ([10.21.118.217]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 21:26:55 -0700 In-Reply-To: <468B6EB7.4040505@gmail.com> References: <468B6EB7.4040505@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Question about lisp-cons aggregation Date: Wed, 4 Jul 2007 21:26:53 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Jul 2007 04:26:55.0409 (UTC) FILETIME=[B8093A10:01C7BEBC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2041; t=1183609622; x=1184473622; 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[RAM]=20Question=20about=20lisp-cons=20aggregation |Sender:=20; bh=cb9ISuCD9iKaPZIhmKswgdAeW3lGenBuAzOAvdyfd1U=; b=Wq5e6uNUcgdt/2X+Sa7Zc8Tn04naYKv5NKo7oIJ0ekr6OJh4xQEpkvr3KjcgDamzyFlkj33p r1cLbaZjpsLUlp1RTsaZyBpH9vL8q0EV7Zuo0Ck9PaAAD9Qz4woN2XDB; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > draft-meyer-lisp-cons doesn't seem to have made it through > the system yet, but I have some points. Right, we posted it yesterday. > I'm probably being stupid, but it seems that you don't > actually define what you mean by an aggregate, or describe > the algorithm for forming an aggregate. Now that may be well > known within routing protocols, but I think you need to > either explain it in this draft or give a precise reference. An aggregate in the CONS context is simple an EID-prefix. So for example, a CAR will have a much of mappings that can fit into a power- of-2 less-specific prefix. That is the prefix the CAR advertises to the level-1 CDR as an "aggregate". > Specifically, in section 4 just after Fig. 2 you say > >> The CARs aggregate these EID-prefixes, > > and I think that needs an algorithmic description. Okay, we will try to improve the text. > In 5.3.1 you say > >> If the CAR finds a match, it next checks to see if the EID- >> prefix is >> the last prefix in an aggregate or is the only EID-prefix in an >> aggregate. > > I think you need to define what "the last prefix in an aggregate" > means; otherwise this description is also not algorithmic. Okay. > I also don't understand how this process (removing an EID-prefix) > fails to create black holes. Because all more-specifics for an CAR advertised aggregate falls into it. So if there are no more-specifics, the aggregate doesn't need to be advertised so the Map-Request that would have been forwarded along this path would cause the CDR to send an Unreachable message to the Reqeusting-CAR. > Incidentally, I noticed two cases of IPv4ism in section 5.1: > a reference to /32 (instead of "/32 or /128") and a default prefix > of 0.0.0.0/0 (instead of "0.0.0.0/0 or 0::/0"). We will fix. > Overall I like this approach more than NERD. Although it requires > more innovation, it seems to match the problem and minimize > dependencies. Thanks for your input. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 05 00:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6J9G-0007hy-PF; Thu, 05 Jul 2007 00:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6J9F-0007hr-Og for ram@iab.org; Thu, 05 Jul 2007 00:40:57 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6J9A-00078N-GY for ram@iab.org; Thu, 05 Jul 2007 00:40:57 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 0BE1A59DA1; Thu, 5 Jul 2007 14:40:47 +1000 (EST) Message-ID: <468C7643.6040305@firstpr.com.au> Date: Thu, 05 Jul 2007 14:40:35 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> <468A4554.5030105@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [RAM] LISP-01 I-D X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, You wrote: > The LISP-01 draft should be in the ID directory today. If people can't > wait, I can post it here. Please post your new version to the RAM list soon - I am keen to read it. In my experience I-D's can take a day or two to appear on the IETF site. http://tools.ietf.org/html/draft-farinacci-lisp - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 05 01:11:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Jck-0002om-Ep; Thu, 05 Jul 2007 01:11:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Jci-0002gC-C1 for ram@iab.org; Thu, 05 Jul 2007 01:11:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Jcc-00056e-QF for ram@iab.org; Thu, 05 Jul 2007 01:11:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Jul 2007 22:11:18 -0700 X-IronPort-AV: i="4.16,501,1175497200"; d="txt'?scan'208"; a="176850131:sNHT202106025" 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 l655BIsJ024352; Wed, 4 Jul 2007 22:11:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l655BDka014442; Thu, 5 Jul 2007 05:11: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, 4 Jul 2007 22:11:12 -0700 Received: from [192.168.0.5] ([10.21.118.217]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 22:11:11 -0700 In-Reply-To: <468C7643.6040305@firstpr.com.au> References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> <468A4554.5030105@cisco.com> <468C7643.6040305@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/mixed; boundary=Apple-Mail-7--853360231 Message-Id: <37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com> From: Dino Farinacci Date: Wed, 4 Jul 2007 22:11:09 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Jul 2007 05:11:11.0777 (UTC) FILETIME=[E75AD110:01C7BEC2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=80839; t=1183612278; x=1184476278; 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=20LISP-01=20I-D |Sender:=20; bh=pwHUK1cfIsgwDtpAGp1s5bO/LIjTcoqoxWkINW/0ATI=; b=JD+nXZftMP4+7iO0+B0JupGYeK0KLYKm3xGqtKMfHkK4iU3pdglC0Mj8hhUhQ7eyO2uAQYHU NcWuqtSwg/aaewmJsDqD9zmth45+/oiYTSphPl4c/a58J0j3orfvLRGO; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ee55aaecc4f51e26a5b012c189b5823d Cc: ram@iab.org Subject: [RAM] Re: LISP-01 I-D X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org --Apple-Mail-7--853360231 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed > Please post your new version to the RAM list soon - I am keen to > read it. Enclosed. Dino --Apple-Mail-7--853360231 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0644; name=draft-farinacci-lisp-01.txt Content-Disposition: attachment; filename=draft-farinacci-lisp-01.txt Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Oran Expires: December 30, 2007 D. Meyer cisco Systems June 28, 2007 Locator/ID Separation Protocol (LISP) draft-farinacci-lisp-01.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 December 30, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Farinacci, et al. Expires December 30, 2007 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 Abstract This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 10 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 12 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 12 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 12 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 14 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 16 6.1. Control-Plane Packet Format . . . . . . . . . . . . . . . 16 6.1.1. Map-Request Message Format . . . . . . . . . . . . . . 17 6.1.2. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 18 6.1.3. Map-Reply Message Format . . . . . . . . . . . . . . . 19 6.1.4. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 21 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 21 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 23 7. Router Performance Considerations . . . . . . . . . . . . . . 25 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 26 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 27 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 27 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 28 9. Multicast Considerations . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 37 Farinacci, et al. Expires December 30, 2007 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci, et al. Expires December 30, 2007 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 2. Introduction Many years of discussion about the current IP routing and addressing architecture have noted that its use of a single numbering space (the "IP address") for both host transport session identification and network routing creates scaling issues (see [CHIAPPA] and [RFC1498]). A number of scaling benefits would be realized by separating the current IP address into separate spaces for Endpoint Identifiers (EIDs) and Routing Locators (RLOCs); among them are: 1. Reduction of routing table size in the "default-free zone" (DFZ). Use of a separate numbering space for RLOCs will allow them to be assigned topologically (in today's Internet, RLOCs would be assigned by providers at client network attachment points), greatly improving aggregation and reducing the number of globally-visible, routable prefixes. 2. Easing of renumbering burden when clients change providers. Because host EIDs are numbered from a separate, non-provider- assigned and non-topologically-bound space, they do not need to be renumbered when a client site changes its attachment points to the network. 3. Mobility with session survivability. Because session state is associated with a persistent host EID, it should be possible for a host (or a collection of hosts) to move to a different point in the network topology (whether by changing providers or by physically moving) without disruption of connectivity. 4. Traffic engineering capabilities that can be performed by network elements and do not depend on injecting additional state into the routing system. This will fall out of the mechanism that is used to implement the EID/RLOC split (see Section 4). This draft describes protocol mechanisms to achieve the desired functional separation. For flexibility, the document decouples the mechanism used for forwarding packets from that used to determine EID to RLOC mappings. This work is in response to and intended to address the problem statement that came out of the RAWS effort [RAWS]. This draft focuses on a router-based solution. Building the solution into the network should facilitate incremental deployment of the technology on the Internet. Note that while the detailed protocol specification and examples in this document assume IP version 4 (IPv4), there is nothing in the design that precludes use of the same techniques and mechanisms for IPv6. It should be possible for IPv4 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 Farinacci, et al. Expires December 30, 2007 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 RLOCs. Related work on host-based solutions is described in Shim6 [SHIM6] and HIP [RFC4423]. Related work on other router-based solutons is described in GSE [GSE]. This draft attempts to not compete or overlap with such solutions and the proposed protocol changes are expected to complement a host-based mechanism when Traffic Engineering functionality is desired. Some of the design goals of this proposal include: 1. Minimize required changes to Internet infrastructure. 2. Require no hardware or software changes to end-systems (hosts). 3. Be incrementally deployable. 4. Require no router hardware changes. 5. Minimize router software changes. 6. Avoid or minimize packet loss when EID-to-RLOC mappings need to be performed. There are 4 variants of LISP, which differ along a spectrum of strong to weak dependence on the topological nature and possible need for routability of EIDs. The variants are: LISP 1: where EIDs are routable through the RLOC topology for bootstrapping EID-to-RLOC mappings. [LISP1] LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC mappings; such routing is via a separate topology. LISP 2: where EIDS are not routable and EID-to-RLOC mappings are implemented within the DNS. [LISP2] LISP 3: where non-routable EIDs are used as lookup keys for a new EID-to-RLOC mapping database. Use of Distributed Hash Tables [DHTs] to implement such a database would be an area to explore. Other examples of new mapping database services are [CONS] and [NERD]. This document will focus on LISP 1 and LISP 1.5, both of which rely on a router-based distributed cache and database for EID-to-RLOC mappings. The LISP 2 and LISP 3 mechanisms, which require separate EID-to-RLOC infrastructure, will be documented in additional drafts. Farinacci, et al. Expires December 30, 2007 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 3. Definition of Terms Provider Independent (PI) Addresses: an address block assigned from a pool that is not associated with any service provider and is therefore not topologically-aggregatable in the routing system. Provider Assigned (PA) Addresses: a block of IP addresses that are assigned to a site by each service provider to which a site connects. Typically, each block is sub-block of a service provider CIDR block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multi-homed site acquiring its own, globally-visible prefix. LISP uses only topologically-assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice. Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Endpoint ID (EID): a 32- or 128-bit value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains an destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a hosts "local" IP address. LISP uses PI blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. EID-prefix: A power-of-2 block of EIDs which are allocated to a site by an address allocation authority. EID-prefixes are associated with a set of RLOC addresses which make up a "database mapping". EID-prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the smaller EID- prefix. End-system: is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e. outside of it's routing domain). An Farinacci, et al. Expires December 30, 2007 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 end-system can be a host computer, a switch or router device, or any network appliance. An iPhone. Ingress Tunnel Router (ITR): a router which accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally-routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closest to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP- encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating hosts supplied EID). TE-ITR: is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. Egress Tunnel Router (ETR): a router that accepts an IP packet where destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. TE-ETR: is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. EID-to-RLOC Cache: a short-lived, on-demand database in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the "database", the cache is dynamic, local, and relatively small while and the database is distributed, relatively static, and much global in scope. Farinacci, et al. Expires December 30, 2007 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 EID-to-RLOC Database: a globally, distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to- RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. Recursive Tunneling: when a packet has more than one LISP IP header. Additional layers of tunneling may be employed to implement traffic engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added and the original RLOCs are preserved in the "inner" header. Reencapsulating Tunnels: when a packet has no more than one LISP IP header (two IP headers total) and when it needs to be diverted to new RLOC, an ETR can decapsulate the packet (remove the LISP header) and prepend a new tunnel header, with new RLOC, on to the packet. Doing this allows a packet to be re-routed by the re- encapsulating router without adding the overhead of additional tunnel headers. LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP header, an ITR prepends or an ETR strips. Farinacci, et al. Expires December 30, 2007 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 4. Basic Overview One key concept of LISP is that end-systems (hosts) operate the same way they do today. The IP addresses that hosts use for tracking sockets, connections, and for sending and receiving packets do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Routers continue to forward packets based on IP destination addresses. These addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/forwarding lookups on addresses (RLOCs) in the IP header. This design introduces "Tunnel Routers", which prepend LISP headers on host-originated packets and strip them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet and an egress tunnel router strips the new header. The ITR performs EID-to-RLOC lookups to determine the routing path to the the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: o End-systems (hosts) only know about EIDs. o EIDs are always IP addresses assigned to hosts. o Routers mostly deal with Routing Locator addresses. See details later in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers; preferably, topologically-oriented addresses from provider CIDR blocks. o Routers can use their RLOCs as EIDs but can also be assigned EIDs when performing host functions. Those EIDs MUST NOT be used as RLOCs. When EIDs are used the routeability of them is scoped to within the site. A hybrid use of this, for example is when a router runs the BGP protocol where iBGP peerings may use EIDs and eBGP peerings may use RLOCs. o EIDs are not expected to be usable for end-to-end communication in the absence of an EID-to-RLOC mapping operation. o EID prefixes are likely to be hierarchically assigned in a manner which is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. The Farinacci, et al. Expires December 30, 2007 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 hierarchy is based on a address alocation hierarchy which is not dependent on the network toplogy. o EIDs may also be structured (subnetted) in a manner suitable for local routing within an autonomous system. An additional LISP header may be pre-pended to packets by a transit router (i.e. TE-ITR) when re-routing of the end-to-end path for a packet is desired. An obvious instance of this would be an ISP router that needs to perform traffic engineering for packets in flow through its network. In such a situation, termed Recursive Tunneling, an ISP transit acts as an additional ingress tunnel router and the RLOC it uses for the new prepended header would be either an TE-ETR within the ISP (along intra-ISP traffic engineered path) or in an TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the egress tunnel router might be the last-hop router directly-connected to the destination host. Another example, perhaps for a VPN service out-sourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other tunnel routers is allowed for maximum flexibility. See Section 8 for more details. 4.1. Packet Flow Sequence This section provides an example of the unicast unicast packet flow with the following parameters: o Source host "host1.abc.com" is sending a packet to "host2.xyz.com". o Each site is multi-homed, so each tunnel router has an address (RLOC) assigned from each of the site's attached service provider address blocks. o The ITR and ETR are directly connected to the source and destination, respectively. Client host1.abc.com wants to communicate with server host2.xyz.com: 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. It does a DNS lookup on host2.xyz.com. An A record is returned. This address is used as the destination EID and the locally- Farinacci, et al. Expires December 30, 2007 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 assigned address of host1.abc.com is used as the source EID. An IP packet is built using the EIDs in the IP header and sent to the default router. 2. The default router is configured as an ITR. It prepends a LISP header to the packet, with one of its RLOCs as the source IP address and uses the destination EID from the original packet header as the destination IP address. Subsequent packets continue to behave the same way until a mapping is learned. 3. In LISP 1, the packet is routed through the Internet as it is today. In LISP 1.5, the packet is routed on a different topology which may have EID prefixes distributed and advertised in an aggregatable fashion. In either case, the packet arrives at the ETR. The router is configured to "punt" the packet to the router's control-plane processor. See Section 7 for more details. 4. The LISP header is stripped so that the packet can be forwarded by the router control-plane. The router looks up the destination EID in the router's EID-to-RLOC database (not the cache, but the configured data structure of RLOCs). An EID-to-RLOC Map-Reply message is originated by the egress router and is addressed to the source RLOC from the LISP header of the original packet (this is the ITR). The source RLOC in the IP header of the UDP message is one of the ETR's RLOCs (one of the RLOCs that is embedded in the UDP payload). 5. The ITR receives the UDP message, parses the message (to check for format validity) and stores the EID-to-RLOC information from the packet. This information is put in the ITR's EID-to-RLOC mapping cache (this is the on-demand cache, the cache where entries time out due to inactivity). 6. Subsequent packets from host1.abc.com to host2.xyz.com will have a LISP header prepended with the RLOCs learned from the ETR. 7. The egress tunnel receives these packets directly (since the destination address is one of its assigned IP addresses), strips the LISP header and delivers the packets to the attached destination host. In order to eliminate the need for a mapping lookup in the reverse direction, the ETR gleans RLOC information from the LISP header. Both ITR and the ETR may also influence the decision the other makes in selecting an RLOC. See section Section 6 for more details. Farinacci, et al. Expires December 30, 2007 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 5. Tunneling Details This section describes the LISP Data Message which defines the tunneling header used to encapsulate IPv4 and IPv6 packets which contain EID addresses. Even though the following formats illustrate IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2 combinations are supported as well. 5.1. LISP IPv4-in-IPv4 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Identification |Flags| Fragment Offset | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol =3D 17 | Header Checksum = | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Type | Locator Reach Bits | Nonce ... | LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | ... Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Identification |Flags| Fragment Offset | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. LISP IPv6-in-IPv6 Header Format Farinacci, et al. Expires December 30, 2007 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header=3D17| Hop Limit = | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | \ + Destination Routing Locator + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Type=3D1 | Locator Reach Bits | Nonce ... = | LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | ... Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | \ + Destination EID + \ | | \ + + \ | | Farinacci, et al. Expires December 30, 2007 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions IH Header: is the inner header, preserved from the datagram received from the originating host. The source and destination IP addresses are EIDs. OH Header: is the outer header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to- RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. UDP Header: contains a random source port allocated by the ITR when encapsulating a packet. The destination port MUST be set to the well-known IANA assigned port value 4342. The UDP checksum field MUST be transmitted as 0 and not ignore by the ETR. UDP Length: field contains the original packet's length. For an IPv4 encapsulated packet, the inner header Total Length is copied. For an IPv6 encapsualted packet, the inner header Payload Length plus the size of the IPv6 header (40 bytes) is copied. LISP Type: set to 1 to encode a LISP Data Message. LISP Nonce: is an ITR randomly generated 6-byte value which tests return routability of an ETR echoing back the none in a Map-Reply message. LISP Locator Reach Bits: in the LISP header are set by an ITR to indicate to an ETR the reachability of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Reach Bits are number from 0 to n-1 from the right significant bit of the 12-bit field. When a bit is set to 1, the ITR is indicating to the ETR the RLOC associated with the bit ordinal is reachable. See Section 6.3 for details on how an ITR can determine other site ITRs are reachable. When doing Recursive Tunneling: o The OH header Time to Live field MUST be copied from the IH header Time to Live field. o The OH header Type of Service field SHOULD be copied from the IH header Type of Service field. When doing Re-encapsulated Tunneling: Farinacci, et al. Expires December 30, 2007 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 o The new OH header Time to Live field SHOULD be copied from the stripped OH header Time to Live field. o The new OH header Type of Service field SHOULD be copied from the stripped OH header Type of Service field. Copying the TTL serves two purposes. First it preserves the distance the host intended the packet to travel. And more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. Farinacci, et al. Expires December 30, 2007 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 6. EID-to-RLOC Mapping 6.1. Control-Plane Packet Format When LISP 1 or LISP 1.5 are used, new UDP packet types encode the EID-to-RLOC mappings: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol =3D 17 | Header Checksum = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Routing Locator + Farinacci, et al. Expires December 30, 2007 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LISP UDP-based messages are the Map-Request and Map-Reply messages. These message formats are also used by LISP-CONS [CONS] but are sent over TCP connections instead. However, this specification is the authoritative source for message format definitions for the Map-Request and Map-Reply messages. 6.1.1. Map-Request Message Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record count | Nonce ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Nonce |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-AFI | CAR-AFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating ITR RLOC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating CAR EID-Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec -> | EID mask-len | EID-AFI | EID-prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Vector List | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Farinacci, et al. Expires December 30, 2007 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 Type: 2 (Map-Request) Reserved: Set to 0 on transmission and ignored on receipt. Checksum: A complement of the 1-complements sum of the LISP packet. The checksum MUST be computed and the UDP checksum MUST be set to 0. Record count: The number of records in this request message. A record comprises of what is labeled 'Rec" above and occurs the a number of times equal to Record count. RLOC Count: The number of RLOCs associated with this EID prefix. EID Mask Len: The mask length of the EID prefix. By encoding an EID prefix, a set of RLOCs can be associated with a block of EIDs. Values are between 0 and 32 inclusive. Nonce: A 6-byte random value created by the sender of the Map- Request. A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. See [CONS] for TCP-based Map-Requests. ITR-AFI: Address family of the "Originating ITR RLOC Address" field. CAR-AFI: Address family of the "Originating ITR RLOC Address" field. Originating ITR RLOC Address: Set to 0 for UDP-based messages. See [CONS] for TCP-based Map-Requests. Originating CAR EID-Prefix: Set to 0 for UDP-based messages by an ITR. See [CONS] for TCP-based Map-Requests. EID Mask-length: Mask length for EID prefix. EID-AFI: Address family of EID-prefix according to [RFC2434] EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. 6.1.2. EID-to-RLOC UDP Map-Request Message A Map-Request contains one or more EIDs encoded in prefix format with a Locator count of 0. The EID-prefix MUST NOT be more specific than a cache entry stored from a previously-received Map-Reply. A Map-Request is sent from an ITR when it wants to test an RLOC for Farinacci, et al. Expires December 30, 2007 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 reachability. This is performed by using the RLOC as the destination address for Map-Request message with a randomly allocated source UDP port number and the well-known destination port number 4342. A successful Map-Reply updates the cached set of RLOCs associated with the EID prefix range. Map-Requests MUST be rate-limited. It is recommended that a Map- Request for the same EID-prefix be sent no more than once per second. 6.1.3. Map-Reply Message Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record count | Nonce ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Nonce | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator count | EID mask-len |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-AFI | EID-AFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating ITR RLOC Address | +---> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | EID-prefix | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e /| Priority | Weight | Unused | Loc-AFI | c Loc +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +---> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Vector List | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 3 (Map-Reply) Reserved: Set to 0 on transmission and ignored on receipt. Checksum: A complement of the 1-complements sum of the LISP packet. The checksum MUST be computed and the UDP checksum MUST be set to 0. Farinacci, et al. Expires December 30, 2007 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 Record count: The number of records in this request message. A record comprises of what is labeled 'Rec' above and occurs the number of times equal to Record count. Record TTL: The time in minutes the recipient of the Map-Reply will store the mapping. If the TTL is 0, the entry should be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping. Locator count: The number of Locator entries. A locator entry comprises what is labeled above as 'Loc'. EID mask-len: Mask length for EID prefix. A: The Authoritative bit, when sent by a UDP-based message is always set by the ETR. See [CONS] for TCP-based Map-Replies. ITR-AFI: Address family of the "Originating ITR RLOC Address" field. EID-AFI: Address family of EID-prefix according to [RFC2434]. Originating ITR RLOC Address: Set to 0 for UDP-based messages. See [CONS] for TCP-based Map-Replies. EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. Priority: each RLOC is assigned a priority. Lower values are more preferable. When multiple RLOCs have the same priority, they are used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used. Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance traffic between them. Weight is encoded as a percentage of total packets that match the mapping entry. If a non-zero weight value is used for any RLOC, then all RLOCs must use a non-zero weight value and then the sum of all weight values MUST equal 100. What did the 3rd grader say after Steve Jobs gave an iPhone demo to the class? If a zero value is used for any RLOC weight, then all weights MUST be zero and the receiver of the Map- Reply will decide how to load-split traffic. Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR or router acting as a proxy replier for the EID-prefix. Note that the destination RLOC address MAY be an anycast address if the tunnel egress point may be via more than one physical device. A souce RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast Farinacci, et al. Expires December 30, 2007 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 address (255.255.255.255 or any subnet broadcast address known to the router), and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID. 6.1.4. EID-to-RLOC UDP Map-Reply Message When a data packet triggers a Map-Reply to be sent, the RLOCs associated with the EID-prefix matched by the EID in the original packet destination IP address field will be returned. The RLOCs in the Map-Reply are the globally-routable IP addresses of the ETR but are not necessarily reachable; separate testing of reachability is required. Note that a Map-Reply may contain different EID-prefix granularity (prefix + length) than the Map-Request which triggers it. This might occur if a Map-Request were for a prefix that had been returned by an earlier Map-Reply. In such a case, the requester updates its cache with the new prefix information and granularity. For example, a requester with two cached EID-prefixes that are covered by a Map- Reply containing one, less-specific prefix, replaces the entry with the less-specific EID-prefix. Note that the reverse, replacement of one less-specific prefix with multiple more-specific prefixes, can also occur but not by removing the less-specific prefix rather by adding the more-specific prefixes which during a lookup will override the less-specific prefix. Replies SHOULD be sent for an EID-prefix no more often than once per second to the same requesting router. For scalability, it is expected that aggregation of EID addresses into EID-prefixes will allow one Map-Reply to satisfy a mapping for the EID addresses in the prefix range thereby reducing the number of Map-Request messages. The addresses for a Data message or Map-Request message are swapped and used for sending the Map-Reply. The UDP source and destination ports are swapped as well. That is, the source port in the UDP header for the Map-Reply is set to the well-known UDP port number 4342. 6.2. Routing Locator Selection Both client-side and server-side may need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply messages. Alternatively, RLOC information may be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. Farinacci, et al. Expires December 30, 2007 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 The following enumerates different scenarios for choosing RLOCs and the controls that are available: o Server-side returns one RLOC. Client-side can only use one RLOC. Server-side has complete control of the selection. o Server-side returns a list of RLOC where a subset of the list has the same best priority. Client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o Server-side sets weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server-side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs are unreachable. o Either side (more likely on the server-side ETR) decides not to send an Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner header source EID and the outer header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server- side ETR must assume each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-prefix encoding cannot be conveyed in data packets, the EID-to-RLOC cache on tunnel routers can grow to be very large. RLOCs that appear in EID-to-RLOC Map-Reply messages are considered reachable. The Map-Reply and the database mapping service does not provide any reachability status for Locators. This is done outside of the mapping service. See next section for details. Farinacci, et al. Expires December 30, 2007 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 6.3. Routing Locator Reachability There are 4 methods for determining when a Locator is either reachable or has become unreachable: 1. Locator reachability is determined by an ETR by examining the Loc-Reach-Bits from a LISP header of a Data Message which is provided by an ITR when an ITR encapsulates data. 2. Locator unreachability is determined by an ITR by receiving ICMP Network or Host Unreachable messages. 3. ETR unreachability is determined when a host sends an ICMP Port Unreachable message. 4. Locator reachability is determined by receiving a Map-Reply message from a ETR's Locator address in response to a previously sent Map-Request. When determining Locator reachability by examining the Loc-Reach-Bits from the LISP Data Message, an ETR will receive up to date status from the ITR closest to the Locators at the source site. The ITRs at the source site can determine reachability when running their IGP at the site. When the ITRs are deployed on CE routers, typically a default route is injected into the site's IGP from each of the ITRs. If an ITR goes down, the CE-PE link goes down, or the PE router goes down, the CE router withdraws the default route. This allows the other ITRs at the site to determine one of the Locators has gone unreachable. The Locators listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Reach-Bits in a LISP Data Message are numbered from 0 to n-1 starting with the least signfiicant bit numbered as 0. So, for example, if the ITR with locator listed as the 3rd Locator position in the Map-Reply goes down, all other ITRs at the site will have the 3rd bit from the right cleared (the bit that corresponds to ordinal 2). When an ETR decapsulates a packet, it will look for a change in the Loc-Reach-Bits value. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to the Locator that has just gone unreachable. It can start using the Locator again when the bit that corresponds to the Locator goes from 0 to 1. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators provided they are injected a stub links into the IGP. This is typically done when a /32 address is configured on a loopback interface. Farinacci, et al. Expires December 30, 2007 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 When ITRs receive ICMP Network or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators which are described in Locator lists of Map-Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Unreachable messages. Optionally, an ITR can send a Map-Request to a Locator and if a Map- Reply is returned, reachability of the Locator has been achieved. Obviously, sending such probes increases the number of control messages originated by tunnel routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When an Locator has been determined unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with priority 255. The ITR can later test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets since that increases the risk of packet loss for end-to-end sessions. Farinacci, et al. Expires December 30, 2007 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 7. Router Performance Considerations LISP is designed to be very hardware-based forwarding friendly. By doing tunnel header prepending [RFC1955] and stripping instead of re- writing addresses, existing hardware could support the forwarding model with little or no modification. Where modifications are required, they should be limited to re-programming existing hardware rather than requiring expensive design changes to hard-coded algorithms in silicon. A few implementation techniques can be used to incrementally implement LISP: o When a tunnel encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control-plane to get packets from the hardware. This may be mitigated by creating special FIB entries for the EID-prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control-plane processing should be performed. The forwarding logic of testing for particular IP protocol number value is not necessary. No changes to existing, deployed hardware should be needed to support this. o On an ITR, prepending a new IP header is as simple as adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Many routers that support GRE tunneling [RFC3056] or 6to4 tunneling [RFC2784] can already support this action. o When a received packet's outer destination address contains an EID which is not intended to be forwarded on the routable topology (i.e. LISP 1.5), the source address of a data packet or the router interface with which the source is associated (the interface from which it was received) can be associated with a VRF (Virtual Routing/Forwarding), in which a different (i.e. non- congruent) topology can be used to find EID-to-RLOC mappings. Farinacci, et al. Expires December 30, 2007 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 8. Deployment Scenarios This section will explore how and where ingress and ETRs can be deployed and will discuss the pros and cons of each deployment scenario. There are two basic deployment tradeoffs to consider: centralized versus distributed caches and flat, recursive, or re- encapsulating tunneling. When deciding on centralized versus distributed caching, the following issues should be considered: o Are the tunnel routers spread out so that the caches are spread across all the memories of each router? o Should management "touch points" be minimized by choosing few tunnel routers, just enough for redundancy? o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, more ETRs does require more management since EID-prefix-to-RLOC mappings need to be explicitly configured. When deciding on flat, recursive, or re-encapsulation tunneling, the following issues should be considered: o Flat tunneling implements a single tunnel between source site and destination site. This generally offers better paths between sources and destinations with a single tunnel path. o Recursive tunneling is when tunneled traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control since the site is prepending a new tunnel header. In the case of TE-based tunneling, the site may have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. o The technique of re-encapsulation ensures that packets only require one tunnel header. So if a packet needs to be rerouted, it is first decapsulated by the ETR and then re-encapsulated with a new tunnel header using a new RLOC. The next sub-sections will describe where tunnel routers can reside in the network. Farinacci, et al. Expires December 30, 2007 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 8.1. First-hop/Last-hop Tunnel Routers By locating tunnel routers close to hosts, the EID-prefix set is at the granularity of an IP subnet. So at the expense of more EID- prefix-to-RLOC sets for the site, the caches in each tunnel router can remain relatively small. But caches always depend on the number of non-aggregated EID destination flows active through these tunnel routers. With more tunnel routers doing encapsulation, the increase in control traffic grows as well: since the EID-granularity is greater, more Map-Requests and replies are traveling between more routers. The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios then their core router counterparts. Memory is typically less expensive in these devices and fewer routes are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing state. LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices as well. 8.2. Border/Edge Tunnel Routers Using customer-edge (CE) routers for tunnel endpoints allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE routers for that site. This offers the opposite benefit of the first-hop/last-hop tunnel router scenario: the number of mapping entries and network management touch points are reduced, allowing better scaling. One disadvantage is that less of the network's resources are used to reach host endpoints thereby centralizing the point-of-failure domain and creating network choke points at the CE router. Note that more than one CE router at a site can be configured with the same IP address. In this case an RLOC is an anycast address. This allows resilency between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Farinacci, et al. Expires December 30, 2007 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 8.3. ISP Provider-Edge (PE) Tunnel Routers Use of ISP PE routers as tunnel endpoint routers gives an ISP control over the location of the egress tunnel endpoints. That is, the ISP can decide if the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. The advantage of this case is that two or more tunnel headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. An obvious disadvantage is that the end site has no control over where its packets flow or the RLOCs used. As mentioned in earlier sections a combination of these scenarios is possible at the expense of extra packet header overhead, if both site and provider want control, then recursive or re-encapsulating tunnels are used. Farinacci, et al. Expires December 30, 2007 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 9. Multicast Considerations A multicast group address, as defined in the original Internet architecture is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determines where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. And the outer IP header (the destination Routing Locator address), prepended by a LISP router, will use the same group address as the destination Routing Locator. Having said that, only the source EID and source Routing Locator needs to be dealt with. Therefore, an ITR merely needs to put its own IP address in the source Routing Locator field when prepending the outer IP header. This source Routing Locator address, like any other Routing Locator address MUST be globally routable. Therefore, an EID-to-RLOC mapping does not need to be performed by an ITR when a received data packet is a multicast data packet or when processing a source-specific Join (either by IGMPv3 or PIM). But the source Routing Locator is decided by the multicast routing protocol in a receiver site. That is, an EID to Routing Locator translation is done at control-time. Another approach is to have the ITR not encapsulate a multicast packet and allow the the host built packet to flow into the core even if the source address is allocated out of the EID namespace. If the RPF-Vector TLV [RPFV] is used by PIM in the core, then core routers can RPF to the ITR (the Locator address which is injected into core routing) rather than the host source address (the EID address which is not injected into core routing). Farinacci, et al. Expires December 30, 2007 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 10. Security Considerations We believe that most of the security mechanisms will be part of the mapping database service when using control-plane procedures for obtaining EID-to-RLOC mappings. For data-plane triggered mappings, as described in this specification, protection is provided against ETR spoofing by using Return- Routeability mechanisms evidenced by the use of a 6-byte Nonce field in the LISP encapsulation header. The nonce, coupled with the ITR accepting only solicited Map-Replies goes a long way towards providing decent authentication. LISP does not rely on a PKI infrastructure or a more heavy weight authentication system. These systems challenge the scalability of LISP which was a primary design goal. DoS attack prevention will depend on implementations rate- limiting of Map-Requests and Map-Replies to the control-plane as well as rate- limiting the number of data triggered Map-Replies. Farinacci, et al. Expires December 30, 2007 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 11. Prototype Plans and Status The operator community has requested that the IETF take a practical approach to solving the scaling problems associated with global routing state growth. This document offers a simple solution which is intended for use in a pilot program to gain experience in working on this problem. The authors hope that publishing this specification will allow the rapid implementation of multiple vendor prototypes and deployment on a small scale. Doing this will help the community: o Decide whether a new EID-to-RLOC mapping database infrastructure is needed or if a simple, UDP-based, data-triggered approach is flexible and robust enough. o Experiment with provider-independent assignment of EIDs while at the same time decreasing the size of DFZ routing tables through the use of topologically-aligned, provider-based RLOCs. o Determine whether multiple levels of tunneling can be used by ISPs to achieve their Traffic Engineering goals while simultaneously removing the more specific routes currently injected into the global routing system for this purpose. o Experiment with mobility to determine if both acceptable convergence and session survivability properties can be scalably implemented to support both individual device roaming and site service provider changes. Here are a rough set of milestones: 1. Stabilize this draft by Summer 2007 Chicago IETF. 2. Start implementations to report on by Summer 2007 Chicago IETF. 3. Start pilot deployment between summer and fall IETFs. Report on deployment at Fall 2007 Vancouver IETF. 4. Achieve multi-vendor interoperability by Fall 2007 Vancouver IETF. 5. Consider prototyping other database lookup schemes, be it DNS, DHTs, CONS, NERD, or other mechanisms by Fall 2007 IETF. As of this writing the following accomplishments have been achieved: Farinacci, et al. Expires December 30, 2007 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 1. A unit tested software switching implementation has been completed for both IPv4 and IPv6 encapsulations for LISP 1 and LISP 1.5 functionality. 2. Dave Meyer and Vince Fuller are testing the implementation this summer. 3. An implementation of LISP-CONS is under way. Please contact authors if interested in doing an implementation and want to interoperability test with our implementation. Farinacci, et al. Expires December 30, 2007 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 12. References 12.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993. [RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. 12.2. Informative References [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", Internet- Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-00.txt (work in progress), June 2007. [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing Algorithms for DHTs: Some Open Questions", PDF file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. [GSE] "GSE - An Alternate Addressing Architecture for IPv6", draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. Farinacci, et al. Expires December 30, 2007 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, "Locator/ID Separation Protocol (LISP1) [Routable ID Version]", Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, October 2006. [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, "Locator/ID Separation Protocol (LISP2) [DNS-based Version]", Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt, November 2006. [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-01.txt (work in progress), June 2007. [RAWS] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", draft-iab-raws-report-00.txt (work in progress), November 2006. [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector TLV", draft-ietf-pim-rpf-vector-03.txt (work in progress), October 2006. [SHIM6] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim protocol", draft-ietf-shim6-proto-06.txt (work in progress), October 2006. Farinacci, et al. Expires December 30, 2007 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 Appendix A. Acknowledgments The authors would like to gratefully acknowledge many people who have contributed discussion and ideas to the making of this proposal. They include Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Darrel Lewis, Vijay Gill, Geoff Huston, David Conrad, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Scott Brim, and Eliot Lear. In particular, we would like to thank Dave Meyer for his clever suggestion for the name "LISP". ;-) Farinacci, et al. Expires December 30, 2007 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Dave Oran cisco Systems 7 Ladyslipper Lane Acton, MA USA Email: oran@cisco.com Dave Meyer cisco Systems 170 Tasman Drive San Jose, CA USA Email: dmm@cisco.com Farinacci, et al. Expires December 30, 2007 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). 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 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Farinacci, et al. Expires December 30, 2007 [Page 37] =0C --Apple-Mail-7--853360231 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-7--853360231 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --Apple-Mail-7--853360231-- From ram-bounces@iab.org Thu Jul 05 11:00:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Sp4-0005vj-DD; Thu, 05 Jul 2007 11:00:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Sp3-0005uy-Hh for ram@iab.org; Thu, 05 Jul 2007 11:00:45 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Sox-0004Mc-TD for ram@iab.org; Thu, 05 Jul 2007 11:00:45 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l65F0Zve001176; Thu, 5 Jul 2007 08:00:36 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l65F0Zdg001175; Thu, 5 Jul 2007 08:00:35 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 5 Jul 2007 08:00:35 -0700 From: David Meyer To: Dino Farinacci Subject: Re: [RAM] Question about lisp-cons aggregation Message-ID: <20070705150035.GB1101@1-4-5.net> References: <468B6EB7.4040505@gmail.com> 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 laugh and I cry, and I'm haunted by...Things I never meant nor wished to say" -- Bob Dylan, "When The Deal Goes Down" User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1781549294==" Errors-To: ram-bounces@iab.org --===============1781549294== 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 On Wed, Jul 04, 2007 at 09:26:53PM -0700, Dino Farinacci wrote: > >draft-meyer-lisp-cons doesn't seem to have made it through > >the system yet, but I have some points. >=20 > Right, we posted it yesterday. >=20 > >I'm probably being stupid, but it seems that you don't > >actually define what you mean by an aggregate, or describe > >the algorithm for forming an aggregate. Now that may be well > >known within routing protocols, but I think you need to > >either explain it in this draft or give a precise reference. >=20 > An aggregate in the CONS context is simple an EID-prefix. So for =20 > example, a CAR will have a much of mappings that can fit into a power-=20 > of-2 less-specific prefix. That is the prefix the CAR advertises to =20 > the level-1 CDR as an "aggregate". >=20 > >Specifically, in section 4 just after Fig. 2 you say > > > >>The CARs aggregate these EID-prefixes, > > > >and I think that needs an algorithmic description. >=20 > Okay, we will try to improve the text. Yes. We've had quite a few comments on that text, so we need to tighten that up. > >In 5.3.1 you say > > > >> If the CAR finds a match, it next checks to see if the EID-=20 > >>prefix is > >> the last prefix in an aggregate or is the only EID-prefix in an > >> aggregate. > > > >I think you need to define what "the last prefix in an aggregate" > >means; otherwise this description is also not algorithmic. >=20 > Okay. Yes, and good point Brian. > >I also don't understand how this process (removing an EID-prefix) > >fails to create black holes. >=20 > Because all more-specifics for an CAR advertised aggregate falls into =20 > it. So if there are no more-specifics, the aggregate doesn't need to =20 > be advertised so the Map-Request that would have been forwarded along =20 > this path would cause the CDR to send an Unreachable message to the =20 > Reqeusting-CAR. >=20 > >Incidentally, I noticed two cases of IPv4ism in section 5.1: > >a reference to /32 (instead of "/32 or /128") and a default prefix > >of 0.0.0.0/0 (instead of "0.0.0.0/0 or 0::/0"). >=20 > We will fix. Yep, another good catch Brian. > >Overall I like this approach more than NERD. Although it requires > >more innovation, it seems to match the problem and minimize =20 > >dependencies. >=20 > Thanks for your input. Yes, thanks Brian. Dave --V0207lvV8h4k8FAm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGjQeTORgD1qCZ2KcRAgaEAJ9bF1josLVhmy7XlAfrpOUJoEG9bgCgg3tS WpgBxiNDWLfgjGixHkmY8ts= =twBx -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- --===============1781549294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1781549294==-- From ram-bounces@iab.org Thu Jul 05 13:54:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6VXD-0008CO-96; Thu, 05 Jul 2007 13:54:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6VXC-00089c-4O for ram@iab.org; Thu, 05 Jul 2007 13:54:30 -0400 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6VWA-0002Z1-B1 for ram@iab.org; Thu, 05 Jul 2007 13:54:29 -0400 Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53])by smtp.uc3m.es (Postfix) with ESMTP id 8584D69DE7; Thu, 5 Jul 2007 19:53:21 +0200 (CEST) In-Reply-To: <37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com> References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E241 54@muada.com> <468A4554.5030105@cisco.com><468C7643.6040305@firstpr.com.au> <37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <21051657-BA9F-4DEE-9425-1DF772245212@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Re: LISP-01 I-D Date: Thu, 5 Jul 2007 19:53:20 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-12.7576 TC:1F TRN:42 TV:3.6.1039(15280.003) 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-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi dino, thanks for the draft just took a quick read on this.... One comment: As i understand it, the new version of LISP described in this 01 =20 version of the draft, no longer uses pure IP in IP tunneling, but =20 adds a LISP header to the packets (which contains the nonce for =20 security reasons) right? In section 7, it is stated that: 7. Router Performance Considerations LISP is designed to be very hardware-based forwarding friendly. By doing tunnel header prepending [RFC1955] and stripping instead of =20= re- writing addresses, existing hardware could support the forwarding model with little or no modification. MB> in the new version, not only the IP header needs to be added but =20 also the LISP header, so i guess this is not the only action that =20 needs to be performed. Would this still be hardware friendly meaning =20 that you could do little reprogramming of the software in the router =20 to support that? I mean, this appending of the LISP header is =20 supposed to be done for every data packet, right? In the previous =20 version, when IP in IP tunneling was used, i guess the IP in IP =20 encapsulation was already available in hardware, but i guess that the =20= new LISP header will need to be added to the hardware? Where modifications are required, they should be limited to re-programming existing hardware rather than requiring expensive design changes to hard-coded algorithms in silicon. A few implementation techniques can be used to incrementally implement LISP: o On an ITR, prepending a new IP header is as simple as adding more bytes to a MAC rewrite string and prepending the string as =20 part of the outgoing encapsulation procedure. Many routers that support GRE tunneling [RFC3056] or 6to4 tunneling [RFC2784] can already support this action. MB> same applies here, not only adding the outer IP header is needed =20 but also the new LISP header needs to be added Regards, marcelo El 05/07/2007, a las 7:11, Dino Farinacci escribi=F3: >> Please post your new version to the RAM list soon - I am keen to >> read it. > > Enclosed. > > Dino > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 05 22:50:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dtT-0002HQ-Ky; Thu, 05 Jul 2007 22:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dtS-0002HL-V7 for ram@iab.org; Thu, 05 Jul 2007 22:50:02 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6dtO-000380-0Z for ram@iab.org; Thu, 05 Jul 2007 22:50:02 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 2F02959DDD; Fri, 6 Jul 2007 12:49:53 +1000 (EST) Message-ID: <468DADC4.4010609@firstpr.com.au> Date: Fri, 06 Jul 2007 12:49:40 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E241 54@muada.com> <468A4554.5030105@cisco.com><468C7643.6040305@firstpr.com.au> <37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com> <21051657-BA9F-4DEE-9425-1DF772245212@it.uc3m.es> In-Reply-To: <21051657-BA9F-4DEE-9425-1DF772245212@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Subject: [RAM] Re: LISP-01 I-D X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org My understanding of LISP-01 is that LISP-00's IP-in-IP encapsulation is not used at all, but that the original packet becomes part of a new UDP packet. The UDP packet's contents begin (page 12) with a "LISP header", but this is not a header in the sense of an IP, TCP or UDP header. UDP packets are also used for messages between ITRs and ETRs. Similarly formatted messages are used with TCP, to the same port number as the UDP messages, for the LISP-CONS system. After reading LISP-01 I think that Ivip, as I am developing it, has less and less in common with LISP-00. Now that LISP-01 has adopted UDP instead of IP-in-IP - and since I think IP-in-IP is just fine for Ivip - there is even less in common. What Ivip takes from LISP is some vital basic concepts: Using existing IP address space in two ways - some addresses as "Ivip-mapped addresses" ("EIDs" in LISP) where packets addressed to these are tunneled to some other IP address (an "RLOC" in LISP). A large number of ITRs to do the encapsulation. ETRs near wherever hosts with Ivip-mapped addresses are located. Some kind of push and/or pull global distributed database to control the operation of ITRs. The aims of providing portability of addresses, down to single IP address granularity (at least for IPv4) and multihoming. A list of differences between LISP and Ivip would be much longer. Probably in late August I will be able to create one or more Ivip I-Ds with more fully-baked ideas - with a more cohesive presentation. I will continue to write up my ideas for this list for those who are interested in reading fresh ideas. This is primarily to help people who are devising their own schemes and want to copy or improve on my ideas - or to avoid them! I see this as the brainstorming phase, with this RAM list the place where we throw ideas into the pot, combine them in different ways, critique and improve upon them etc. Some of what I write may be applicable to some LISP variants - but I am concentrating on what I think are more expansive goals, with a more incrementally deployable scheme, rather than trying to contribute directly to LISP. Hopefully writing these ideas up on this public web-archived mailing list will mean anything which might have been patentable will no longer be so. If even one of my ideas winds up being part of the final system, my efforts will have been worthwhile. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 02:27:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hI0-0005cF-SM; Fri, 06 Jul 2007 02:27:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hHz-0005VR-KV for ram@iab.org; Fri, 06 Jul 2007 02:27:35 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6hHv-0005c2-4y for ram@iab.org; Fri, 06 Jul 2007 02:27:35 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2007 23:27:30 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFZ9jUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,506,1175497200"; d="scan'208"; a="500555035:sNHT30488700" 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 l666RUDB009380; Thu, 5 Jul 2007 23:27:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l666RRka004829; Fri, 6 Jul 2007 06:27:28 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); Thu, 5 Jul 2007 23:27:27 -0700 Received: from [192.168.0.5] ([10.21.114.132]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 23:27:27 -0700 In-Reply-To: <21051657-BA9F-4DEE-9425-1DF772245212@it.uc3m.es> References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E241 54@muada.com> <468A4554.5030105@cisco.com><468C7643.6040305@firstpr.com.au> <37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com> <21051657-BA9F-4DEE-9425-1DF772245212@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: LISP-01 I-D Date: Thu, 5 Jul 2007 23:27:24 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 06 Jul 2007 06:27:27.0192 (UTC) FILETIME=[B8ED7D80:01C7BF96] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3597; t=1183703250; x=1184567250; 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[RAM]=20Re=3A=20LISP-01=20I-D |Sender:=20; bh=qE4Lyce0x565nM8oibfVIhk9bC2KGo/Jl8tTNuXOl4o=; b=aZSMjTV1ISzZ5cO3DzutpiQrRIn7YT5n8/3SOeVeCgL+6TosZLKItaLVp17B9b9TyTIWTzM1 wdT9j/yMiCO5wBOBNvGa1NlchxHkp94oR4kjq1Mao8rh2fq8z2wD/Rgb; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > As i understand it, the new version of LISP described in this 01 > version of the draft, no longer uses pure IP in IP tunneling, but > adds a LISP header to the packets (which contains the nonce for > security reasons) right? That is correct. We are using UDP encapsulation with a LISP header for the following reasons: o Get through firewalls o ITR hashes on inner header to produce a source port LAG router can hash on o Can carry nonce for ETR anti-spoofing o Can carry Locator reachability bits > In section 7, it is stated that: > > 7. Router Performance Considerations > > LISP is designed to be very hardware-based forwarding friendly. By > doing tunnel header prepending [RFC1955] and stripping instead > of re- > writing addresses, existing hardware could support the forwarding > model with little or no modification. > > MB> in the new version, not only the IP header needs to be added > but also the LISP header, so i guess this is not the only action > that needs to be performed. Would this still be hardware friendly > meaning that you could do little reprogramming of the software in > the router to support that? I mean, this appending of the LISP > header is supposed to be done for every data packet, right? In the > previous On the ITR, yes if you can preload an encapsulation string that contains the outer IP header, the UDP header, and the LISP header. There is a per-packet selection of the source-port but we felt it was important enough to make LAGs work well in the core (which use 5- tuple hashing to load-split traffic over the members of the LAG). The locator reachability bits and the nonce for a resolved EID entry can be preloaded in the encapsulation string. > version, when IP in IP tunneling was used, i guess the IP in IP > encapsulation was already available in hardware, but i guess that > the new LISP header will need to be added to the hardware? Well what was proposed (IP protocol number 4) isn't in a lot of hardware. GRE and L2TP are the popular encapsulations. > Where modifications are > required, they should be limited to re-programming existing > hardware > rather than requiring expensive design changes to hard-coded > algorithms in silicon. Right. But let's first solve the problems we need to solve. If ITRs and ETRs are placed at CE routers, the performance requirement isn't as strong as in other parts of the network (you would need around a 1 Gig of forwarding performance which can be done in software these days). > A few implementation techniques can be used to incrementally > implement LISP: > > > o On an ITR, prepending a new IP header is as simple as adding > more > bytes to a MAC rewrite string and prepending the string as > part of > the outgoing encapsulation procedure. Many routers that support > GRE tunneling [RFC3056] or 6to4 tunneling [RFC2784] can already > support this action. > > MB> same applies here, not only adding the outer IP header is > needed but also the new LISP header needs to be added Right, like I said above, you just need to add more bytes. The problem is on the ETR that has to parse the new format. Typically this is either done via: o Hardwired silicon (in an ASIC). o In software using general purpose processors. o In microcode for line-rate performance. In the later 2 cases, it is much easier to rev the product. > Regards, marcelo Thanks again for your comments, Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 04:17:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6j0H-0002Jw-Dh; Fri, 06 Jul 2007 04:17:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6j0F-0002Ji-P4 for ram@iab.org; Fri, 06 Jul 2007 04:17:23 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6j0B-0007NF-7A for ram@iab.org; Fri, 06 Jul 2007 04:17:23 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 7165459DA2; Fri, 6 Jul 2007 18:17:15 +1000 (EST) Message-ID: <468DFA7E.7020005@firstpr.com.au> Date: Fri, 06 Jul 2007 18:17:02 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] draft-lear-lisp-nerd-01 References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> In-Reply-To: <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Regarding the centralised nature of NERD, Iljitsch van Beijnum wrote: > I REALLY don't like this. Whenever stuff comes together in a central > place, that means the people that run that place are important, there > need to be policies, arbitrary restrictions pop up etc etc. In "4 User-interface and delegation tree for central database (LISP/Ivip)" and "5 Database <--> ITR push, pull and notify" I also depicted a central database. I will post a reply to the second message with a decentralised alternative. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 04:45:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jRH-00045C-9w; Fri, 06 Jul 2007 04:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jRF-00043w-Sg for ram@iab.org; Fri, 06 Jul 2007 04:45:17 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6jR9-000189-TD for ram@iab.org; Fri, 06 Jul 2007 04:45:17 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id AED9A59DA2; Fri, 6 Jul 2007 18:45:06 +1000 (EST) Message-ID: <468E0106.8040007@firstpr.com.au> Date: Fri, 06 Jul 2007 18:44:54 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] 5 Database <--> ITR push, pull and notify References: <46890ECE.2030309@firstpr.com.au> In-Reply-To: <46890ECE.2030309@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here is a decentralised alternative to what I proposed - to take the place of the "Distributed redundant central database" and to remove the need to send regular dumps of the database through the replicator system. In this new approach, the replicators, ITRDs and QSDs are doing much the same thing as before, but the replicators only carry real-time updates. Rather than a single stream, there are multiple streams, each stream carrying updates for one of the Ivip system's "master-subnets". Multiple companies, organisations etc. which have one or more "master-subnets" in the Ivip system each have their own UAS (Update Authorisation Server) systems, which in themselves would be some kind of redundant pair or set of servers which behaved as one and was not subject to a single point of failure. The diagram in the message a few days ago "4 User-interface and delegation tree for central database (LISP/Ivip)" shows how the UAS-X of company X delegates control of different sections of this "master-subnet" and gets all the updates within a fraction of a second of the end-user's making the changes. The UAS-X (or redundant set of such servers) is the central store of mapping database for this "master-subnet". UAS-X could handle multiple separate "master-subnets" but this example only considers one IPv4 "master-subnet" 20.0.0.0/14. There could be potentially large number of such UAS systems, maybe hundreds or up to tens of thousands. Ideally there would be no more than a few dozen or a few hundred. Each UAS periodically, say ever 10 minutes, generates a compressed "dump" file of its database and makes it available for download by HTTP or FTP on multiple redundant servers. Each dump file has a timestamp. There needs to be some crypto system so that ITRDs and QSDs can check the hash of the dump file they download against some signed record of its proper value. There also needs to be some crypto validation of the dump messages - which I haven't thought about yet. Each UAS continually generates a UDP stream of updates, also timestamped. One of the messages in that stream may be "a dump file was generated now". In practice, the UAS system generates several identical streams from different locations. Maybe it generates an update message as soon as the incoming updates fill a UDP packet or after one second elapses. If no updates come in for ten seconds, maybe it sends a time-stamped update message anyway, with no updates. Each message needs a 64 bit sequence number, and a 32 bit or similar identifier for which master-subnet it is updating the mapping of. The distributed system of "replicators" is configured to replicate the contents of the update stream produced by UAS-X. A newly booted ITRD (Ingress Tunnel Router with full database) or QSD (Query Server with full Database) performs the following procedure, for each of the master-subnets in the Ivip system. The ITRD or QSD is receiving from the replicator system many streams of updates, including for the master-subnet in question, which is the one coming from UAS-X. (UAS-X could also be responsible for other master-subnets.) The ITRD/QSD monitors the stream, waiting for the flag which says a dump has been created. It then buffers all subsequent updates in the stream, waits until the dump file is available (which could take some seconds) and then starts to download the dump file. By the time it arrives, perhaps a minute or so of updates will have been buffered. The ITRD/QSC unpacks the dump file into an array in RAM which is 4 bytes for every IP address in the master-subnet. (This is an IPv4 example.) It then applies the buffered updates, bringing the data totally up-to-date with the last received update - and then continues to apply all subsequent update messages as they arrive from the replicator system. Then the ITRD/QSD has an up-to-date copy of UAS-X's database for this master prefix. A QSD can start answering queries about it. A ITRD can advertise this master-subnet's BGP prefix. Soon it will receive packets addressed to this master-subnet and can encapsulate them and forward them to peers towards their ETRs. It would be important to have a close or perfect match between the address range of each "master-subnet" and the BGP advertisement which the ITRs make for it. We want each ITR either advertising or not advertising a BGP prefix. We don't want excessive churn in the advertisements, such as advertising a small subnet (longer prefix) when one master-subnet's mapping is complete and then withdrawing this to advertise a larger subnet when an adjacent master-subnet's mapping data is complete. On the other hand, even if there was a massive master-subnet, like a whole /8, it would be good for some ITRDs to advertise a subset of this, if the total ITR load was to be split among several ITRDs by making each one only handle a subset of Ivip-mapped address space. Periodically the ITRD/QSC could repeat the process of downloading a dump file, building a second array in RAM while the current one is being updated. When the process was complete, it would switch to using the second one for its queries or mapping functions, freeing the first area of memory. Since some or many of the packets coming from the UAS systems to the Level 1 replicators might be short, perhaps they should have a way of combining shorter packets into longer ones, to reduce the total number which need to be sent through the rest of the replicator system. This could be dodgy, since a single missing packet at that point could cause some difference in the streams leaving each Level 1 replicator. If there were 30 Level 1 replicators, UAS-X might generate streams to every such replicator. (Maybe two streams to every Level 1 replicator?) Level 2 replicators typically receive streams from two level 1 replicators for redundancy. There could be hundreds of systems like UAS-X feeding UDP update streams to the Level 1 replicators. This removes any central system for handling the data. It does away with my initial idea of sending regular (say every 10 minutes) full database dumps via the replicator network. So an ITRD would boot and advertise various prefixes as it acquired the full mapping information for each master-prefix. (See "4 User-interface and delegation tree ...".) \ | / } Update information from end-users \ V / } directly or via child UAS systems. \ | / \|/ UAS-X --------->-------------------[Dump server 1] /|\ \ / | \ \----[Dump server 2] / | \ \ / V \ \-- etc. | \ | | 30 UDP streams of identical realtime | updates to the 30 Level 1 replicators | | \ \ | / / Each of the 30 Level 1 replicators gets a \ \ V / / stream from every UAS such as UAS-X - one \ \ | / / stream for every "master-subnet". [Replicator-N] / / | \ \ / / V \ \ Each of 30 Level 1 replicators sends 30 / | | | \ "full streams" (the sum of all the streams | it receives from systems like UAS-X) to | Level 2 replicators. \ \ / \ / \ / Level 2 replicator gets two (ideally [Replicator] identical) full streams from two of the / / | \ \ Level 1 replicators. / / V \ \ / | | | \ | / / \ / \ / \ / Level 3 replicator gets two (ideally [Replicator] identical) full streams from two of the / / | \ \ Level 2 replicators. / / V \ \ / | | | \ All these replicators are cheap | | diskless Linux/BSD servers with one or | | two gigabit Ethernet links. They would | | ideally be located on stub connections | | to transit routers, though the Level \ | | 3 (or 4 etc. if desired) might be at \ | | the border of, or inside, provider and \ | | ASN-end-user networks. \ | \ ITRD QSD ITRDs and QSDs ideally get two or more /|\ ideally identical full feeds of updates - / | \ so generally a missing packet from one / QSC \ is fine since the other stream has the / /|\ \ same packet. / / | / / | Both therefore have a real-time updated / QSC | copy all the databases of all the UASes ITRC /| ITRC like UAS-X. Queries go up to the QSD - / | or to a QSC which has a cached answer. / | Responses go back down to the requester ITFH ITRC which is either a QSC or one of the two "pull and be notified" caching ITRs: ITRC (ITR with Cached mapping) and ITFH (Ingress Tunnel Function in Host). The figures quoted below are wide guesses for the example. Exactly what the database sizes are, the update rates, the data rates of updates etc. depends on many factors. I want a system which can scale to handling one or two billion IPv4 addresses, with some of these having reasonably frequent updates due to mobility - with those mobile end-users paying per update to help finance this system. The average Level 2 replicator gets two full streams from two widely separated Level 1 replicators. This means there can be 450 Level 2 replicators, each of which sends out 30 streams to Level 3 replicators. The pattern continues with 15 * 450 = 6750 Level 3 replicators, each of which has 30 output streams, with most ITRDs and QSDs getting two streams, from widely separated Level 3 replicators. With this push to ITRDs and QSDs, pull via queries to QSDs, and the QSDs notifying (carefully directed push) their child QSCs or ITRCs of an update - those which recently (10 minutes?) made a query whose answer covered one or more addresses affected by an update - the entire global ITRD, ITRC and ITFH system should get updates within a few seconds of the end-user making their change. There would be some agreed, centrally coordinated, system by which the Level 1 replicators and the ITRDs and QSDs could recognise which UAS systems were currently a part of the Ivip system, and their IP addresses. That could be as simple as some organisation pointing to them with DNS from a domain of theirs. It could also be in the form of an agreement for the replicators and ITRs to accept updates from a generally expanding list of UASes. This would involve central coordination, but it doesn't involve centralised flows or storage of data - just non-real-time configuration information which the operators of replicators, ITRDs and QSDs would follow. For scaling purposes, some ITRDs may not cover the entire set of Ivip-mapped master-prefixes. Then two or more ITRDs at the same site could split the load among themselves. In that case, an ITRD which covers a subset should be able to request of its upstream (typically two, but maybe three or more) replicators only to send those updates for the master-prefixes it is advertising. This means the packet format needs to be easy for the replicators to recognise and classify, which would be more complex if some or all of the full stream packets contained data collected from separate packets sent by separate UAS systems to the Level 1 replicators. In the previous message I mentioned how a replicator, ITRD or QSD could request of an upstream replicator another copy of some packets it was missing. Maybe that could be done via making the packets available in a structured manner, such as with file names with their sequence number in ASCII as the name, available in the same web servers which are used to supply full dump files of the database for each master-subnet. These files only need to be kept for 10 or 20 minutes at most, assuming there is a dump every 10 minutes or so. In principle, the mapping data in each ITRD or ITRC could be simply updated for months or years, leaving soft RAM errors to fester for this time. Each such error would tunnel packets for given IP address to the wrong location. Fully refreshing the mapping data in each ITRD from a dump every few hours, as CPU capacity permits, would prevent soft errors accumulating for too long in non-error corrected RAM. Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 06:35:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6lAJ-0007lU-Fq; Fri, 06 Jul 2007 06:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6lAH-0007ew-DV for ram@iab.org; Fri, 06 Jul 2007 06:35:53 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6lAC-0004Hx-Op for ram@iab.org; Fri, 06 Jul 2007 06:35:53 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 6A98B59DA2; Fri, 6 Jul 2007 20:35:42 +1000 (EST) Message-ID: <468E1AF1.9020704@firstpr.com.au> Date: Fri, 06 Jul 2007 20:35:29 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E241 54@muada.com> <468A4554.5030105@cisco.com><468C7643.6040305@firstpr.com.au> <37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com> <21051657-BA9F-4DEE-9425-1DF772245212@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [RAM] Re: LISP-01 I-D - UDP vs. IP-in-IP encapsulation X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dino wrote: > That is correct. We are using UDP encapsulation with a LISP > header for the following reasons: > > o Get through firewalls > o ITR hashes on inner header to produce a source port LAG > router can hash on > o Can carry nonce for ETR anti-spoofing > o Can carry Locator reachability bits With Ivip, there is no TE functionality in the ITR, no reachability detection of the ETR and no signalling one way or the other between ITR and ETR. All that happens is the packet is tunneled to an IP address which the end-user selects - presumably the address of an ETR. So Ivip doesn't need the last three things. I don't know enough about firewalls in all the various situations to know what problems IP-in-IP would suffer. What sort of firewalls would an ETR be located behind? If an edge network wanted to put an ETR behind a firewall, maybe they should configure their firewall to handle a major architectural aspect of getting packets to the ETR - the simplest and most standardised of which is IP-in-IP, as far as I know. I am not arguing against UDP encapsulation, except that it is longer, since it requires a UDP header too. Ivip could easily use UDP instead of IP-in-IP. By the way, links to the current LISP I-Ds are at: http://www.firstpr.com.au/ip/sram-ip-forwarding/#LISP The RRG wiki: http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup doesn't yet point to all three LISP I-Ds. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 11:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6qDC-0000Yy-55; Fri, 06 Jul 2007 11:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6qDB-0000Yq-7N for ram@iab.org; Fri, 06 Jul 2007 11:59:13 -0400 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6qD6-00027u-Rp for ram@iab.org; Fri, 06 Jul 2007 11:59:13 -0400 Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53])by smtp.uc3m.es (Postfix) with ESMTP id 9F6D330D89; Fri, 6 Jul 2007 17:59:07 +0200 (CEST) In-Reply-To: <37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com> References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E241 54@muada.com> <468A4554.5030105@cisco.com><468C7643.6040305@firstpr.com.au> <37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D5B80AF-D823-4FDE-8CE3-1D491A0B9C53@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Fri, 6 Jul 2007 17:59:06 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.9258 TC:1F TRN:24 TV:3.6.1039(15282.003) 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-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ram@iab.org Subject: [RAM] question about LISP v1 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, i have a question about the new version of LISP i.e. draft-farinacci- lisp-0 How does an initiator node informs the receiver about its multiple RLOCs? I mean, in the described packet flow sequence, the initiator sends a LISP data packet containing its EID and RLOC in the source address fields of the inner and outer header, and this is how the receiver ETR learns about the EID-to-RLOC mapping of the initiator. However, this only conveys a single RLOC, what happens if the initiator has multiple RLOCs (the most common in a multihomed site) and wants to inform the receiver ETR about them? In the previous version of LISP, it was possible for the initiator to send an unsolicited Map-Reply message containing the whole RLOC set to the receiver. however, the current version includes the nonce, so Map-reply messages can only be sent as replies to data packets or map request messages. So, does this means that the initiator cannot inform spontaneously of its locator set and must wait for the receiver to ask for it? or there is a mean for the initiator to send the locator set to the receiver even if the receiver haven't asked for it? Thanks, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 13:26:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6rZy-0007vX-QG; Fri, 06 Jul 2007 13:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6rZx-0007dQ-0g for ram@iab.org; Fri, 06 Jul 2007 13:26:49 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6rZs-0006Ep-IU for ram@iab.org; Fri, 06 Jul 2007 13:26:49 -0400 Received: from [192.168.0.93] ([83.68.31.213]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l66HNVS9058734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jul 2007 19:23:31 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <468A2065.1060200@nomadiclab.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7127E3B7-660F-4E8F-A8B5-032F7030BC88@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Re: the separation of ID/RLOC Date: Fri, 6 Jul 2007 18:39:43 +0200 To: Christian Vogt X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-2.6 required=3.5 tests=BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 3-jul-2007, at 12:09, Christian Vogt wrote: >> For what value of "quickly"? Please quantify. > I am looking at this from the perspective of a pair of communicating > hosts. A provider change initiated by either host's edge network > operator will lead to delay and packet loss, and both should be small. > Let's take a look at the typical case of a TCP connection. Here we > will > see substantial throughput degradations after a provider change if the > delay is more than 1 RTT: Two things: 1. It's doubtful that detecting, let alone restoring, a failure within an RTT is doable. If it is, the costs of doing so will be significant. 2. When you lose part of your connectivity, a substantial reduction in the traffic offered to the network is exactly the appropriate response. With today's multihoming, it's possible to suffer delays of up to 180 seconds before a failure is detected. The most important thing is that we can repair a problem before TCP times out, and if we can repair it before the user times out, so much the better. In my opinion, anything on top of that is icing and not worth additional effort. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 13:26:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ra7-0000FN-8P; Fri, 06 Jul 2007 13:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ra5-0008RM-6Y for ram@iab.org; Fri, 06 Jul 2007 13:26:57 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6ra0-0006F0-QG for ram@iab.org; Fri, 06 Jul 2007 13:26:57 -0400 Received: from [192.168.0.93] ([83.68.31.213]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l66HNVSA058734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jul 2007 19:23:44 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <465BA0DB.3070000@firstpr.com.au> References: <465BA0DB.3070000@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Number of DFZ routers Date: Fri, 6 Jul 2007 19:05:46 +0200 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-2.6 required=3.5 tests=BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 29-mei-2007, at 5:41, Robin Whittle wrote: > So if BGP could be radically improved, RAM-based FIBs would > make the global routing system support finer-grained address > assignment with greater efficiency of use, while supporting > existing BGP multihoming practices to a granularity of 256 > IP addresses. This would reduce the size and scope of the > problems which remain to be solved by LISP etc. > Unfortunately, no BGP experts think that such improvements > are feasible. Maybe some unconventional ideas from > non-experts might be helpful. If you present a common goal along with a list of things we're allowed to break, coming up with a new routing protocol that better meets these goals than BGP won't be too difficult. Shoehorning the changes into BGP would be harder. Deploying it a challenge. But the real problem is agreeing on the goals and throwing out current "features". iljitsch@bgpexpert.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 13:57:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6s3g-0004OH-1p; Fri, 06 Jul 2007 13:57:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6s3e-0004O9-H3 for ram@iab.org; Fri, 06 Jul 2007 13:57:30 -0400 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6s3a-0000HT-4m for ram@iab.org; Fri, 06 Jul 2007 13:57:30 -0400 Received: from [163.117.203.208] (unknown [163.117.203.208])by smtp.uc3m.es (Postfix) with ESMTP id 3B3337A0DD; Fri, 6 Jul 2007 19:57:16 +0200 (CEST) In-Reply-To: <0D5B80AF-D823-4FDE-8CE3-1D491A0B9C53@it.uc3m.es> References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E241 54@muada.com> <468A4554.5030105@cisco.com><468C7643.6040305@firstpr.com.au> <37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com> <0D5B80AF-D823-4FDE-8CE3-1D491A0B9C53@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] question about LISP v1 Date: Fri, 6 Jul 2007 19:57:14 +0200 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-17.6517 TC:1F TRN:31 TV:3.6.1039(15282.003) 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-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 06/07/2007, a las 17:59, marcelo bagnulo braun escribi=F3: > Hi Dino, > > i have a question about the new version of LISP i.e. draft-=20 > farinacci-lisp-0 > i meant draft-farinacci-lisp-01 > How does an initiator node informs the receiver about its multiple =20 > RLOCs? > > I mean, in the described packet flow sequence, the initiator sends =20 > a LISP data packet containing its EID and RLOC in the source =20 > address fields of the inner and outer header, and this is how the =20 > receiver ETR learns about the EID-to-RLOC mapping of the initiator. =20= > However, this only conveys a single RLOC, what happens if the =20 > initiator has multiple RLOCs (the most common in a multihomed site) =20= > and wants to inform the receiver ETR about them? > > In the previous version of LISP, it was possible for the initiator =20 > to send an unsolicited Map-Reply message containing the whole RLOC =20 > set to the receiver. however, the current version includes the =20 > nonce, so Map-reply messages can only be sent as replies to data =20 > packets or map request messages. So, does this means that the =20 > initiator cannot inform spontaneously of its locator set and must =20 > wait for the receiver to ask for it? or there is a mean for the =20 > initiator to send the locator set to the receiver even if the =20 > receiver haven't asked for it? > > Thanks, marcelo > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 20:00:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6xio-0002n1-DM; Fri, 06 Jul 2007 20:00:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6xin-0002mr-EM for ram@iab.org; Fri, 06 Jul 2007 20:00:21 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6xij-0006DP-3f for ram@iab.org; Fri, 06 Jul 2007 20:00:21 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2007 20:00:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACJ0jkZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,510,1175486400"; d="scan'208"; a="125421136:sNHT28716384" 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 l6700EbT013566; Fri, 6 Jul 2007 20:00:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6700Cs0005935; Sat, 7 Jul 2007 00:00:13 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, 6 Jul 2007 20:00:12 -0400 Received: from [192.168.0.5] ([10.82.216.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 20:00:12 -0400 In-Reply-To: <0D5B80AF-D823-4FDE-8CE3-1D491A0B9C53@it.uc3m.es> References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E241 54@muada.com> <468A4554.5030105@cisco.com><468C7643.6040305@firstpr.com.au> <37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com> <0D5B80AF-D823-4FDE-8CE3-1D491A0B9C53@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F49209D-D02B-4EA7-8ED6-1AED699E4C48@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Date: Fri, 6 Jul 2007 17:00:09 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 07 Jul 2007 00:00:12.0277 (UTC) FILETIME=[CA409250:01C7C029] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2623; t=1183766414; x=1184630414; 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=20question=20about=20LISP=20v1 |Sender:=20 |To:=20marcelo=20bagnulo=20braun=20; bh=fLZaPlqXscy+BQsJECV617CkyF9sJ9qFtd+M5nO5YR4=; b=Y0GKl+tDQDeJymrHUZX5vrqeIg4QcjlFBFTRkmiGG9zMamktqp+inObPGv69seVVBH0lqXCj fJ579xaffhafYhbmKA6WVwQjy9KOgXifL7MEl8+38JzEGaq/rLfVGzRw; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ram@iab.org Subject: [RAM] Re: question about LISP v1 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > How does an initiator node informs the receiver about its multiple > RLOCs? This has not changed from the -00 draft. the receiver can glean *a* locator from the packet it is decaping (the ETR that is). If the ETR wants the complete set of locators with their associated priorities and weights, it must either 1) send a packet returning with the outer DA equal to the inner DA (I call this a data probe) or 2) if there is a mapping service in place, do a lookup to get the mapping. For the later, if LISP-NERD is used, the lookup is local the the ITR since the mappings are pushed. If LISP-CONS is used, a Map-Request is sent by the ITR to it's configured CAR over a TCP connection. > I mean, in the described packet flow sequence, the initiator sends > a LISP data packet containing its EID and RLOC in the source > address fields of the inner and outer header, and this is how the > receiver ETR learns about the EID-to-RLOC mapping of the initiator. > However, this only conveys a single RLOC, what happens if the > initiator has multiple RLOCs (the most common in a multihomed site) > and wants to inform the receiver ETR about them? Right, the ETR has some flexibility here. It can use the single locator to return packets while in parallel send a Map-Request to get the rest of them. When the ITR is sending packets this ETR, the Locoator Reachability bits are continually updated for each packet the ITR encaps to the ETR. So the ETR will know the reachability status. There is a detail about which loc-reach-bit to associated with the outer SA but I can tell you about that offline. > In the previous version of LISP, it was possible for the initiator > to send an unsolicited Map-Reply message containing the whole RLOC > set to the receiver. No, it was never unsolicited, because the sender of the Map-Reply would not know where to send it. > however, the current version includes the nonce, so Map-reply > messages can only be sent as replies to data packets or map request > messages. So, does this means that The -01 draft uses both the fact that the Nonce much match as well as the ITR keeping a local cached entry for the EID in a "incomplete" state. Similar to how some ARP implementations are coded. > the initiator cannot inform spontaneously of its locator set and > must wait for the receiver to ask for it? or there is a mean for > the initiator to send the locator set to the receiver even if the > receiver haven't asked for it? The Map-Reply is never sent unsolicited. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 21:42:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6zJn-0000pi-7d; Fri, 06 Jul 2007 21:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6zJl-0000oC-UN for ram@iab.org; Fri, 06 Jul 2007 21:42:37 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6zJg-0000LI-Nh for ram@iab.org; Fri, 06 Jul 2007 21:42:37 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id D40F859E3F; Sat, 7 Jul 2007 11:42:25 +1000 (EST) Message-ID: <468EEF75.3000308@firstpr.com.au> Date: Sat, 07 Jul 2007 11:42:13 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely References: <465BA0DB.3070000@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Iljitsch, Short version: I no longer have any hope that BGP could be improved so much that DFZ routers could cope indefinitely with current growth in the global routing table size - or with the larger growth I had in mind which would enable routers with RAM-based FIBs to handle millions of prefixes to /24 granularity, without concern about route aggregation. Long version: You quoted something I wrote on 29 May. Initially, I had thought that the problem with routing and addressing was with FIBs running hot and not coping with the number of routes. I proposed a RAM-based lookup system for IPv4 and IPv6 which would only make sense if the routers could use BGP to cope with 3, 10 or 20 times the ~200k routes they currently handle. I thought that wouldn't be impossible, because BGP is just a matter of a "CPU, router software, message with peers" etc., operating at much lower speeds than the gigabits per second of the FIB handling the packets themselves. By late May, I was despondent about LISP ever helping much, because I couldn't see how it could be incrementally deployed and because it seemed to be a patch-up overlay for a routing system where the FIBs surely could be made (in the 5 to 7 year timeframe) to handle IPv4 space in millions of arbitrarily located /24 granularity prefixes. So I was still thinking the best place to start was by souping up BGP enough to be able to slice and dice IPv4 space at the BGP level into millions of prefixes, with RAM-based FIBs, without concern about route aggregation. Then, I thought, what remaining problems could be solved by placing less demands on something like LISP. That was when I had only a cursory understanding of BGP. During May I learnt a lot more about the memory requirements, CPU load, software and policy complexities of BGP. I also learnt something about the current implementation of the MRAI timer and path hunting. There was a fascinating discussion about this on the RRG and then the IDR lists, starting 20 June: http://psg.com/lists/rrg/2007/maillist.html#00146 http://www1.ietf.org/mail-archive/web/idr/current/maillist.html#02422 Then I came to understand what most people have known for years - BGP uses intentionally highly simplified messages in order to help with scaling, but this gives routers only limited abilities to recognise which alternative paths may still work after another path is withdrawn. Even with the simplification, the load on CPUs and memory is extreme and the thought of handling five or ten times more routes - and then ten and twenty times more in the next ten years, is not realistic. Now I think there could be some worthwhile improvements to BGP, maybe to be developed and incrementally introduced over the next few years - but that this would at most "hold-back-the-clock" against routing table growth by a year or so. The simplest approach is probably Tony Li's and Geoff Huston's Path Length Damping - yet this will rely on router manufacturers largely restoring the RFC1771 (propagate withdrawals immediately) MRAI timer function, which I understand they generally ignored by 2002 and which RFC4271 banned in 2006! I wrote: > So if BGP could be radically improved, . . . > > Unfortunately, no BGP experts think that such improvements > are feasible. Maybe some unconventional ideas from > non-experts might be helpful. I withdraw this suggestion. I can't imagine any backwards-compatible upgrade or incrementally deployable replacement for BGP could achieve the radical improvements I was hoping for. Maybe someone else will have some great ideas for dramatically souping up BGP. BGP solves some very difficult problems. I can't think of any drastic improvements. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 06 22:22:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6zw0-0001I0-Tq; Fri, 06 Jul 2007 22:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6zvz-00019z-9P for ram@iab.org; Fri, 06 Jul 2007 22:22:07 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6zvu-00043T-O4 for ram@iab.org; Fri, 06 Jul 2007 22:22:07 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id EDA5459DE9; Sat, 7 Jul 2007 12:22:00 +1000 (EST) Message-ID: <468EF8BC.9000104@firstpr.com.au> Date: Sat, 07 Jul 2007 12:21:48 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [RAM] Ivip I-D soon X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org A number of people have expressed frustration about trying to understand Ivip by reading the mailing list messages, which are listed at: http://www.firstpr.com.au/ip/ivip/ I will write up a cohesive Ivip Internet Draft in the next few days and will announce it on this list and make it available immediately at the above site. I have other commitments during July which mean I can't do much more work on Ivip etc. until later in August. The forthcoming I-D will give a cohesive overview, without reliance on an understanding of LISP. It will then have various more detailed sections for those who are interested. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 07 09:52:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7AhW-000314-Gd; Sat, 07 Jul 2007 09:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7AhU-00030z-Om for ram@iab.org; Sat, 07 Jul 2007 09:51:52 -0400 Received: from imo-m12.mx.aol.com ([64.12.136.171] helo=imo-m12.mail.aol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7AhQ-00009p-GQ for ram@iab.org; Sat, 07 Jul 2007 09:51:52 -0400 Received: from HeinerHummel@aol.com by imo-m12.mx.aol.com (mail_out_v38_r9.2.) id z.cde.132c3069 (39952); Sat, 7 Jul 2007 09:51:34 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Sat, 7 Jul 2007 09:51:34 EDT Subject: Re: [RAM] Number of DFZ routers To: iljitsch@muada.com, rw@firstpr.com.au MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2070775332==" Errors-To: ram-bounces@iab.org --===============2070775332== Content-Type: multipart/alternative; boundary="-----------------------------1183816294" -------------------------------1183816294 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 06.07.2007 19:27:04 Westeurop=E4ische Normalzeit schreibt= =20 iljitsch@muada.com: > Unfortunately, no BGP experts think that such improvements > are feasible. Maybe some unconventional ideas from > non-experts might be helpful. BGP needs to be replaced, not repaired. A 200 k FIB should be proof enough =20 that this is the wrong way to go. 2k should be sufficient for a 100 times =20 bigger internet. It's the basic concept of BGP which is totally wrong. Othe= r,=20 secondary parts (Hello's etc.) can be re-used of course. Me and my research partners hope to come up with a respective solution soon= . =20 Heiner =20 _www.hummel-research.de_ (http://www.hummel-research.de) =20 =20 -------------------------------1183816294 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 06.07.2007 19:27:04 Westeurop=E4ische Normalzeit sch= reibt=20 iljitsch@muada.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>>=20 Unfortunately, no BGP experts think that such improvements
> are=20 feasible.  Maybe some unconventional ideas from
> non-experts m= ight=20 be helpful.

 
BGP needs to be replaced, not repaired. A 200 k FIB should be proof eno= ugh=20 that this is the wrong way to go.  2k should be sufficient for a 100 ti= mes=20 bigger internet. It's the basic concept of BGP which is totally wrong.=20 Other, secondary parts (Hello's etc.) can be re-used of course.
Me and my research partners hope to come up with a respective solu= tion=20 soon.
 
Heiner
 
-------------------------------1183816294-- --===============2070775332== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============2070775332==-- From ram-bounces@iab.org Sat Jul 07 10:46:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7BYb-0002P6-6p; Sat, 07 Jul 2007 10:46:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7BYX-0002Oa-29 for ram@iab.org; Sat, 07 Jul 2007 10:46:41 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7BYT-0003yR-SC for ram@iab.org; Sat, 07 Jul 2007 10:46:41 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 57D09872C7; Sat, 7 Jul 2007 10:46:35 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Number of DFZ routers Message-Id: <20070707144635.57D09872C7@mercury.lcs.mit.edu> Date: Sat, 7 Jul 2007 10:46:35 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: HeinerHummel@aol.com > BGP needs to be replaced, not repaired. So far, so good! :-) > A 200 k FIB should be proof enough that this is the wrong way to go. > 2k should be sufficient for a 100 times bigger internet. Huh? The size of the FIB is caused by the way IPv4 addresses are assigned, and has nothing to do with the algorithm/protocol by which paths are computed. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 07 11:14:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Byy-0003sl-Ot; Sat, 07 Jul 2007 11:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Byx-0003kb-Og for ram@iab.org; Sat, 07 Jul 2007 11:13:59 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7Byt-0005zi-F1 for ram@iab.org; Sat, 07 Jul 2007 11:13:59 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 07 Jul 2007 08:13:54 -0700 Received: from [172.26.250.99] ([172.26.250.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l67FDmO10204; Sat, 7 Jul 2007 08:13:52 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <468FADAA.60405@juniper.net> Date: Sat, 07 Jul 2007 17:13:46 +0200 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: HeinerHummel@aol.com Subject: Re: [RAM] Number of DFZ routers References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: rw@firstpr.com.au, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@juniper.net List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hello Heiner, > BGP needs to be replaced, not repaired. /* I would recommend to start replacing it today and the best place to start is your own AS. */ Seriously even if we would have a new protocol to replace BGP call it PGB all defined and it's RFC ready it will take years to implement and years^years to deploy. I would therefor recommend not to cross the option to repair BGP. > A 200 k FIB should be proof > enough that this is the wrong way to go. 2k should be sufficient for a > 100 times bigger internet. It's the basic concept of BGP which is > totally wrong. Number of FIB entires have nothing to do with the protocol. Please observe that BGP uses recursion. Most often it recurses to an IGP next hop, but it can also recurse to BGP itself then to IGP or something else. We could introduce hierarchy with BGP protocol as is without any changes to the protocol or existing and deployed routers. Your FIB could shrink tomorrow if we would have an agreement between operators to use tunneling for forwarding. I think this is the biggest obstacle today. We don't have a way to tunnel interdomain. I see all proposals today are moving the issue and if during such move the handling of 10^7-10^9 number of prefixes get's solved it would only benefit everyone. I am quite convinced that if we would just do two steps: * Mark BGP next hops with some community * Do not change nhs on EBGP boundaries So the recursion would be: Dst -> BGP NH -> IGP NH to BGP NH Encapsulation end point would be to original BGP NH. All destinations would not be present in all transit ASBRs as long as the LTR was there somewhere on the packet's way. The FIB size in most transit ASBR routers would shrink immediately. I am assuming that we are not worrying about P routers which can be BGP free today. > Other, secondary parts (Hello's etc.) can be re-used of course. I wouldn't be so convinced about that one actually. Cheers, R. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 07 11:29:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7CDu-0003il-U6; Sat, 07 Jul 2007 11:29:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7CDt-0003ie-Av for ram@iab.org; Sat, 07 Jul 2007 11:29:25 -0400 Received: from imo-m24.mx.aol.com ([64.12.137.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7CDp-00084R-28 for ram@iab.org; Sat, 07 Jul 2007 11:29:25 -0400 Received: from HeinerHummel@aol.com by imo-m24.mx.aol.com (mail_out_v38_r9.2.) id 1.cd7.14143245 (40520); Sat, 7 Jul 2007 11:28:59 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Sat, 7 Jul 2007 11:28:59 EDT Subject: Re: [RAM] Number of DFZ routers To: raszuk@juniper.net MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: rw@firstpr.com.au, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1616893050==" Errors-To: ram-bounces@iab.org --===============1616893050== Content-Type: multipart/alternative; boundary="-----------------------------1183822139" -------------------------------1183822139 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 07.07.2007 17:14:02 Westeurop=E4ische Normalzeit schreibt= =20 raszuk@juniper.net: I would therefor recommend not to cross the option to repair BGP. You are absolutely right. And it should be done by the idr WG. Including LISP etc. =20 I also agree that it is not too early to start developing something new. =20 Heiner =20 -------------------------------1183822139 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 07.07.2007 17:14:02 Westeurop=E4ische Normalzeit sch= reibt=20 raszuk@juniper.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>I would=20 therefor recommend not to cross the option to repair=20 BGP.
You are absolutely right. And it should be done by the idr WG.
Including LISP etc.
 
I also agree that it is not too early to start developing something=20 new.
 
Heiner
-------------------------------1183822139-- --===============1616893050== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1616893050==-- From ram-bounces@iab.org Sat Jul 07 14:28:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7F1O-000388-6f; Sat, 07 Jul 2007 14:28:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7F1N-000382-Ek for ram@iab.org; Sat, 07 Jul 2007 14:28:41 -0400 Received: from imo-m28.mx.aol.com ([64.12.137.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7F1J-0004xY-6i for ram@iab.org; Sat, 07 Jul 2007 14:28:41 -0400 Received: from HeinerHummel@aol.com by imo-m28.mx.aol.com (mail_out_v38_r9.2.) id 9.c92.e190410 (65099); Sat, 7 Jul 2007 14:28:30 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Sat, 7 Jul 2007 14:28:29 EDT Subject: Re: [RAM] Number of DFZ routers To: jnc@mercury.lcs.mit.edu, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1841275696==" Errors-To: ram-bounces@iab.org --===============1841275696== Content-Type: multipart/alternative; boundary="-----------------------------1183832909" -------------------------------1183832909 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 07.07.2007 16:46:36 Westeurop=E4ische Normalzeit schreibt= =20 jnc@mercury.lcs.mit.edu: > A 200 k FIB should be proof enough that this is the wrong way to go. > 2k should be sufficient for a 100 times bigger internet.=20 Huh? The size of the FIB is caused by the way IPv4 addresses are assigned, and has nothing to do with the algorithm/protocol by which paths are computed. Noel Sorry, I was too sloppy. 2k, mayby 1k of addresses are even sufficient. So =20= I=20 don't care about prefixes, neither PA nor PI, at all. But let's wait and see. There are other hurdles to take in the first place. =20 Heiner =20 =20 =20 -------------------------------1183832909 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 07.07.2007 16:46:36 Westeurop=E4ische Normalzeit sch= reibt=20 jnc@mercury.lcs.mit.edu:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2> =20 > A 200 k FIB should be proof enough that this is the wrong way to=20 go.
    > 2k should be sufficient for a 100 times bigger=20 internet.

Huh? The size of the FIB is caused by the way IPv4 addre= sses=20 are assigned,
and has nothing to do with the algorithm/protocol by whic= h=20 paths are
computed.

    Noel
Sorry, I was too sloppy. 2k, mayby 1k of addresses are even sufficient.= So=20 I don't care about prefixes, neither PA nor PI, at all.
But let's wait and see. There are other hurdles to take in the first=20 place.
 
Heiner
 
 
-------------------------------1183832909-- --===============1841275696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1841275696==-- From ram-bounces@iab.org Sat Jul 07 15:12:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Fi6-00082g-Pu; Sat, 07 Jul 2007 15:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Fi5-000805-An for ram@iab.org; Sat, 07 Jul 2007 15:12:49 -0400 Received: from smtpout.sgsi.ucl.ac.be ([130.104.5.77] helo=smtp4.sgsi.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7Fi0-0007od-T3 for ram@iab.org; Sat, 07 Jul 2007 15:12:49 -0400 Received: from smtp4.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTP id CE827EF63F; Sat, 7 Jul 2007 21:12:52 +0200 (CEST) Received: from [192.168.1.102] (ip-83-134-209-46.dsl.scarlet.be [83.134.209.46]) (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 ESMTP; Sat, 7 Jul 2007 21:12:52 +0200 (CEST) Message-ID: <468FE5A7.7070407@uclouvain.be> Date: Sat, 07 Jul 2007 21:12:39 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: HeinerHummel@aol.com Subject: Re: [RAM] Number of DFZ routers References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: Authenticated, X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: jnc@mercury.lcs.mit.edu, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Heiner, > In einer eMail vom 07.07.2007 16:46:36 Westeurop=E4ische Normalzeit=20 > schreibt jnc@mercury.lcs.mit.edu: >=20 > > A 200 k FIB should be proof enough that this is the wrong way t= o go. > > 2k should be sufficient for a 100 times bigger internet. >=20 > Huh? The size of the FIB is caused by the way IPv4 addresses are > assigned, > and has nothing to do with the algorithm/protocol by which paths ar= e > computed. >=20 > Noel >=20 > Sorry, I was too sloppy. 2k, mayby 1k of addresses are even sufficient.= =20 > So I don't care about prefixes, neither PA nor PI, at all. > But let's wait and see. There are other hurdles to take in the first pl= ace. I completely agree with Noel. The FIB size mainly depends on how=20 addresses are assigned and not on the routing protocol used to=20 distribute the addresses. For a discussion on the FIB size with=20 id/locator split solutions, you might have a look at : B. Quoitin, L. Iannone, C. de Launois and O. Bonaventure. Evaluating=20 the Benefits of the Locator/Identifier Separation. Proceedings of=20 MobiArch (ACM SIGCOMM Workshop), Kyoto, Japan, August 2007. http://inl.info.ucl.ac.be/publications/evaluating-benefits-locator-identi= fier-separation-0 In this paper, we evaluate two possible scenarios for the assignement of=20 locators in an id/locator separation solution and show that basically=20 the max FIB size can be O(number of provider independant locator blocks). Best regards, Olivier Bonaventure --=20 http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 07 15:28:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Fws-0007Cn-0p; Sat, 07 Jul 2007 15:28:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Fwq-00077U-S7 for ram@iab.org; Sat, 07 Jul 2007 15:28:04 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7Fwm-0000Rq-Kx for ram@iab.org; Sat, 07 Jul 2007 15:28:04 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 19E5987319; Sat, 7 Jul 2007 15:27:47 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Number of DFZ routers Message-Id: <20070707192747.19E5987319@mercury.lcs.mit.edu> Date: Sat, 7 Jul 2007 15:27:47 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: HeinerHummel@aol.com >> The size of the FIB is caused by the way IPv4 addresses are assigned, >> and has nothing to do with the algorithm/protocol by which paths are >> computed. > Sorry, I was too sloppy. 2k, mayby 1k of addresses are even sufficient. Sure, if we can reassign all IPv4 addresses from scratch, for every network in the entire world. Lots of luck getting everyone to agree to do that. And then, of course, you have to keep them perfectly assigned with the connection topology - i.e. almost no PI addresses at all, for anything smaller than, say one of the 500 largest organizations in the world. So we're talking maybe the US gets 100 PI addresses, Europe as a whole 150, Japan 75, the entire rest of the world gets 75, and that leaves us 50 spare. Note that means all mid-level ISP's don't get their own address space, they have to get it from one of their upstream ISP's - and if they change upstreams, all their customers have to change their addresses. I don't think so. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 07 16:48:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7HCF-0001HA-39; Sat, 07 Jul 2007 16:48:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7HCD-0001FO-NP for ram@iab.org; Sat, 07 Jul 2007 16:48:01 -0400 Received: from imo-m24.mx.aol.com ([64.12.137.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7HC9-0006Zy-BB for ram@iab.org; Sat, 07 Jul 2007 16:48:01 -0400 Received: from HeinerHummel@aol.com by imo-m24.mx.aol.com (mail_out_v38_r9.2.) id 9.c36.147654ea (29673); Sat, 7 Jul 2007 16:47:54 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Sat, 7 Jul 2007 16:47:54 EDT Subject: Re: [RAM] Number of DFZ routers To: jnc@mercury.lcs.mit.edu, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0307701082==" Errors-To: ram-bounces@iab.org --===============0307701082== Content-Type: multipart/alternative; boundary="-----------------------------1183841274" -------------------------------1183841274 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Noel, =20 No,no,no. I am talking completely different things.=20 At this point in time I just responded to an email which sounded pretty =20 desperately and I only wanted to express my view that there is no reason to=20= be =20 desperate (unless ALL are in favor of BGP forever , which I don't think is= the=20 case) - well and all of this one day before going on vacation :-) =20 =20 In einer eMail vom 07.07.2007 21:28:05 Westeurop=E4ische Normalzeit schreibt= =20 jnc@mercury.lcs.mit.edu: > From: HeinerHummel@aol.com >> The size of the FIB is caused by the way IPv4 addresses are assigned, >> and has nothing to do with the algorithm/protocol by which paths are >> computed. > Sorry, I was too sloppy. 2k, mayby 1k of addresses are even sufficient. Sure, if we can reassign all IPv4 addresses from scratch, for every network in the entire world. Lots of luck getting everyone to agree to do that. And then, of course, you have to keep them perfectly assigned with the connection topology - i.e. almost no PI addresses at all, for anything smaller than, say one of the 500 largest organizations in the world. So we'= re talking maybe the US gets 100 PI addresses, Europe as a whole 150, Japan 75= , the entire rest of the world gets 75, and that leaves us 50 spare. Note that means all mid-level ISP's don't get their own address space, they have to get it from one of their upstream ISP's - and if they change upstreams, all their customers have to change their addresses. =20 There is no need to reassign all IPv4 addresses from scratch (after all, =20 that would only be perfect for this current moment in 2007). I wouldn't even= =20 mind if the address assignment were even worse.=20 =20 Enjoy your Chicago meeting =20 Heiner =20 -------------------------------1183841274 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Noel,
 
No,no,no. I am talking completely different things. 
At this point in time I just responded to an email which sounded pretty= =20 desperately and I only wanted to express my view that there is no reason to=20= be=20 desperate (unless ALL are in favor of BGP forever ,  which I=20 don't think is the case) - well and all of this one day before going on vaca= tion=20 :-)
 
 
In einer eMail vom 07.07.2007 21:28:05 Westeurop=E4ische Normalzeit sch= reibt=20 jnc@mercury.lcs.mit.edu:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>>=20 From: HeinerHummel@aol.com

    >> The size of the F= IB=20 is caused by the way IPv4 addresses are assigned,
    >>= ;=20 and has nothing to do with the algorithm/protocol by which paths are
&n= bsp;=20   >> computed.

    > Sorry, I was too slopp= y.=20 2k, mayby 1k of addresses are even sufficient.

Sure, if we can reas= sign=20 all IPv4 addresses from scratch, for every network
in the entire world.= =20 Lots of luck getting everyone to agree to do that.

And then, of cou= rse,=20 you have to keep them perfectly assigned with the
connection topology -= =20 i.e. almost no PI addresses at all, for anything
smaller than, say one=20= of=20 the 500 largest organizations in the world. So we're
talking maybe the=20= US=20 gets 100 PI addresses, Europe as a whole 150, Japan 75,
the entire rest= of=20 the world gets 75, and that leaves us 50 spare.

Note that means all= =20 mid-level ISP's don't get their own address space, they
have to get it=20= from=20 one of their upstream ISP's - and if they change
upstreams, all their=20 customers have to change their addresses.
There is no need to reassign all IPv4 addresses from scratch (after all= ,=20 that would only be perfect for this current moment in 2007). I wouldn't even= =20 mind if the address assignment were even worse.
 
Enjoy your Chicago meeting
 
Heiner
-------------------------------1183841274-- --===============0307701082== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0307701082==-- From ram-bounces@iab.org Mon Jul 09 02:03:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mLP-00089R-5k; Mon, 09 Jul 2007 02:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mLN-00089A-8I for ram@iab.org; Mon, 09 Jul 2007 02:03:33 -0400 Received: from ns2.nict.go.jp ([133.243.3.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7mLI-0004NJ-Ks for ram@iab.org; Mon, 09 Jul 2007 02:03:33 -0400 Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns2.nict.go.jp with ESMTP id l6963Qdf005568 for ; Mon, 9 Jul 2007 15:03:26 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id l6963Q9l003975 for ; Mon, 9 Jul 2007 15:03:26 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id l6963Qe2003972 for ; Mon, 9 Jul 2007 15:03:26 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id C64C26EE2 for ; Mon, 9 Jul 2007 15:03:25 +0900 (JST) Received: from nictkafle (5gou2f-dhcp28.nict.go.jp [133.243.146.188]) by mail2.nict.go.jp (Postfix) with ESMTP id 8C0166EA6 for ; Mon, 9 Jul 2007 15:03:25 +0900 (JST) From: "Ved Kafle" To: Date: Mon, 9 Jul 2007 15:05:15 +0900 Message-ID: <003d01c7c1ef$2148eb80$bc92f385@nictkafle> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [RAM] Meeting at IETF-69? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1323496953==" Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --===============1323496953== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01C7C23A.91309380" This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C7C23A.91309380 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I would like to know if the participants of this mailing list are going to have an informal meeting at the IETF-69. Ved ------=_NextPart_000_003E_01C7C23A.91309380 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Hi,
I would like to know = if the=20 participants of this mailing list are going to have an informal meeting = at the=20 IETF-69.
 
Ved
 
 
------=_NextPart_000_003E_01C7C23A.91309380-- --===============1323496953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1323496953==-- From ram-bounces@iab.org Mon Jul 09 05:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7py4-0003Aq-F4; Mon, 09 Jul 2007 05:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7py2-0003Aj-VI for ram@iab.org; Mon, 09 Jul 2007 05:55:42 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7pxT-0001XQ-Cg for ram@iab.org; Mon, 09 Jul 2007 05:55:42 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2007 02:55:07 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAB+ikUarR7O6/2dsb2JhbACCZA X-IronPort-AV: i="4.16,516,1175497200"; d="scan'208,217"; a="501163472:sNHT59077568" 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 l699t6dU005223; Mon, 9 Jul 2007 02:55:06 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l699swXH007388; Mon, 9 Jul 2007 09:55:06 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, 9 Jul 2007 02:54:58 -0700 Received: from [192.168.0.100] ([10.21.118.62]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 02:54:57 -0700 In-Reply-To: <003d01c7c1ef$2148eb80$bc92f385@nictkafle> References: <003d01c7c1ef$2148eb80$bc92f385@nictkafle> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 (Normal) Message-Id: From: Tony Li Subject: Re: [RAM] Meeting at IETF-69? Date: Mon, 9 Jul 2007 02:54:56 -0700 To: Ved Kafle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Jul 2007 09:54:57.0750 (UTC) FILETIME=[35471F60:01C7C20F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1560; t=1183974906; x=1184838906; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Meeting=20at=20IETF-69? |Sender:=20; bh=nYx2BgjJ5KZDBzHreKE3dYzQNgtwCoXBACSO2rbI8Yo=; b=V1W6NSOMOgFX8q2YEX+99GSd7MIPmnKI655dUH6BWxlWik9hhUyDhDbF3GvYUpSVJOJQl5fe 3P2aNZjyQeOHFQckOlHKll3nKr0USg82jWmhMRoKJNo/HNRXZKmhTtvs; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0434855839==" Errors-To: ram-bounces@iab.org --===============0434855839== Content-Type: multipart/alternative; boundary=Apple-Mail-4--490733319 --Apple-Mail-4--490733319 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 8, 2007, at 11:05 PM, Ved Kafle wrote: > I would like to know if the participants of this mailing list are > going to have an informal meeting at the IETF-69. There will be a Routing Research Group meeting on July 27th. Details can be found here: http://www3.tools.ietf.org/group/irtf/trac/wiki/ RRGagendaChicago Regards, Tony --Apple-Mail-4--490733319 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Jul 8, 2007, at = 11:05 PM, Ved Kafle wrote:

=
I would like to know = if=A0the participants of this mailing list are going to have an informal = meeting at the IETF-69.
=


There will be a Routing = Research Group meeting on July 27th.=A0 Details can be found here:=A0= http://www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaChicago
=

Regards,
Tony
=

= --Apple-Mail-4--490733319-- --===============0434855839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0434855839==-- From ram-bounces@iab.org Mon Jul 09 06:00:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7q2A-0006Vy-AA; Mon, 09 Jul 2007 05:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7q29-0006S6-8y for ram@iab.org; Mon, 09 Jul 2007 05:59:57 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7q24-0001lJ-RS for ram@iab.org; Mon, 09 Jul 2007 05:59:57 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6B696212D38; Mon, 9 Jul 2007 12:59:51 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 349D8212D37; Mon, 9 Jul 2007 12:59:51 +0300 (EEST) Message-ID: <46920716.1070108@nomadiclab.com> Date: Mon, 09 Jul 2007 12:59:50 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <7127E3B7-660F-4E8F-A8B5-032F7030BC88@muada.com> In-Reply-To: <7127E3B7-660F-4E8F-A8B5-032F7030BC88@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Iljitsch: > 1. It's doubtful that detecting, let alone restoring, a failure within > an RTT is doable. If it is, the costs of doing so will be significant. You are raising an interesting point. The process of detecting failure of a provider may indeed be a bottleneck today. But I would argue that this, too, could be improved in the future. It would therefore be wise no to limit the efficiency of a routing and addressing solution to the performance of state-of-the-art failure detection mechanisms. One possible improvement would call for an edge network operator to redirect part of its traffic to an alternative provider as the delays incurred by the current primary provider increase. > 2. When you lose part of your connectivity, a substantial reduction in > the traffic offered to the network is exactly the appropriate response. If you have an alternative provider to switch to, then it would be good if the mapping function would allow you to do this quickly enough to not impact ongoing communications too much. Of course, if you don't have an alternative provider, then a reduction in traffic would be appropriate -- and TCP would do exactly that. - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 09 07:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rYc-0003em-Gc; Mon, 09 Jul 2007 07:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rYR-0003Mo-IX for ram@iab.org; Mon, 09 Jul 2007 07:37:23 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7rYN-0004Cs-6E for ram@iab.org; Mon, 09 Jul 2007 07:37:23 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.49]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1I7rYD-0006VV-R7; Mon, 09 Jul 2007 13:37:14 +0200 Message-ID: <46921DDF.2090105@pi.se> Date: Mon, 09 Jul 2007 13:37:03 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Meeting at IETF-69? References: <003d01c7c1ef$2148eb80$bc92f385@nictkafle> In-Reply-To: X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org All, Tony Li wrote: > > On Jul 8, 2007, at 11:05 PM, Ved Kafle wrote: > >> I would like to know if the participants of this mailing list are >> going to have an informal meeting at the IETF-69. > > > There will be a Routing Research Group meeting on July 27th. Details > can be found here: > http://www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaChicago it might be worth noting that the IETF agenda, schedules the rrg meeting 9-11.30am, while the agenda found from the link above is from 9am-5pm. I guess that the latter is right /Loa > > Regards, > Tony > > > > ------------------------------------------------------------------------ > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 09 08:41:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7sXw-0001mI-MI; Mon, 09 Jul 2007 08:40:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7sXh-0001TS-AV for ram@iab.org; Mon, 09 Jul 2007 08:40:41 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7sXc-00066y-Mw for ram@iab.org; Mon, 09 Jul 2007 08:40:41 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 0368D59DEB; Mon, 9 Jul 2007 22:40:32 +1000 (EST) Message-ID: <46922CB3.2090107@firstpr.com.au> Date: Mon, 09 Jul 2007 22:40:19 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [RAM] draft-jen-apt and eFIT X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org There is a new I-D which hasn't been mentioned on this list so far: APT: A Practical Transit Mapping Service Dan Jen, Michael Meisel, Dan Massey, Lan Wang, Beichuan Zhang and Lixia Zhang http://tools.ietf.org/html/draft-jen-apt Section 8 begins: Clearly, the deployment of APT will coincide with the deployment of eFIT (or a similar architecture). eFIT is: A Scalable Routing System Design for Future Internet Dan Massey, Lan Wang, Beichuan Zhang, Lixia Zhang ACM SIGCOMM Workshop on IPv6, August 2007. The copy of this paper at: http://www.cs.ucla.edu/~lixia/papers/07SIG_IP6WS.pdf currently has a problem with permissions, but I emailed Lixia about this, so hopefully it will be available soon. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 09 09:22:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7tBp-0007v2-TC; Mon, 09 Jul 2007 09:22:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7tBc-0007ro-2f for ram@iab.org; Mon, 09 Jul 2007 09:21:57 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7tBY-0007Lz-Hw for ram@iab.org; Mon, 09 Jul 2007 09:21:56 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id B2B9859E40; Mon, 9 Jul 2007 23:21:48 +1000 (EST) Message-ID: <4692365F.3070006@firstpr.com.au> Date: Mon, 09 Jul 2007 23:21:35 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] draft-jen-apt and eFIT References: <46922CB3.2090107@firstpr.com.au> In-Reply-To: <46922CB3.2090107@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org There is an eFIT I-D from February: http://tools.ietf.org/html/draft-wang-ietf-efit-00 - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 09 13:14:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7woc-0006Lt-OY; Mon, 09 Jul 2007 13:14:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wob-0006Li-84 for ram@iab.org; Mon, 09 Jul 2007 13:14:25 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7woW-0005zK-Px for ram@iab.org; Mon, 09 Jul 2007 13:14:25 -0400 Received: from [10.100.10.70] (deimos.iu-bremen.de [212.201.44.249]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l69HBJm0024615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jul 2007 19:11:19 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <46920716.1070108@nomadiclab.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <7127E3B7-660F-4E8F-A8B5-032F7030BC88@muada.com> <46920716.1070108@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Re: the separation of ID/RLOC Date: Mon, 9 Jul 2007 19:13:01 +0200 To: Christian Vogt X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-2.0 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 9-jul-2007, at 11:59, Christian Vogt wrote: >> 1. It's doubtful that detecting, let alone restoring, a failure >> within >> an RTT is doable. If it is, the costs of doing so will be >> significant. > You are raising an interesting point. The process of detecting > failure > of a provider may indeed be a bottleneck today. Actually, this is the easy part, because you can simply send hello packets at a pretty high rate across a link. Or even better: let a watchdog timer go off when no packets have been received for a certain time. The latter has the advantage that you don't need to inject keepalives when there is real traffic and you aren't bound by round trip time speed. (Which isn't too bad for a single layer 2 link in almost all cases, though, especially if you can get rid of the variability by bypassing any queues for the keepalives.) But we were talking end-to-end, or at least across a number of links. This means the keepalive traffic explodes and there are no longer any interface-specific tricks that can be done for optimization. > One possible improvement would call for an edge network operator to > redirect part of its traffic to an alternative provider as the delays > incurred by the current primary provider increase. This is susceptible to oscillations. In my opinion, the correct way to handle this stuff is with multipath transport protocols. >> 2. When you lose part of your connectivity, a substantial >> reduction in >> the traffic offered to the network is exactly the appropriate >> response. > If you have an alternative provider to switch to, then it would be > good This sounds very much like optical restoration to me. :-) With IP, "backup" paths are rarely idle when the "primary" path is active, so loss of the path that's currently used means a reduction of total available bandwidth which can easily reduce this to less than the amount of traffic generated. So backing off until a new equilibrium is found is a good idea. > if the mapping function would allow you to do this quickly enough > to not > impact ongoing communications too much. If you were using a TCP-like transport protocol that works over multiple paths at the same time, you'd already have RTT times and window sizes for the other path so switching could happen without reducing bandwidth more than necessary. And load balancing would happen automatically. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 09 14:09:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7xfS-0005sf-7s; Mon, 09 Jul 2007 14:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7xfR-0005sV-6X for ram@iab.org; Mon, 09 Jul 2007 14:09:01 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7xfN-0007sz-R3 for ram@iab.org; Mon, 09 Jul 2007 14:09:01 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2007 11:08:53 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJsWkkarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,517,1175497200"; d="scan'208"; a="179019944:sNHT61110774" 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 l69I8q9H024559; Mon, 9 Jul 2007 11:08:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l69I8TXR010691; Mon, 9 Jul 2007 18:08: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); Mon, 9 Jul 2007 11:08:33 -0700 Received: from [192.168.0.100] ([10.21.118.62]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 11:08:33 -0700 In-Reply-To: <46921DDF.2090105@pi.se> References: <003d01c7c1ef$2148eb80$bc92f385@nictkafle> <46921DDF.2090105@pi.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FAE671E-A492-46E7-A651-58D8C29C86D6@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Meeting at IETF-69? Date: Mon, 9 Jul 2007 11:08:32 -0700 To: Loa Andersson X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Jul 2007 18:08:33.0252 (UTC) FILETIME=[297E1A40:01C7C254] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=634; t=1184004533; x=1184868533; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Meeting=20at=20IETF-69? |Sender:=20; bh=rAYZ+fNVjcod/EbiK38UCdyCUBu9sioCzPc3qjxpA+k=; b=LwW7VeUM7k8E/PYHG+gMGlyLe3qbV7726UM3skNcP3D76aVQqE2kQm+bpnSVEpCjuy1y4T7P 0WuP5DMonfnFYy6sNbwo3wz9+wscwcSACX98Y84T1/2g2m7/Mj6xq+aEbj4JI93V1ef4ZByJaT c2KRBOpGlbxd2vUrMWmbRo1WA=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jul 9, 2007, at 4:37 AM, Loa Andersson wrote: >> There will be a Routing Research Group meeting on July 27th. Details >> can be found here: >> http://www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaChicago > > it might be worth noting that the IETF agenda, schedules the rrg > meeting > 9-11.30am, while the agenda found from the link above is from 9am-5pm. > > I guess that the latter is right That's correct. The IETF schedule stops at the official end of IETF, which is Friday at noon. Other plucky intrepid souls will carry on regardless. ;-) We do have the room for the entire day. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 09 14:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yQD-0007h2-EE; Mon, 09 Jul 2007 14:57:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yQB-0007gf-HE for ram@iab.org; Mon, 09 Jul 2007 14:57:20 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7yQ7-0001dM-99 for ram@iab.org; Mon, 09 Jul 2007 14:57:19 -0400 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 7881278; Mon, 09 Jul 2007 14:57:12 -0400 In-Reply-To: <6FAE671E-A492-46E7-A651-58D8C29C86D6@cisco.com> References: <003d01c7c1ef$2148eb80$bc92f385@nictkafle> <46921DDF.2090105@pi.se> <6FAE671E-A492-46E7-A651-58D8C29C86D6@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] Meeting at IETF-69? Date: Mon, 9 Jul 2007 14:57:08 -0400 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jul 9, 2007, at 2:08 PM, Tony Li wrote: > > On Jul 9, 2007, at 4:37 AM, Loa Andersson wrote: > >>> There will be a Routing Research Group meeting on July 27th. >>> Details >>> can be found here: >>> http://www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaChicago >> >> it might be worth noting that the IETF agenda, schedules the rrg >> meeting >> 9-11.30am, while the agenda found from the link above is from >> 9am-5pm. >> >> I guess that the latter is right > > > That's correct. > > The IETF schedule stops at the official end of IETF, which is > Friday at noon. Other plucky intrepid souls will carry on > regardless. ;-) > > We do have the room for the entire day. Note that the wireless will likely come down at or shortly after Noon. I could ask if it could be extended, but generally they resist that. > > Tony > Regards Marshall > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 09 17:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80OJ-0005cM-AB; Mon, 09 Jul 2007 17:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80OI-0005bT-3r for ram@iab.org; Mon, 09 Jul 2007 17:03:30 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I80OE-0006eU-QE for ram@iab.org; Mon, 09 Jul 2007 17:03:30 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2007 14:03:26 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJ8/kkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,518,1175497200"; d="scan'208"; a="179113592:sNHT24716772" 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 l69L3Qvd021541; Mon, 9 Jul 2007 14:03:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l69L3CnK016972; Mon, 9 Jul 2007 21:03:26 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, 9 Jul 2007 14:03:23 -0700 Received: from [171.70.224.106] ([171.70.224.106]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 14:03:23 -0700 In-Reply-To: References: <003d01c7c1ef$2148eb80$bc92f385@nictkafle> <46921DDF.2090105@pi.se> <6FAE671E-A492-46E7-A651-58D8C29C86D6@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Meeting at IETF-69? Date: Mon, 9 Jul 2007 14:03:20 -0700 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Jul 2007 21:03:23.0557 (UTC) FILETIME=[96339D50:01C7C26C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=198; t=1184015006; x=1184879006; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Meeting=20at=20IETF-69? |Sender:=20; bh=BtJA/sFoBmEuE8uTUpQjvYIbhsgPtMV6LMH3OXMa5bs=; b=GeX8/s3CTgCbdCxwQT33SEkJADcQPoxZWE4W7uEMLUwkmDMFK01l6rj0nC0ocl0O1gAYcj8m U/saGw8vyP6UveUEnUwIu6RcnpzoDxZYmhgGQi5yQNObeh2G6QHRgeIH; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Note that the wireless will likely come down at or shortly after > Noon. I could ask if it could be extended, but generally they > resist that. Already asked and declined. ;-( T _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 09 21:05:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I849v-0005g7-1i; Mon, 09 Jul 2007 21:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I849u-0005g1-Kq for ram@iab.org; Mon, 09 Jul 2007 21:04:54 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I849q-0003Za-4r for ram@iab.org; Mon, 09 Jul 2007 21:04:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2007 18:04:49 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKJ3kkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,519,1175497200"; d="scan'208"; a="7470195:sNHT21061482" 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 l6A14nZU026295; Mon, 9 Jul 2007 18:04:49 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6A14eXH006432; Tue, 10 Jul 2007 01:04:44 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); Mon, 9 Jul 2007 18:04:40 -0700 Received: from [171.70.224.106] ([171.70.224.106]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 18:04:40 -0700 In-Reply-To: <468B7388.3020306@nomadiclab.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> <468B7388.3020306@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Re: the separation of ID/RLOC Date: Mon, 9 Jul 2007 18:04:37 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Jul 2007 01:04:40.0519 (UTC) FILETIME=[4B24B570:01C7C28E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4254; t=1184029489; x=1184893489; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20the=20separation=20of=20ID/RLOC |Sender:=20; bh=Su1QE2FxJ50LXPfiFBlOzoWRmfwWHEta5NjszkPdaUs=; b=qOSWwbqayroHiiShr8jNIDxXgc61XdjQ2YZO+8Dv2xWCpZ6wo1fH0/QuWQcIAU0qMNgXuG/a AqGeh5dOwnsS2zWJvj5vRCnvubx/jEHauttUlw3XKcEQlOnUzYDY9774; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Christian, Sorry to take so long to respond. On Jul 4, 2007, at 3:16 AM, Christian Vogt wrote: >>> Whether or not long update delays are an issue depends, as you >>> say, on >>> the change frequency and granularity. However, any assumptions >>> that we >>> make in this regards should be very careful. Our goal is to give >>> edge >>> networks more freedom in traffic engineering and provider selection. >>> And it would be great if we could reach this goal without >>> restrictions >>> -- such as in terms of change frequency or granularity. >> >> Isn't this issue easily resolved by advertising more than one >> locator? > > if you want to an enable edge network to decide through which provider > ingress packets are received, then the edge network must be able to > tell > remote edge networks one specific transit locator to which they should > send packets. A destination can certainly express a preference, but as always, the holder of the packet gets to decide on the next hop. This may or may not include dropping the packet. This is best effort and there are no guarantees. > If an edge network advertises more than one transit locator, then > it is > up to remote edge networks to select one of those. This takes away > the > ability for edge networks to select an ingress provider. Since a destination does not currently have that ability and the ability to be multi-homed today, I don't see that this is truly an issue. Further, I don't see a path to a world where this could ever be the case. In today's world, where only a single prefix is advertised, the destination can use various methods (e.g., path prepend) to try to induce particular path selection, but this is not a guarantee. A transit provider can easily have a policy in place that contradicts the end-user policy, and the transit provider's policy will win. In a world where a host can express a locator preference, the correspondent can also choose to ignore the destination's preferences. This seems like it shifts control from the transit to the correspondent, but at no time would it ever seem to give the destination true and unilateral control. > Additionally, > you still need a locator selection mechanism for the remote edge > network > -- which may involve its own signaling overhead, delay, and packet > loss. I think you're making an assumption that only a single locator would be advertised at a time, and that signaling would be required to transition between locators. In fact, I was positing having multiple locators advertised simultaneously, with preferences expressed about their utilization. We do this already today with MX records and it seems to work passably well. > With Six/One [1], edge networks can select both their ingress and > egress > providers, and they can change them within 1 RTT without signaling. If I understand it correctly, a host can advertise what addresses are in its bunch, and a network can choose to do a prefix rewrite, which *should* result in the correspondent using the same addresses. However, the enforced symmetry is based on the actions of the correspondent host, which is not guaranteed. Further, when taken into conjunction with source address filtering by the next hop egress network, it implies that the edge network is going to necessarily couple its ingress and egress providers on a per-packet basis. > There is also no packet loss if the old provider is still > operational at > the time of the change. And the granularity of provider selection > (both > ingress and egress) is on a per-communication-session level. Unfortunately, the only practical way of determining that an old provider (or, more generally, an old path) is non-operational is to lose packets. In short, I'm not seeing anything different here: if you advertise multiple locators, you would seem to be doing about the best that can be done in terms of providing alternate path information short of doing an explicit path setup. This would seem to be true of most of the proposals, unsurprisingly. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 02:11:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I88wI-0003gy-8W; Tue, 10 Jul 2007 02:11:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I88wG-0003gj-IM for ram@iab.org; Tue, 10 Jul 2007 02:11:08 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I88wC-0000oC-7j for ram@iab.org; Tue, 10 Jul 2007 02:11:08 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2007 08:11:03 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEvAkkaQ/uCKh2dsb2JhbACPMwEBAQgOLA X-IronPort-AV: i="4.16,520,1175464800"; d="scan'208"; a="147627447:sNHT710888144" 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 l6A6B3j8022207; Tue, 10 Jul 2007 08:11:03 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp230.cisco.com [10.61.64.230]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6A6B2TC020596; Tue, 10 Jul 2007 06:11:02 GMT Message-ID: <469322F2.4000700@cisco.com> Date: Tue, 10 Jul 2007 08:10:58 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> <468B7388.3020306@nomadiclab.com> <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> In-Reply-To: <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=690; t=1184047863; x=1184911863; 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[RAM]=20Re=3A=20the=20separation=20of=20ID/RLOC |Sender:=20; bh=9PsecbFpd60bU2uqB1nOd2PNNXddrDuoQDSXFtVBQmA=; b=a/IJIkCxe0KeXijEEieJvFnj3c5QOtbdZ9xGkkC7ClyNnYVk3pRmMBHKjUbDx/4w54tUy+hY vFpboLtFiHgM+MHaJER+TK1J9J7q4InMiDt98J8EbKuhhzCTItTHgGis; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Christian Vogt , RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Tony Li wrote: >> Additionally, >> you still need a locator selection mechanism for the remote edge network >> -- which may involve its own signaling overhead, delay, and packet loss. > > > I think you're making an assumption that only a single locator would > be advertised at a time, and that signaling would be required to > transition between locators. > > In fact, I was positing having multiple locators advertised > simultaneously, with preferences expressed about their utilization. > We do this already today with MX records and it seems to work passably > well. LISP has just this notion, and use of NERD provides you the information in advance. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 04:12:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Apt-00062F-G1; Tue, 10 Jul 2007 04:12:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Apr-000620-OW for ram@iab.org; Tue, 10 Jul 2007 04:12:39 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Apn-0003RU-9t for ram@iab.org; Tue, 10 Jul 2007 04:12:39 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B7604212D77; Tue, 10 Jul 2007 11:12:33 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 77765212D7E; Tue, 10 Jul 2007 11:12:33 +0300 (EEST) Message-ID: <46933F70.10602@nomadiclab.com> Date: Tue, 10 Jul 2007 11:12:32 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Provider Selection and Mapping Updates (Re: [RAM] Re: the separation of ID/RLOC) References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <7127E3B7-660F-4E8F-A8B5-032F7030BC88@muada.com> <46920716.1070108@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Iljitsch: >> You are raising an interesting point. The process of detecting >> failure of a provider may indeed be a bottleneck today. > > Actually, this is the easy part, because you can simply send hello > packets at a pretty high rate across a link. Or even better: let a > watchdog timer go off when no packets have been received for a > certain time. The latter has the advantage that you don't need to > inject keepalives when there is real traffic and you aren't bound by > round trip time speed. (Which isn't too bad for a single layer 2 link > in almost all cases, though, especially if you can get rid of the > variability by bypassing any queues for the keepalives.) > > But we were talking end-to-end, or at least across a number of links. > This means the keepalive traffic explodes and there are no longer > any interface-specific tricks that can be done for optimization. But end-to-end keepalives are not the only solution to update remote mapping functions. E.g., the solution that I was having in mind is to put the edge network in charge of selecting one of the providers it connects to. This edge network can find a working provider efficiently due to the topological vicinity (as you also mentioned above). If a provider change is needed, mapping functions in remote edge networks can be updated on demand. This idea does not work equally well for all architectural approaches: - The idea is incompatible with pure host-based solutions such as Shim6, where effectively hosts are in charge of provider selection (by choosing IP source addresses from a specific provider). - The idea can be realized with pure network-based solutions such as LISP/Ivip. The problem that remains in this case is to update remote mapping functions /efficiently/ since the number of to-be-updated mapping functions is large (it potentially equals the number of edge networks). - The idea naturally fits together with combined host/network-based solutions such as Six/One. Moreover, you avoid the problem of cumbersome mapping function updates in this case. The reason is that the to-be-updated mapping function is with the correspondent host, and such a mapping function gets updated automatically (and implicitly, without extra signaling) based on the regular packet exchange. - Christian PS: I'll respond to the rest of your email in a separate message. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 04:12:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8AqA-00066c-GY; Tue, 10 Jul 2007 04:12:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Aq9-00066V-GD for ram@iab.org; Tue, 10 Jul 2007 04:12:57 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Aq5-0003SA-0X for ram@iab.org; Tue, 10 Jul 2007 04:12:57 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 66FB8212D77; Tue, 10 Jul 2007 11:12:52 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 319B4212D37; Tue, 10 Jul 2007 11:12:52 +0300 (EEST) Message-ID: <46933F83.10808@nomadiclab.com> Date: Tue, 10 Jul 2007 11:12:51 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Transport Protocol Adaptation (Re: [RAM] Re: the separation of ID/RLOC) References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <7127E3B7-660F-4E8F-A8B5-032F7030BC88@muada.com> <46920716.1070108@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Iljitsch van Beijnum wrote: >> One possible improvement would call for an edge network operator to >> redirect part of its traffic to an alternative provider as the >> delays incurred by the current primary provider increase. > > This is susceptible to oscillations. > > In my opinion, the correct way to handle this stuff is with multipath > transport protocols. Having worked on mobility management for several years, I fully agree that, for efficiency reasons, the transport layer must be made aware of connectivity changes at lower layers. This holds for both mobility and multi-homing. Purely relying on multi-homing support in transport protocols, however, would suffer the same disadvantages as Shim6. It would limit edge network operators in their freedom to pursue traffic engineering. Purely network-based solutions, on the other hand, make it much harder for a transport protocol to adapt to provider changes, because they do not receive explicit indications of such changes. (IP addresses are provider-independent, after all.) Only combined host/network-based solutions can bridge the gap. They allow edge network providers to do what they desire, and at the same time provide the host with timely information on provider changes, which is what the host's transport layer needs to adapt. > With IP, "backup" paths are rarely idle when the "primary" path is > active, so loss of the path that's currently used means a reduction > of total available bandwidth which can easily reduce this to less > than the amount of traffic generated. Ok. > So backing off until a new equilibrium is found is a good idea. Without question. >> if the mapping function would allow you to do this quickly enough >> to not impact ongoing communications too much. > > If you were using a TCP-like transport protocol that works over > multiple paths at the same time, you'd already have RTT times and > window sizes for the other path so switching could happen without > reducing bandwidth more than necessary. And load balancing would > happen automatically. Yes, I agree. Take care, - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 04:26:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8B2o-0001zE-7l; Tue, 10 Jul 2007 04:26:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8B2m-0001z2-7I for ram@iab.org; Tue, 10 Jul 2007 04:26:00 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8B2h-0004LA-QM for ram@iab.org; Tue, 10 Jul 2007 04:26:00 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 166BC212D7E; Tue, 10 Jul 2007 11:25:55 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D4C66212D77; Tue, 10 Jul 2007 11:25:54 +0300 (EEST) Message-ID: <46934292.10508@nomadiclab.com> Date: Tue, 10 Jul 2007 11:25:54 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> <468B7388.3020306@nomadiclab.com> <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> In-Reply-To: <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> if you want to an enable edge network to decide through which provider >> ingress packets are received, then the edge network must be able to tell >> remote edge networks one specific transit locator to which they should >> send packets. > > A destination can certainly express a preference, but as always, the > holder of the packet gets to decide on the next hop. This may or may > not include dropping the packet. This is best effort and there are no > guarantees. Tony, before I reply to your email, let me make sure there is no misunderstanding. What I was thinking is that, if edge network E communicates with edge network F, and E directly connects to providers P1 and P2, then E should be able to choose one of P1 and P2 for (1) egress packets that E sends to F, and (2) ingress packets that E receives from F. I think that we actually agree on this, right? - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 05:53:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CP1-00048e-Do; Tue, 10 Jul 2007 05:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8COy-00048F-QM for ram@iab.org; Tue, 10 Jul 2007 05:53:00 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8COs-0006ZW-1T for ram@iab.org; Tue, 10 Jul 2007 05:53:00 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 79A99212D7E; Tue, 10 Jul 2007 12:52:52 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3ECD7212D77; Tue, 10 Jul 2007 12:52:52 +0300 (EEST) Message-ID: <469356F3.6030204@nomadiclab.com> Date: Tue, 10 Jul 2007 12:52:51 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tony Li , RAM Mailing List Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> <468B7388.3020306@nomadiclab.com> <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> In-Reply-To: <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Tony: >> With Six/One [1], edge networks can select both their ingress and egress >> providers, and they can change them within 1 RTT without signaling. > > If I understand it correctly, a host can advertise what addresses are in > its bunch, and a network can choose to do a prefix rewrite, which > *should* result in the correspondent using the same addresses. However, > the enforced symmetry is based on the actions of the correspondent host, > which is not guaranteed. Yes, you need support on both sides. It's similar to TCP congestion control, which also can be effectively disabled by a misbehaving host, namely through acknowledgment pacing. The difference between Six/One and TCP congestion control is that, in Six/One, a host has no incentives to misbehave. The requirement for compliance on both sides exists for network-based solutions as well. Here, you need compliance by both edge networks. > Further, when taken into conjunction with > source address filtering by the next hop egress network, it implies that > the edge network is going to necessarily couple its ingress and egress > providers on a per-packet basis. Yes, Six/One enforces a symmetric path for each communication session. You can have different paths for different sessions, but each of them will be symmetric. >> There is also no packet loss if the old provider is still operational at >> the time of the change. And the granularity of provider selection (both >> ingress and egress) is on a per-communication-session level. > > Unfortunately, the only practical way of determining that an old > provider (or, more generally, an old path) is non-operational is to lose > packets. Here I was referring not to the provider fail-over case, but to the case where the edge network operator decides to switch traffic to a different operator for traffic engineering reasons. E.g., the edge network operator might want to load-balance traffic across its border routers. > In short, I'm not seeing anything different here: if you advertise > multiple locators, you would seem to be doing about the best that can be > done in terms of providing alternate path information short of doing an > explicit path setup. This would seem to be true of most of the > proposals, unsurprisingly. Not sure if I understand you correctly. But in any case: Informing a remote mapping function about locator alternatives is not enough. You also need... - a provider selection mechanism locally in an edge network that monitors provider connections and decides when it is time to switch, and - a mapping update mechanism that tells remote mapping functions /when/ to switch to /which/ alternative locator. Iljitsch and I have discussed the provider selection mechanisms in a recent email exchange (see my email "Provider Selection and Mapping Updates" from today). And it is the mapping update mechanism where the delays and packet losses that I was talking about in this email exchange come into play. - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 06:00:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CWU-0000Ui-Ga; Tue, 10 Jul 2007 06:00:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CWT-0000RL-2U for ram@iab.org; Tue, 10 Jul 2007 06:00:45 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8CWP-0006nH-M0 for ram@iab.org; Tue, 10 Jul 2007 06:00:45 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 11A75212D7E; Tue, 10 Jul 2007 13:00:41 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CB1A2212D77; Tue, 10 Jul 2007 13:00:40 +0300 (EEST) Message-ID: <469358C8.4010001@nomadiclab.com> Date: Tue, 10 Jul 2007 13:00:40 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> <468B7388.3020306@nomadiclab.com> <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> In-Reply-To: <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > In fact, I was positing having multiple locators advertised > simultaneously, with preferences expressed about their utilization. We > do this already today with MX records and it seems to work passably well. Informing a remote mapping function about locator alternatives is just one out of three mechanisms that are necessary. As said in my previous email, you also need... - a provider selection mechanism locally in an edge network that monitors provider connections and decides when it is time to switch, and - a mapping update mechanism that tells remote mapping functions /when/ to switch to /which/ alternative locator. These two additional mechanisms are the ones most critical in terms of delay and packet loss. I attended to this more in my previous email. Ciao, - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 09:52:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8G8R-0006mj-FA; Tue, 10 Jul 2007 09:52:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8G8Q-0006mW-ID for ram@iab.org; Tue, 10 Jul 2007 09:52:10 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8G8Q-0005H4-Ac for ram@iab.org; Tue, 10 Jul 2007 09:52:10 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.49]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1I8G8L-0000B2-1v; Tue, 10 Jul 2007 15:52:08 +0200 Message-ID: <46938F00.5010500@pi.se> Date: Tue, 10 Jul 2007 15:52:00 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Meeting at IETF-69? References: <003d01c7c1ef$2148eb80$bc92f385@nictkafle> <46921DDF.2090105@pi.se> <6FAE671E-A492-46E7-A651-58D8C29C86D6@cisco.com> In-Reply-To: <6FAE671E-A492-46E7-A651-58D8C29C86D6@cisco.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org All, Tony Li wrote: > > On Jul 9, 2007, at 4:37 AM, Loa Andersson wrote: > >>> There will be a Routing Research Group meeting on July 27th. Details >>> can be found here: >>> http://www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaChicago >> >> it might be worth noting that the IETF agenda, schedules the rrg meeting >> 9-11.30am, while the agenda found from the link above is from 9am-5pm. >> >> I guess that the latter is right > > > That's correct. > > The IETF schedule stops at the official end of IETF, which is Friday at > noon. Other plucky intrepid souls will carry on regardless. ;-) it feels good to be included among the "plucky intrepid souls" :) / Loa > > We do have the room for the entire day. > > Tony > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 11:32:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Hht-00066i-3A; Tue, 10 Jul 2007 11:32:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Hhp-000661-OC for ram@iab.org; Tue, 10 Jul 2007 11:32:49 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Hhp-0008Mf-FI for ram@iab.org; Tue, 10 Jul 2007 11:32:49 -0400 Received: from [10.71.183.226] (deimos.iu-bremen.de [212.201.44.249]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l6AFTlop045803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jul 2007 17:29:48 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <46933F70.10602@nomadiclab.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <7127E3B7-660F-4E8F-A8B5-032F7030BC88@muada.com> <46920716.1070108@nomadiclab.com> <46933F70.10602@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16D89DF5-E0F6-412F-85BA-227DACD8DDCB@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Provider Selection and Mapping Updates (Re: [RAM] Re: the separation of ID/RLOC) Date: Tue, 10 Jul 2007 17:31:31 +0200 To: Christian Vogt X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-2.3 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 10-jul-2007, at 10:12, Christian Vogt wrote: >> But we were talking end-to-end, or at least across a number of links. >> This means the keepalive traffic explodes and there are no longer >> any interface-specific tricks that can be done for optimization. > But end-to-end keepalives are not the only solution to update remote > mapping functions. True, but then you soon arrive at a push mechanism for the mapping/ reachability state, which also has downsides. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 11:44:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Ht8-00046s-Kf; Tue, 10 Jul 2007 11:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Ht7-00046K-Dp for ram@iab.org; Tue, 10 Jul 2007 11:44:29 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Ht7-0000Dt-5Z for ram@iab.org; Tue, 10 Jul 2007 11:44:29 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2007 17:44:24 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGtFk0aQ/uCLh2dsb2JhbACPNwEBCQ4s X-IronPort-AV: i="4.16,523,1175464800"; d="scan'208"; a="147700843:sNHT27766584" 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 l6AFiOWF032335; Tue, 10 Jul 2007 17:44:24 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp230.cisco.com [10.61.64.230]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6AFiJTC025570; Tue, 10 Jul 2007 15:44:19 GMT Message-ID: <4693A950.40202@cisco.com> Date: Tue, 10 Jul 2007 17:44:16 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: Provider Selection and Mapping Updates (Re: [RAM] Re: the separation of ID/RLOC) References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <7127E3B7-660F-4E8F-A8B5-032F7030BC88@muada.com> <46920716.1070108@nomadiclab.com> <46933F70.10602@nomadiclab.com> <16D89DF5-E0F6-412F-85BA-227DACD8DDCB@muada.com> In-Reply-To: <16D89DF5-E0F6-412F-85BA-227DACD8DDCB@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1730; t=1184082264; x=1184946264; 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=20Provider=20Selection=20and=20Mapping=20Updates=20(Re= 3A=20[RAM]=20Re=3A=20the=09separation=0A=20of=20ID/RLOC) |Sender:=20; bh=ZN1kxrOLe4wcucZrcGURshLmZXQK3lP6dCPYpLoRriw=; b=oYtAm8HHXmB0AttpBdmwwuOULD/7ClheJ7uaHcCcz0iZ85iUhYL0FWXzupkPPmXtESOPqYSo dqemzqEnBRsfX19XsT/NrvihBEBVNXi2kpDMs8ZEbrnhfGRI42UrEMq+; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Christian Vogt , RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Iljitsch van Beijnum wrote: > On 10-jul-2007, at 10:12, Christian Vogt wrote: > >>> But we were talking end-to-end, or at least across a number of links. >>> This means the keepalive traffic explodes and there are no longer >>> any interface-specific tricks that can be done for optimization. > >> But end-to-end keepalives are not the only solution to update remote >> mapping functions. > > True, but then you soon arrive at a push mechanism for the > mapping/reachability state, which also has downsides. Yes, I think this is a fair point, and so one requires a bit of intelligence when it comes to doing keepalives. For instance, if they are generated by the LISP ETR in the reverse direction with an indication of expected frequency then it becomes a matter of policy by the mapping owner as to how often they can be set, and they can be generated as long as there is traffic for a given EID prefix. This same approach can be used with any tunneled architecture. Think of it akin to a DNS SOA record. Some examples then come to mind: * A prefix that is used for voice might have a very high update frequency (10 - 20 seconds); * A prefix that is used by a consumer might be a lower frequency. The key point is that the processing of these keepalives are done, at least in LISP, solely by ITRs and ETRs, and not by the global routing system or by end hosts. So this means that there is potential aggregation of keepalives with no impact on the core, other than what is likely to be a modest amount of traffic. But I've only really just thought a little about this issue. Does anyone have a few good references to work in this space? Eliot Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 11:57:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8I5z-0006Jt-FC; Tue, 10 Jul 2007 11:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8I5y-0006GE-Id for ram@iab.org; Tue, 10 Jul 2007 11:57:46 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8I5y-0000b7-Bc for ram@iab.org; Tue, 10 Jul 2007 11:57:46 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Jul 2007 08:57:45 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAN9Jk0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,523,1175497200"; d="scan'208"; a="179606309:sNHT27460701" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6AFvjNX027232; Tue, 10 Jul 2007 08:57:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6AFvcH0014400; Tue, 10 Jul 2007 15:57:45 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); Tue, 10 Jul 2007 08:57:44 -0700 Received: from [171.69.135.120] ([171.69.135.120]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 08:57:44 -0700 In-Reply-To: <46934292.10508@nomadiclab.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> <468B7388.3020306@nomadiclab.com> <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> <46934292.10508@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A446F49-E8A4-4F86-B5F4-D238153E1B94@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Re: the separation of ID/RLOC Date: Tue, 10 Jul 2007 08:57:40 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Jul 2007 15:57:44.0048 (UTC) FILETIME=[0D6A5F00:01C7C30B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1479; t=1184083065; x=1184947065; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20the=20separation=20of=20ID/RLOC |Sender:=20; bh=wI4u1TqFXQteORFPwVB569UOSPS+tQ3zc8KabhJ0lgA=; b=uwNWhwYzndWNDnjFLVHC5mdLNNBV1xWxFub9X7Lff5WDyxjpjyDrgLWbZ30UKH7sqeXuz5Xm S55YAM5h2bnH2XPrSYmECFRv1AOdbLQ4/64QIIlZ6NjYlC1KNN432cXK; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jul 10, 2007, at 1:25 AM, Christian Vogt wrote: >>> if you want to an enable edge network to decide through which >>> provider >>> ingress packets are received, then the edge network must be able >>> to tell >>> remote edge networks one specific transit locator to which they >>> should >>> send packets. >> >> A destination can certainly express a preference, but as always, the >> holder of the packet gets to decide on the next hop. This may or may >> not include dropping the packet. This is best effort and there >> are no >> guarantees. > > before I reply to your email, let me make sure there is no > misunderstanding. > > What I was thinking is that, if edge network E communicates with edge > network F, and E directly connects to providers P1 and P2, then E > should > be able to choose one of P1 and P2 for (1) egress packets that E sends > to F, and (2) ingress packets that E receives from F. > > I think that we actually agree on this, right? No, sorry. E gets to decide which egress it uses. However, F also gets to decide what egress it uses. This is necessary for symmetry. Since F and E may not agree, ingress policy may not be respected. If E prefers P1 as ingress and F prefers P2 as egress and there's no P1-P2 link, then you end up violating E's preferences. The only way that E can guarantee its ingress policy is to not advertise reachability through sub-optimal providers. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 12:13:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8IKq-0003zg-9v; Tue, 10 Jul 2007 12:13:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8IKo-0003oJ-NR for ram@iab.org; Tue, 10 Jul 2007 12:13:06 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8IKo-0001Mb-CK for ram@iab.org; Tue, 10 Jul 2007 12:13:06 -0400 Received: from [10.71.183.226] (deimos.iu-bremen.de [212.201.44.249]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l6AGA2nu046520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jul 2007 18:10:02 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <4693A950.40202@cisco.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <7127E3B7-660F-4E8F-A8B5-032F7030BC88@muada.com> <46920716.1070108@nomadiclab.com> <46933F70.10602@nomadiclab.com> <16D89DF5-E0F6-412F-85BA-227DACD8DDCB@muada.com> <4693A950.40202@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C6D5A1A-5342-41F6-A073-987BD9C297B3@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Provider Selection and Mapping Updates (Re: [RAM] Re: the separation of ID/RLOC) Date: Tue, 10 Jul 2007 18:11:46 +0200 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-2.4 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Christian Vogt , RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 10-jul-2007, at 17:44, Eliot Lear wrote: > The key point is that the processing of these keepalives are done, > at least in LISP, solely by ITRs and ETRs, and not by the global > routing system or by end hosts. So this means that there is > potential aggregation of keepalives with no impact on the core, > other than what is likely to be a modest amount of traffic. Yes, that helps a lot. However, I still feel the need to be the voice of restraint in the face of additional overhead... > But I've only really just thought a little about this issue. Does > anyone have a few good references to work in this space? Please have a look at: http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- detection-08.txt The idea here is that both the situation where there is traffic in each direction and the situation where there is no traffic are an indication that there is no problem, so we don't need to do anything here, and no keepalives are sent. Only when we send but not receive there must be a problem, and if we receive but don't send the other side is going to think there's a problem so we send keepalives. If you add some special case logic for common things such as TCP ACKs and TCP session termination, there's hardly ever any need to send keepalives. Only when active/quiet transitions can't be detected or in the unusual case that there is only traffic in one direction will there be keepalives. Obviously this takes a bit more logic to implement than simply fire off a keepalive every few seconds. For shim6, it's important to do this right because you can get keepalive explosions if something goes down if you're not careful. For the ETR/ITR case I would at least want to avoid keepaliving when there is no traffic between an ETR and an ITR. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 12:21:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ITF-00073C-FN; Tue, 10 Jul 2007 12:21:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ITE-000735-FD for ram@iab.org; Tue, 10 Jul 2007 12:21:48 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8ITE-0001ad-6E for ram@iab.org; Tue, 10 Jul 2007 12:21:48 -0400 Received: from [192.168.13.69] (44.Red-80-37-82.staticIP.rima-tde.net [80.37.82.44]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l6AGLcVI001866; Tue, 10 Jul 2007 09:21:38 -0700 (PDT) In-Reply-To: <4692365F.3070006@firstpr.com.au> References: <46922CB3.2090107@firstpr.com.au> <4692365F.3070006@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: [RAM] draft-jen-apt and eFIT Date: Tue, 10 Jul 2007 09:21:34 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jul 9, 2007, at 6:21 AM, Robin Whittle wrote: > There is an eFIT I-D from February: > > http://tools.ietf.org/html/draft-wang-ietf-efit-00 > > > - Robin that one is really outdated. We are working on a new version. Will send a pointer before Chicago. Lixia _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 12:25:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8IWe-0003ES-Cu; Tue, 10 Jul 2007 12:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8IWc-0003EG-Kx for ram@iab.org; Tue, 10 Jul 2007 12:25:18 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8IWc-0001gZ-Bp for ram@iab.org; Tue, 10 Jul 2007 12:25:18 -0400 Received: from [192.168.13.69] (44.Red-80-37-82.staticIP.rima-tde.net [80.37.82.44]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l6AGPFt1002040; Tue, 10 Jul 2007 09:25:15 -0700 (PDT) In-Reply-To: <46922CB3.2090107@firstpr.com.au> References: <46922CB3.2090107@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9476BFC4-02A4-4FA6-ACD9-BFE5A81CB7CF@cs.ucla.edu> Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: [RAM] draft-jen-apt and eFIT Date: Tue, 10 Jul 2007 09:25:12 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jul 9, 2007, at 5:40 AM, Robin Whittle wrote: > There is a new I-D which hasn't been mentioned on this list so far: > > APT: A Practical Transit Mapping Service > > Dan Jen, Michael Meisel, Dan Massey, Lan Wang, > Beichuan Zhang and Lixia Zhang > > http://tools.ietf.org/html/draft-jen-apt > > Section 8 begins: > > Clearly, the deployment of APT will coincide with the > deployment of eFIT (or a similar architecture). I would put emphasis on that APT is designed for the class of solutions that need a mapping service. > eFIT is: > > A Scalable Routing System Design for Future Internet > > Dan Massey, Lan Wang, Beichuan Zhang, Lixia Zhang > ACM SIGCOMM Workshop on IPv6, August 2007. > > The copy of this paper at: > > http://www.cs.ucla.edu/~lixia/papers/07SIG_IP6WS.pdf > > currently has a problem with permissions, but I emailed Lixia > about this, so hopefully it will be available soon. fixed. Lixia _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 10 15:47:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Lge-0006ru-9O; Tue, 10 Jul 2007 15:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Lgc-0006rm-Ik for ram@iab.org; Tue, 10 Jul 2007 15:47:50 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8LgY-0001lt-0W for ram@iab.org; Tue, 10 Jul 2007 15:47:50 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 8EBAF59E47; Wed, 11 Jul 2007 05:47:43 +1000 (EST) Message-ID: <4693E252.4090507@firstpr.com.au> Date: Wed, 11 Jul 2007 05:47:30 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [RAM] Early version of Ivip I-D X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here is a draft version of the forthcoming Ivip I-D: http://www.firstpr.com.au/ip/ivip/temp/draft-whittle-ivip-arch-00-draft.txt http://www.firstpr.com.au/ip/ivip/temp/draft-whittle-ivip-arch-00-draft.html There are about 62 pages of text and diagrams. If anyone is keen enough to read some of this before the weekend and suggest any improvements, point out any blunders etc. I would really appreciate it. I plan to finalise version 00 on Sunday. The operation of Ivip ETRs is simple - they decapsulate. ITRs tunnel to a given address, for every Ivip-mapped destination address. That's it - there's no ITR to ETR communication, no information in the IP-in-IP header, multiple ETR addresses, no explicit mechanisms for TE or trying to determine reachability. There are two reasons why this I-D is relatively long. Firstly I cover an ambitious system by which end-user changes are intended to reach all the ITRs very quickly - in a few seconds ideally, but perhaps faster. Secondly, my explanation is pretty hands-on, with discussion and diagrams. I hope that RAM list members will be able to read it from one end to the other and understand it pretty well without much frustration or head scratching. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 11 02:30:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Viq-00085U-9G; Wed, 11 Jul 2007 02:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Vio-00085L-Bf for ram@iab.org; Wed, 11 Jul 2007 02:30:46 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Vij-0006If-UG for ram@iab.org; Wed, 11 Jul 2007 02:30:46 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Jul 2007 08:30:42 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAMWlEaQ/uCLh2dsb2JhbACPOAEBAQgOLA X-IronPort-AV: i="4.16,525,1175464800"; d="scan'208"; a="147736922:sNHT201759868" 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 l6B6UeD6010412; Wed, 11 Jul 2007 08:30:40 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6B6UeTE013907; Wed, 11 Jul 2007 06:30:40 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:30:40 +0200 Received: from [192.168.0.5] ([10.61.80.111]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:30:39 +0200 In-Reply-To: <469358C8.4010001@nomadiclab.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> <468B7388.3020306@nomadiclab.com> <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> <469358C8.4010001@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66440E3B-AA51-48F5-8ECB-665C227BF73E@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: the separation of ID/RLOC Date: Tue, 10 Jul 2007 23:30:33 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Jul 2007 06:30:39.0671 (UTC) FILETIME=[FFB83470:01C7C384] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2405; t=1184135440; x=1184999440; c=relaxed/simple; s=amsdkim2001; 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[RAM]=20Re=3A=20the=20separation=20of=20ID/RLOC |Sender:=20; bh=zPvydR9MkDwMQMcRBYJzk6A9+7VeE5HBczrPe22iCBs=; b=AqOKwUMSEicIN27KHVHOuIK4O4itD8FBr0DG9bg4Nr4gzgDsbQLwRPJETf0x9ON4irnKIU6e NbdTzVpIDjgp3InHO2oLnZoAA2CGxFtNpWpHMk7r7s0XKlqD6BzYIduT; Authentication-Results: ams-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Tony Li , RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Informing a remote mapping function about locator alternatives is just > one out of three mechanisms that are necessary. As said in my > previous > email, you also need... > > - a provider selection mechanism locally in an edge network that > monitors provider connections and decides when it is time to > switch, and > > - a mapping update mechanism that tells remote mapping functions / > when/ > to switch to /which/ alternative locator. > > These two additional mechanisms are the ones most critical in terms of > delay and packet loss. I attended to this more in my previous email. The LISP-01 draft documents the following design: o Map-Replies contain locator-sets for an EID-prefix. Along with each locator is a priority and weight. This is used so either the ETR can force the ITR what locators to use or the ETR can allow an ITR to select the locators it wants within the scope of locators the ETR allows. o The Map-Replies do not convey reachability status of the locators. o The ITR, when it encapsulates packets sets the loc-reach-bits field to indicate which locators for its site are currently reachable. The loc-reach- bits is a bitfield that defines the relative location of a locator record in a Map- Reply. Currently the bitfield is 12-bits to convey reachability for 12 locators for a given EID-prefix. o The ITR at a site knows reachability of it's own locators based on the IGP. And typically, the ITRs will be close to the failures, so will be able to have this info sooner than any other node in the network. As long as packets are being sent out of the site, any receiving site will get up to date reachability of locators. Failures that are close the ITR include 1) ITR failure, 2) CE-PE link failure, and 3) PE router failure. o When an ETR detects a loc-reach-bit setting that changes from 1 to 0, it will not use the locator associated with that bit-setting. Also, using NERD or CONS as a database mapping service, the mapping entries within them also do not provide reachability status. This allows us to scale the Tony Li rule of "state * rate". Where we know the variable 'state' will be very large so we must keep the value of 'rate' small. Keeping reachability status out of the mapping database allows us to do that. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 11 03:39:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WmM-0004t6-Ej; Wed, 11 Jul 2007 03:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WmL-0004sv-0y for ram@iab.org; Wed, 11 Jul 2007 03:38:29 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8WmG-0007cY-J5 for ram@iab.org; Wed, 11 Jul 2007 03:38:29 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C7018212D7E; Wed, 11 Jul 2007 10:38:22 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9195D212D77; Wed, 11 Jul 2007 10:38:22 +0300 (EEST) Message-ID: <469488EC.1050504@nomadiclab.com> Date: Wed, 11 Jul 2007 10:38:20 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: Provider Selection and Mapping Updates (Re: [RAM] Re: the separation of ID/RLOC) References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <7127E3B7-660F-4E8F-A8B5-032F7030BC88@muada.com> <46920716.1070108@nomadiclab.com> <46933F70.10602@nomadiclab.com> <16D89DF5-E0F6-412F-85BA-227DACD8DDCB@muada.com> In-Reply-To: <16D89DF5-E0F6-412F-85BA-227DACD8DDCB@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> But end-to-end keepalives are not the only solution to update remote >> mapping functions. > > True, but then you soon arrive at a push mechanism for the > mapping/reachability state, which also has downsides. Another option, which is the one Six/One uses, is to rely on a mechanism that is locally executed between an edge network and its providers. If that mechanism decides to switch to a different provider, then it rewrites the IP source addresses of egress packets so as to signal the provider/address change to both end hosts. End hosts then adopt the new provider. Then you don't have any signaling on an end-to-end basis. Only possibly some signaling between the edge network and its providers. (Since this signaling occurs only locally, one could do it at higher frequency.) A host's task of finding a correspondent host's first IP address can be done through advertising multiple addresses in DNS. If trying multiple IP addresses causes a bit of latency, this is typically not so critical during session establishment than it may be in the middle of a session. The host will cache the correspondent host's last working IP address in case it contacts that correspondent host again shortly afterwards. FWIW, the mechanism I am describing here is, in a sense, a "push" mechanism. So it does not contradict your statement (which I think is valid) that you end up with a push mechanism if you don't "pull" mapping state information through keepalives. My point here is that "push" in this case goes without extra end-to-end signaling overhead. - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 11 06:35:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ZXC-0008Ii-Fz; Wed, 11 Jul 2007 06:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ZX9-0008Bt-Qb for ram@iab.org; Wed, 11 Jul 2007 06:34:59 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8ZX5-0003dS-CN for ram@iab.org; Wed, 11 Jul 2007 06:34:59 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0648A212D7E; Wed, 11 Jul 2007 13:34:54 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C044A212D77; Wed, 11 Jul 2007 13:34:53 +0300 (EEST) Message-ID: <4694B24B.40608@nomadiclab.com> Date: Wed, 11 Jul 2007 13:34:51 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> <468B7388.3020306@nomadiclab.com> <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> <46934292.10508@nomadiclab.com> <7A446F49-E8A4-4F86-B5F4-D238153E1B94@cisco.com> In-Reply-To: <7A446F49-E8A4-4F86-B5F4-D238153E1B94@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > If E prefers P1 as ingress and F prefers P2 as egress and there's no > P1-P2 link, then you end up violating E's preferences. Tony, why would E prefer an ingress provider (P1 in this case) via which it cannot reach correspondent edge networks? Or vice versa, why would F prefer an egress provider (P2 in this case) via which it cannot be reached by correspondent edge networks? The only case where this would make sense is, IMO, a scenario in which all of an edge network's providers allow only unidirectional traffic, either ingress or egress. That edge network would want to chose a different provider for ingress than for egress. You are raising an interesting point. I wonder how often this happens, though. Do you have some more insight on this? And one should also take a look at the impact of such asymmetry on applications... - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 11 10:49:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dVH-0002wc-1T; Wed, 11 Jul 2007 10:49:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dVF-0002wW-OE for ram@iab.org; Wed, 11 Jul 2007 10:49:17 -0400 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8dVB-0002DM-79 for ram@iab.org; Wed, 11 Jul 2007 10:49:17 -0400 Received: from [163.117.139.227] (unknown [163.117.139.227])by smtp.uc3m.es (Postfix) with ESMTP id 2256342C62for ; Wed, 11 Jul 2007 16:49:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Wed, 11 Jul 2007 16:49:07 +0200 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.9791 TC:1F TRN:66 TV:3.6.1039(15292.003) 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-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [RAM] Fwd: I-D ACTION:draft-bagnulo-lisp-threat-01.txt X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, I have updated the threat analysis for LISP to the new 01 version of LISP. Regards, marcelo Inicio del mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 9 de julio de 2007 21:15:02 GMT+02:00 > Para: i-d-announce@ietf.org > Asunto: I-D ACTION:draft-bagnulo-lisp-threat-01.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Preliminary LISP Threat Analysis > Author(s) : M. Bagnulo > Filename : draft-bagnulo-lisp-threat-01.txt > Pages : 16 > Date : 2007-7-9 > > This document performs a preliminary threat analysis on the > Locator/ID Separation Protocol (LISP) as defined in > draft-farinacci-lisp-01.txt. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-lisp-threat-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-bagnulo-lisp-threat-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bagnulo-lisp-threat-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-7-9142859.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 11 11:48:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ePy-0003vh-Q2; Wed, 11 Jul 2007 11:47:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ePw-0003sU-Mf for ram@iab.org; Wed, 11 Jul 2007 11:47:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8ePr-00042M-BK for ram@iab.org; Wed, 11 Jul 2007 11:47:52 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2007 08:47:46 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJGYlEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,527,1175497200"; d="scan'208"; a="384963264:sNHT805913280" 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 l6BFljD4021962; Wed, 11 Jul 2007 08:47:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6BFlaka025387; Wed, 11 Jul 2007 15:47: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); Wed, 11 Jul 2007 08:47:36 -0700 Received: from [171.69.135.120] ([171.69.135.120]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:47:36 -0700 In-Reply-To: <4694B24B.40608@nomadiclab.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com> <468B7388.3020306@nomadiclab.com> <34F6E4E3-C4FA-433E-B921-EB509FE485A7@cisco.com> <46934292.10508@nomadiclab.com> <7A446F49-E8A4-4F86-B5F4-D238153E1B94@cisco.com> <4694B24B.40608@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Re: the separation of ID/RLOC Date: Wed, 11 Jul 2007 08:47:31 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Jul 2007 15:47:36.0179 (UTC) FILETIME=[CD82AC30:01C7C3D2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=995; t=1184168865; x=1185032865; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20the=20separation=20of=20ID/RLOC |Sender:=20; bh=SFXMmhd8VV4mgkp6o9xbPisyQCtYejpnXJACfo+J8Fk=; b=W83rL6Z3XLrNRuvsNBtSdBs1lPRm3p9A54tZthjI1PscGGfY//vPGOFPKmGXxN1oc9HmaRWL SXfU7aZAJUJSp9cZX8bilgyTJiFhFTo4Ny/YcWm6LBIL/Ig+s/ryMfvV; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jul 11, 2007, at 3:34 AM, Christian Vogt wrote: >> If E prefers P1 as ingress and F prefers P2 as egress and there's no >> P1-P2 link, then you end up violating E's preferences. > why would E prefer an ingress provider (P1 in this case) via which it > cannot reach correspondent edge networks? > > Or vice versa, why would F prefer an egress provider (P2 in this case) > via which it cannot be reached by correspondent edge networks? I was assuming reachability, otherwise the entire question makes no sense. > You are raising an interesting point. I wonder how often this > happens, > though. Do you have some more insight on this? And one should also > take a look at the impact of such asymmetry on applications... Sorry, not much. I'm sure that in the whole of the Internet today, there must be at least one case like this currently in existence. It's probably masked by the multihomed networks using a PI address instead of PA. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 11 14:08:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gbW-0004XE-OO; Wed, 11 Jul 2007 14:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gbU-0004V6-It for ram@iab.org; Wed, 11 Jul 2007 14:07:56 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8gbP-0000x8-J8 for ram@iab.org; Wed, 11 Jul 2007 14:07:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2007 11:07:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAF+5lEarR7O6/2dsb2JhbACCYg X-IronPort-AV: i="4.16,527,1175497200"; d="scan'208,217"; a="385009659:sNHT540230482" 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 l6BI7cfI025150; Wed, 11 Jul 2007 11:07:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6BI7WXt016776; Wed, 11 Jul 2007 18:07: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); Wed, 11 Jul 2007 11:07:34 -0700 Received: from [171.69.135.120] ([171.69.135.120]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 11:07:34 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) To: Routing Research Group list , RAM Mailing List Message-Id: <172E28D8-8862-4BA4-A908-B18F385006B9@cisco.com> References: From: Tony Li Date: Wed, 11 Jul 2007 11:07:29 -0700 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Jul 2007 18:07:34.0163 (UTC) FILETIME=[5B195630:01C7C3E6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=17470; t=1184177258; x=1185041258; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Fwd=3A=20I-D=20ACTION=3Adraft-irtf-rrg-design-goals-01.txt=20 |Sender:=20; bh=lA6ksm0Qi6Qrv+fLksFqpNw3cevvCBKjgVDEv44fzoQ=; b=IkpBou14zbmmxLBpV5YXoXcc+QLyZQblBaLTekL4y12QDK6esJgNMnUVTU468AJD2KeL0G33 aKfnjZkJ588ICBhUivUGLZKIpG3HRQVdLMe8v0MhVBoTH03SvZB8gGz+; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: Subject: [RAM] Fwd: I-D ACTION:draft-irtf-rrg-design-goals-01.txt X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0199537314==" Errors-To: ram-bounces@iab.org --===============0199537314== Content-Type: multipart/alternative; boundary=Apple-Mail-9--288380340 --Apple-Mail-9--288380340 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI... Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: July 10, 2007 11:15:01 AM PDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-irtf-rrg-design-goals-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Design Goals for Scalable Internet Routing > Author(s) : T. Li > Filename : draft-irtf-rrg-design-goals-01.txt > Pages : 9 > Date : 2007-7-10 > > It is commonly recognized that the Internet routing and addressing > architecture is facing challenges in scalability, mobility, multi- > homing, and inter-domain traffic engineering. The RRG is designing > an alternate architecture to meet these challenges. This document > consists of a prioritized list of design goals for the > architecture. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-irtf-rrg-design-goals-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-irtf-rrg-design-goals-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-irtf-rrg-design-goals-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-7-10131601.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-9--288380340 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

FYI...


Begin= forwarded message:

Date: July 10, 2007 11:15:01 AM = PDT
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-irtf-rrg-design-goals-01.txt=A0

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


Title : Design Goals for Scalable = Internet Routing
Author(s) : T. = Li
Filename : = draft-irtf-rrg-design-goals-01.txt
= Pages = = : 9
Date : 2007-7-10


It is = commonly recognized that the Internet routing and addressing
=A0=A0 = architecture is facing challenges in scalability, mobility, = multi-
=A0=A0 homing, and inter-domain = traffic engineering.=A0 The = RRG is designing
=A0=A0 an alternate architecture = to meet these challenges.=A0 = This document
=A0=A0 consists of a prioritized = list of design goals for the architecture.

A URL for = this Internet-Draft is:

To remove yourself from the I-D Announcement list, = send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-irtf-rrg-design-goals-01.txt".

A list of Internet-Drafts = directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-irtf-rrg-design-goals-01.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

=

= --Apple-Mail-9--288380340-- --===============0199537314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0199537314==-- From ram-bounces@iab.org Thu Jul 12 00:39:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8qSe-0006lM-Ls; Thu, 12 Jul 2007 00:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8qSd-0006kz-8t for ram@iab.org; Thu, 12 Jul 2007 00:39:27 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8qSZ-0004Tl-52 for ram@iab.org; Thu, 12 Jul 2007 00:39:27 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id CB6A259DDD; Thu, 12 Jul 2007 14:39:15 +1000 (EST) Message-ID: <4695B066.4000805@firstpr.com.au> Date: Thu, 12 Jul 2007 14:39:02 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org References: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> In-Reply-To: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Subject: [RAM] draft-bagnulo-lisp-threat-01 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org My understanding of: http://tools.ietf.org/html/draft-bagnulo-lisp-threat-01 is that 3.1 to 3.1.1.3 involves sending an encapsulated packet to a combined ETR-ITR which convinces that router that the RLOC to use when encapsulating packets with EID=V is the the attacker's address. So subsequent packets with EID=V will wind up at the attacker's host. This is for "LISP 1" (1.5?) where there is no central database. In LISP 2.x, 3.x or 4.x: http://www1.ietf.org/mail-archive/web/ram/current/msg01289.html is it true to say that the ETR-ITR wouldn't learn any such false information simply by receiving a packet, because its mapping is controlled by a database instead? Ivip's ITRs are always controlled by one or more databases - there are no messages and ETRs don't "learn" anything from the encapsulated packet. So this vulnerability doesn't apply to Ivip. Likewise, Ivip has no "Map-Reply" message and the ITRs don't learn their mapping from anything other than their own copy of the database(s) or from responses resulting from queries to a query server which has a copy. So the rest of section 3.1, 3.2.1, 3.2.2 and 3.2.3 doesn't apply to Ivip. In LISP 2 to 4 does the ITR learn mapping information from Map-Reply messages or from an associated ETR learning an RLOC from the outer header of an encapsulated packet it receives? 3.2.4 concerns the cache of ETRs or ITRs overflowing - but the sentence: An attacker could massively generate either tunnelled data packets so that the router cache is overflowed. looks incomplete. I think that in all LISP variants the ITR is not intended to carry a copy of the entire database, so in principle its cache could be overflowed by either making it learn mapping information from the headers of encapsulated packets or perhaps by some use of the Map Reply message. I think the ITR's cache could also be made to overflow by simply sending packets to it which are addressed to a wide variety of LISP EIDs, each with different mappings. This would force the ITR to query and cache the mapping for each EID, or for whatever prefix each EID is within which has the same mapping information. Ivip has ITRDs with a full copy of "the database" - actually multiple arrays of mapping information, one for each Ivip Mapped Address Block (IMAB, previously "master-subnet"). So an ITRD can't be overloaded by any pattern of destination addresses in the packets it encapsulates. This is practical, at least for IPv4, using a server with a 64 bit CPU, rather than a conventional router (though in principle some routers could do it) because the Ivip mapping is simply a 4 byte IP address for every address in the IMABs. (LISP's data per EID IP address or prefix is more extensive.) 2 billion Ivip-mapped addresses therefore require 8 gigabytes of RAM, plus some extra RAM for indexing into this set of arrays for each IMAB and for decoding the incoming database dumps (boot time) and real-time updates. Ivip ITRCs (caching ITRs) and ITFHs (caching ITR functions in sending hosts) are subject to some cache size limit and so would be subject to a DoS attack (or simply non-malicious traffic) which consisted of a sufficiently fast and diverse range of data packets to addressed to Ivip-mapped addresses. However, the response of an ITFH or ITRC to this would probably be to not try to retain the mapping for every address of every packet - which is the same as their normal way of working, which is to only seek mapping information for addresses for which multiple packets are received. If an ITFH lets through a packet without tunneling it, then the packet will be forwarded to some ITRC or ITRD (or maybe explicitly tunneled by the ITFH to an ITRD). Likewise, if things are properly organised, an ITRC doesn't have to encapsulate and tunnel every packet with an Ivip-mapped DA. It can either tunnel these packets to some other ITRC, or ideally to an ITRD, which will handle them - or if the local routing system is suitably organised, the packets will flow through one or more ITRCs or ITRDs anyway. I will add something like this to the I-D: The idea is that any ITFH or ITRC can let a packet addressed to an IMAB pass on to another ITRC or an ITRD which will handle it. This will happen naturally with an ITFH, since any still unencapsulated packets it emits will ultimately be forwarded to some router which advertises the Ivip-Mapped Address Blocks (IMABs) and so can presumably definitely encapsulate the packet. To achieve this, any ITRC which advertises the Ivip IMABs must have a way of tunneling the packets it can't handle to some other ITR which definitely can encapsulate them. This could be another such ITRC, provided any chain or tree of these always forwards packets which still need to be encapsulated towards either an ITRD which will do it, or to the Internet, where the packets should find such an ITRD (which hopefully won't be overloaded.) ITRC functions could be installed on internal routers in a network, so they look out for all packets with DA matching any IMAB and either encapsulate them, or leave them unencapsulated. However, forwarding some or all of these packets without encapsulation will only work if this ITRC does not actually advertise itself as the destination for packets addressed to these IMABs. If it did, the packets it forwards which still need to be encapsulated will probably not progress to any other router. So an ITRC which is simply in the path of packets in general, without advertising itself as the destination for the Ivip IMABs, doesn't need to explicitly tunnel packets it can't handle to some other ITR. So the impact of the DoS attack on any one ITRC or ITFH in a network which was correctly configured for Ivip (according to the new text above) would be to cause some packets to go on longer paths before an ITR encapsulated them. This would cause extra load on the network, and on these other ITRs, but unless the packet wound up at a core ITR or some other ITR which advertised the IMAB prefixes and was overloaded with traffic, then the packet would always be encapsulated and find its way to the destination. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 12 01:33:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8rIt-0004gy-Of; Thu, 12 Jul 2007 01:33:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8rIr-0004Zf-Of for ram@iab.org; Thu, 12 Jul 2007 01:33:25 -0400 Received: from ns2.nict.go.jp ([133.243.3.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8rIn-0006fG-0f for ram@iab.org; Thu, 12 Jul 2007 01:33:25 -0400 Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns2.nict.go.jp with ESMTP id l6C5X9nS017600; Thu, 12 Jul 2007 14:33:09 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id l6C5X9u2018201; Thu, 12 Jul 2007 14:33:09 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id l6C5X97D018196; Thu, 12 Jul 2007 14:33:09 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 5F3F4420E; Thu, 12 Jul 2007 14:33:09 +0900 (JST) Received: from nictkafle (5gou2f-dhcp28.nict.go.jp [133.243.146.188]) by mail1.nict.go.jp (Postfix) with ESMTP id 40A2C4206; Thu, 12 Jul 2007 14:33:09 +0900 (JST) From: "Ved Kafle" To: "'Dino Farinacci'" Date: Thu, 12 Jul 2007 14:35:05 +0900 Message-ID: <000101c7c446$66a01330$bc92f385@nictkafle> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1F49209D-D02B-4EA7-8ED6-1AED699E4C48@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ram@iab.org Subject: [RAM] RE: question about LISP v1 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, I have the following questions and comments on LISP v01. Section 6.1.1 What is a CAR? Its description is missing. ITR-AFI and CAR-AFI has the same description. How to distinguish them? Why do you set Originating ITR RLOC Address to zero for UDP-based messages? What are its other possible values? What is a Path Vector List? Its description is missing. You say LISP Nonce is 6 bytes long, in Map-Request Message Format it's just 5 bytes. (Why the LISP Nonce is 6 bytes long? Any reasons?) Section 6.1.3 How many Locs can be included in each Rec? How to know that there are many Locs in each Rec? If there is only one Loc in each Rec, then using Record count and Locator count fields is redundant. If many, then the Locator count field should be inside Rec. In that case, the total number of locators would be equal to the summation of number of Recs multiplied by the number of Locs in each Rec. Some typos: ---------------------- Section 4.1 (First line ) ... unicast unicast packet flow ... (Last para) ... section Section 6 ... Section 6.1.1 Record count: ... the a number of times . Section 6.1.3 Record Count: The number of records in this request message => or reply message? Thank you. Ved Kafle @NICT, Japan > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Saturday, July 07, 2007 9:00 AM > To: marcelo bagnulo braun > Cc: ram@iab.org > Subject: [RAM] Re: question about LISP v1 > > > > How does an initiator node informs the receiver about its multiple > > RLOCs? > > This has not changed from the -00 draft. the receiver can glean *a* > locator from the packet it is decaping (the ETR that is). If the ETR > wants the complete set of locators with their associated priorities > and weights, it must either 1) send a packet returning with > the outer > DA equal to the inner DA (I call this a data probe) or 2) if > there is > a mapping service in place, do a lookup to get the mapping. > > For the later, if LISP-NERD is used, the lookup is local the the ITR > since the mappings are pushed. If LISP-CONS is used, a > Map-Request is > sent by the ITR to it's configured CAR over a TCP connection. > > > I mean, in the described packet flow sequence, the initiator sends > > a LISP data packet containing its EID and RLOC in the source > > address fields of the inner and outer header, and this is how the > > receiver ETR learns about the EID-to-RLOC mapping of the > initiator. > > However, this only conveys a single RLOC, what happens if the > > initiator has multiple RLOCs (the most common in a > multihomed site) > > and wants to inform the receiver ETR about them? > > Right, the ETR has some flexibility here. It can use the single > locator to return packets while in parallel send a > Map-Request to get > the rest of them. When the ITR is sending packets this ETR, the > Locoator Reachability bits are continually updated for each packet > the ITR encaps to the ETR. So the ETR will know the > reachability status. > > There is a detail about which loc-reach-bit to associated with the > outer SA but I can tell you about that offline. > > > In the previous version of LISP, it was possible for the initiator > > to send an unsolicited Map-Reply message containing the whole RLOC > > set to the receiver. > > No, it was never unsolicited, because the sender of the Map-Reply > would not know where to send it. > > > however, the current version includes the nonce, so Map-reply > > messages can only be sent as replies to data packets or map > request > > messages. So, does this means that > > The -01 draft uses both the fact that the Nonce much match as > well as > the ITR keeping a local cached entry for the EID in a "incomplete" > state. Similar to how some ARP implementations are coded. > > > the initiator cannot inform spontaneously of its locator set and > > must wait for the receiver to ask for it? or there is a mean for > > the initiator to send the locator set to the receiver even if the > > receiver haven't asked for it? > > The Map-Reply is never sent unsolicited. > > Dino > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 12 04:05:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tft-0001M6-MQ; Thu, 12 Jul 2007 04:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tfr-0001Lm-Fz for ram@iab.org; Thu, 12 Jul 2007 04:05:19 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8tfn-0002ZG-31 for ram@iab.org; Thu, 12 Jul 2007 04:05:19 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 12 Jul 2007 01:05:13 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMZ9lUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,530,1175497200"; d="scan'208"; a="6654868:sNHT14504520" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6C85DPw006517; Thu, 12 Jul 2007 01:05:13 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6C853GW019344; Thu, 12 Jul 2007 08:05:13 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); Thu, 12 Jul 2007 01:05:03 -0700 Received: from [192.168.0.5] ([10.21.117.135]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 01:05:02 -0700 In-Reply-To: <000101c7c446$66a01330$bc92f385@nictkafle> References: <000101c7c446$66a01330$bc92f385@nictkafle> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Date: Thu, 12 Jul 2007 01:04:58 -0700 To: "Ved Kafle" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jul 2007 08:05:02.0879 (UTC) FILETIME=[59AAEAF0:01C7C45B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2430; t=1184227513; x=1185091513; 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=20question=20about=20LISP=20v1 |Sender:=20; bh=+iCuTV3Gl/88aHfPAdqFFoYu9UZkyEktstrwj/hZUoc=; b=oGuaoXlhcFdx+Oih3r1Qd8XaGbh6WZ+dQWuGq6K/65yQ6W4wDkO6orL87unnsGS4TPumelY8 7kaEPmGm2jDS8MOpuekGHk5eBwdtce1nj9DN/4Dfmur2rKUwkX7q2XB8; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ram@iab.org Subject: [RAM] Re: question about LISP v1 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Section 6.1.1 > > What is a CAR? Its description is missing. > ITR-AFI and CAR-AFI has the same description. How to distinguish > them? CAR is defined in the CONS reference. Will fix the typo. Nice find. > Why do you set Originating ITR RLOC Address to zero for > UDP-based messages? What are its other possible values? Because in LISP 1.5 the Map-Request is being originated by the ITR itself. In CONS, the ITR sends the Map-Request over a TCP connection to the CAR and when the CAR receives the Map-Reply back it needs to route the Map-Reply to the originating ITR. Hence we have to preserve the identity of the ITR. > What is a Path Vector List? Its description is missing. See the CONS reference. I will make sure I refer to it in this spec. > You say LISP Nonce is 6 bytes long, in Map-Request Message > Format it's just 5 bytes. The description says it is 6 bytes even though it looks like it is drawn as 5 bytes. The intent is 6 bytes. I will fix the packet format illustration. > (Why the LISP Nonce is 6 bytes long? Any reasons?) Wanted it longer than 32-bits and didn't see a need for 64-bits. > Section 6.1.3 > How many Locs can be included in each Rec? How to know that > there are many Locs in each Rec? If there is only one Loc in each Rec, The 'Locator Count' field 8 bits in width per EID-prefix record. > then using Record count and Locator count fields is redundant. If > many, Record count is there to allow you encode multiple mappings, each mapping has one EID-prefix associated with a locator-set. The number of locators in a locator-set is determined by the 'Locator Count' field. > then the Locator count field should be inside Rec. In that case, the > total number of locators would be equal to the summation of number of > Recs multiplied by the number of Locs in each Rec. No, not true. > Some typos: > ---------------------- > Section 4.1 > (First line ) ... unicast unicast packet flow ... > (Last para) ... section Section 6 ... > Section 6.1.1 > Record count: ... the a number of times . > Section 6.1.3 > Record Count: The number of records in this request message => or > reply > message? Thanks for the careful reading. I have fixed all of the above occurrences and will be reflected in the -02 update of the draft. > Thank you. > > Ved Kafle @NICT, Japan Thank you, Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 12 06:29:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8vp3-0004tu-Fo; Thu, 12 Jul 2007 06:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8vp2-0004tp-3N for ram@iab.org; Thu, 12 Jul 2007 06:22:56 -0400 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8voy-0005rc-GG for ram@iab.org; Thu, 12 Jul 2007 06:22:56 -0400 Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53])by smtp.uc3m.es (Postfix) with ESMTP id D4F2D40219; Thu, 12 Jul 2007 12:22:48 +0200 (CEST) In-Reply-To: <4695B066.4000805@firstpr.com.au> References: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> <4695B066.4000805@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Thu, 12 Jul 2007 12:22:52 +0200 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-23.7648 TC:1F TRN:84 TV:3.6.1039(15292.003) 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-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ram@iab.org Subject: [RAM] Re: draft-bagnulo-lisp-threat-01 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Robin, El 12/07/2007, a las 6:39, Robin Whittle escribi=F3: > My understanding of: > > http://tools.ietf.org/html/draft-bagnulo-lisp-threat-01 > > is that 3.1 to 3.1.1.3 involves sending an encapsulated packet to > a combined ETR-ITR which convinces that router that the RLOC to > use when encapsulating packets with EID=3DV is the the attacker's > address. So subsequent packets with EID=3DV will wind up at the > attacker's host. > right > This is for "LISP 1" (1.5?) where there is no central database. > this applies to LISP as defined in draft-farinacci-lisp-01 which states: This document will focus on LISP 1 and LISP 1.5, both of which rely on a router-based distributed cache and database for EID-to-RLOC mappings. The LISP 2 and LISP 3 mechanisms, which require separate EID-to-RLOC infrastructure, will be documented in additional drafts. So, it is not clear to me whether this threats apply only to LISP1 =20 and 1,5, it depends on whether the other (yet to be documeted) =20 versions of LISP will learn using data and MapReply packets or they =20 will striclty learn mapping infromation from the database interface which is clear that an additional threat analysis is needed to =20 understand the threats to the database, how to introduce and =20 propagate mapping information in it. > In LISP 2.x, 3.x or 4.x: > > http://www1.ietf.org/mail-archive/web/ram/current/msg01289.html > > is it true to say that the ETR-ITR wouldn't learn any such false > information simply by receiving a packet, because its mapping is > controlled by a database instead? i don't know, there is no ID describing LISP v2,3,4 afaik > > Ivip's ITRs are always controlled by one or more databases - there > are no messages and ETRs don't "learn" anything from the > encapsulated packet. So this vulnerability doesn't apply to Ivip. > haven't read the ivip draft yet, sorry, > Likewise, Ivip has no "Map-Reply" message and the ITRs don't learn > their mapping from anything other than their own copy of the > database(s) or from responses resulting from queries to a query > server which has a copy. So the rest of section 3.1, 3.2.1, 3.2.2 > and 3.2.3 doesn't apply to Ivip. > the tradeoff here, is that the receiving host needs to query the =20 database to learn that information, introducing additional latency =20 when the first packet is received i guess. > In LISP 2 to 4 does the ITR learn mapping information from > Map-Reply messages or from an associated ETR learning an RLOC from > the outer header of an encapsulated packet it receives? > don't know, as i said i am not aware of any ID that documents lisp 2,3,4 > 3.2.4 concerns the cache of ETRs or ITRs overflowing - but the > sentence: > > An attacker could massively generate either tunnelled data > packets so that the router cache is overflowed. > > looks incomplete. > ? > I think that in all LISP variants the ITR is not intended to carry > a copy of the entire database, so in principle its cache could be > overflowed by either making it learn mapping information from the > headers of encapsulated packets or perhaps by some use of the Map > Reply message. > exactly > I think the ITR's cache could also be made to overflow by simply > sending packets to it which are addressed to a wide variety of > LISP EIDs, each with different mappings. This would force the ITR > to query and cache the mapping for each EID, or for whatever > prefix each EID is within which has the same mapping information. > right > Ivip has ITRDs with a full copy of "the database" - actually > multiple arrays of mapping information, one for each Ivip Mapped > Address Block (IMAB, previously "master-subnet"). So an ITRD > can't be overloaded by any pattern of destination addresses in the > packets it encapsulates. This is practical, at least for IPv4, > using a server with a 64 bit CPU, rather than a conventional > router (though in principle some routers could do it) because the > Ivip mapping is simply a 4 byte IP address for every address in > the IMABs. (LISP's data per EID IP address or prefix is more > extensive.) 2 billion Ivip-mapped addresses therefore require 8 > gigabytes of RAM, plus some extra RAM for indexing into this set > of arrays for each IMAB and for decoding the incoming database > dumps (boot time) and real-time updates. > > Ivip ITRCs (caching ITRs) and ITFHs (caching ITR functions in > sending hosts) are subject to some cache size limit and so would > be subject to a DoS attack (or simply non-malicious traffic) which > consisted of a sufficiently fast and diverse range of data packets > to addressed to Ivip-mapped addresses. However, the response of > an ITFH or ITRC to this would probably be to not try to retain the > mapping for every address of every packet - which is the same as > their normal way of working, which is to only seek mapping > information for addresses for which multiple packets are received. > so, they would seeks for the maping information, forward the packet =20 and discard the mapping information? So, when the second packet =20 arrives, do they rememeber that they have queried for the same =20 mapping before? (If yes, then they store some state, hence a DoS =20 vector is possible) In any case, i guess that: - if you have a mapping database, the effect of the DoS attack is =20 less than when you don't since you can recover the mapping =20 information, so you don't have to discard the packets for which you =20 have discarded the cache information (which is the case of LISP 1, 1,5) - the DoS attack will also affect the mapping database, which will =20 receive all the requests from all the routers it is serving, regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 12 07:35:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8wx3-00013J-QT; Thu, 12 Jul 2007 07:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8wx1-00012E-NJ for ram@iab.org; Thu, 12 Jul 2007 07:35:15 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8www-0007WJ-LA for ram@iab.org; Thu, 12 Jul 2007 07:35:15 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 1E7D759DDD; Thu, 12 Jul 2007 21:35:09 +1000 (EST) Message-ID: <469611DF.1070808@firstpr.com.au> Date: Thu, 12 Jul 2007 21:34:55 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org References: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> <4695B066.4000805@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [RAM] Re: draft-bagnulo-lisp-threat-01 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Marcelo, I was just stating how I believe Ivip differs from LISP and asking questions about LISP, for Dino and others to answer rather than you. When I wrote: >> An attacker could massively generate either tunnelled data >> packets so that the router cache is overflowed. >> >> looks incomplete. > > ? it was because I couldn't make full sense of this sentence in the context. I thought maybe it should be "either tunneled data packets or ICMP packets" or similar - I think this is just a typo or expression glitch. >> Ivip ITRCs (caching ITRs) and ITFHs (caching ITR functions in >> sending hosts) are subject to some cache size limit and so would >> be subject to a DoS attack (or simply non-malicious traffic) which >> consisted of a sufficiently fast and diverse range of data packets >> to addressed to Ivip-mapped addresses. However, the response of >> an ITFH or ITRC to this would probably be to not try to retain the >> mapping for every address of every packet - which is the same as >> their normal way of working, which is to only seek mapping >> information for addresses for which multiple packets are received. > > so, they would seeks for the maping information, forward the packet and > discard the mapping information? So, when the second packet arrives, do > they rememeber that they have queried for the same mapping before? (If > yes, then they store some state, hence a DoS vector is possible) OK - this is my bad expression. What I meant to write is that with Ivip, the ITRC's job is to find and tunnel as many packets as it can. It doesn't necessarily have to tunnel each one, because (ideally, one way or another) the untunneled packets will get to to another ITRD - perhaps via one or more ITRCs. Unless it is too busy, that ITRD which will tunnel it immediately, because its FIB is set up to do every mapping in the system. I described what needs to happen in order that packets will be handled like this later in my message in the text following "I will add something like this to the I-D:". So an ITRC which is running out of cache memory could either dump some of its cached mapping and use the space for a recently received response, or it could keep the current cache contents. Either way, it is probably going to get packets it doesn't have mapping data for, so it doesn't tunnel them. > In any case, i guess that: > - if you have a mapping database, the effect of the DoS attack is less > than when you don't since you can recover the mapping information, The idea with Ivip is that nearby, there will be a QSD which has a copy of the database and can answer queries quickly. Maybe the ITRC doesn't send the query to that directly, but to a closer (and less expensive) QSC caching query server. This way, one QSD with one feed of update data can handle a bunch of QSCs which can collectively handle more ITRCs than just the QSD alone. Ideally, it would only take a fraction of a second for any of these ITRCs to get a response to its query, so it might be OK for the ITRC to hold a packet for a moment while it waits for the response - but then if the response doesn't come, it is left with a highly delayed packet. My idea is that the ITRCs would not hold onto packets at all, but would let those it doesn't have mapping pass through untunneled. > so > you don't have to discard the packets for which you have discarded the > cache information (which is the case of LISP 1, 1,5) LISP doesn't have any alternative as exists (or at least can and generally will exist) for Ivip, so any ITR which can't get mapping data will effectively drop the packet - and all LISP ITRs need to get the mapping information from somewhere else, since the whole database is too big to store. > - the DoS attack will also affect the mapping database, which will > receive all the requests from all the routers it is serving, The QSD and any QSCs (which also have limited caches) would certainly get a hammering. The result would be that other ITRCs nearby which are not subject to the attack would not be able to get so many responses to its requests. So those ITRCs will be passing more untunneled packets. Further along in the path taken by the packets, other ITRCs or an ITRD will get a lot more packets to handle than usual, which ultimately means that beyond some level, the DoS attack will succeed - including by stopping the tunneling of some packets from other parts of the network which rely on the one ITRD as the last way of tunneling packets. I plan to finalise the ivip-arch-00 I-D on Sunday. There isn't enough detail in it regarding how the database updates get to the ITRD and QSD for a security critique to be made. There is a lot of stuff to think about regarding getting updates to hundreds of thousands of ITRDs and QSCs all over the world. I am thinking it that unless some really snappy techniques can be developed, it would be difficult to absolutely protect against spoofed packets being sent to the ITRDs and QSCs - but I think there will be ways of detecting any problems within a few seconds. These are really interesting problems. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 12 07:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xGN-0000AE-9R; Thu, 12 Jul 2007 07:55:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xGA-0008Jo-RZ for ram@iab.org; Thu, 12 Jul 2007 07:55:02 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8xDL-0007yO-6x for ram@iab.org; Thu, 12 Jul 2007 07:52:12 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 9DB1359E3D; Thu, 12 Jul 2007 21:52:03 +1000 (EST) Message-ID: <469615D5.4010408@firstpr.com.au> Date: Thu, 12 Jul 2007 21:51:49 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Subject: [RAM] ETRs checking src & dest addresses X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I think ETRs will require careful management to stop them being used by attackers to get around existing filtering systems. I will use the terms "inner packet" to refer to the packet which is encapsulated and "outer packet" to refer to the whole thing, with encapsulation. On a border router - the one accepting packets from BGP peers - is there sometimes or often a filter to drop packets whose SA matches any of network's own the prefixes? I guess most well-run networks do this. If so, maybe all ETRs need to do the same regarding the SA of the inner packet - unless the ETR can be sure the outer packet packet was sent from an ITR within the local network. In the current definition of Ivip, the SA of the outer packet is the same as of the inner packet - it is the address of the original sending host, not of the ITR. Maybe there is a reason for using the ITR's address for the outer SA, but for now I will assume not. If the network's border routers filter packets coming from the rest of the Internet to reject those with SA matching local prefixes, then all the ETR has to do to enforce the rule of not forwarding inner packets from outside the network with a spoofed local address, is to drop any inner packet which has a different SA from the outer SA. The simplicity of this arrangement is probably a good argument for retaining the current definition that the ITR uses the original packet's SA for the SA of the outer IP header. If the network's border routers don't have such filters, then it probably doesn't matter much whether the ETR is fussy about the inner SA, since the whole system is insecure anyway. Ideally, the ETR would be a lot fussier than just dropping an inner packet if its inner SA doesn't match its outer SA. Ideally it would drop any inner packet with an SA which did not match a narrow range of addresses: the LISP EID or Ivip DID (endpoint identifier) addresses of hosts or routers which it has been configured to decapsulate packets for. That set would depend on whether it could only send the decapsulated packets to end-user hosts or routers with direct connections to this ETR (or via some tunnel to wherever in the local network they can be reached) or whether the local routing system had specific routes for all the Ivip-mapped addresses of such end-user hosts and routers. In the latter case, the ETR should forward all decapsulated packets which match any of the Ivip-mapped hosts in the network. If there was no restriction on the inner DA of packets an ETR forwards, then an attacker could send an outer packet to an ETR in network A, with the inner packet being forwarded out of this network to some other host in another network B, including via an ITR if the inner DA was an Ivip-mapped address. Actually, if ETRs simply decapsulated and forwarded every packet they got, an attacker could create a nested set of IP-in-IP headers so the packet was decapsulated, forwarded to another ETR - even the same ETR . . . - and decapsulated again, to go to another ETR and so on. Also, the inner packet from an attacker could have an Ivip-mapped address which was not a host in the current network with that Ivip-mapped address, so the packet would find its way to an ITR and be forwarded somewhere, presumably to an ETR in some other network, where it would be decapsulated to reveal yet another packet which gets forwarded somewhere. If there were lots of ETRs around which were not fussy enough about the DA of inner packets, then I can imagine this becoming a sport: a Russian Doll game of leapfrogging around the ETRs and potentially the ITRs of the world! The object would be to launch a packet into some ETR (in a network which doesn't implement the drop rules I suggest below) and have as many levels of inner packet as packet length allows, with the first inner packet being an IP-in-IP header which is addressed to another ETR, which decapsulated it to create another packet which goes to some other ETR and is decapsulated etc. Finally, the innermost packet would arrive back at the player's computer, after having been forwarded, smaller and smaller, each time, between different ETRs and maybe ITRs all over the Net for the last few seconds. Below my signature is how I worked out the following rules, assuming that the ETR always drops a packet which has a different inner SA from its outer SA: Irrespective of whether the network filters incoming packets to reject those with source addresses which are within local prefixes, and: Irrespective of whether there are any ITRs (ITRDs, ITRCs or ITFHs) in the local network (and ITFHs could be hard to spot or prevent): If the local routing system supports forwarding of the specific Ivip-mapped addresses which are currently used by hosts with such addresses, meaning it forwards the raw packets to the proper host (or a link to an end-user site where they have a router etc.) then: Forward the inner packet only if it matches that list of hosts, end-user networks etc. which are in this network. Alternatively, if the local routing system doesn't have special routes for these Ivip-mapped addresses, then: Forward the inner packet only if it matches that list of hosts, end-user networks etc. which are directly connected to this ETR (or reachable via some tunnel). - Robin Here is an attempt to be systematic about this. I will ignore private (non globally routed) addresses. Most of this would apply to LISP as well, I think, but I will only mention Ivip. Addresses are: Local = within a prefix this network advertises to BGP. Non-Local = any other address, which includes all IMIP addresses: IMIP = Ivip-mapped address: within one of the Ivip Mapped Address Blocks (IMABs). Loc-DID = This will be within the IMIP set (and therefore also within the non-local set) but matches one of the addresses of hosts in the local network with Ivip-mapped addresses. Dir-DID = An address within the one or more Ivip-mapped addresses for hosts or routers which this ETR has a direct connection with. These are a subset of Loc-DID. In the current definition of Ivip encapsulated packet, the outer SA is the same as the inner SA. Any packet arriving with a different outer SA than inner SA probably should be dropped, because it doesn't comply with Ivip - so the following assumes they are the same. The outer DA is the address of the ETR, otherwise the packet wouldn't be here. The questions are the way the network is organised and what classes the outer/inner SA and the inner DA fall into. 111 --- Border router drops packets arriving from BGP peers with SA = Local? Yes Internal routing system recognises Loc-DID addresses with special routes to the appropriate host? Yes Some ITRDs, ITRCs or ITFHs in local network may encapsulate legitimate packets? Yes Outer SA Inner DA ETR should: =Inner SA Any Loc-DID Decapsulate and forward. If the SA is Local, it is valid, because packets from outside with AS = Local (a spoofed source address) have been blocked by the border router. So if SA is local, this must have been via a local ITR. Any Not Loc-ID Drop - must be an attacker trying to get past filters to send packet to an ordinary non-Ivip-mapped host in the local network or to some other host (on a normal or an Ivip-mapped address) in another network - which is not what Ivip and this ETR are for. 110 --- This differs from 111 only in that: Border router drops packets arriving from BGP peers with SA = Local? No The actions of the ETR are the same, although the reasons are not: Any Loc-DID Decapsulate and forward. If the SA is Local, it could be a spoofed packet, but there is no reason to drop it because the network admins don't care enough about spoofed SAs to filter them out at the border router. Any Not Loc-ID Drop - must be an attacker - see 111. 10x --- Border router drops packets arriving from BGP peers with SA = Local? F = Yes or No Internal routing system recognises Loc-DID addresses with special routes to the appropriate host? No Some ITRDs, ITRCs or ITFHs in local network may encapsulate legitimate packets? Yes Outer SA Inner DA ETR should: =Inner SA Any Dir-ID Decapsulate and forward. See 110 and 111 for reasons why whether F = Yes or No. Any Not Dir-ID Drop - ETR only knows how to get packets to directly connected hosts/routers with Ivip-mapped addresses. 01x --- Border router drops packets arriving from BGP peers with SA = Local? F = Yes or No Internal routing system recognises Loc-DID addresses with special routes to the appropriate host? Yes Some ITRDs, ITRCs or ITFHs in local network may encapsulate legitimate packets? No Outer SA Inner DA ETR should: =Inner SA Non-Local Loc-ID Decapsulate and forward. See 110 and 111 for reasons why whether F = Yes or No. Local Loc-ID F = Yes: Why does this happen? No local ITRs and filters mean this couldn't have come from outside. F = No: Decapsulate and forward - its probably from an attacker but the admins don't care. Any Not Loc-ID Drop - must be an attacker - see 111. 00x --- This is the same as 01x, except that the test is for Dir-DID instead of Loc-DID. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 12 07:55:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xGk-0000QM-2e; Thu, 12 Jul 2007 07:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xGi-0000QH-N5 for ram@iab.org; Thu, 12 Jul 2007 07:55:36 -0400 Received: from smtpout.sgsi.ucl.ac.be ([130.104.5.77] helo=smtp1.sgsi.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8xGe-0008Bh-57 for ram@iab.org; Thu, 12 Jul 2007 07:55:36 -0400 Received: from smtp1.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP id 8C6DEE8845 for ; Thu, 12 Jul 2007 13:55:31 +0200 (CEST) Received: from [130.104.228.72] (unknown [130.104.228.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: iannone@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP for ; Thu, 12 Jul 2007 13:55:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) To: ram@iab.org Message-Id: References: <132C4735-5809-4DF9-A46B-3ADB7833FAD6@uclouvain.be> From: Luigi Iannone Date: Thu, 12 Jul 2007 13:56:01 +0200 X-Mailer: Apple Mail (2.752.2) X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: Authenticated, X-SGSI-MailScanner: Found to be clean X-SGSI-From: luigi.iannone@uclouvain.be X-SGSI-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [RAM] Technical report on Loc/ID separation cost X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0938389269==" Errors-To: ram-bounces@iab.org --===============0938389269== Content-Type: multipart/alternative; boundary=Apple-Mail-105--224268834 --Apple-Mail-105--224268834 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear All, we made a study about the cost of caching Loc/ID on border routers and the cost of performing lookup queries (in the context of a pull model for Loc/ID mappings distribution). A technical report is available at: http://inl.info.ucl.ac.be/publications/locator-id-separation-study- cost-mappings-caching-and-mappings-lookups Comments are more than welcome. Regards Luigi Iannone luigi.iannone@uclouvain.be --Apple-Mail-105--224268834 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII

Dear = All,

we made = a study about the cost of caching Loc/ID on border routers and the cost = of performing lookup queries (in the context of a pull model for Loc/ID = mappings distribution).
A technical report is available = at:


Comments are more than = welcome.

Regards


Luigi Iannone





= --Apple-Mail-105--224268834-- --===============0938389269== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0938389269==-- From ram-bounces@iab.org Thu Jul 12 10:24:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zal-00030Q-Cv; Thu, 12 Jul 2007 10:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zak-0002y0-22 for ram@iab.org; Thu, 12 Jul 2007 10:24:26 -0400 Received: from smtp01.uc3m.es ([163.117.176.131] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8zag-0003yZ-D6 for ram@iab.org; Thu, 12 Jul 2007 10:24:26 -0400 Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53])by smtp.uc3m.es (Postfix) with ESMTP id 0FEF067760; Thu, 12 Jul 2007 16:24:18 +0200 (CEST) In-Reply-To: <469611DF.1070808@firstpr.com.au> References: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> <4695B066.4000805@firstpr.com.au> <469611DF.1070808@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4FDFBAA7-B42B-4CF5-9473-1EE615413B3C@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Thu, 12 Jul 2007 16:24:22 +0200 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-18.2805 TC:1F TRN:92 TV:3.6.1039(15294.003) 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-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: ram@iab.org Subject: [RAM] Re: draft-bagnulo-lisp-threat-01 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Robin, El 12/07/2007, a las 13:34, Robin Whittle escribi=F3: > Hi Marcelo, > > I was just stating how I believe Ivip differs from LISP and asking > questions about LISP, for Dino and others to answer rather than you. > I am relieved then :-) > When I wrote: > >>> An attacker could massively generate either tunnelled data >>> packets so that the router cache is overflowed. >>> >>> looks incomplete. >> >> ? > > it was because I couldn't make full sense of this sentence in the > context. I thought maybe it should be "either tunneled data > packets or ICMP packets" or similar - I think this is just a typo > or expression glitch. right, i think the either should be removed and it should then make =20 more sense... > > >>> Ivip ITRCs (caching ITRs) and ITFHs (caching ITR functions in >>> sending hosts) are subject to some cache size limit and so would >>> be subject to a DoS attack (or simply non-malicious traffic) which >>> consisted of a sufficiently fast and diverse range of data packets >>> to addressed to Ivip-mapped addresses. However, the response of >>> an ITFH or ITRC to this would probably be to not try to retain the >>> mapping for every address of every packet - which is the same as >>> their normal way of working, which is to only seek mapping >>> information for addresses for which multiple packets are received. >> >> so, they would seeks for the maping information, forward the =20 >> packet and >> discard the mapping information? So, when the second packet =20 >> arrives, do >> they rememeber that they have queried for the same mapping before? =20= >> (If >> yes, then they store some state, hence a DoS vector is possible) > > OK - this is my bad expression. > > What I meant to write is that with Ivip, the ITRC's job is to find > and tunnel as many packets as it can. It doesn't necessarily have > to tunnel each one, because (ideally, one way or another) the > untunneled packets will get to to another ITRD - perhaps via one > or more ITRCs. so this basically means that the attack is propagated to other =20 ITRC's, right? I mean, if oneITRC is receiving too many packets and =20 it decides to forward them without tunnelling them to the next ITRC, =20 then the the next ITRC will start receiving a huge amount of =20 untunnelled packets, hence the attack is now not only affecting the =20 initial router under attack but also to other routers that were used =20 as fall back. My point is that this is a two edged sword. On one hand, you have =20 more processing power, becuase you can get the help of other routers, =20= but otoh, a single attack can have a domino effect and affect =20 multiple routers... makes sense? > Unless it is too busy, that ITRD which will tunnel > it immediately, because its FIB is set up to do every mapping in > the system. I described what needs to happen in order that > packets will be handled like this later in my message in the text > following "I will add something like this to the I-D:". > > So an ITRC which is running out of cache memory could either dump > some of its cached mapping and use the space for a recently > received response, or it could keep the current cache contents. > Either way, it is probably going to get packets it doesn't have > mapping data for, so it doesn't tunnel them. so other routers will need to tunnel them, hence the effect of the =20 attack will affect the other routers as well, right? > > >> In any case, i guess that: >> - if you have a mapping database, the effect of the DoS attack is =20 >> less >> than when you don't since you can recover the mapping information, > > The idea with Ivip is that nearby, there will be a QSD which has a > copy of the database and can answer queries quickly. Maybe the > ITRC doesn't send the query to that directly, but to a closer (and > less expensive) QSC caching query server. This way, one QSD with > one feed of update data can handle a bunch of QSCs which can > collectively handle more ITRCs than just the QSD alone. Ideally, > it would only take a fraction of a second for any of these ITRCs > to get a response to its query, so it might be OK for the ITRC to > hold a packet for a moment while it waits for the response - but > then if the response doesn't come, it is left with a highly > delayed packet. My idea is that the ITRCs would not hold onto > packets at all, but would let those it doesn't have mapping pass > through untunneled. so, bascally the effect of the dos based on overflowing the cache =20 would be that the system is slower, because for every new address, =20 query to the database is needed. (this seems better than not being =20 able to communicate :-) > > >> so >> you don't have to discard the packets for which you have discarded =20= >> the >> cache information (which is the case of LISP 1, 1,5) > > LISP doesn't have any alternative as exists (or at least can and > generally will exist) for Ivip, so any ITR which can't get mapping > data will effectively drop the packet - and all LISP ITRs need to > get the mapping information from somewhere else, since the whole > database is too big to store. yes, this is what i meant in the threat analysis and this seems an =20 grave vulnerability imho > > >> - the DoS attack will also affect the mapping database, which will >> receive all the requests from all the routers it is serving, > > The QSD and any QSCs (which also have limited caches) would > certainly get a hammering. The result would be that other ITRCs > nearby which are not subject to the attack would not be able to > get so many responses to its requests. So those ITRCs will be > passing more untunneled packets. Further along in the path taken > by the packets, other ITRCs or an ITRD will get a lot more packets > to handle than usual, which ultimately means that beyond some > level, the DoS attack will succeed - including by stopping the > tunneling of some packets from other parts of the network which > rely on the one ITRD as the last way of tunneling packets. > yes, i think this is what i expressed above... > I plan to finalise the ivip-arch-00 I-D on Sunday. There isn't > enough detail in it regarding how the database updates get to the > ITRD and QSD for a security critique to be made. There is a lot > of stuff to think about regarding getting updates to hundreds of > thousands of ITRDs and QSCs all over the world. > > I am thinking it that unless some really snappy techniques can be > developed, it would be difficult to absolutely protect against > spoofed packets being sent to the ITRDs and QSCs - but I think > there will be ways of detecting any problems within a few seconds. > > These are really interesting problems. > i would expect that certificates similar to those being proposed in =20 sidr for bgp could be used for protecting this database. It would be =20 nice to have cheaper techniques though Regards, marcelo > - Robin > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 12 11:57:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9133-00041q-7Y; Thu, 12 Jul 2007 11:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9132-00041l-FH for ram@iab.org; Thu, 12 Jul 2007 11:57:44 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I912y-0006qx-5U for ram@iab.org; Thu, 12 Jul 2007 11:57:44 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6CFtUki017652 for ; Thu, 12 Jul 2007 11:55:30 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0AaWDI; Thu, 12 Jul 07 11:55:23 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 300323F484; Thu, 12 Jul 2007 11:29:07 -0400 (EDT) To: ram@iab.org Subject: RE: [RAM] Re: LISP-01 I-D Message-Id: <20070712152907.300323F484@pecan.tislabs.com> Date: Thu, 12 Jul 2007 11:29:07 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sandy@tislabs.com X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On July 4, Dino Farinacci said: >> Please post your new version to the RAM list soon - I am keen to >> read it. > >Enclosed. I am curious. I have not seen an announcement of the -01 draft and it does not seem to be in the internet-draft database. I don't need to get it from there, the mailing list copy is sufficient. But if, for example, it was not posted because changes were still being made, it would be useful to know that. Or it could just be that the database is still behind due to the final glut of internet-draft submissions and I just need to be a bit more patient. Or I missed something. --Sandy _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 12 12:13:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91If-0001Ag-UJ; Thu, 12 Jul 2007 12:13:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91Ie-0001AQ-A5 for ram@iab.org; Thu, 12 Jul 2007 12:13:52 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I91IZ-0007Hd-Ts for ram@iab.org; Thu, 12 Jul 2007 12:13:52 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l6CGDlXD006604; Thu, 12 Jul 2007 09:13:47 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l6CGDl0f006603; Thu, 12 Jul 2007 09:13:47 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 12 Jul 2007 09:13:47 -0700 From: David Meyer To: Sandy Murphy Subject: Re: [RAM] Re: LISP-01 I-D Message-ID: <20070712161347.GA6562@1-4-5.net> References: <20070712152907.300323F484@pecan.tislabs.com> MIME-Version: 1.0 In-Reply-To: <20070712152907.300323F484@pecan.tislabs.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 laugh and I cry, and I'm haunted by...Things I never meant nor wished to say" -- Bob Dylan, "When The Deal Goes Down" User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1507218076==" Errors-To: ram-bounces@iab.org --===============1507218076== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2007 at 11:29:07AM -0400, Sandy Murphy wrote: > On July 4, Dino Farinacci said: >=20 > >> Please post your new version to the RAM list soon - I am keen to > >> read it. > > > >Enclosed. >=20 > I am curious. I have not seen an announcement of the -01 draft and > it does not seem to be in the internet-draft database. >=20 > I don't need to get it from there, the mailing list copy is sufficient. > But if, for example, it was not posted because changes were still being > made, it would be useful to know that. Or it could just be that the > database is still behind due to the final glut of internet-draft > submissions and I just need to be a bit more patient. Or I missed > something. I don't think you have. We're struggling with the internet-drafts folks; I'm hoping -01 hits the I-D repository today. I just checked and I don't see it there (yet). Dave --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGllM7ORgD1qCZ2KcRAm1+AJ9er6rtEmzXfP7UXYieGjbvsZZMTgCeO/bv jzy9XKWwQtHJLd83VhEFL2o= =BGF/ -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- --===============1507218076== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1507218076==-- From ram-bounces@iab.org Thu Jul 12 17:06:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95rN-0006jU-MN; Thu, 12 Jul 2007 17:06:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95rM-0006hZ-2P for ram@iab.org; Thu, 12 Jul 2007 17:06:00 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I95rI-0006LU-Lo for ram@iab.org; Thu, 12 Jul 2007 17:06:00 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l6CL2r85000671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Jul 2007 23:02:53 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <3DB9629A-0C1D-4D8E-B779-5D6686DC9F69@it.uc3m.es> References: <2D647210-AF54-4B24-9FBA-A7865B4F4325@muada.com> <3DB9629A-0C1D-4D8E-B779-5D6686DC9F69@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5544034C-9139-4E6B-A6A7-DBE087BCF37A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Thu, 12 Jul 2007 23:04:37 +0200 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: shim6-wg , RAM Mailing List Subject: [RAM] Re: proxy shim with hash in upper address bits? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org [crossposted, please prune as required. RAM people, please look at the bottom of the message] On 11-jul-2007, at 15:23, marcelo bagnulo braun wrote: >> After reading Marcelo's draft about a proxy implementation of >> shim6 a while ago I was somewhat disheartened: this is extremely >> hard to do, mostly because an unsuspecting host would need to >> receive an HBA-compatible address. > why do you think so?... you can deal with this doing dhcp > delegation of the HBAs/CGAs? (you would be breaking stateless > address autoconf, but i guess the same would happen if you need a > reasonable amount of bits in the prefix to carry crypto > information...) You're right, if you can get the hosts to create only HBA addresses by use of DHCPv6 or some other mechanism, that would work. Note thought that most of today's IPv6 hosts don't support DHCPv6 address assignment so this may not be a suitable solution for true legacy IPv6 support. Obviously stateless autoconf would have to work with the bits in the upper part of the address or this would be an exercise in futility. > Yes, creating a crypto prefix for the identifier namespace would > bean option for dealing with this, but i guess it would break SAA SAA? Another, possibly even harder to solve, problem with proxy shim is what happens when a host behind the proxy want to talk to a non-shim host. But quite possibly, we can solve this if we can make proxy shim interoperable with a LISP-like approach. So the user of the portable space would implement a shim proxy cq ETR/ITR which would obviously be able to talk to other shim proxy/ETR/ITR devices as well as to any host that supports shim6. Hosts that don't implement shim6 would have to reach hosts behind a proxy through ETRs that are deployed by their ISPs or possibly by the sellers of the portable address space. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 12 17:14:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95zJ-0007Fi-0I; Thu, 12 Jul 2007 17:14:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95zI-0007Fd-CQ for ram@iab.org; Thu, 12 Jul 2007 17:14:12 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I95zD-0006UO-WA for ram@iab.org; Thu, 12 Jul 2007 17:14:12 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l6CLAtsv000814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Jul 2007 23:10:56 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <469615D5.4010408@firstpr.com.au> References: <469615D5.4010408@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EA94A78-B056-4938-B6E0-051EE4013A98@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] ETRs checking src & dest addresses Date: Thu, 12 Jul 2007 23:12:39 +0200 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 12-jul-2007, at 13:51, Robin Whittle wrote: > In the current definition of Ivip, the SA of the outer packet is > the same as of the inner packet - it is the address of the > original sending host, not of the ITR. Maybe there is a reason > for using the ITR's address for the outer SA, but for now I will > assume not. What do security associations have to do with any of this? Oh wait, you mean source address. I don't think it's a good idea to have node Y send packets where the source address is X, both because this claims that the sender is different from his/her actual identity and because return traffic, such as ICMP messages, will then end up at (arguably) the wrong node. Knowing the address of the encapsulating TR is also useful if the decapsulating TR ever wants to get in touch with it. [not replying to the rest of the message because I didn't have time to read it] _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 13 02:22:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9ENC-0001B9-V4; Fri, 13 Jul 2007 02:11:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9ENB-0001B4-E0 for ram@iab.org; Fri, 13 Jul 2007 02:11:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9EN7-0003Bm-3E for ram@iab.org; Fri, 13 Jul 2007 02:11:25 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Jul 2007 23:11:20 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFO0lkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,535,1175497200"; d="scan'208"; a="181406970:sNHT26748378" 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 l6D6BK3w017787; Thu, 12 Jul 2007 23:11:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6D6BBmo012835; Fri, 13 Jul 2007 06:11:11 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); Thu, 12 Jul 2007 23:11:10 -0700 Received: from [192.168.0.4] ([10.82.242.161]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 23:10:10 -0700 In-Reply-To: References: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> <4695B066.4000805@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: draft-bagnulo-lisp-threat-01 Date: Thu, 12 Jul 2007 23:08:46 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Jul 2007 06:11:10.0600 (UTC) FILETIME=[9BB9A080:01C7C514] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=495; t=1184307080; x=1185171080; 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[RAM]=20Re=3A=20draft-bagnulo-lisp-threat-01 |Sender:=20; bh=nmOYhBdY52/kezdyWvPxpGyQyl3sNmOf/csGCIw1TJA=; b=X/lDhCItYhKHVIvHDx15Xe+umbsn4de5Bg9RQbN07VOUBu4iE0NlQ2vjNNz4LJsyS5k1wahl Y50w6qrvus656xS+K9JS1PK3OITrg7dS6SUL7gi9A7oAQbAsRelfVqc9; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > i don't know, there is no ID describing LISP v2,3,4 afaik There will probably never be a LISP 2 because many people have sounded off about the circular dependency even though DNS gives the best low latency for a request based mapping lookup (that is, it shares the DNS lookup latency with the map lookup). The LISP authors have never mentioned or defined a variant numbered 4. And for LISP 3, there is currently 3 examples of LISP 3, that is CONS, NERD, and APT. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 13 04:49:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9GqJ-0002KC-2d; Fri, 13 Jul 2007 04:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9GqH-0002K6-Ny for ram@iab.org; Fri, 13 Jul 2007 04:49:37 -0400 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9GqD-0007bG-DW for ram@iab.org; Fri, 13 Jul 2007 04:49:37 -0400 Received: from [163.117.82.80] (wifi-82-80.uc3m.es [163.117.82.80])by smtp.uc3m.es (Postfix) with ESMTP id 381DA86140; Fri, 13 Jul 2007 10:49:31 +0200 (CEST) In-Reply-To: References: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> <4695B066.4000805@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <69C39BDA-E346-40D7-8378-2E9CBACBE0ED@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Re: draft-bagnulo-lisp-threat-01 Date: Fri, 13 Jul 2007 10:49:32 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.0759 TC:1F TRN:19 TV:3.6.1039(15294.003) 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-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 13/07/2007, a las 8:08, Dino Farinacci escribi=F3: >> i don't know, there is no ID describing LISP v2,3,4 afaik > > There will probably never be a LISP 2 because many people have =20 > sounded off about the circular dependency even though DNS gives the =20= > best low latency for a request based mapping lookup (that is, it =20 > shares the DNS lookup latency with the map lookup). > > The LISP authors have never mentioned or defined a variant numbered 4. > > And for LISP 3, there is currently 3 examples of LISP 3, that is =20 > CONS, NERD, and APT. > from a security analysis perspective, i guess an important question =20 would be if in LISP 3, TR also learn through tunneled data packets =20 and MAP-Reply packets as described in the draft-farinacci-lisp-01. If =20= yes, then we need to see if the threats identified in the threat =20 analysis draft also apply (but it is likely to be the case, if no =20 additional measures are taken to prevent them) regards, marcelo > Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 13 05:04:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9H4G-0002R2-1A; Fri, 13 Jul 2007 05:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9H4F-0002Qw-3s for ram@iab.org; Fri, 13 Jul 2007 05:04:03 -0400 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9H4B-0007zD-KW for ram@iab.org; Fri, 13 Jul 2007 05:04:03 -0400 Received: from [163.117.82.80] (wifi-82-80.uc3m.es [163.117.82.80])by smtp.uc3m.es (Postfix) with ESMTP id A85145E9C3; Fri, 13 Jul 2007 11:03:58 +0200 (CEST) In-Reply-To: <5544034C-9139-4E6B-A6A7-DBE087BCF37A@muada.com> References: <2D647210-AF54-4B24-9FBA-A7865B4F4325@muada.com> <3DB9629A-0C1D-4D8E-B779-5D6686DC9F69@it.uc3m.es> <5544034C-9139-4E6B-A6A7-DBE087BCF37A@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3EE630C1-49E1-4DFD-A7AD-77357C0C17CA@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Fri, 13 Jul 2007 11:03:55 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-14.3866 TC:1F TRN:49 TV:3.6.1039(15294.003) 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-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: shim6-wg , RAM Mailing List Subject: [RAM] Re: proxy shim with hash in upper address bits? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 12/07/2007, a las 23:04, Iljitsch van Beijnum escribi=F3: > [crossposted, please prune as required. RAM people, please look at =20 > the bottom of the message] > > On 11-jul-2007, at 15:23, marcelo bagnulo braun wrote: > >>> After reading Marcelo's draft about a proxy implementation of =20 >>> shim6 a while ago I was somewhat disheartened: this is extremely =20 >>> hard to do, mostly because an unsuspecting host would need to =20 >>> receive an HBA-compatible address. > >> why do you think so?... you can deal with this doing dhcp =20 >> delegation of the HBAs/CGAs? (you would be breaking stateless =20 >> address autoconf, but i guess the same would happen if you need a =20 >> reasonable amount of bits in the prefix to carry crypto =20 >> information...) > > You're right, if you can get the hosts to create only HBA addresses =20= > by use of DHCPv6 or some other mechanism, that would work. Note =20 > thought that most of today's IPv6 hosts don't support DHCPv6 =20 > address assignment so this may not be a suitable solution for true =20 > legacy IPv6 support. > > Obviously stateless autoconf would have to work with the bits in =20 > the upper part of the address or this would be an exercise in =20 > futility. > >> Yes, creating a crypto prefix for the identifier namespace would =20 >> bean option for dealing with this, but i guess it would break SAA > > SAA? > stateless address auto configuration > Another, possibly even harder to solve, problem with proxy shim is =20 > what happens when a host behind the proxy want to talk to a non-=20 > shim host. it depends what type of idetifiers are you using if you are using routable identifiers, then you don't have problem if you are not using routble ids, then you are in trouble and =20 backward compatibility woudl require either configuring routable =20 address to hosts (in addition of the non routable ids) or some form =20 of nat > But quite possibly, we can solve this if we can make proxy shim =20 > interoperable with a LISP-like approach. So the user of the =20 > portable space would implement a shim proxy cq ETR/ITR which would =20 > obviously be able to talk to other shim proxy/ETR/ITR devices as =20 > well as to any host that supports shim6. Hosts that don't implement =20= > shim6 would have to reach hosts behind a proxy through ETRs that =20 > are deployed by their ISPs or possibly by the sellers of the =20 > portable address space. how does this solve the backward compatibility problem? I mean you =20 still need to deploy ETR/ITR in the remote site, so if you do that, =20 you may well deploy any other box i.e a pproxy shim Bottom line: proxy shim, shim6, lisp, you-name-it, they all require =20 support from both ends involved in the communication (either host or =20 a box next to the host (proxy, TR)) (and the multihoming benefits =20 only apply to the path between the two multihoming aware boxes) Regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 13 05:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9HL9-0000Og-VD; Fri, 13 Jul 2007 05:21:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9HL7-0000O2-W5 for ram@iab.org; Fri, 13 Jul 2007 05:21:29 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9HL3-0008IQ-IM for ram@iab.org; Fri, 13 Jul 2007 05:21:29 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l6D9IMLB012151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jul 2007 11:18:22 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <3EE630C1-49E1-4DFD-A7AD-77357C0C17CA@it.uc3m.es> References: <2D647210-AF54-4B24-9FBA-A7865B4F4325@muada.com> <3DB9629A-0C1D-4D8E-B779-5D6686DC9F69@it.uc3m.es> <5544034C-9139-4E6B-A6A7-DBE087BCF37A@muada.com> <3EE630C1-49E1-4DFD-A7AD-77357C0C17CA@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Fri, 13 Jul 2007 11:20:06 +0200 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: shim6-wg , RAM Mailing List Subject: [RAM] Re: proxy shim with hash in upper address bits? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 13-jul-2007, at 11:03, marcelo bagnulo braun wrote: >> Another, possibly even harder to solve, problem with proxy shim is >> what happens when a host behind the proxy want to talk to a non- >> shim host. > it depends what type of idetifiers are you using Of course, I was assuming non-routable identifiers. >> But quite possibly, we can solve this if we can make proxy shim >> interoperable with a LISP-like approach. So the user of the >> portable space would implement a shim proxy cq ETR/ITR which would >> obviously be able to talk to other shim proxy/ETR/ITR devices as >> well as to any host that supports shim6. Hosts that don't >> implement shim6 would have to reach hosts behind a proxy through >> ETRs that are deployed by their ISPs or possibly by the sellers of >> the portable address space. > how does this solve the backward compatibility problem? I mean you > still need to deploy ETR/ITR in the remote site, so if you do that, > you may well deploy any other box i.e a pproxy shim > Bottom line: proxy shim, shim6, lisp, you-name-it, they all require > support from both ends involved in the communication (either host > or a box next to the host (proxy, TR)) (and the multihoming > benefits only apply to the path between the two multihoming aware > boxes) Yes, this is an important limitation. With shim6 in hosts, you can determine if the other side supports shim6 before selecting an unroutable identifier, and fall back on legacy IPv6 if it doesn't, but then you're not multihomed for that session. With LISP et al this isn't possible, but the logic doesn't have to be in the hosts, so as long as there is a box somewhere in the path that supports the protocol, you're in business. The degenerative case would be where the encapsuating devices for site X which is reachable through ISPs A and B are located in the networks of A and B. Making (proxy) shim6 and LISP interoperable helps shim6 because the deployment of LISP boxes means more people to talk shim6 with, and it helps LISP because you get to optimize paths to a much higher degree because this can happen at individual hosts, even ones that are not served by a *TR device. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 13 06:13:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9I8p-0008Vb-R9; Fri, 13 Jul 2007 06:12:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9I8o-0008Nw-23 for ram@iab.org; Fri, 13 Jul 2007 06:12:50 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9I8k-0001Vy-F9 for ram@iab.org; Fri, 13 Jul 2007 06:12:50 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 9F95659DDD; Fri, 13 Jul 2007 20:12:42 +1000 (EST) Message-ID: <4697500D.2070403@firstpr.com.au> Date: Fri, 13 Jul 2007 20:12:29 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Re: draft-bagnulo-lisp-threat-01 References: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> <4695B066.4000805@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, You wrote of Marcelo's comment: >> i don't know, there is no ID describing LISP v2,3,4 afaik > > There will probably never be a LISP 2 because many people have sounded > off about the circular dependency even though DNS gives the best low > latency for a request based mapping lookup (that is, it shares the DNS > lookup latency with the map lookup). > > The LISP authors have never mentioned or defined a variant numbered 4. > > And for LISP 3, there is currently 3 examples of LISP 3, that is CONS, > NERD, and APT. I mentioned LISP 2.x, 3.x and 4.x, which are listed in your message on 16 April: http://www1.ietf.org/mail-archive/web/ram/current/msg01289.html including several 4.x variants. I don't recall any other mentions of 4.x. I don't think there is a problem with circular dependencies with LISP using DNS provided the LISP-mapped address space comes with a caution or something to say it shouldn't be used for some DNS functions, including root nameservers and a few other things, and any nameserver on which LISP depends. Brian Carpenter made the original circularity critique, I think, but on 28 June: http://www1.ietf.org/mail-archive/web/ram/current/msg01588.html I think he agreed to a certain extent with the limitations I suggested which would prevent circularity problems. His remaining critique is that the list of constraints is "operationally error prone", but I think a lot of things we have to rely on are "operationally error-prone". - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 13 19:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9US8-0008R1-QI; Fri, 13 Jul 2007 19:21:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9US6-0008Qd-N4 for ram@iab.org; Fri, 13 Jul 2007 19:21:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9US2-0003r5-CM for ram@iab.org; Fri, 13 Jul 2007 19:21:34 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2007 19:21:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAmll0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175486400"; d="scan'208"; a="65151883:sNHT26059446" 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 l6DNLUpM016615; Fri, 13 Jul 2007 19:21:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6DNLOEZ019354; Fri, 13 Jul 2007 23:21:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 19:21:24 -0400 Received: from [192.168.0.4] ([10.82.210.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 19:21:23 -0400 In-Reply-To: <69C39BDA-E346-40D7-8378-2E9CBACBE0ED@it.uc3m.es> References: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> <4695B066.4000805@firstpr.com.au> <69C39BDA-E346-40D7-8378-2E9CBACBE0ED@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53AFD529-2430-4405-AA02-55535E4850A1@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: draft-bagnulo-lisp-threat-01 Date: Fri, 13 Jul 2007 16:21:17 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Jul 2007 23:21:23.0998 (UTC) FILETIME=[8761A3E0:01C7C5A4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=839; t=1184368890; x=1185232890; 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[RAM]=20Re=3A=20draft-bagnulo-lisp-threat-01 |Sender:=20 |To:=20marcelo=20bagnulo=20braun=20; bh=sbzp5QNlVRuRzgjWgHPfUEs6ua7+Tygd4LUEhSzzdKE=; b=pIEGxMA63gcnOCh49iuap2GFlXUBX3MwVk/JJviZJtEX06nUY4b1efTKzVEfVzz4nS+vlvwe SOnJSAx4mrp9DNNIs5H+jCmdhVS2fSM0XBrSeDtB1AVvzIoh+tyoyY7n; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > from a security analysis perspective, i guess an important question > would be if in LISP 3, TR also learn through tunneled data packets > and MAP-Reply packets as described in the draft-farinacci-lisp-01. > If yes, then we need to see if the threats identified in the threat > analysis draft also apply (but it is likely to be the case, if no > additional measures are taken to prevent them) Yes, I agree. We are assuming at this point that CONS and NERD are control plane based and do not have data-triggered Map-Replies. Using APT, it depends. Because the design indicates that you send packet along the mapping service topology. That is a bit different where there isn't data plane triggered mappings but the data is sent over a control-plane. Much different than a LISP 1 and 1.5 approach. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 13 21:35:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9WX8-0005YY-0h; Fri, 13 Jul 2007 21:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9WX6-0005Ps-64 for ram@iab.org; Fri, 13 Jul 2007 21:34:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9WX2-0008I8-TR for ram@iab.org; Fri, 13 Jul 2007 21:34:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2007 21:34:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKvEl0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175486400"; d="scan'208"; a="65157698:sNHT24432392" 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 l6E1YllV016159; Fri, 13 Jul 2007 21:34:47 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6E1YfWI002196; Sat, 14 Jul 2007 01:34:42 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 21:34:39 -0400 Received: from [192.168.0.4] ([10.82.210.56]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 21:34:38 -0400 In-Reply-To: <4697500D.2070403@firstpr.com.au> References: <1A1EE942-944D-4CE6-8C79-C8382C000D1B@it.uc3m.es> <4695B066.4000805@firstpr.com.au> <4697500D.2070403@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C95E915-92FD-43DA-AB03-49DEC3A88C1A@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: draft-bagnulo-lisp-threat-01 Date: Fri, 13 Jul 2007 18:34:32 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Jul 2007 01:34:38.0194 (UTC) FILETIME=[244B2520:01C7C5B7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=407; t=1184376888; x=1185240888; 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[RAM]=20Re=3A=20draft-bagnulo-lisp-threat-01 |Sender:=20 |To:=20Robin=20Whittle=20; bh=BZTDfgerDE2wkfPBW5toafjDtYqI2oWaQR5EflHHh9E=; b=G5EdikfF/wd7zE9Yu194dfJT6qHanxfj7tutyDu4zhuZoY/p3eXR1DAZhVvVwfpL6L8B4Dmm metRhcZdxzK3dXG199er0ah3ZCfieYGYog7eQ1VZxciBYAnElaRisYjF; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > I mentioned LISP 2.x, 3.x and 4.x, which are listed in your > message on 16 April: > > http://www1.ietf.org/mail-archive/web/ram/current/msg01289.html > > including several 4.x variants. I don't recall any other mentions > of 4.x. You shouldn't take an email reference verbatim. I said in that email "for instance" and it was never documented in an ID so we were brainstorming. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 14 04:10:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9chI-0001zG-7m; Sat, 14 Jul 2007 04:09:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9chG-0001zB-3C for ram@iab.org; Sat, 14 Jul 2007 04:09:46 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9ch9-0001Oi-T8 for ram@iab.org; Sat, 14 Jul 2007 04:09:46 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 35E4A59DDD; Sat, 14 Jul 2007 18:09:36 +1000 (EST) Message-ID: <469884B2.1060307@firstpr.com.au> Date: Sat, 14 Jul 2007 18:09:22 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] ETRs checking src & dest addresses References: <469615D5.4010408@firstpr.com.au> <2EA94A78-B056-4938-B6E0-051EE4013A98@muada.com> In-Reply-To: <2EA94A78-B056-4938-B6E0-051EE4013A98@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 708bdb947b83e88c58fd603ed07f3c7a Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org A short version of this message is: The easiest and most robust way to enable a network to enforce on its ETRs the rule that encapsulated packets from ITRs outside the network must not contain inner packets with a source address (SA) which matches one of the network's own prefixes is (along with some other requirements) to break with convention and require ITRs to tunnel the packet with the outer SA = the inner SA. That is, the packet sent by the ITR to the ETR has the same source address as the sending host. This means that no-one or nothing in the destination network (or after the ITR), including the ETR itself, can find which ITR tunneled the packet - unless the encapsulation method carries extra data which includes the ITR's address, which is not the case with Ivip or with current LISP plans. The reason is that it is probably very difficult or perhaps impossible to make all ETRs inside the network filter the decapsulated packets to drop those which arrived from an external ITR and have the inner SA matching a local prefix (this would be a packet with a spoofed source address) - so it is better to achieve the same desired protection by: 1 - Requiring all ITRs to set the outer SA = inner SA. 2 - Let the border routers continue to drop packets arriving from outside the network with SA matching any one of the network's local prefixes. 3 - Require all ETRs to drop all decapsulated packets with an SA (inner SA) which is not identical to the SA of the outer header (outer SA). Having the outer SA = inner SA also has the benefit that traceroute functions normally. The current LISP 1 and 1.5 definition has the SA = ETR's address, which means the sending host gets no traceroute results for any router between the ITR and the ETR - and perhaps not from the ETR either. I also explore the idea for LISP or Ivip of there being a service so the current and recent history of the database (multiple databases perhaps, as is the case with Ivip) can be queried to see when any mapping - of any EID (LISP) or DID (Ivip) address - has been to a particular (RLOC) IP address. This would be vital for debugging problems with end-users setting the mapping incorrectly, for determining why streams of encapsulated packets arrived in some unwelcome fashion etc. It would be impossible to prevent this sort of analysis of the mapping data. Hi Iljitsch, I tend to agree with what you wrote: > Oh wait, you mean source address. I don't think it's a good idea > to have node Y send packets where the source address is X, both > because this claims that the sender is different from his/her > actual identity and because return traffic, such as ICMP > messages, will then end up at (arguably) the wrong node. > > Knowing the address of the encapsulating TR is also useful if > the decapsulating TR ever wants to get in touch with it. However, I think there are some strong arguments for making the outer SA = the inner SA, which is contrary to the conventional sensible notion that any packet created by node Y should have its SA = Node Y's address. The general arrangement is: HA-----ITR~~~~~~~~~~~~~~~~~~ETR------HB where HB has the LISP/Ivip-mapped address (maybe HA has such an address too, but that doesn't matter). The current LISP-01 I-D only describes LISP 1 and 1.5, so there's no way of knowing whether with LISP 3.x the outer SA (Source Address of the UDP packet which encapsulates data packets when the ITR tunnels a data packet to an ETR) will be the original packet's SA (HA's IP address) or the ITR's address. In LISP 1 and 1.5 the outer SA is definitely the ITR's address (see Definition of terms: ITR). In LISP 3.x I am not sure to what degree the ITR sends messages to the ETR, or whether the ETR sends anything back to the ITR. Dino's recent message: http://www1.ietf.org/mail-archive/web/ram/current/msg01703.html indicates that the 3.x approaches using CONS or NERD do not involve the ETR sending a Map-Reply message to the ITR and that perhaps with APT there would be such messages. So I am not sure whether some or all 3.x variants of LISP involve no messages at all from the ETR to the ITR. If there is no requirement for such messages or information exchange, then maybe the ETR doesn't need to get any information from the ITR in data packets, or presumably by any other means. In that case, the ETR wouldn't need to know the address of the one or more ITRs which are tunneling packets to it. In that case, it may be possible for LISP to adopt the same "outer SA = inner SA" approach I currently favor for Ivip. As far as I can tell at present, this would have the same benefits for LISP as for Ivip - much greater ease of a network protecting itself from a particular form of attack which I will call "internal source address spoofing", and the retention of the sending host's ability to fully traceroute the path taken by the packets it sends. If LISP or Ivip uses the ITR's address for the outer SA then HA will find that traceroute does not produce any results for any routers between the ITR and ETR. Whether or not it would produce a response from the ETR depends on whether the ETR treats the decapsulated packet just like any newly arrived packet or not. I regard this as a substantial argument against using the original packet's SA for the outer SA. I am assuming in all this that both LISP and Ivip ITRs and ETRs follow the principle that the ITR copies the TTL (Time to Live) from the packet it is encapsulating to the header of the new packet which contains it (the IP-UDP IP header for LISP and the IP-in-IP IP header for Ivip). Similarly, the ETR takes the TTL from the outer IP header and copies it to the TTL field of the IP header of the decapsulated packet. (These operations are specified for Ivip, but are not actually specified in LISP, except for similar concepts with recursive or re-encapsulating tunneling.) My previous message contained some detailed thoughts on why requiring ITRs to make the outer SA = inner SA makes it much easier for the network in which the ETR is located to ensure that packets arriving from outside the network and being decapsulated by its ETRs do not produce decapsulated packets with SAs from local prefixes. Here I develop this line of argument further - in support for the initially unpalatable notion of having the ITR tunnel the packet with outer SA = the packet's original SA (inner SA). I then examine what benefits and difficulties would result from following convention and having the ITR use one of its own addresses as the outer SA. Ivip has no communication from ITR to ETR or from ETR to ITR. There is no header, other than the outer header of IP-in-IP encapsulation. Ivip could be redefined to use the ITR's address as the outer SA, but at present I think it is best not to. Ivip could be redefined to use UDP encapsulation as is currently defined for LISP 1 and 1.5 - then various other items such as the ITR's address could be included in the encapsulated packet - but I am trying to keep Ivip simple and see no reason to do this. In this discussion, when I refer to "network" I mean any Autonomous System network (provider or for an end-user) in which ETRs are deployed. I don't refer in this discussion to the edge networks of a single-homed or multihomed end-user which relies upon LISP-mapped or Ivip-mapped addresses. Those edge networks have different requirements for preventing "internal source address spoofing", which I discuss in Note 1 at the end. Here is a description of the particular security problem I am concerned about: ............. .................... N1 . . N2 . . . . H1---ETR1~~~BR1~~~~~~~~TR~~~~~~BR1~~~~~ETR1---MN1 . / . \ \ ............. / . \---H2 \--MN2 / . \ / . \-H3 / . AT1~~~~~~~~~~~~~~~~~~~TR .................... N1 has a host H1 which is sending a packet to Mapped Node MN1. Whether MN1 is a host with one or multiple IP addresses, or a link to a router at a multihomed end-user's site, doesn't matter. Nor does it matter whether H1's address is Ivip-mapped or not. Also, it probably doesn't matter whether the ETR gets the decapsulated packet to MN1 via a direct link or via relying on N2's internal routing system to forward the packets to MN1. This problem only concerns packets flowing left to right in this diagram. Howe MN1 gets packets to H1 is a separate matter and not affected by the security problem. I assume N2 has BR2 set up to drop any packet which arrives from the outside world where the SA matches any of the one or more prefixes N2 advertises to its BGP peers. If N2 doesn't bother to do this, there is no point in fussing over how the ETRs should filter packets to achieve the same purpose. I assume (for reasons discussed in my first message in this thread and in Note 2 below) that all ETRs will drop any packet which has a DA for any address other than the set of hosts/routers which it knows it can deliver decapsulated packets to, with LISP/Ivip-mapped addresses. This means that if the ETR decapsulates a packet and finds its DA is for H2, then it drops the packet. This also means that if it decapsulates a packet and finds its DA is for some other LISP/Ivip-mapped address which it can't deliver packets to (either directly or via support from the local routing system) then this packet will be dropped too. The purpose of this "internal source address spoofing" protection is to stop MN1 receiving a packet with SA matching any of N2's BGP-advertised prefixes, for instance the address of H2. Without this protection, an attacker AT1 can easily create an encapsulated packet, with outer DA = ETR1, inner DA = MN1 and inner SA = H2. It is not the purpose of "internal source address spoofing" to stop ETR1 from decapsulating and forwarding an inner packet to MN1 when its SA is any LISP/Ivip-mapped address, including some address of another host/node MN2, which happens to be "within" N2 or potentially (multihomed link which may not be working) connected to N2. An attacker can already do this by sending a packet with a spoofed SA to any ITR, or by generating its own encapsulated packet. The only purpose is to prevent attackers spoofing source addresses of the non-LISP/Ivip-mapped addresses within N2. Attackers are assumed to be outside N2. (It's all over if an attacker is inside N2.) I start with some further assumptions: A1 - Whatever new architecture is adopted - LISP, Ivip etc. - the new architecture must not force a lower level of security than currently exists (RRG Design Goals 3.9) and should not make it significantly more difficult, costly or error-prone to ensure the same levels of security are maintained. A2 - Therefore, for networks which protect against "internal source address spoofing" the new architecture must make it easy to maintain this protection for packets being decapsulated by ETRs. A3 - That the ETR needs to decapsulate packets which were encapsulated by ITRs in this same network. I argue in Note 2 at the end of this message why this is a reasonable requirement. A4 - We can't expect the border router to perform deep packet inspection on every incoming packet - for instance to find any packet which looks like it might be intended to be decapsulated by an ETR, and to then decapsulate it, and filter it according to the SA of its inner packet. So we can assume that BR1 drops any packet arriving from outside if the SA matches, for instance, H3's (ordinary, BGP reachable) address. Preventing SA spoofing when outer SA = inner SA ----------------------------------------------- In the above framework, it becomes very easy to protect against "internal source address spoofing" if all ITRs make their outer SA equal to the source address of the sending host (the inner SA). All that needs to be added is that ETRs drop any packet whose inner SA does not match the outer SA. This means that there are two classes of spoofed SA packets being filtered: 1 - Those sent as ordinary packets, from outside. This is handled by the border router's existing filters. 2 - Those in inner packets with an outer header with DA = an ETR. This is performed in two stages - by the border router and then by the ETR dropping packets where inner and outer SA do not match. This seems to be a bullet-proof arrangement, and works fine with encapsulated packets created by ITRs in the network. These are assumed not to arise from attackers, since attackers are defined to be outside the network. Preventing SA spoofing when outer SA = ITR's address ---------------------------------------------------- In this arrangement, the ETR can't drop packets with inner SA != outer SA. So there is no way the ETR can use this simple technique to extend the border router's filtering to the inner SA. The only alternative is for the ETR to drop the inner packet according to the following criteria: 1 - If the inner SA matches any of the network's BGP advertised prefixes. and 2 - The outer SA does not match any of these prefixes. (So the packet arrived in encapsulated form from outside the network while pretending to be sent from inside the network.) Assuming the ETR needs to accept encapsulated packets from ITRs inside the network (Note 2 below) then both these tests are required. However, this is likely to be prohibitively difficult for an ETR to perform. Firstly, the FIB hardware of a proper router isn't necessarily able to perform these gymnastics. (The decapsulation and "drop if inner SA != outer SA is still tricky, but does not involve any knowledge of the potentially numerous local prefixes.) Secondly, the list of prefixes this network advertises could be very large indeed. This would make it perhaps impossible for FIBs to cope with such a list. Thirdly, we want to be able to do ETR functions in servers, not just hardware-FIB "routers", including in the destination host (if it has a BGP-reachable care-of address). There is no way with ordinary software of applying a huge list of rules to the inner SA to decide if the packet should be dropped, and then applying the same set of rules to the outer SA as well. Finally, even if routers and software ETRs could do this, there are serious problems with the network's control system finding all these ETR functions ensuring they comply with these rules. With my idea towards the end of Note 2 below - that ETRs should know how to deliver packets directly to the destination host, rather than use the internal routing system (which is compatible with LISP-01 page 11 point 7: "attached destination host") - there is no need for a general system to control all ETRs at once (as would be required if every ETR was to decapsulate packets for any host in the network with a LISP/Ivip-mapped address, relying on the local routing system to get the packets there). What is lost by making outer SA == inner SA? -------------------------------------------- By defying convention and having ITRs send tunneled packets without their own IP address in the SA of the outer header, we lose certain things: 1 - We can't find directly which ITR tunneled the packet, once it left the ITR. 2 - Therefore, we can't get a message to that ITR, or two whoever runs it. It is an uncomfortable thing to propose such an arrangement, but here I explore exactly what would be lost. (As with all this stuff, I could be mistaken and be missing many important things - so please let me know what I have missed.) Ivip requires no communication from an ETR to an ITR, or vice-versa, so nothing is lost with this arrangement. Some variants of LISP do require this communication, so if this "outer SA == inner SA" was adopted for LISP (for instance because it seems to be the only practical or reasonable way of allowing a destination network to maintain current security limits) then the LISP header would need to contain the ITR's address. I think the remaining reasons for wanting to know the ITR's address are to do with coping with unwelcome packets. Here is a possibly incomplete list of the scenarios which could lead to the perception of unwelcome packets arriving from an ITR. In the case of packets from an attacker, I will assume that the outer SA (Ivip) or any "ITR address" in a LISP header contains a bogus address, which may be part of the attack by encouraging victim V1 (whoever's host gets the unwelcome packets) to send messages to victim V2 who probably runs an ITR, or to V3 which is whoever runs the LISP/Ivip database system, with possible negative consequences for further victims who might use LISP/Ivip-mapped addresses: a - The packets are sent to an ETR but have inner DAs for LISP/Ivip-mapped addresses which the ETR is not configured to deliver to a destination host. This could include an address which is a BGP reachable address, or some other LISP/Ivip-mapped address other than the small subset of those addresses for which the current ETR can deliver packets. b - The packets are sent to an ETR and have inner DAs which is one the ETR is configured to deliver packets for - however the flow of packets is excessive in volume, is regarded by that host as irrelevant or unwelcome etc. c - The packets are sent to an address which is not an ETR - it may be of a host, an ordinary router or to some address which has no destination node. In all these cases, if the encapsulated packets come direct from an attacker (that is they have not been generated by a proper ITR) then there is no point in looking at the outer DA. That will probably not lead to any clues about the location of the attacker. Any attempt to complain about an attack from that outer DA address will probably cause V1 to drag other victims into the attacker's ploy. If the packets do come from one or more genuine ITRs, then I think one of the following must be true: e - The one or more ITRs are functioning properly, with fully updated databases (an ITRD or an ITRC or ITFH with access to properly updated query servers, and getting notifications from those query servers in the event of a database change for some mapping information they cached). f - The one or more ITRs are not functioning correctly. Maybe their FIB is broken and doesn't reflect their RIB (copy of database or cached mapping information). Maybe they are not properly updated. For this reason, ITRDs which for some reason are not getting updates or which have detected some corruption should probably stop forwarding packets. this is a tricky business I will write more about in the future. In the case of 'e', there is no point in knowing which one or more ITR is tunneling the packets, because there is nothing wrong with these or any other ITR - and similar problems can be expected with packets being tunneled by any of the world's hundreds of thousands of ITRs (or millions, with ITFHs widely deployed). The problem is either with the contents of the mapping database(s) or with the behavior of sending hosts. In Note 3 I discuss how to resolve the first problem. The second problem has nothing to do with the LISP or Ivip system, although perhaps changing the mapping to "drop" or pointing it to some other ETR could resolve some problems. In the case of 'f', it would be good to find the ITR which is sending the packets which are considered unfriendly. Ivip as I am currently proposing it would prevent anyone from finding out which one or more broken or out-of-synch ITRs are causing the trouble. This problem is similar to having some router out in the Net malfunction, forwarding packets to some place they don't belong. Generally, the packets wouldn't get to an ETR or a host, because not even a malfunction in a local router could do this (unless the victim host was on a single link, rather than a LAN, from the errant router. The broken ITR is not generating the packet, but it is tunneling a packet which should be tunneled to some ETR which would be happy about it to some other address where the packets are not welcome. If the outer SA was the ITR's address, then victim V1 could potentially find who runs this ITR and complain - but it could be tricky finding out who to complain to, unless there was some global register of ITRs, which won't include the hundreds of millions of ITFHs on host computers if Ivip is widely implemented in the future. There is something lost by not being able to identify the genuine ITR which mistakenly tunneled the packets. However, if the ITR was functioning properly, there is no point in finding out its address or who owns it - the problem is not with the ITR but can only be resolved by either changing the mapping information or by altering the behaviour of sending hosts - which is no different from the situation with unwelcome packets today without LISP or Ivip. Even if it was possible to identify the genuine ITR which tunneled the unwelcome packets, why should the operator of that ITR shut it down just because V1 complains about it? Who is to say that the complaint is not the work of an attacker? There does need to be is a way of V1 finding out the recent history of its IP address being involved in the mapping database. I write more about this in Note 3 below. - Robin Note 1 - Edge networks and "internal source address spoofing" ------------------------------------------------------------- A single-homed or multihomed "edge network" which uses purely LISP-mapped or Ivip-mapped addresses has a very different set of conditions in which it might protect against "internal source address spoofing". Firstly, it has no BGP connections to the Internet. It only receives incoming packets via one or more links to provider networks. Here, I assume that it relies upon ETRs in those provider networks (see Figure 3 in the Ivip I-D). These ETRs feed the inner packets (that is the packets with DA = some LISP/Ivip-mapped address, where this is one of the edge network's address range, such as the address of IH9 in Figure 3) directly to the edge-network's router, Ethernet switch or whatever. However, if the edge network gets from each of its one or more providers one or a few of the provider's PA addresses, on which it runs its own ETRs, and then routes only the inner packets produced by these ETRs to the rest of the edge network, then similar principles apply. The edge network does not contain any ETRs, because ETRs do not reside on addresses which are LISP/Ivip-mapped. Therefore, the edge network doesn't need to worry about packets emerging from ETRs within its own network. I can think of two scenarios which require different approaches to protecting against an attacker (implicitly any host outside this edge network) from sending packets with spoofed local addresses - meaning addresses within the range of LISP-Ivip-mapped addresses of this edge network. 1 - The edge network has no ITRs - including any ITFHs - which might be tricky to establish if ITFHs became a common part of operating systems . . . but then an ITFH will always send queries to some Query Server, so if there was a way of preventing this from succeeding at the network's router, then this would prevent any ITFH function working. In this case, the edge network relies on its internal routing system to forward packets from its hosts to its hosts. In this case, raw packets with DA matching a LISP or Ivip-mapped address range will be forwarded directly to the correct host if that is their DA, or to the router and out one of the links to the provider network if they don't match one of the edge network's addresses. There they will soon be encapsulated by one or a series of ITRCs, ITRD etc. Protection against packets from the outside with spoofed local SAs must be done by the edge network's router - it must drop any incoming packet with a SA which matches one of the edge network's LISP/Ivip-mapped addresses. 2 - The edge network has its own ITRD, ITRC and/or ITFH functions - and these may encapsulate packets which were addressed to one of the edge network's LISP/Ivip-mapped addresses. This is probably a bad idea, since it makes it much more difficult, or impossible, to protect against "internal source address spoofing". There are various reasons I won't explore here why this is a messy arrangement to be avoided, but for instance how can the edge network's router know whether decapsulated packets from an ETR originated in its own network or were decapsulated from a packet of an attacker? 3 - Probably some other scenarios I can't think of now. Note 2 - ETRs must handle packets from ITRs in the same network --------------------------------------------------------------- (See assumption A3 above.) In a large network, for scaling purposes, there needs to be lots of ITRs. We can't make all the ITR functionality be in the border routers. Also, at least with Ivip, it would be advantageous to allow and encourage caching ITR functions in sending hosts (both those on ordinary BGP reachable IP addresses and those with Ivip-mapped addresses). This is an ITFH function. It needs to send queries to QSD or QSC query servers, and it doesn't necessarily have to tunnel every packet - because those it doesn't tunnel will (in a well designed network) be forwarded (or perhaps explicitly tunneled to) one or more ITRCs or an ITRD which can encapsulate it. The ITFH greatly reduces the load on ITRCs and ITRDs, without any cost to anyone and with the path taken by the packets to the ETR being entirely optimal, since they never need to go via an ITRC or ITRD. (ITRCs and ITFHs may not tunnel all packets, so they need a backup of some other ITRCs or ideally an ITRD to handle these.) I assume ITFHs can't easily be detected (except by detecting or blocking their requests to query servers - maybe the autodiscovery system returns a message "ITFHs not supported here", which may be as simple as an empty list of Query Servers) and that they can't be highly managed, at least in terms of rapid changes to their behavior. For instance there could be thousands or hundred of thousands of ITFHs in a large network, in many hosts or in DSL modem NAT functions (I call this "function in host" because the "router" is just a CPU and software, with no FIB hardware etc.). Nonetheless, I expect there to be autodiscovery arrangements for an ITRC or ITFH to find where to send queries to and perhaps where to tunnel packets it doesn't encapsulate for some reason, but which should be - for instance because it doesn't have mapping information for that packet's DA. It is probably much more robust and easier to plaster ITRs all over the network and to encourage the adoption of ITFHs in many hosts and DSL etc. modem-routers - than to try to ban ITFHs and centralise all ITRs in a few places where their activities can be carefully controlled. If all the ITRs in a network could be carefully controlled, then it would be possible to ensure that the local routing system took precedence over encapsulation, so that if a host H3 wanted to send a packet to MN1, then the packet would be sent via the local routing system to MN1, and not encapsulated and tunneled to ETR1. However this is unlikely to be practical, because it could be difficult or impossible to immediately change the internal routing system and all local ITR behaviour to reflect the fact that MN1's one or more LISP/Ivip-mapped addresses have just become reachable inside this network, or have just become unreachable. If the local routing system forwards packets to MN1 - this must be stopped the moment MN1 is no longer reachable - such as if MN1 has moved and changed its mapping to some other ETR or another network's ETR. Even if the local routing system forwards packets to MN1, then it would still be best if any packet which is encapsulated by an ITR anywhere will be delivered properly. Generally, I think there should be no exception to the rule "if the raw packet finds its way to an ITR which encapsulates it according to the current state of the database(s), then it definitely will be delivered to the currently selected ETR". A local routing system which attempts to get the packet to the destination host might be acceptable, provided it changed its behavior very rapidly to reflect the contents of the mapping database. Overall, I think it will be best if: 1 - One or more ETRs have some explicit tunnel system for getting decapsulated packets to the destination host, rather than relying on the local routing system. 2 - Hosts inside the same network should rely on ITRs (and perhaps their own ITFH function) to deliver the packets, in accordance with the current state of the database(s) - and not have this interfered with by the local routing system trying to take packets directly to the destination host. 3 - We don't want to concentrate all the ITR functions in border routers. To maintain optimal path lengths within the network, we want the packets to encounter an ITR ASAP, including in the sending host's own ITFH function. 4 - Therefore, we need ITRs all over the network, and these ITRs will be encapsulating packets to be sent to ETRs in the network, which will directly get the decapsulated packets to the proper destination. All this only applies to Autonomous System networks - not the end-user networks which consist only of LISP/Ivip-mapped addresses. Note 3 - A "search-mapping" service to debug LISP/Ivip mapping -------------------------------------------------------------- This proposal would work with Ivip as currently defined - and perhaps with some forms of LISP. I think there really needs to be some kind of service like this, for LISP or Ivip. There are some security and privacy implications of such a service being open to anyone to query about any IP address, but there is absolutely no way of preventing such a service being created, so there is no point in trying to prohibit misuse of such a service. This service could be implemented as part of the main Ivip system, but there is no need for this to be done, since one or more separate companies, organisations or individuals could set up their own system to do the same job. The service has a server which gets a full feed of the update stream - "US-Complete" in the current Ivip I-D. It can also download the IMAB-DBD periodic dumps of the complete set of mapping databases. It is absolutely required that this information be freely available to anyone, so anyone can set up their own ITRD and QSD-QSC-ITRC-ITFH systems. No practical measures could prevent anyone from gaining access to this information. The service analyses the data and stores a copy of its analysis in some database, covering the last few weeks of activity. Then, the service is able to definitively answer queries such as: What is the history of RLOC (LISP) or TELOC (Ivip) mapping of this particular EID (LISP) or DID (Ivip) address? What is the history of the RLOC/TELOC mapping of any EID/DID over the past minutes, weeks etc. which involved the ITRs being told to tunnel packets to this particular IP address? This means that if the unwelcome packets resulted from something in the mapping system, now or in the past, that V1 could find out for sure which one or more EID/DID addresses was involved. Then, it could quickly establish which RUAS (Ivip Root Update Authorisation System) the update was made through. If that RUAS considered the complaint to be genuine, it could try to resolve it with the end-user who it authorises (directly or via one or more branch and leave UASes) to control the mapping of this IP address. Spies, dodgy detectives and the security authorities will be watching the changes in the database, so anyone with something to hide (which includes ordinary folk who are targeted by nosey authorities and those with malicious intent) need to consider how changes to their mapping might leak information to others. BTW, future generations will want to know why LISP, Ivip or whatever was foisted on the Internet - because it is certain to add to the difficulty of understanding and managing the system, with its own set of gotchas and security problems. They will hopefully realise that BGP couldn't be asked to do much more and that IPv6 wasn't ready for mass adoption, and doesn't solve the major problems anyway. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 14 04:12:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9cjq-0005ll-8Y; Sat, 14 Jul 2007 04:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9cjp-0005hG-3u for ram@iab.org; Sat, 14 Jul 2007 04:12:25 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9cjl-0001Ri-Gw for ram@iab.org; Sat, 14 Jul 2007 04:12:25 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 1453C59DDD; Sat, 14 Jul 2007 18:12:20 +1000 (EST) Message-ID: <46988556.9060007@firstpr.com.au> Date: Sat, 14 Jul 2007 18:12:06 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [RAM] iPlane stats on number of BGP routers etc. X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I found out about the iPlane project from the paper "Locator/ID Separation: Study on the cost of Mappings Caching and Mappings Lookups": http://inl.info.ucl.ac.be/publications/locator-id-separation-study-cost-mappings-caching-and-mappings-lookups recently mentioned by Luigi Iannone. http://iplane.cs.washington.edu This has some interesting bodies of data: http://iplane.cs.washington.edu/data.html (Data) http://iplane.cs.washington.edu/osdi06.pdf (Description) including: Lists of alias clusters 62,698 lines "We provide all sets of alias sets that we have discovered. Each line in this file contains a space-separated list of interfaces that correspond to a single router." Origin AS mapping 223,338 lines This is the "global BGP routing table". I thnik this is what is referred to on page 8 of "Locator/ID Separation: Study on the cost of Mappings Caching and Mappings Lookups" as "/BGP" and "prefix blocks assigned by RIRs". In fact it is the prefixes advertised as Autonomous Systems choose to split them up, not as assigned by the RIRs. Internet Atlas 551,589 lines "Each line in the file contains one distinct inter-PoP link." I think this means they have found 62,698 BGP routers. Does anyone want to hazard a guess about the cost of the multihomed ones in this set. I guess most are multihomed border routers or transit routers, so most are in the DFZ and have to cope with the growth in the global BPG routing table. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jul 15 10:30:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA56d-0003gS-MK; Sun, 15 Jul 2007 10:29:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA56c-0003dv-Jn for ram@iab.org; Sun, 15 Jul 2007 10:29:50 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA56Y-0004RC-2J for ram@iab.org; Sun, 15 Jul 2007 10:29:50 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 555AF59DA1; Mon, 16 Jul 2007 00:29:43 +1000 (EST) Message-ID: <469A2F49.6080407@firstpr.com.au> Date: Mon, 16 Jul 2007 00:29:29 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Ivip I-D soon References: <468EF8BC.9000104@firstpr.com.au> In-Reply-To: <468EF8BC.9000104@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I have sent draft-whittle-ivip-arch-00 to the IETF and have HTML and text copies of it at: http://www.firstpr.com.au/ip/ivip/ The additions since the draft version I made available on 7 July are: Differences with respect to LISP: LISP: UDP encapsulation with outer SA = ITR's address. Ivip: IP-in-IP encapsulation with outer SA = inner SA = sending host's address New sections at the end: ETRs checking src & dest addresses Scaling the Replicator network Is fast, secure, Replication possible on the Internet? TTRs and Mobility Not counting boilerplate and blank pages, there's about 86 pages of material here. There's a few hours of reading - but it is cohesive and should make sense to all RAM list readers. Please let me know of any blunders, suggestions for improvements, links to similar ideas elsewhere etc. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 17 06:13:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAk3Y-0003ME-Av; Tue, 17 Jul 2007 06:13:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAk3V-00038Y-At for ram@iab.org; Tue, 17 Jul 2007 06:13:21 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAk3P-00007H-HB for ram@iab.org; Tue, 17 Jul 2007 06:13:21 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 3D54459DA1; Tue, 17 Jul 2007 20:13:11 +1000 (EST) Message-ID: <469C962B.1090600@firstpr.com.au> Date: Tue, 17 Jul 2007 20:12:59 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4be0d55bab88df9d21005ced9551e26 Subject: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I started off wanting to discuss what was in common and different between LISP 3.x and eFIT - however it grew into an attempt to compare major aspects of the current proposals. - Robin http://www.firstpr.com.au/ip/ivip/ LISP 1.0 and to a limited extent 1.5 is documented in the LISP-01 I-D: http://tools.ietf.org/html/draft-farinacci-lisp There is nothing specific there or anywhere else about LISP 3.x - however it has been stated on the RAM list that 3.x is the most likely variant to be deployed. 1 and 1.5 are theoretical models for trying out concepts - but the look very different to me from 3.x, so I don't know what lessons learnt with them would be applicable to 3.x. According to Dino's RAM list message 1703 (July 13), the three mapping distribution systems applicable to LISP 3.x would be: NERD (No data driven Map Reply messages.) http://tools.ietf.org/html/draft-lear-lisp-nerd-01 (June 12) CONS (No data driven Map Reply messages.) http://tools.ietf.org/html/draft-meyer-lisp-cons-00 (July 3) APT (Perhaps some data driven Map Reply messages.) http://tools.ietf.org/html/draft-jen-apt-00 (July 2) APT is designed not for LISP, but for eFIT: http://www.cs.ucla.edu/~lixia/papers/07SIG_IP6WS.pdf A Scalable Routing System Design for Future Internet Daniel Massey, Lan Wang, Beichuan Zhang and Lixia Zhang. July 2007 http://tools.ietf.org/html/draft-wang-ietf-efit-00 Of the efit-00 I-D, Lixia wrote on this list on 10 July: > That one is really outdated. We are working on a new > version. Will send a pointer before Chicago. So there are now five potential new architectures - all but one with a push database arrangement: LISP-NERD LISP-CONS (Pull.) LISP-APT (APT is only intended for eFIT.) eFIT-APT Ivip All these are in an early stage of development. Ivip is extensively documented, http://www.firstpr.com.au/ip/ivip/. NERD is a push system in that all ITRs have a copy of each mapping database for each prefix of LISP-mapped addresses. It has only modest speed goals. "... updates to the mapping are intended to be relatively rare". The mapping database is not intended to change when a link fails or is restored - so the ITRs must somehow be smart enough to detect loss of reachability to an ETR, and already have the alternative ETR's address in their database, to switch to another ETR which is reachable. Since there is no ITR-to-ITR communication about this as far as I know, I guess each ITR has to figure out reachability on its own when it tries to send packets. This is much more complex for the database contents and for ITR functionality than Ivip - in which an external monitoring system changes the mapping and the ITRs simply follow the changes to the mapping, which need to be delivered very quickly. While NERD is "push", in comparison to CONS - which is purely a query and cache system - the mapping updates are not actually sent to the ITRs. Each ITR has to poll a server and retrieve the update files. However NERD-01 anticipates ITRs advertising the update files they have, and downloading these files from neighbouring ITRs, as an alternative to getting them from centralised servers. If each update file needs to be fully downloaded and authenticated before it can be made available for other ITRs to download, then this will lead to a slow propagation of these files across the Net. Alternative approaches using NNTP, and with ITRs only storing part of the database with "push" and are also contemplated. (I don't understand how an ITR would have only part of the database, unless it has another ITR with the full database to which it would tunnel the packets it doesn't have mapping for, or a nearby full database query server like in Ivip or eFIT-APT's Default Mappers.) LISP-CONS is a "pull" system. ITRs query and cache the mapping data, via local CARs which also cache. Requests and replies traverse a mesh of CARs and (non-caching) CDR servers, all linked via authenticated TCP sessions. Depending on the caching time, LISP-CONS could work with more frequent database updates than LISP-NERD, but there is no attempt to speed things up as with Ivip's Notify (cache invalidation) or the same concept in eFIT-APT: "updated mapping entry" - which are real-time, local, push messages directed to the caching ITRs (and for Ivip, the caching Query Servers) which they query. eFIT-APT differs from LISP and Ivip in a number of respects, including: 1 - ETR and ITR functions are always contained in the same device (TR) whereas these can be in separate devices for both LISP and Ivip. These TRs will replace all current Provider Edge routers - or all PE routers will be upgraded to have these capabilities. 2 - The ITR function is a query and cache system, as with LISP-CONS and Ivip's ITRC (ITR Cache) and ITFH (Ingress Tunnel Function in Host), but unlike the full database ITR in LISP-NERD in in Ivip's ITRD. 3 - Each transit network is expected to run at least one "Default Mapper", which may be router (at least it can encapsulate packets, even if it only has one interface), and which has a real-time updated copy of the entire eFIT-APT mapping database. (Except in the future for IPv6 - section 7.4.) There is nothing about implementation of Default Mappers in the I-D, but I think they would best be implemented in a server, rather than a conventional router with hardware FIB etc.) ITRs send queries to the Default Mapper in their network. Each query is packet they do not currently have mapping data for. The Default Mapper encapsulates the packet and forwards it towards the ETR in the destination network, and then sends back an ICMP response to the ITR with the mapping information the ITR needs to handle such a packet in the future. (If a future packet's DA was part of a prefix with the same mapping data, then the ITR would then know how to encapsulate it.) This aspect of the Default Mapper is analogous to Ivip's QSD (Query Server with Database) combined with Ivip's ITRD handling packets which can't immediately be tunneled by an ITRC or ITFH. This will lead to much faster and more reliable query responses than LISP-CONS - but as with Ivip, raises the challenging problem of distributing the database updates in real-time to all these Default Mappers. However, eFIT-APT has very slow goals regarding the speed of distributing these updates. As with Ivip, there is no delay for packets which cannot be mapped by an ITR, although APT's Default Mapper or Ivip's "backup" (maybe I should call it a wicket-keeper . . .) ITR could be a bottleneck. With Ivip, there could be a chain of ITRCs leading to a final ITRD. 4 - The Default Mappers can be reached by anycast within a particular provider network. (I don't propose QSDs be accessed this way, but it is an interesting idea as an option, provided all queries, responses and Notifications can be done with UDP. Since Notification involves the QSD ensuring that the message was received by whichever QSD or ITRC the QSD sent it to, TCP might be a better approach than UDP - so anycast QSDs may not be such a good idea.) There is no two-way communication when the Default Mapper sends the ICMP packet with the mapping information to the ITR. Two-way communication would be tricky with anycast unless all the Default Mappers had very intimate links between them, which is to be avoided. However, I guess non-guaranteed ICMP reply is fine, since if the ITR doesn't get it, the worst thing that can happen is that the ITR will send the next data packet to the Default Mapper as well. Default Mappers also have the equivalent of an Ivip "Notify": "M1 can respond with an updated mapping entry". There's no mention of the ITR having to acknowledge this - and even if it did, if anycast is used, it would be difficult to ensure that the ack would go to the correct Default Mapper. Both Ivip and APT should have a way of ensuring the updated mapping information really has been received by the ITR (APT) or QSC, ITRC or ITFH (Ivip) it was sent to. 5 - The ITR function of APT TRs does not make any decisions regarding which of multiple ETRs to tunnel to in a multihoming scenario. Each ITR is told to tunnel packets which match a particular EID prefix to a single RLOC location: a single ETR. (However, see the next point about the ETR function performing various functions and sending messages back to an ITR.) This *greatly* simplifies the FIB work of the ITRs - and reduces the size and complexity of the mapping information they cache. In this respect, the ITR function of an APT TR somewhat resembles an Ivip ITRC. However, unlike an Ivip ITRC, and APT ITR is required to detect unreachability of the tunnel endpoint - the ETR's address. It can do this via the ETR's address being unreachable, or via an ICMP Destination Unreachable message, or some other ICMP message for the third kind of failure (5.1.3). (I am not convinced there would always be an ICMP Destination Unreachable message if there was no host at the address where the ITR (ITR function of a TR) is supposed to be.) In any of these cases the ITR sends the next packet intended for this ETR to the Default Mapper instead, and it is the Default Mapper which makes the difficult decisions, including by tunneling the packet to an alternative ETR (assuming it is reachable via BGP) and waiting to see if there are any ICMP messages in response. I think the way the APT system responds to ICMP messages, at least the "Destination Unreachable" messages - which would not have any nonce from any APT data packet header (no header details are currently available) - makes it an easy target for spoofed ICMP messages for a DoS attack. Devolving the multihoming link selection problem, and the TE functions, to the Default Mapper is a good idea, I think, but involves more ICMP packets to ITRs with "updated mapping entry" information. As noted above, I don't see any provision in APT for this to be delivered in a reliable manner. There also needs to be some crypto or protection against an attacker spoofing packets with the Default Mapper's address, to ensure the ITR's cache is not corrupted by someone who wants to steer packets to their own address. The ITR function of TRs are also required to forward any ICMP messages they receive to their Default Mapper - which will use these to decide which of the various RLOC mappings are for ETRs which are currently reachable. Again, all these communications need to be secured in some way against spoofed packets from an attacker. (This is acknowledged in sect. 7.) 6 - 5.1.3 states that an ETR which can't reach the destination host or router will send the packet to its Default Mapper, (which has some complex rules about not sending it back to the same ETR) as well as sending an ICMP message back to the ITR in the sender's network which tunnelled the packet in the first place. (Actually, the packet could have been tunneled by the Default Mapper in the sender's network too.) Here are some questions about each scheme, with "LISP" implying LISP 3.x. There is no concrete information about LISP 3.x other than that implied by NERD and CONS that I won't consider how LISP might work with APT. Encapsulation of data --------------------- LISP-NERD/CONS: Not documented yet, but presumably using UDP, with the outer source address being that of the ITR which encapsulated the packet. (Outer SA = ITR's address.) See the recent messages "ETRs checking src & dest addresses" about how I think this makes it harder for the ETR's filtering system to protect against spoofing of local source addresses. eFIT-APT: Not documented, but APT mentions an ICMP Destination Unreachable message being generated if the encapsulated packet does not reach an ETR, so I guess this means UDP encapsulation with outer SA = ITR (or Default Mapper) address, similar to that described in LISP-01's description of LISP 1 / 1.5. Ivip: Currently defined as IP-in-IP with outer SA = inner SA, to help with the filtering. However, it could be changed to UDP with the ITR's address in the payload, with outer SA = inner SA, to enable unwelcome packets to be traced back to the ITR which encapsulated them. Source of mapping data ---------------------- LISP-NERD: A hopefully small number of database authorities. No particular relationship to any provider network, as far as I know. Various other approaches are considered too. This seems to be different from what I call the "Bring-your-own address space" model of LISP-CONS and maybe eFIT-APT. LISP-CONS: CAR servers are authoritative. These are distributed around the Net and there are two or more in some redundant arrangement - though it is not clear from the current I-D how a CDR decides to forward a query to two or more redundant CARs, or whether both replies are sent back through the CDR mesh to the CAR which made the query. I guess the CARs are related to provider networks and the various LISP-mapped blocks of address space are controlled by various providers. eFIT-APT: Provider networks have one or more Default Mappers, which in addition to many other functions, are the authoritative source of mapping information for a set of prefixes which are currently BGP advertised by that provider (but won't be at some time in the future). So as with LISP-CONS, it seems the system of address management of mapped address space which is dependent on existing provider networks. If an end user is with provider X, using some of their PA addresses, could they go to another provider Y for connectivity, or X and Y or Y and Z for multihoming, and still have to rely on X to to the mapping the way they want? What if an AS-end-user with their own PI space is currently connecting with provider X. If they want to move to provider Y, does this means that X's Default Mapper no longer is authoritative, and that Y's is? I am confused about exactly how eFIT-APT works. Ivip: Multiple independent Root Update Authorisation Systems devolve responsibility to other systems and then to end-users. Updates are funneled in real-time to a Replication system which fans it out to ITRs and QSDs all over the Net. So the address space management, mapping changes etc. is not tied to any provider organisation or to provider devices or networks. I think LISP-NERD's organisational aims may be similar. Speed and method of update propagation -------------------------------------- LISP-NERD: Slow. ITRs are "full database" and download files from each database authority. The ITRs then poll for changes. "Updates to the mapping will be relatively rare" and "are not intended to change when a link either fails or is restored". So TE and multihoming service restoration are performed by the ITRs and ETRs, rather than via changes to the mapping database. I guess times of tens of minutes to hours, depending on how busy the ITR is about polling for changes. In principle, it can be quite fast, but that requires a huge burden of polling traffic. LISP-CONS: Faster than LISP-NERD. All communications via a meshed TCP-linked CDR network - queries go along it and responses come back along it, rather than the responses going straight from the authoritative CAR to the querying CAR. (I understand this is because the meshed network is secure and all the TCP sessions are already running.) ITRs are query and cache devices, via CARs which also cache and which are also typically authoritative for some part of the mapping database. EID-to-RLOC mappings "are assumed to change at low frequency". As with LISP-NERD, TE and multihoming service restoration are performed by the ITRs and ETRs, rather than via changes to the mapping database. eFIT-APT: Very slow indeed. Default Mappers in each provider network are authoritative, and push their data to other Default Mappers via BGP. Full database push and occasional update push techniques are used. "Transient failures do not cause mapping announcements in APT." "Permanent mapping changes are unlikely to occur more than once per month per customer." Ivip: As fast as possible - maybe a few seconds from the end-user changing their mapping to all ITRs following the new mapping. "Notify" messages from QSDs to ITRCs and ITFHs. This requires an ambitious Replication network, which will involve authentication. Full database downloads via HTTP are used by ITRs and QSDs when they boot up, or to refresh their copy of each database if there is corruption. Method of performing short term MH and TE changes ------------------------------------------------- LISP-NERD/CONS: The mapping database (really multiple databases) gives instructions to ITRs, which detect failures and make moment-to-moment decisions regarding TE and changes to which ETR for multihoming. This leads to a complex database, to complex communications, complex ITR and ETR functions and to greater difficulty securing these communications against attacks. eFIT-APT: Similar in principle to LISP in that the mapping database is not involved in the dynamic responses, and the ITRs etc. have to work it out amongst themselves. ITRs (or rather the ITR functions of TRs, which also have an ETR function) are involved in detecting failure, and send messages to their own Default Mapper. They may also send messages (as an ETR) to the ITR which encapsulated the packet (and although it is not mentioned, that encapsulation might have been done by a Default Mapper in the sender's network, so there is a complex web of potential communications, which will be difficult to make reliable and difficult to secure against attack. Ivip: The Ivip system (Root Update Authority Servers, Replicator system and ITRs (really ITRs and ITRCs/ITFHs which rely on QSDs and perhaps QSCs) are not involved at all in failure detection or any explicit system of TE. Therefore, the database is very simple and more suitable for being fully stored in numerous ITRs and QSDs. The simpler database is also a lot easier to distribute updates for. The Replicator system is the most ambitious part of the system, and aims to get updates to ITRs etc. very quickly. TE and responses to mulithoming outages are done by some external system - the end-user manually, or some automatic system they set up, including perhaps their host or router or some multihoming or mobility monitoring system. So the Ivip system needs to be fast, but it can be conceptually quite simple and involve very defined and more easily secured communications than the other systems. Also, since the control of the mapping is external and not at all encoded into the Ivip system, it is endlessly flexible, simply by the end-user giving their credentials to any software system which controls the mapping the way they want it. ITR function and placement -------------------------- With LISP and Ivip, ETR and ITR functions may often be in the same device. ETR and ITRs always being in the one device is enforced by the current definition of eFIT-APT - but I don't see why the system needs to be so inflexible. The ITR functions in LISP and eFIT-APT must be on ordinary BGP reachable addresses. Ivip ITRs are typically on BGP reachable addresses, but can be on Ivip-mapped addresses. Those on Ivip-mapped addresses would usually be ITRC and ITFH functions in hosts, rather than the full database ITRD with its requirement for a constant feed of updates from typically two Replicators. LISP-NERD/CONS: As noted above, ITRs have complex functions, including making decisions on a packet-by-packet basis for MH service restoration, TE and I think load balancing functions. The ITR may or may not communicate with the ETR, but I think the ITR is always ready to accept ICMP messages as sign it is tunneling the data packets to the wrong address. Since LISP-mapped addresses are not in any prefix which is advertised in BGP, ITRs must be inside or at the border of provider or end-user networks. eFIT-APT: The placement of TRs is specifically limited to the border routers between providers (defined as any organisation such as a provider which offers transit of packets through its network which are not for its directly connected customers) and their non-provider "customer" networks. ITRs have complex communication functions, including detecting failure. However, they only tunnel to one RLOC at any one time - the Default Mappers do the hard work for TE and MH failure restoration - of deciding what the mapping will be for each ITR. Default Mappers also perform ITR functions - usually for packets sent to them by ordinary ITRs which have no mapping data for them. Having the ITR and ETR functions fixed at these routers - Provider Edge routers I think - seems likely to produce a bottleneck and burden these routers with even greater workloads. This may also preclude doing ETR or ITR functions in servers, which may be more cost effective than routers with all the new functionality. Ivip: ITR functions can be in the sending host in routers in customer and provider networks - and can be "anycast ITRs in the core". Core ITRs are typically full ITRDs. ITRCs and ITFHs rely on nearby query servers, of which there are caching and full database types. Packets not encapsulated by an ITRC or ITFH can be left for another ITRC or ultimately an ITRD in the network or in the core to encapsulate. Unless I change Ivip so it uses UDP encapsulation to include the ITR's address, the encapsulation is IP-in-IP, which has less overhead in bytes and processing than UDP. The ITR doesn't choose different addresses to use as the tunnel endpoint - there is only "RLOC" (LISP terminology) address for every "EID" address or prefix. The ITR doesn't respond to ICMP messages, or send messages to anything. A conventional server could probably be programmed to perform reasonable speed (500Mbps or more?) ITRD or ITRC functions. ITR functions can be performed on hosts and routers which use Ivip-mapped addresses - but these can't be behind NAT. ETR function and placement -------------------------- ETRs must always be on BGP-reachable addresses. So there are no ETRs located in networks which themselves have all their addresses mapped by the LISP/eFIT-APT/Ivip system. LISP-NERD/CONS: ETRs are located in the provider network or at its border router, or in the end-user's network or at its border (CE) with the provider network - as long as the address is BGP reachable. I think ETRs have complex communication functions. eFIT-APT: The placement of TRs is specifically limited to the border routers between providers and their non-provider "customer" networks. ETRs have complex communication functions, including detecting failure of the link to the end-user's host or router. They send messages to their local Default Mapper and to the ITR function of the TR which encapsulated the packet (which can include the Default Mapper of the sender's network). Ivip: ETRs are typically located as per LISP, but there are some exceptions. Firstly, a TTR (Translating Tunnel Router) can be outside the network the end-user's mobile node is connecting with, with a 2-way tunnel from the mobile node. Secondly, a host with a BGP-reachable (care-of) address can perform its own ETR functions. ETRs are not involved in any communication with ITRs or with the database system. They may be involved in failure detection, but that is outside the scope of Ivip. As with the other systems, Ivip ETRs need to know how to get packets to the destination host/router, based on the inner DA. See the discussion on "ETRs checking src & dest addresses" for some simple filtering they do to drop packets where outer DA != inner DA - but this is part of supporting the network's filtering of packets with spoofed local addresses, which is a problem the other proposals have not yet addressed. That discussion also concerns why I think ETRs in any of these schemes need to have an explicit connection (including a tunnel) to the destination host/router, rather than relying on the local routing system to know how to get decapsulated packets to the destination. Incremental deployability ------------------------- LISP-NERD/CONS: According to current definitions and all my off-list attempts to understand LISP, LISP-mapped addresses are not part of BGP advertised prefixes. So in order for a host to send packets to a host on any LISP-mapped address, the sending host must be in a network with an ITR. I think this makes LISP not at all incrementally deployable. Why would an early adopter want to use LISP-mapped addresses when it will make their hosts unreachable for any communication initiated by a host on a non-LISP-upgraded network? eFIT-APT: I am still trying to figure out what the transition plan would be, but maybe it is more incrementally deployable than LISP. Prefixes which are to be subject to mapping are still advertised in BGP and the PE routers (where the TR=ITR+ETR functions are performed) can accept incoming packets both via encapsulation and by the existing, normal, delivery of raw packets. However, it will only be feasible to no longer advertise the prefix in BGP when all, or virtually all (depending on how many sending hosts the end-user doesn't care about) provider networks fully implement eFIT-APT at all their CE routers. This would take years, since it involves expensive new functionality in a lot of routers - probably requiring new routers in many cases. In the meantime, what benefits would there be for end-user networks? They can't gain any portability - unless they accept that hosts in non-upgradeable networks won't be able to send them packets. So this a similar bleak situation to LISP. LISP provides a powerful disincentive to early adopters - unreachability from the all non-upgraded networks. However, to the extent that LISP is introduced, it does incrementally decrease the number of prefixes in the global BGP routing table. With eFIT-APT, there would be no benefit for early adopters (no portability without grave loss of reachability - and TE only for packets from upgraded networks) and no benefit for the whole network (removal of prefixes from the BGP routing table) until virtually all networks had upgraded. One of eFIT-APT's goals is increased security by making provider addresses unreachable from end-user networks. However, assuming full reachability was to be maintained, this could only happen once every provider had fenced off every single end-user network with its eFIT-APT-capable CE routers. Even then, this is a weak form of security, since a single breach in this global fence will enable an end-user network to send packets to any transit provider address, including any ETR (including with spoofed source addresses in the inner and outer headers) - so the target ETR is unable to distinguish this from legitimate packets arriving from other provider network's ITRs and Default Mappers. Ivip: Every prefix assigned to the Ivip system remains advertised in BGP. The idea is that each such prefix be used for more end-user networks, and that in general bigger (shorter) prefixes should be assigned to Ivip and used to serve thousands of end-users. Even with smaller (longer) prefixes, as these are assigned and become contiguous, their mapping should be merged into one RUAS - whereas each smaller (longer) prefix might have had a separate RUAS initially. Hosts on Ivip-mapped addresses are always reachable by hosts from non-upgraded networks, provided there are sufficient "anycast ITRs in the core". As with all proposals, there are major challenges in setting up the infrastructure. Ivip's Replicator and ITR system is adventurous, but the ITRs are doing a simpler job and the overall design is simpler than the designs of other proposals. The ETRs are free-wheeling, low-cost devices and require no coordination. With sufficient provider networks with ETRs, one or more independent Ivip or Ivip-like systems could be set up, and work fine alongside each other (each with their own set of core ITRs, or perhaps all driving data to a common set). These could probably run at a profit, because they provide portability, multihoming (with basic TE) and mobility with full reachability (and generally pretty good path lengths, if the core-ITRs are well distributed) from all hosts. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 17 10:51:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoP4-00075D-Bm; Tue, 17 Jul 2007 10:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoP2-0006zz-V5 for ram@iab.org; Tue, 17 Jul 2007 10:51:52 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAoP0-0002Sd-L8 for ram@iab.org; Tue, 17 Jul 2007 10:51:52 -0400 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 l6HEpi6S016077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Jul 2007 07:51:45 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6HEpiqP011856; Tue, 17 Jul 2007 07:51:44 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6HEpWYn011319; Tue, 17 Jul 2007 07:51:42 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 07:51:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Re: LISP-01 I-D Date: Tue, 17 Jul 2007 07:51:40 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED916@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: LISP-01 I-D Thread-Index: Ace/lsOmvttG/G2fQyK9DQPcLcbcIwI6t03A References: <466FFEB8.9080701@cisco.com> <76EB0C5F-16DF-42FB-ADEC-680AE6E24154@muada.com> <468A4554.5030105@cisco.com><468C7643.6040305@firstpr.com.au><37C01E2C-1F92-4AA1-A247-136EFA203F35@cisco.com><21051657-BA9F-4DEE-9425-1DF772245212@it.uc3m.es> From: "Templin, Fred L" To: "Dino Farinacci" , "marcelo bagnulo braun" X-OriginalArrivalTime: 17 Jul 2007 14:51:40.0556 (UTC) FILETIME=[FBE1BCC0:01C7C881] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org One small point from several days back:=20 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Thursday, July 05, 2007 11:27 PM > To: marcelo bagnulo braun > Cc: ram@iab.org > Subject: Re: [RAM] Re: LISP-01 I-D >=20 > > As i understand it, the new version of LISP described in this 01 =20 > > version of the draft, no longer uses pure IP in IP tunneling, but =20 > > adds a LISP header to the packets (which contains the nonce for =20 > > security reasons) right? >=20 > That is correct. We are using UDP encapsulation with a LISP header =20 > for the following reasons: >=20 > o Get through firewalls I think the UDP encapsulation will also get through NATs, as for other UDP encapsulation schemes like Teredo. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 17 11:02:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoZ7-0004Zz-Jd; Tue, 17 Jul 2007 11:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoZ5-0004Zk-KW for ram@iab.org; Tue, 17 Jul 2007 11:02:15 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAoZ4-0002oZ-Dh for ram@iab.org; Tue, 17 Jul 2007 11:02:15 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6HF22i2009198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Jul 2007 10:02:11 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6HF211f025404; Tue, 17 Jul 2007 08:02:02 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6HF0ExJ020237; Tue, 17 Jul 2007 08:00:17 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 08:00:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Date: Tue, 17 Jul 2007 08:00:14 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED917@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <469C962B.1090600@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Thread-Index: AcfIWyVw6W48iCnrSCCxztzfW7fm1AAJtskQ References: <469C962B.1090600@firstpr.com.au> From: "Templin, Fred L" To: "Robin Whittle" , X-OriginalArrivalTime: 17 Jul 2007 15:00:15.0416 (UTC) FILETIME=[2EC32380:01C7C883] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > So there are now five potential new architectures - all but one > with a push database arrangement: >=20 > LISP-NERD > LISP-CONS (Pull.) > LISP-APT (APT is only intended for eFIT.) > eFIT-APT > Ivip Please also keep IPvLX on your list (http://ipvlx.com). Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 17 13:56:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArHv-0001bN-Pl; Tue, 17 Jul 2007 13:56:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArHu-0001WP-7P for ram@iab.org; Tue, 17 Jul 2007 13:56:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IArHs-0000fx-TD for ram@iab.org; Tue, 17 Jul 2007 13:56:42 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Jul 2007 10:56:40 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMufnEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="183661079:sNHT30843549" 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 l6HHue7G018284 for ; Tue, 17 Jul 2007 10:56:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HHuaA0002593 for ; Tue, 17 Jul 2007 17:56:40 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); Tue, 17 Jul 2007 10:56:35 -0700 Received: from [171.69.132.204] ([171.69.132.204]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 10:56:35 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: RAM Mailing List From: Dino Farinacci Date: Tue, 17 Jul 2007 10:56:28 -0700 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 17 Jul 2007 17:56:35.0557 (UTC) FILETIME=[D1048950:01C7C89B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=450; t=1184695000; x=1185559000; 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:=20New=20LISP=20draft=20available=20... |Sender:=20; bh=03sQaoJMdSkgfmrMRnfrXT2DYBUOGx0th2uOFjSAVmY=; b=WNHWTiVJwIOO27bouDvGlzdOqCtUiuu0RCM/CY0KVjXQ4Bcn8K8WELnTRZKzvA48k2jHt9t1 hJDWP7u1s1PdFr5ulkZvLKki+q45vfWfp4SX824En2UbOJzQrFItBHtN; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [RAM] New LISP draft available ... X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org We have a new LISP-02 draft available. The packet formats are consistent with CONS-01 as well as the implementation we are testing. The draft has been submitted to the ID directory, but you can find a draft at: http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt This version is formatted much better. ;-) This draft also reflects comments from Ved Kafle and Olivier Bonaventure. Thanks, Dino, DaveM, Vince, DaveO _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 18 03:22:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB3rc-0005Y4-Db; Wed, 18 Jul 2007 03:22:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB3ra-0005Xy-TR for ram@iab.org; Wed, 18 Jul 2007 03:22:22 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB3rX-0006Q5-R9 for ram@iab.org; Wed, 18 Jul 2007 03:22:22 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2007 09:22:20 +0200 X-IronPort-AV: i="4.16,549,1175464800"; d="scan'208,217"; a="148325261:sNHT204020442" 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 l6I7MJEm007636; Wed, 18 Jul 2007 09:22:19 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4177.cisco.com [10.61.80.80]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6I7MEkt009223; Wed, 18 Jul 2007 07:22:17 GMT Message-ID: <469DBFA0.7010103@cisco.com> Date: Wed, 18 Jul 2007 09:22:08 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared References: <469C962B.1090600@firstpr.com.au> In-Reply-To: <469C962B.1090600@firstpr.com.au> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=68683; t=1184743339; x=1185607339; 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[RAM]=20LISP=20NERD/CONS, =20eFIT-APT=20&=20Ivip=20com pared |Sender:=20; bh=Rk1DlRbCn/jUq5HzO18uY22KevaEO4a1a1WGQk2XNTI=; b=Zku3JLOsCBDFUTJ2B/qxVp5YAw/+xjDbk/6gAVGuLr3AbUDA75h4A/XEd+0Bd2+nzknJJwog 3BhYhLQl2wlOKc0mwBw8INtGXTgGg9PIXN3ybrTQeRijSFkNSk2d1CYO; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f526f24f459cc7a00934c463cb2f9eb6 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1849698577==" Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --===============1849698577== Content-Type: multipart/alternative; boundary="------------040602020405060500030300" This is a multi-part message in MIME format. --------------040602020405060500030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robin, This is an excellent email that at least demonstrates where our drafts are not clear, if not our own thinking in some cases. I think the basic issue that you are contending with is that many of the ideas contained in many of these documents are evolving. However, you captured a few points very clearly that are worth reiterating now: 1. LISP in its later stages assumes some method to retrieve a mapping from EID to RLOC that does not deal with operational state. This is true for both LISP-CONS and LISP-NERD. In these cases we do indeed assume that the ITRs and ETRs play an active role in determining operational state. The way that happens is evolving, indeed. 2. The difference between a LISP-CONS CAR and a NERD database authority is only in scope. Each is authoritative for a group of mappings. The real question is how many. Taken to one extreme, there is only one CAR and it look a lot like a single NERD database authority for all of the world. Taken to the other extreme, each ETR could play the function of the CAR. Each has some benefits and limitations. 3. You accurately assess that I really didn't care too much precisely HOW the ITR receives a NERD database. In fact my point was that it doesn't really matter all that much because of the nature of the data. As we are talking about a provisioned mapping, the data is relatively static and can be signed in bulk. Once that has occurred, you could use IRC (!!) to distribute it because other sides could test that the information arrived intact. 4. You raise a good point about the speed with which a database update makes it across the network in LISP-NERD. There are two mitigating factors, however. First of all, most updates will be small. The intent is for even hosts that have been down for hours to be able to retrieve incremental updates. Second, again because of the nature of the data, unlike routing data, a smart administrator will remove an advertisement some time before actually disabling an ETR. Unless, there are ETRs which themselves use EIDs, we do not have to worry about one mapping being dependent on another. 5. Finally, you comment about complexity of database in terms of separating operational and provisioned changes. I envision an ITR running a process that retains state about mappings it is using. I would expect a table to contain the RLOC of the ETR, /ifstate/ (e.g., up or down), and a timer. The /ifstate/ implies a next action, such as polling to see if the ETR has returned to service, or when to expect some sort of positive acknowledgement. As I said above, I think this area is evolving. But the key point is that this table is separate from the mapping itself, and only indicates reachability. If an ETR is unreachable or reachable, it is unreachable or reachable for as many mappings as it has. Furthermore, traffic is not redirected to other mappings based on in stream messages, lest we expose ourselves to that same-named class of attack. The rest of your message requires a bit more digestion, but I do appreciate you taking the time to write it. I think it helps quite a bit to advance our thinking. Eliot Robin Whittle wrote: > I started off wanting to discuss what was in common and different > between LISP 3.x and eFIT - however it grew into an attempt to > compare major aspects of the current proposals. > > - Robin http://www.firstpr.com.au/ip/ivip/ > > > > LISP 1.0 and to a limited extent 1.5 is documented in the LISP-01 > I-D: > > http://tools.ietf.org/html/draft-farinacci-lisp > > There is nothing specific there or anywhere else about LISP 3.x - > however it has been stated on the RAM list that 3.x is the most > likely variant to be deployed. 1 and 1.5 are theoretical models > for trying out concepts - but the look very different to me from > 3.x, so I don't know what lessons learnt with them would be > applicable to 3.x. According to Dino's RAM list message 1703 > (July 13), the three mapping distribution systems applicable to > LISP 3.x would be: > > NERD (No data driven Map Reply messages.) > > http://tools.ietf.org/html/draft-lear-lisp-nerd-01 (June 12) > > > CONS (No data driven Map Reply messages.) > > http://tools.ietf.org/html/draft-meyer-lisp-cons-00 (July 3) > > > APT (Perhaps some data driven Map Reply messages.) > > http://tools.ietf.org/html/draft-jen-apt-00 (July 2) > > > APT is designed not for LISP, but for eFIT: > > http://www.cs.ucla.edu/~lixia/papers/07SIG_IP6WS.pdf > > A Scalable Routing System Design for Future Internet > Daniel Massey, Lan Wang, Beichuan Zhang and Lixia Zhang. > July 2007 > > http://tools.ietf.org/html/draft-wang-ietf-efit-00 > > Of the efit-00 I-D, Lixia wrote on this list on 10 July: > > > That one is really outdated. We are working on a new > > version. Will send a pointer before Chicago. > > > So there are now five potential new architectures - all but one > with a push database arrangement: > > LISP-NERD > LISP-CONS (Pull.) > LISP-APT (APT is only intended for eFIT.) > eFIT-APT > Ivip > > All these are in an early stage of development. Ivip is > extensively documented, http://www.firstpr.com.au/ip/ivip/. > > > NERD is a push system in that all ITRs have a copy of each mapping > database for each prefix of LISP-mapped addresses. It has only > modest speed goals. "... updates to the mapping are intended to > be relatively rare". The mapping database is not intended to > change when a link fails or is restored - so the ITRs must somehow > be smart enough to detect loss of reachability to an ETR, and > already have the alternative ETR's address in their database, to > switch to another ETR which is reachable. Since there is no > ITR-to-ITR communication about this as far as I know, I guess each > ITR has to figure out reachability on its own when it tries to > send packets. This is much more complex for the database contents > and for ITR functionality than Ivip - in which an external > monitoring system changes the mapping and the ITRs simply follow > the changes to the mapping, which need to be delivered very quickly. > > While NERD is "push", in comparison to CONS - which is purely a > query and cache system - the mapping updates are not actually sent > to the ITRs. Each ITR has to poll a server and retrieve the > update files. However NERD-01 anticipates ITRs advertising the > update files they have, and downloading these files from > neighbouring ITRs, as an alternative to getting them from > centralised servers. If each update file needs to be fully > downloaded and authenticated before it can be made available for > other ITRs to download, then this will lead to a slow propagation > of these files across the Net. > > Alternative approaches using NNTP, and with ITRs only storing part > of the database with "push" and are also contemplated. (I don't > understand how an ITR would have only part of the database, unless > it has another ITR with the full database to which it would tunnel > the packets it doesn't have mapping for, or a nearby full database > query server like in Ivip or eFIT-APT's Default Mappers.) > > > LISP-CONS is a "pull" system. ITRs query and cache the mapping > data, via local CARs which also cache. Requests and replies > traverse a mesh of CARs and (non-caching) CDR servers, all linked > via authenticated TCP sessions. > > Depending on the caching time, LISP-CONS could work with more > frequent database updates than LISP-NERD, but there is no attempt > to speed things up as with Ivip's Notify (cache invalidation) or > the same concept in eFIT-APT: "updated mapping entry" - which are > real-time, local, push messages directed to the caching ITRs (and > for Ivip, the caching Query Servers) which they query. > > eFIT-APT differs from LISP and Ivip in a number of respects, > including: > > 1 - ETR and ITR functions are always contained in the same device > (TR) whereas these can be in separate devices for both LISP > and Ivip. These TRs will replace all current Provider Edge > routers - or all PE routers will be upgraded to have these > capabilities. > > 2 - The ITR function is a query and cache system, as with > LISP-CONS and Ivip's ITRC (ITR Cache) and ITFH (Ingress Tunnel > Function in Host), but unlike the full database ITR in > LISP-NERD in in Ivip's ITRD. > > 3 - Each transit network is expected to run at least one "Default > Mapper", which may be router (at least it can encapsulate > packets, even if it only has one interface), and which has a > real-time updated copy of the entire eFIT-APT mapping > database. (Except in the future for IPv6 - section 7.4.) > There is nothing about implementation of Default Mappers in > the I-D, but I think they would best be implemented in a > server, rather than a conventional router with hardware FIB > etc.) > > ITRs send queries to the Default Mapper in their network. > Each query is packet they do not currently have mapping data > for. The Default Mapper encapsulates the packet and forwards > it towards the ETR in the destination network, and then sends > back an ICMP response to the ITR with the mapping information > the ITR needs to handle such a packet in the future. (If a > future packet's DA was part of a prefix with the same mapping > data, then the ITR would then know how to encapsulate it.) > > This aspect of the Default Mapper is analogous to Ivip's QSD > (Query Server with Database) combined with Ivip's ITRD > handling packets which can't immediately be tunneled by an > ITRC or ITFH. > > This will lead to much faster and more reliable query > responses than LISP-CONS - but as with Ivip, raises the > challenging problem of distributing the database updates in > real-time to all these Default Mappers. However, eFIT-APT > has very slow goals regarding the speed of distributing > these updates. > > As with Ivip, there is no delay for packets which cannot be > mapped by an ITR, although APT's Default Mapper or Ivip's > "backup" (maybe I should call it a wicket-keeper . . .) ITR > could be a bottleneck. With Ivip, there could be a chain of > ITRCs leading to a final ITRD. > > 4 - The Default Mappers can be reached by anycast within a > particular provider network. (I don't propose QSDs be > accessed this way, but it is an interesting idea as an > option, provided all queries, responses and Notifications can > be done with UDP. Since Notification involves the QSD > ensuring that the message was received by whichever QSD or > ITRC the QSD sent it to, TCP might be a better approach than > UDP - so anycast QSDs may not be such a good idea.) > > There is no two-way communication when the Default Mapper > sends the ICMP packet with the mapping information to the > ITR. Two-way communication would be tricky with anycast > unless all the Default Mappers had very intimate links > between them, which is to be avoided. However, I guess > non-guaranteed ICMP reply is fine, since if the ITR > doesn't get it, the worst thing that can happen is that > the ITR will send the next data packet to the Default Mapper > as well. > > Default Mappers also have the equivalent of an Ivip "Notify": > "M1 can respond with an updated mapping entry". There's > no mention of the ITR having to acknowledge this - and even > if it did, if anycast is used, it would be difficult to ensure > that the ack would go to the correct Default Mapper. Both > Ivip and APT should have a way of ensuring the updated mapping > information really has been received by the ITR (APT) or QSC, > ITRC or ITFH (Ivip) it was sent to. > > 5 - The ITR function of APT TRs does not make any decisions > regarding which of multiple ETRs to tunnel to in a multihoming > scenario. Each ITR is told to tunnel packets which match a > particular EID prefix to a single RLOC location: a single ETR. > > (However, see the next point about the ETR function performing > various functions and sending messages back to an ITR.) > > This *greatly* simplifies the FIB work of the ITRs - and > reduces the size and complexity of the mapping information > they cache. In this respect, the ITR function of an APT TR > somewhat resembles an Ivip ITRC. However, unlike an Ivip > ITRC, and APT ITR is required to detect unreachability of > the tunnel endpoint - the ETR's address. It can do this via > the ETR's address being unreachable, or via an ICMP > Destination Unreachable message, or some other ICMP message > for the third kind of failure (5.1.3). (I am not convinced > there would always be an ICMP Destination Unreachable message > if there was no host at the address where the ITR (ITR > function of a TR) is supposed to be.) In any of these cases > the ITR sends the next packet intended for this ETR to the > Default Mapper instead, and it is the Default Mapper which > makes the difficult decisions, including by tunneling > the packet to an alternative ETR (assuming it is reachable > via BGP) and waiting to see if there are any ICMP messages > in response. > > I think the way the APT system responds to ICMP messages, at > least the "Destination Unreachable" messages - which would not > have any nonce from any APT data packet header (no header > details are currently available) - makes it an easy target for > spoofed ICMP messages for a DoS attack. > > Devolving the multihoming link selection problem, and the TE > functions, to the Default Mapper is a good idea, I think, but > involves more ICMP packets to ITRs with "updated mapping > entry" information. As noted above, I don't see any provision > in APT for this to be delivered in a reliable manner. There > also needs to be some crypto or protection against an attacker > spoofing packets with the Default Mapper's address, to ensure > the ITR's cache is not corrupted by someone who wants to steer > packets to their own address. > > The ITR function of TRs are also required to forward any ICMP > messages they receive to their Default Mapper - which will use > these to decide which of the various RLOC mappings are for > ETRs which are currently reachable. Again, all these > communications need to be secured in some way against spoofed > packets from an attacker. (This is acknowledged in sect. 7.) > > 6 - 5.1.3 states that an ETR which can't reach the destination > host or router will send the packet to its Default Mapper, > (which has some complex rules about not sending it back to > the same ETR) as well as sending an ICMP message back to > the ITR in the sender's network which tunnelled the packet > in the first place. (Actually, the packet could have been > tunneled by the Default Mapper in the sender's network too.) > > > Here are some questions about each scheme, with "LISP" implying > LISP 3.x. There is no concrete information about LISP 3.x other > than that implied by NERD and CONS that I won't consider how LISP > might work with APT. > > > Encapsulation of data > --------------------- > > LISP-NERD/CONS: Not documented yet, but presumably using UDP, with > the outer source address being that of the ITR which encapsulated > the packet. (Outer SA = ITR's address.) See the recent messages > "ETRs checking src & dest addresses" about how I think this makes > it harder for the ETR's filtering system to protect against > spoofing of local source addresses. > > eFIT-APT: Not documented, but APT mentions an ICMP Destination > Unreachable message being generated if the encapsulated packet > does not reach an ETR, so I guess this means UDP encapsulation > with outer SA = ITR (or Default Mapper) address, similar to that > described in LISP-01's description of LISP 1 / 1.5. > > Ivip: Currently defined as IP-in-IP with outer SA = inner SA, to > help with the filtering. However, it could be changed to UDP with > the ITR's address in the payload, with outer SA = inner SA, to > enable unwelcome packets to be traced back to the ITR which > encapsulated them. > > > Source of mapping data > ---------------------- > > LISP-NERD: A hopefully small number of database authorities. No > particular relationship to any provider network, as far as I know. > Various other approaches are considered too. This seems to be > different from what I call the "Bring-your-own address space" > model of LISP-CONS and maybe eFIT-APT. > > LISP-CONS: CAR servers are authoritative. These are distributed > around the Net and there are two or more in some redundant > arrangement - though it is not clear from the current I-D how a > CDR decides to forward a query to two or more redundant CARs, or > whether both replies are sent back through the CDR mesh to the CAR > which made the query. I guess the CARs are related to provider > networks and the various LISP-mapped blocks of address space are > controlled by various providers. > > eFIT-APT: Provider networks have one or more Default Mappers, > which in addition to many other functions, are the authoritative > source of mapping information for a set of prefixes which are > currently BGP advertised by that provider (but won't be at some > time in the future). So as with LISP-CONS, it seems the system of > address management of mapped address space which is dependent on > existing provider networks. > > If an end user is with provider X, using some of their PA > addresses, could they go to another provider Y for connectivity, > or X and Y or Y and Z for multihoming, and still have to rely on X > to to the mapping the way they want? > > What if an AS-end-user with their own PI space is currently > connecting with provider X. If they want to move to provider Y, > does this means that X's Default Mapper no longer is > authoritative, and that Y's is? I am confused about exactly how > eFIT-APT works. > > Ivip: Multiple independent Root Update Authorisation Systems > devolve responsibility to other systems and then to end-users. > Updates are funneled in real-time to a Replication system which > fans it out to ITRs and QSDs all over the Net. So the address > space management, mapping changes etc. is not tied to any provider > organisation or to provider devices or networks. I think > LISP-NERD's organisational aims may be similar. > > > Speed and method of update propagation > -------------------------------------- > > LISP-NERD: Slow. ITRs are "full database" and download files from > each database authority. The ITRs then poll for changes. > "Updates to the mapping will be relatively rare" and "are not > intended to change when a link either fails or is restored". So > TE and multihoming service restoration are performed by the ITRs > and ETRs, rather than via changes to the mapping database. I > guess times of tens of minutes to hours, depending on how busy the > ITR is about polling for changes. In principle, it can be quite > fast, but that requires a huge burden of polling traffic. > > LISP-CONS: Faster than LISP-NERD. All communications via a meshed > TCP-linked CDR network - queries go along it and responses come > back along it, rather than the responses going straight from the > authoritative CAR to the querying CAR. (I understand this is > because the meshed network is secure and all the TCP sessions are > already running.) ITRs are query and cache devices, via CARs > which also cache and which are also typically authoritative for > some part of the mapping database. EID-to-RLOC mappings "are > assumed to change at low frequency". As with LISP-NERD, TE and > multihoming service restoration are performed by the ITRs and > ETRs, rather than via changes to the mapping database. > > eFIT-APT: Very slow indeed. Default Mappers in each provider > network are authoritative, and push their data to other Default > Mappers via BGP. Full database push and occasional update push > techniques are used. "Transient failures do not cause mapping > announcements in APT." "Permanent mapping changes are unlikely to > occur more than once per month per customer." > > Ivip: As fast as possible - maybe a few seconds from the end-user > changing their mapping to all ITRs following the new mapping. > "Notify" messages from QSDs to ITRCs and ITFHs. This requires an > ambitious Replication network, which will involve authentication. > Full database downloads via HTTP are used by ITRs and QSDs when > they boot up, or to refresh their copy of each database if there > is corruption. > > > Method of performing short term MH and TE changes > ------------------------------------------------- > > LISP-NERD/CONS: The mapping database (really multiple databases) > gives instructions to ITRs, which detect failures and make > moment-to-moment decisions regarding TE and changes to which ETR > for multihoming. This leads to a complex database, to complex > communications, complex ITR and ETR functions and to greater > difficulty securing these communications against attacks. > > eFIT-APT: Similar in principle to LISP in that the mapping > database is not involved in the dynamic responses, and the ITRs > etc. have to work it out amongst themselves. ITRs (or rather the > ITR functions of TRs, which also have an ETR function) are > involved in detecting failure, and send messages to their own > Default Mapper. They may also send messages (as an ETR) to the > ITR which encapsulated the packet (and although it is not > mentioned, that encapsulation might have been done by a Default > Mapper in the sender's network, so there is a complex web of > potential communications, which will be difficult to make reliable > and difficult to secure against attack. > > Ivip: The Ivip system (Root Update Authority Servers, Replicator > system and ITRs (really ITRs and ITRCs/ITFHs which rely on QSDs > and perhaps QSCs) are not involved at all in failure detection or > any explicit system of TE. Therefore, the database is very simple > and more suitable for being fully stored in numerous ITRs and > QSDs. The simpler database is also a lot easier to distribute > updates for. The Replicator system is the most ambitious part of > the system, and aims to get updates to ITRs etc. very quickly. > > TE and responses to mulithoming outages are done by some external > system - the end-user manually, or some automatic system they set > up, including perhaps their host or router or some multihoming or > mobility monitoring system. So the Ivip system needs to be fast, > but it can be conceptually quite simple and involve very defined > and more easily secured communications than the other systems. > Also, since the control of the mapping is external and not at all > encoded into the Ivip system, it is endlessly flexible, simply by > the end-user giving their credentials to any software system which > controls the mapping the way they want it. > > > ITR function and placement > -------------------------- > > With LISP and Ivip, ETR and ITR functions may often be in the same > device. ETR and ITRs always being in the one device is enforced > by the current definition of eFIT-APT - but I don't see why the > system needs to be so inflexible. The ITR functions in LISP and > eFIT-APT must be on ordinary BGP reachable addresses. Ivip ITRs > are typically on BGP reachable addresses, but can be on > Ivip-mapped addresses. Those on Ivip-mapped addresses would > usually be ITRC and ITFH functions in hosts, rather than the full > database ITRD with its requirement for a constant feed of updates > from typically two Replicators. > > LISP-NERD/CONS: As noted above, ITRs have complex functions, > including making decisions on a packet-by-packet basis for MH > service restoration, TE and I think load balancing functions. The > ITR may or may not communicate with the ETR, but I think the ITR > is always ready to accept ICMP messages as sign it is tunneling > the data packets to the wrong address. > > Since LISP-mapped addresses are not in any prefix which is > advertised in BGP, ITRs must be inside or at the border of > provider or end-user networks. > > eFIT-APT: The placement of TRs is specifically limited to the > border routers between providers (defined as any organisation such > as a provider which offers transit of packets through its network > which are not for its directly connected customers) and their > non-provider "customer" networks. ITRs have complex communication > functions, including detecting failure. However, they only tunnel > to one RLOC at any one time - the Default Mappers do the hard work > for TE and MH failure restoration - of deciding what the mapping > will be for each ITR. Default Mappers also perform ITR functions > - usually for packets sent to them by ordinary ITRs which have no > mapping data for them. Having the ITR and ETR functions fixed at > these routers - Provider Edge routers I think - seems likely to > produce a bottleneck and burden these routers with even greater > workloads. This may also preclude doing ETR or ITR functions in > servers, which may be more cost effective than routers with all > the new functionality. > > Ivip: ITR functions can be in the sending host in routers in > customer and provider networks - and can be "anycast ITRs in the > core". Core ITRs are typically full ITRDs. ITRCs and ITFHs rely > on nearby query servers, of which there are caching and full > database types. Packets not encapsulated by an ITRC or ITFH can > be left for another ITRC or ultimately an ITRD in the network or > in the core to encapsulate. > > Unless I change Ivip so it uses UDP encapsulation to include the > ITR's address, the encapsulation is IP-in-IP, which has less > overhead in bytes and processing than UDP. The ITR doesn't choose > different addresses to use as the tunnel endpoint - there is only > "RLOC" (LISP terminology) address for every "EID" address or prefix. > > The ITR doesn't respond to ICMP messages, or send messages to > anything. A conventional server could probably be programmed to > perform reasonable speed (500Mbps or more?) ITRD or ITRC > functions. ITR functions can be performed on hosts and routers > which use Ivip-mapped addresses - but these can't be behind NAT. > > > ETR function and placement > -------------------------- > > ETRs must always be on BGP-reachable addresses. So there are no > ETRs located in networks which themselves have all their addresses > mapped by the LISP/eFIT-APT/Ivip system. > > LISP-NERD/CONS: ETRs are located in the provider network or at its > border router, or in the end-user's network or at its border (CE) > with the provider network - as long as the address is BGP > reachable. I think ETRs have complex communication functions. > > eFIT-APT: The placement of TRs is specifically limited to the > border routers between providers and their non-provider "customer" > networks. ETRs have complex communication functions, including > detecting failure of the link to the end-user's host or router. > They send messages to their local Default Mapper and to the ITR > function of the TR which encapsulated the packet (which can > include the Default Mapper of the sender's network). > > Ivip: ETRs are typically located as per LISP, but there are some > exceptions. Firstly, a TTR (Translating Tunnel Router) can be > outside the network the end-user's mobile node is connecting with, > with a 2-way tunnel from the mobile node. Secondly, a host with a > BGP-reachable (care-of) address can perform its own ETR functions. > > ETRs are not involved in any communication with ITRs or with the > database system. They may be involved in failure detection, but > that is outside the scope of Ivip. As with the other systems, > Ivip ETRs need to know how to get packets to the destination > host/router, based on the inner DA. See the discussion on "ETRs > checking src & dest addresses" for some simple filtering they do > to drop packets where outer DA != inner DA - but this is part of > supporting the network's filtering of packets with spoofed local > addresses, which is a problem the other proposals have not yet > addressed. That discussion also concerns why I think ETRs in any > of these schemes need to have an explicit connection (including a > tunnel) to the destination host/router, rather than relying on the > local routing system to know how to get decapsulated packets to > the destination. > > > Incremental deployability > ------------------------- > > LISP-NERD/CONS: According to current definitions and all my > off-list attempts to understand LISP, LISP-mapped addresses are > not part of BGP advertised prefixes. So in order for a host to > send packets to a host on any LISP-mapped address, the sending > host must be in a network with an ITR. I think this makes LISP > not at all incrementally deployable. Why would an early adopter > want to use LISP-mapped addresses when it will make their hosts > unreachable for any communication initiated by a host on a > non-LISP-upgraded network? > > > eFIT-APT: I am still trying to figure out what the transition plan > would be, but maybe it is more incrementally deployable than LISP. > > Prefixes which are to be subject to mapping are still advertised > in BGP and the PE routers (where the TR=ITR+ETR functions are > performed) can accept incoming packets both via encapsulation and > by the existing, normal, delivery of raw packets. However, it > will only be feasible to no longer advertise the prefix in BGP > when all, or virtually all (depending on how many sending hosts > the end-user doesn't care about) provider networks fully implement > eFIT-APT at all their CE routers. This would take years, since it > involves expensive new functionality in a lot of routers - > probably requiring new routers in many cases. > > In the meantime, what benefits would there be for end-user > networks? They can't gain any portability - unless they accept > that hosts in non-upgradeable networks won't be able to send them > packets. > > So this a similar bleak situation to LISP. LISP provides a > powerful disincentive to early adopters - unreachability from the > all non-upgraded networks. However, to the extent that LISP is > introduced, it does incrementally decrease the number of prefixes > in the global BGP routing table. With eFIT-APT, there would be no > benefit for early adopters (no portability without grave loss of > reachability - and TE only for packets from upgraded networks) and > no benefit for the whole network (removal of prefixes from the BGP > routing table) until virtually all networks had upgraded. > > One of eFIT-APT's goals is increased security by making provider > addresses unreachable from end-user networks. However, assuming > full reachability was to be maintained, this could only happen > once every provider had fenced off every single end-user network > with its eFIT-APT-capable CE routers. Even then, this is a weak > form of security, since a single breach in this global fence will > enable an end-user network to send packets to any transit provider > address, including any ETR (including with spoofed source > addresses in the inner and outer headers) - so the target ETR is > unable to distinguish this from legitimate packets arriving from > other provider network's ITRs and Default Mappers. > > > Ivip: Every prefix assigned to the Ivip system remains advertised > in BGP. The idea is that each such prefix be used for more > end-user networks, and that in general bigger (shorter) prefixes > should be assigned to Ivip and used to serve thousands of > end-users. Even with smaller (longer) prefixes, as these are > assigned and become contiguous, their mapping should be merged > into one RUAS - whereas each smaller (longer) prefix might have > had a separate RUAS initially. Hosts on Ivip-mapped addresses are > always reachable by hosts from non-upgraded networks, provided > there are sufficient "anycast ITRs in the core". > > As with all proposals, there are major challenges in setting up > the infrastructure. Ivip's Replicator and ITR system is > adventurous, but the ITRs are doing a simpler job and the overall > design is simpler than the designs of other proposals. The ETRs > are free-wheeling, low-cost devices and require no coordination. > With sufficient provider networks with ETRs, one or more > independent Ivip or Ivip-like systems could be set up, and work > fine alongside each other (each with their own set of core ITRs, > or perhaps all driving data to a common set). These could > probably run at a profit, because they provide portability, > multihoming (with basic TE) and mobility with full reachability > (and generally pretty good path lengths, if the core-ITRs are well > distributed) from all hosts. > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > > --------------040602020405060500030300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Robin,

This is an excellent email that at least demonstrates where our drafts are not clear, if not our own thinking in some cases.  I think the basic issue that you are contending with is that many of the ideas contained in many of these documents are evolving.  However, you captured a few points very clearly that are worth reiterating now:

  1. LISP in its later stages assumes some method to retrieve a mapping from EID to RLOC that does not deal with operational state.  This is true for both LISP-CONS and LISP-NERD.  In these cases we do indeed assume that the ITRs and ETRs play an active role in determining operational state.  The way that happens is evolving, indeed.
  2. The difference between a LISP-CONS CAR and a NERD database authority is only in scope.  Each is authoritative for a group of mappings.  The real question is how many.  Taken to one extreme, there is only one CAR and it look a lot like a single NERD database authority for all of the world.  Taken to the other extreme, each ETR could play the function of the CAR.  Each has some benefits and limitations.
  3. You accurately assess that I really didn't care too much precisely HOW the ITR receives a NERD database.  In fact my point was that it doesn't really matter all that much because of the nature of the data.  As we are talking about a provisioned mapping, the data is relatively static and can be signed in bulk.  Once that has occurred, you could use IRC (!!) to distribute it because other sides could test that the information arrived intact.
  4. You raise a good point about the speed with which a database update makes it across the network in LISP-NERD.  There are two mitigating factors, however.  First of all, most updates will be small.  The intent is for even hosts that have been down for hours to be able to retrieve incremental updates.  Second, again because of the nature of the data, unlike routing data, a smart administrator will remove an advertisement some time before actually disabling an ETR.  Unless, there are ETRs which themselves use EIDs, we do not have to worry about one mapping being dependent on another.
  5. Finally, you comment about complexity of database in terms of separating operational and provisioned changes.  I envision an ITR running a process that retains state about mappings it is using.  I would expect a table to contain the RLOC of the ETR, ifstate (e.g., up or down), and a timer.  The ifstate implies a next action, such as polling to see if the ETR has returned to service, or when to expect some sort of positive acknowledgement.  As I said above, I think this area is evolving.  But the key point is that this table is separate from the mapping itself, and only indicates reachability.  If an ETR is unreachable or reachable, it is unreachable or reachable for as many mappings as it has.  Furthermore, traffic is not redirected to other mappings based on in stream messages, lest we expose ourselves to that same-named class of attack.

The rest of your message requires a bit more digestion, but I do appreciate you taking the time to write it.  I think it helps quite a bit to advance our thinking.

Eliot


Robin Whittle wrote: 
I started off wanting to discuss what was in common and different
between LISP 3.x and eFIT - however it grew into an attempt to
compare major aspects of the current proposals.

  - Robin      http://www.firstpr.com.au/ip/ivip/



LISP 1.0 and to a limited extent 1.5 is documented in the LISP-01
I-D:

  http://tools.ietf.org/html/draft-farinacci-lisp

There is nothing specific there or anywhere else about LISP 3.x -
however it has been stated on the RAM list that 3.x is the most
likely variant to be deployed.  1 and 1.5 are theoretical models
for trying out concepts - but the look very different to me from
3.x, so I don't know what lessons learnt with them would be
applicable to 3.x.  According to Dino's RAM list message 1703
(July 13), the three mapping distribution systems applicable to
LISP 3.x would be:

NERD   (No data driven Map Reply messages.)

  http://tools.ietf.org/html/draft-lear-lisp-nerd-01 (June 12)


CONS   (No data driven Map Reply messages.)

  http://tools.ietf.org/html/draft-meyer-lisp-cons-00 (July 3)


APT    (Perhaps some data driven Map Reply messages.)

  http://tools.ietf.org/html/draft-jen-apt-00 (July 2)


APT is designed not for LISP, but for eFIT:

  http://www.cs.ucla.edu/~lixia/papers/07SIG_IP6WS.pdf

    A Scalable Routing System Design for Future Internet
    Daniel Massey, Lan Wang, Beichuan Zhang and Lixia Zhang.
    July 2007

  http://tools.ietf.org/html/draft-wang-ietf-efit-00

    Of the efit-00 I-D, Lixia wrote on this list on 10 July:

    > That one is really outdated.  We are working on a new
    >  version.  Will send a pointer before Chicago.


So there are now five potential new architectures - all but one
with a push database arrangement:

LISP-NERD
LISP-CONS  (Pull.)
LISP-APT   (APT is only intended for eFIT.)
eFIT-APT
Ivip

All these are in an early stage of development. Ivip is
extensively documented, http://www.firstpr.com.au/ip/ivip/.


NERD is a push system in that all ITRs have a copy of each mapping
database for each prefix of LISP-mapped addresses.  It has only
modest speed goals.  "... updates to the mapping are intended to
be relatively rare".  The mapping database is not intended to
change when a link fails or is restored - so the ITRs must somehow
be smart enough to detect loss of reachability to an ETR, and
already have the alternative ETR's address in their database, to
switch to another ETR which is reachable.  Since there is no
ITR-to-ITR communication about this as far as I know, I guess each
ITR has to figure out reachability on its own when it tries to
send packets.  This is much more complex for the database contents
and for ITR functionality than Ivip - in which an external
monitoring system changes the mapping and the ITRs simply follow
the changes to the mapping, which need to be delivered very quickly.

While NERD is "push", in comparison to CONS - which is purely a
query and cache system - the mapping updates are not actually sent
to the ITRs.  Each ITR has to poll a server and retrieve the
update files.  However NERD-01 anticipates ITRs advertising the
update files they have, and downloading these files from
neighbouring ITRs, as an alternative to getting them from
centralised servers.  If each update file needs to be fully
downloaded and authenticated before it can be made available for
other ITRs to download, then this will lead to a slow propagation
of these files across the Net.

Alternative approaches using NNTP, and with ITRs only storing part
of the database with "push" and are also contemplated.  (I don't
understand how an ITR would have only part of the database, unless
it has another ITR with the full database to which it would tunnel
the packets it doesn't have mapping for, or a nearby full database
query server like in Ivip or eFIT-APT's Default Mappers.)


LISP-CONS is a "pull" system.  ITRs query and cache the mapping
data, via local CARs which also cache.  Requests and replies
traverse a mesh of CARs and (non-caching) CDR servers, all linked
via authenticated TCP sessions.

Depending on the caching time, LISP-CONS could work with more
frequent database updates than LISP-NERD, but there is no attempt
to speed things up as with Ivip's Notify (cache invalidation) or
the same concept in eFIT-APT: "updated mapping entry" - which are
real-time, local, push messages directed to the caching ITRs (and
for Ivip, the caching Query Servers) which they query.

eFIT-APT differs from LISP and Ivip in a number of respects,
including:

1 - ETR and ITR functions are always contained in the same device
    (TR) whereas these can be in separate devices for both LISP
    and Ivip.  These TRs will replace all current Provider Edge
    routers - or all PE routers will be upgraded to have these
    capabilities.

2 - The ITR function is a query and cache system, as with
    LISP-CONS and Ivip's ITRC (ITR Cache) and ITFH (Ingress Tunnel
    Function in Host), but unlike the full database ITR in
    LISP-NERD in in Ivip's ITRD.

3 - Each transit network is expected to run at least one "Default
    Mapper", which may be router (at least it can encapsulate
    packets, even if it only has one interface), and which has a
    real-time updated copy of the entire eFIT-APT mapping
    database.  (Except in the future for IPv6 - section 7.4.)
    There is nothing about implementation of Default Mappers in
    the I-D, but I think they would best be implemented in a
    server, rather than a conventional router with hardware FIB
    etc.)

    ITRs send queries to the Default Mapper in their network.
    Each query is packet they do not currently have mapping data
    for.  The Default Mapper encapsulates the packet and forwards
    it towards the ETR in the destination network, and then sends
    back an ICMP response to the ITR with the mapping information
    the ITR needs to handle such a packet in the future.  (If a
    future packet's DA was part of a prefix with the same mapping
    data, then the ITR would then know how to encapsulate it.)

    This aspect of the Default Mapper is analogous to Ivip's QSD
    (Query Server with Database) combined with Ivip's ITRD
    handling packets which can't immediately be tunneled by an
    ITRC or ITFH.

    This will lead to much faster and more reliable query
    responses than LISP-CONS - but as with Ivip, raises the
    challenging problem of distributing the database updates in
    real-time to all these Default Mappers.  However, eFIT-APT
    has very slow goals regarding the speed of distributing
    these updates.

    As with Ivip, there is no delay for packets which cannot be
    mapped by an ITR, although APT's Default Mapper or Ivip's
    "backup" (maybe I should call it a wicket-keeper . . .) ITR
    could be a bottleneck.  With Ivip, there could be a chain of
    ITRCs leading to a final ITRD.

4 - The Default Mappers can be reached by anycast within a
    particular provider network.  (I don't propose QSDs be
    accessed this way, but it is an interesting idea as an
    option, provided all queries, responses and Notifications can
    be done with UDP.  Since Notification involves the QSD
    ensuring that the message was received by whichever QSD or
    ITRC the QSD sent it to, TCP might be a better approach than
    UDP - so anycast QSDs may not be such a good idea.)

    There is no two-way communication when the Default Mapper
    sends the ICMP packet with the mapping information to the
    ITR.  Two-way communication would be tricky with anycast
    unless all the Default Mappers had very intimate links
    between them, which is to be avoided.  However, I guess
    non-guaranteed ICMP reply is fine, since if the ITR
    doesn't get it, the worst thing that can happen is that
    the ITR will send the next data packet to the Default Mapper
    as well.

    Default Mappers also have the equivalent of an Ivip "Notify":
    "M1 can respond with an updated mapping entry".  There's
    no mention of the ITR having to acknowledge this - and even
    if it did, if anycast is used, it would be difficult to ensure
    that the ack would go to the correct Default Mapper.  Both
    Ivip and APT should have a way of ensuring the updated mapping
    information really has been received by the ITR (APT) or QSC,
    ITRC or ITFH (Ivip) it was sent to.

5 - The ITR function of APT TRs does not make any decisions
    regarding which of multiple ETRs to tunnel to in a multihoming
    scenario.  Each ITR is told to tunnel packets which match a
    particular EID prefix to a single RLOC location: a single ETR.

    (However, see the next point about the ETR function performing
    various functions and sending messages back to an ITR.)

    This *greatly* simplifies the FIB work of the ITRs - and
    reduces the size and complexity of the mapping information
    they cache.  In this respect, the ITR function of an APT TR
    somewhat resembles an Ivip ITRC.  However, unlike an Ivip
    ITRC, and APT ITR is required to detect unreachability of
    the tunnel endpoint - the ETR's address.  It can do this via
    the ETR's address being unreachable, or via an ICMP
    Destination Unreachable message, or some other ICMP message
    for the third kind of failure (5.1.3).  (I am not convinced
    there would always be an ICMP Destination Unreachable message
    if there was no host at the address where the ITR (ITR
    function of a TR) is supposed to be.)  In any of these cases
    the ITR sends the next packet intended for this ETR to the
    Default Mapper instead, and it is the Default Mapper which
    makes the difficult decisions, including by tunneling
    the packet to an alternative ETR (assuming it is reachable
    via BGP) and waiting to see if there are any ICMP messages
    in response.

    I think the way the APT system responds to ICMP messages, at
    least the "Destination Unreachable" messages - which would not
    have any nonce from any APT data packet header (no header
    details are currently available) - makes it an easy target for
    spoofed ICMP messages for a DoS attack.

    Devolving the multihoming link selection problem, and the TE
    functions, to the Default Mapper is a good idea, I think, but
    involves more ICMP packets to ITRs with "updated mapping
    entry" information.  As noted above, I don't see any provision
    in APT for this to be delivered in a reliable manner.  There
    also needs to be some crypto or protection against an attacker
    spoofing packets with the Default Mapper's address, to ensure
    the ITR's cache is not corrupted by someone who wants to steer
    packets to their own address.

    The ITR function of TRs are also required to forward any ICMP
    messages they receive to their Default Mapper - which will use
    these to decide which of the various RLOC mappings are for
    ETRs which are currently reachable.  Again, all these
    communications need to be secured in some way against spoofed
    packets from an attacker.  (This is acknowledged in sect. 7.)

6 - 5.1.3 states that an ETR which can't reach the destination
    host or router will send the packet to its Default Mapper,
    (which has some complex rules about not sending it back to
    the same ETR) as well as sending an ICMP message back to
    the ITR in the sender's network which tunnelled the packet
    in the first place. (Actually, the packet could have been
    tunneled by the Default Mapper in the sender's network too.)


Here are some questions about each scheme, with "LISP" implying
LISP 3.x.  There is no concrete information about LISP 3.x other
than that implied by NERD and CONS that I won't consider how LISP
might work with APT.


Encapsulation of data
---------------------

LISP-NERD/CONS: Not documented yet, but presumably using UDP, with
the outer source address being that of the ITR which encapsulated
the packet. (Outer SA = ITR's address.)  See the recent messages
"ETRs checking src & dest addresses" about how I think this makes
it harder for the ETR's filtering system to protect against
spoofing of local source addresses.

eFIT-APT: Not documented, but APT mentions an ICMP Destination
Unreachable message being generated if the encapsulated packet
does not reach an ETR, so I guess this means UDP encapsulation
with outer SA = ITR (or Default Mapper) address, similar to that
described in LISP-01's description of LISP 1 / 1.5.

Ivip: Currently defined as IP-in-IP with outer SA = inner SA, to
help with the filtering.  However, it could be changed to UDP with
the ITR's address in the payload, with outer SA = inner SA, to
enable unwelcome packets to be traced back to the ITR which
encapsulated them.


Source of mapping data
----------------------

LISP-NERD: A hopefully small number of database authorities.  No
particular relationship to any provider network, as far as I know.
 Various other approaches are considered too.  This seems to be
different from what I call the "Bring-your-own address space"
model of LISP-CONS and maybe eFIT-APT.

LISP-CONS: CAR servers are authoritative.  These are distributed
around the Net and there are two or more in some redundant
arrangement - though it is not clear from the current I-D how a
CDR decides to forward a query to two or more redundant CARs, or
whether both replies are sent back through the CDR mesh to the CAR
which made the query.  I guess the CARs are related to provider
networks and the various LISP-mapped blocks of address space are
controlled by various providers.

eFIT-APT: Provider networks have one or more Default Mappers,
which in addition to many other functions, are the authoritative
source of mapping information for a set of prefixes which are
currently BGP advertised by that provider (but won't be at some
time in the future).  So as with LISP-CONS, it seems the system of
address management of mapped address space which is dependent on
existing provider networks.

If an end user is with provider X, using some of their PA
addresses, could they go to another provider Y for connectivity,
or X and Y or Y and Z for multihoming, and still have to rely on X
to to the mapping the way they want?

What if an AS-end-user with their own PI space is currently
connecting with provider X.  If they want to move to provider Y,
does this means that X's Default Mapper no longer is
authoritative, and that Y's is?  I am confused about exactly how
eFIT-APT works.

Ivip: Multiple independent Root Update Authorisation Systems
devolve responsibility to other systems and then to end-users.
Updates are funneled in real-time to a Replication system which
fans it out to ITRs and QSDs all over the Net.  So the address
space management, mapping changes etc. is not tied to any provider
organisation or to provider devices or networks.  I think
LISP-NERD's organisational aims may be similar.


Speed and method of update propagation
--------------------------------------

LISP-NERD: Slow.  ITRs are "full database" and download files from
each database authority.  The ITRs then poll for changes.
"Updates to the mapping will be relatively rare" and "are not
intended to change when a link either fails or is restored".  So
TE and multihoming service restoration are performed by the ITRs
and ETRs, rather than via changes to the mapping database.  I
guess times of tens of minutes to hours, depending on how busy the
ITR is about polling for changes.  In principle, it can be quite
fast, but that requires a huge burden of polling traffic.

LISP-CONS: Faster than LISP-NERD. All communications via a meshed
TCP-linked CDR network - queries go along it and responses come
back along it, rather than the responses going straight from the
authoritative CAR to the querying CAR.  (I understand this is
because the meshed network is secure and all the TCP sessions are
already running.)  ITRs are query and cache devices, via CARs
which also cache and which are also typically authoritative for
some part of the mapping database.  EID-to-RLOC mappings "are
assumed to change at low frequency".  As with LISP-NERD, TE and
multihoming service restoration are performed by the ITRs and
ETRs, rather than via changes to the mapping database.

eFIT-APT: Very slow indeed.  Default Mappers in each provider
network are authoritative, and push their data to other Default
Mappers via BGP.  Full database push and occasional update push
techniques are used.  "Transient failures do not cause mapping
announcements in APT."  "Permanent mapping changes are unlikely to
occur more than once per month per customer."

Ivip: As fast as possible - maybe a few seconds from the end-user
changing their mapping to all ITRs following the new mapping.
"Notify" messages from QSDs to ITRCs and ITFHs.  This requires an
ambitious Replication network, which will involve authentication.
 Full database downloads via HTTP are used by ITRs and QSDs when
they boot up, or to refresh their copy of each database if there
is corruption.


Method of performing short term MH and TE changes
-------------------------------------------------

LISP-NERD/CONS: The mapping database (really multiple databases)
gives instructions to ITRs, which detect failures and make
moment-to-moment decisions regarding TE and changes to which ETR
for multihoming.  This leads to a complex database, to complex
communications, complex ITR and ETR functions and to greater
difficulty securing these communications against attacks.

eFIT-APT: Similar in principle to LISP in that the mapping
database is not involved in the dynamic responses, and the ITRs
etc. have to work it out amongst themselves.  ITRs (or rather the
ITR functions of TRs, which also have an ETR function) are
involved in detecting failure, and send messages to their own
Default Mapper.  They may also send messages (as an ETR) to the
ITR which encapsulated the packet (and although it is not
mentioned, that encapsulation might have been done by a Default
Mapper in the sender's network, so there is a complex web of
potential communications, which will be difficult to make reliable
and difficult to secure against attack.

Ivip: The Ivip system (Root Update Authority Servers, Replicator
system and ITRs (really ITRs and ITRCs/ITFHs which rely on QSDs
and perhaps QSCs) are not involved at all in failure detection or
any explicit system of TE.  Therefore, the database is very simple
and more suitable for being fully stored in numerous ITRs and
QSDs.  The simpler database is also a lot easier to distribute
updates for.  The Replicator system is the most ambitious part of
the system, and aims to get updates to ITRs etc. very quickly.

TE and responses to mulithoming outages are done by some external
system - the end-user manually, or some automatic system they set
up, including perhaps their host or router or some multihoming or
mobility monitoring system.  So the Ivip system needs to be fast,
but it can be conceptually quite simple and involve very defined
and more easily secured communications than the other systems.
Also, since the control of the mapping is external and not at all
encoded into the Ivip system, it is endlessly flexible, simply by
the end-user giving their credentials to any software system which
controls the mapping the way they want it.


ITR function and placement
--------------------------

With LISP and Ivip, ETR and ITR functions may often be in the same
device.  ETR and ITRs always being in the one device is enforced
by the current definition of eFIT-APT - but I don't see why the
system needs to be so inflexible.  The ITR functions in LISP and
eFIT-APT must be on ordinary BGP reachable addresses.  Ivip ITRs
are typically on BGP reachable addresses, but can be on
Ivip-mapped addresses.  Those on Ivip-mapped addresses would
usually be ITRC and ITFH functions in hosts, rather than the full
database ITRD with its requirement for a constant feed of updates
from typically two Replicators.

LISP-NERD/CONS:  As noted above, ITRs have complex functions,
including making decisions on a packet-by-packet basis for MH
service restoration, TE and I think load balancing functions.  The
ITR may or may not communicate with the ETR, but I think the ITR
is always ready to accept ICMP messages as sign it is tunneling
the data packets to the wrong address.

Since LISP-mapped addresses are not in any prefix which is
advertised in BGP, ITRs must be inside or at the border of
provider or end-user networks.

eFIT-APT: The placement of TRs is specifically limited to the
border routers between providers (defined as any organisation such
as a provider which offers transit of packets through its network
which are not for its directly connected customers) and their
non-provider "customer" networks.  ITRs have complex communication
functions, including detecting failure.  However, they only tunnel
to one RLOC at any one time - the Default Mappers do the hard work
for TE and MH failure restoration - of deciding what the mapping
will be for each ITR.  Default Mappers also perform ITR functions
- usually for packets sent to them by ordinary ITRs which have no
mapping data for them.  Having the ITR and ETR functions fixed at
these routers - Provider Edge routers I think - seems likely to
produce a bottleneck and burden these routers with even greater
workloads.  This may also preclude doing ETR or ITR functions in
servers, which may be more cost effective than routers with all
the new functionality.

Ivip:  ITR functions can be in the sending host in routers in
customer and provider networks - and can be "anycast ITRs in the
core".  Core ITRs are typically full ITRDs.  ITRCs and ITFHs rely
on nearby query servers, of which there are caching and full
database types.  Packets not encapsulated by an ITRC or ITFH can
be left for another ITRC or ultimately an ITRD in the network or
in the core to encapsulate.

Unless I change Ivip so it uses UDP encapsulation to include the
ITR's address, the encapsulation is IP-in-IP, which has less
overhead in bytes and processing than UDP.  The ITR doesn't choose
different addresses to use as the tunnel endpoint - there is only
"RLOC" (LISP terminology) address for every "EID" address or prefix.

The ITR doesn't respond to ICMP messages, or send messages to
anything.  A conventional server could probably be programmed to
perform reasonable speed (500Mbps or more?) ITRD or ITRC
functions.   ITR functions can be performed on hosts and routers
which use Ivip-mapped addresses - but these can't be behind NAT.


ETR function and placement
--------------------------

ETRs must always be on BGP-reachable addresses.  So there are no
ETRs located in networks which themselves have all their addresses
mapped by the LISP/eFIT-APT/Ivip system.

LISP-NERD/CONS: ETRs are located in the provider network or at its
border router, or in the end-user's network or at its border (CE)
with the provider network - as long as the address is BGP
reachable.  I think ETRs have complex communication functions.

eFIT-APT: The placement of TRs is specifically limited to the
border routers between providers and their non-provider "customer"
networks.  ETRs have complex communication functions, including
detecting failure of the link to the end-user's host or router.
They send messages to their local Default Mapper and to the ITR
function of the TR which encapsulated the packet (which can
include the Default Mapper of the sender's network).

Ivip:  ETRs are typically located as per LISP, but there are some
exceptions.  Firstly, a TTR (Translating Tunnel Router) can be
outside the network the end-user's mobile node is connecting with,
with a 2-way tunnel from the mobile node.  Secondly, a host with a
BGP-reachable (care-of) address can perform its own ETR functions.

ETRs are not involved in any communication with ITRs or with the
database system.  They may be involved in failure detection, but
that is outside the scope of Ivip.  As with the other systems,
Ivip ETRs need to know how to get packets to the destination
host/router, based on the inner DA.  See the discussion on "ETRs
checking src & dest addresses" for some simple filtering they do
to drop packets where outer DA != inner DA - but this is part of
supporting the network's filtering of packets with spoofed local
addresses, which is a problem the other proposals have not yet
addressed.  That discussion also concerns why I think ETRs in any
of these schemes need to have an explicit connection (including a
tunnel) to the destination host/router, rather than relying on the
local routing system to know how to get decapsulated packets to
the destination.


Incremental deployability
-------------------------

LISP-NERD/CONS: According to current definitions and all my
off-list attempts to understand LISP, LISP-mapped addresses are
not part of BGP advertised prefixes.  So in order for a host to
send packets to a host on any LISP-mapped address, the sending
host must be in a network with an ITR.  I think this makes LISP
not at all incrementally deployable.  Why would an early adopter
want to use LISP-mapped addresses when it will make their hosts
unreachable for any communication initiated by a host on a
non-LISP-upgraded network?


eFIT-APT: I am still trying to figure out what the transition plan
would be, but maybe it is more incrementally deployable than LISP.

Prefixes which are to be subject to mapping are still advertised
in BGP and the PE routers (where the TR=ITR+ETR functions are
performed) can accept incoming packets both via encapsulation and
by the existing, normal, delivery of raw packets.  However, it
will only be feasible to no longer advertise the prefix in BGP
when all, or virtually all (depending on how many sending hosts
the end-user doesn't care about) provider networks fully implement
eFIT-APT at all their CE routers.  This would take years, since it
involves expensive new functionality in a lot of routers -
probably requiring new routers in many cases.

In the meantime, what benefits would there be for end-user
networks?  They can't gain any portability - unless they accept
that hosts in non-upgradeable networks won't be able to send them
packets.

So this a similar bleak situation to LISP.  LISP provides a
powerful disincentive to early adopters - unreachability from the
all non-upgraded networks.  However, to the extent that LISP is
introduced, it does incrementally decrease the number of prefixes
in the global BGP routing table.  With eFIT-APT, there would be no
benefit for early adopters (no portability without grave loss of
reachability - and TE only for packets from upgraded networks) and
no benefit for the whole network (removal of prefixes from the BGP
routing table) until virtually all networks had upgraded.

One of eFIT-APT's goals is increased security by making provider
addresses unreachable from end-user networks.  However, assuming
full reachability was to be maintained, this could only happen
once every provider had fenced off every single end-user network
with its eFIT-APT-capable CE routers.  Even then, this is a weak
form of security, since a single breach in this global fence will
enable an end-user network to send packets to any transit provider
address, including any ETR (including with spoofed source
addresses in the inner and outer headers) - so the target ETR is
unable to distinguish this from legitimate packets arriving from
other provider network's ITRs and Default Mappers.


Ivip: Every prefix assigned to the Ivip system remains advertised
in BGP.  The idea is that each such prefix be used for more
end-user networks, and that in general bigger (shorter) prefixes
should be assigned to Ivip and used to serve thousands of
end-users.  Even with smaller (longer) prefixes, as these are
assigned and become contiguous, their mapping should be merged
into one RUAS - whereas each smaller (longer) prefix might have
had a separate RUAS initially.  Hosts on Ivip-mapped addresses are
always reachable by hosts from non-upgraded networks, provided
there are sufficient "anycast ITRs in the core".

As with all proposals, there are major challenges in setting up
the infrastructure.  Ivip's Replicator and ITR system is
adventurous, but the ITRs are doing a simpler job and the overall
design is simpler than the designs of other proposals.  The ETRs
are free-wheeling, low-cost devices and require no coordination.
With sufficient provider networks with ETRs, one or more
independent Ivip or Ivip-like systems could be set up, and work
fine alongside each other (each with their own set of core ITRs,
or perhaps all driving data to a common set).  These could
probably run at a profit, because they provide portability,
multihoming (with basic TE) and mobility with full reachability
(and generally pretty good path lengths, if the core-ITRs are well
distributed) from all hosts.




_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram

--------------040602020405060500030300-- --===============1849698577== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1849698577==-- From ram-bounces@iab.org Wed Jul 18 06:30:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB6n9-0006u8-Jx; Wed, 18 Jul 2007 06:29:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB6n2-0006tp-UZ for ram@iab.org; Wed, 18 Jul 2007 06:29:53 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB6n0-00049i-TP for ram@iab.org; Wed, 18 Jul 2007 06:29:52 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 4280F59E3C; Wed, 18 Jul 2007 20:29:49 +1000 (EST) Message-ID: <469DEB91.1000805@firstpr.com.au> Date: Wed, 18 Jul 2007 20:29:37 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared References: <469C962B.1090600@firstpr.com.au> <469DBFA0.7010103@cisco.com> In-Reply-To: <469DBFA0.7010103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "Templin, Fred L" X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Fred and Eliot, Fred, I didn't try to compare IPvLX (http://ipvlx.com) with the others because I think it is very different from these. Firstly, I understand that IPvLX requires changes in host software. Secondly, it involves IPv6, although as best I understand it I think you want it to help with IPv4 communications, and doesn't actually require IPv6 connectivity. Thirdly, I don't understand it anywhere near enough to evaluate it. The first point is the most important to me. As long as a proposal to solve what I call the "crisis in routing and addressing" involves changes to host software, I am convinced it will never actually be deployed. I am am wrong about any of this, please correct me. Thanks, Eliot, for your appreciative response and for clarifying some points about the state maintained in a LISP-NERD ITR. I understand that "ifstate" and the timer will exist for every RLOC address the ITR has recently been attempting to send packets to, and that the database could have one or more likely many EID addresses and prefixes mapped to this RLOC address. I re-read the proposals and got enough of the material in my brain at once to be able to compare them. There may well be inadequacies in what I wrote. I have a version of the comparison at: http://www.firstpr.com.au/ip/ivip/comp/ with a note about how the proposals will no-doubt change rapidly. I won't try to keep this comparison up-to-date forever, but if there are any things I should change I will do so. I point to this mailing list discussion from that page. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 18 11:13:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBDe-0002DX-5f; Wed, 18 Jul 2007 11:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBDZ-0002D7-Cz for ram@iab.org; Wed, 18 Jul 2007 11:13:33 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBBDY-0003ml-3Y for ram@iab.org; Wed, 18 Jul 2007 11:13:33 -0400 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 l6IFDKcl021092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Jul 2007 08:13:20 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6IFDKKT023854; Wed, 18 Jul 2007 08:13:20 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6IFDFXg023702; Wed, 18 Jul 2007 08:13:20 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 08:13:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Date: Wed, 18 Jul 2007 08:13:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED91C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <469DEB91.1000805@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Thread-Index: AcfJJpNstuBmMKBSTDuvhfo51w1qRQAJCuAQ References: <469C962B.1090600@firstpr.com.au> <469DBFA0.7010103@cisco.com> <469DEB91.1000805@firstpr.com.au> From: "Templin, Fred L" To: "Robin Whittle" , X-OriginalArrivalTime: 18 Jul 2007 15:13:18.0371 (UTC) FILETIME=[2BDA5730:01C7C94E] X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Robin, Thanks for looking. Just as clarification, IPvLX does not require changes to host software; it requires changes to router software. If the host and router occur on the same physical platform (which is *not* a requirement), then it may appear that host software changes are needed - but, it is really only router software that is being changed. About similarities to other proposals, I think if there were to be a LISP 2 it would probably look a lot like IPvLX. But, there is no reason IPvLX can't be extended to support other mapping mechanisms than just DNS, too. About IPv6, IPvLX accomplishes the ID/loc split by using IPv6 addresses as EIDs and IPv4 addresses as RLOCs. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Robin Whittle [mailto:rw@firstpr.com.au]=20 > Sent: Wednesday, July 18, 2007 3:30 AM > To: ram@iab.org > Cc: Eliot Lear; Templin, Fred L > Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared >=20 > Hi Fred and Eliot, >=20 > Fred, I didn't try to compare IPvLX (http://ipvlx.com) with the > others because I think it is very different from these. Firstly, > I understand that IPvLX requires changes in host software. > Secondly, it involves IPv6, although as best I understand it I > think you want it to help with IPv4 communications, and doesn't > actually require IPv6 connectivity. Thirdly, I don't understand > it anywhere near enough to evaluate it. >=20 > The first point is the most important to me. As long as a > proposal to solve what I call the "crisis in routing and > addressing" involves changes to host software, I am convinced it > will never actually be deployed. I am am wrong about any of this, > please correct me. >=20 >=20 > Thanks, Eliot, for your appreciative response and for clarifying > some points about the state maintained in a LISP-NERD ITR. I > understand that "ifstate" and the timer will exist for every RLOC > address the ITR has recently been attempting to send packets to, > and that the database could have one or more likely many EID > addresses and prefixes mapped to this RLOC address. >=20 > I re-read the proposals and got enough of the material in my brain > at once to be able to compare them. There may well be > inadequacies in what I wrote. I have a version of the comparison at: >=20 > http://www.firstpr.com.au/ip/ivip/comp/ >=20 > with a note about how the proposals will no-doubt change rapidly. > I won't try to keep this comparison up-to-date forever, but if > there are any things I should change I will do so. I point to > this mailing list discussion from that page. >=20 > - Robin >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 18 18:43:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIEm-00079A-3Y; Wed, 18 Jul 2007 18:43:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIEk-00072b-BU for ram@iab.org; Wed, 18 Jul 2007 18:43:14 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBIEd-0000G1-UF for ram@iab.org; Wed, 18 Jul 2007 18:43:14 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 96A7259DE9; Thu, 19 Jul 2007 08:43:02 +1000 (EST) Message-ID: <469E976A.5060804@firstpr.com.au> Date: Thu, 19 Jul 2007 08:42:50 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared References: <469C962B.1090600@firstpr.com.au> <469DBFA0.7010103@cisco.com> <469DEB91.1000805@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1029ED91C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED91C@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: "Templin, Fred L" X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Fred, Thanks for clarifying my understanding of IPvLX to some extent. I still don't have anything like a clear enough understanding of it to compare it with the other schemes. Is IPvLX intended to help with IPv4 in respect of multihoming, portability, TE, splitting up existing space into finer and more flexibly used sections for more users and/or with reduction in BPG advertisements and/or churn in IPv4? If not, then as with Six/One, I don't think IPvLX helps with the most pressing problems of the foreseeable future - and so is not comparable to LISP, eFIT-APT or Ivip. If your proposal does help with IPv4 communications, with non-upgraded hosts - for instance resulting in immediate or long-term reduction in the size of the global BGP routing table, and/or in improvements to multihoming, portability or TE then it would be great if you could explain on the list exactly how this works, with network diagrams, examples of deployment etc. Can IPv4 hosts on non-upgraded networks send packets to IPv4 hosts on upgraded networks? If not, then I think IPvLX suffers from the same problem as LISP-NERD or LISP-CONS - and so is not incrementally deployable because early adopters (really any adopters until adoption is universal) suffer loss of reachability Early adopters suffer the worst costs or barriers, since hosts in virtually no other networks will be able to reach their hosts. Although there is no detailed documentation of how eFIT-APT could be incrementally deployed (at least in terms of reachability and what is and is not advertised in BGP), I imagined a way it could be done while retaining reachability from non-upgraded networks. However, this defers the reduction in the size of the BPG routing table until either all networks are upgraded, or until enough of them are that some upgraded networks don't mind about not being reachable from those networks which are not - and so stop advertising their prefixes in BPG. How does IPvLX handle the requirement that a multihoming system short-term changes to traffic flow? I think service restoration for a multihomed link is an example of what Eliot called "operational state"? This is an important aspect of architectural goals in which Ivip differs completely from LISP or eFIT-APT. LISP-NERD/CONS and eFIT-APT all have slow-changing databases which carry instructions for the ITR-ETR system on how to cope with short-term traffic flow requirements, such as loss of reachability on one link, requiring packets to be tunneled to another ETR in order to restore communications. The short-term decisions are made by the ITR-ETR and the mapping data does not change at all during multihoming service restoration. This means a more complex database and *much* more complex ITR-ETR functionality, with much more communication between ITRs, ETRs and in some cases recipients of tunneled packets which are not ETRs which are ready to handle the packets. This introduces a much greater burden of complexity in order to adequately protect against attacks and other security problems. In short, LISP-NERD/CONS and eFIT-APT all card-code short-term behavior into the system itself, and make it configurable to some extent by parameters in the mapping database. Also, LISP-NERD/CONS and eFIT-APT do not attempt to assist with mobile-IP - because their database distribution systems are too slow with a mobile host's requirement that traffic flow to one ETR or another in the different networks it has connections with. Ivip is completely different. The database is simple and intended to be very rapidly changed. Ivip does not attempt any reachability testing or require its ITRs or ETRs to make any decisions, such as for TE, multihoming service restoration or for mobility. This means Ivip can be used to support with mobile IP just as it supports multihoming restoration, portability, finer splitting of the address space among many more end-users etc. - without actually containing any special database information or ITR functions to support these separate applications. Ivip more closely follows what I think is a common IETF philosophy: single function, open-ended, building blocks which can be used in combination with other building blocks to solve a wide variety of problems, without having to create a monolithic system for each particular problem. (I don't know of a formal statement of this, but it is evident from the whole nature of TCP/IP design, DNS, HTTP etc.) Assuming IPvLX helps with ordinary IPv4 communications, it would be great if you could explain on this list how IPvLX would be deployed: Give a fully detailed example of the BGP or other benefits it brings to IPv4, and of how IPv4 packets flow in both directions between hosts in firstly two upgraded networks and secondly in one upgraded and one non-upgraded network. Describe the possible placement of upgraded or new routers. Describe the new features which are required in routers and how feasible these are to implement in the FIBs of current routers, with firmware upgrades. The rest has to be done in the main CPU. In both cases, it is important to discuss the communications, CPU and memory requirements of these new features for a reasonably widely deployed scenario. Also, in the long-term future, can scaling be achieved by parallel routers, servers etc. rather than having to ramp up performance of routers which can't have their load split amongst others. (eFIT-APT seems to suffer here, because all the ITR and ETR work has to be done in Customer Edge routers of provider networks.) Examples of packets which are used in IPv4 host communications and separate examples for IPv6. What other servers, databases, distribution systems etc. are required. Then, ideally, you could write something about IPvLX for each of the underlines headings in my comparison. I would link to your message in the list or perhaps splice this into my page: http://www.firstpr.com.au/ip/ivip/comp/ - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 08:22:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBV19-0001p8-0w; Thu, 19 Jul 2007 08:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBV18-0001on-2M for ram@iab.org; Thu, 19 Jul 2007 08:22:02 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBV15-0004H0-LF for ram@iab.org; Thu, 19 Jul 2007 08:22:02 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 8648259E3D; Thu, 19 Jul 2007 22:21:55 +1000 (EST) Message-ID: <469F5757.9040700@firstpr.com.au> Date: Thu, 19 Jul 2007 22:21:43 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [RAM] IPv6 /32 to /48 prefixes and Tree-Bitmap FIB speed X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org If someone can help me with a few questions, I would really appreciate it. One concerns IPv6 BGP practice and the other how Tree-Bitmap FIBs work with long prefixes. When I look at the table "Root Prefix Length Distributions": http://bgp.potaroo.net/v6/as1221/ (not the first table which precedes it "Prefix Length Distributions") I see a bunch of prefix lengths which I assume are those advertised globally: /19 2 ... /32 617 /33 4 /34 1 /35 18 /48 60 Is there some formal or informal agreement not to accept advertisements for prefixes longer than /48? I know there is such a rule for IPv4 (/24) but am not sure if it is formalised anywhere. If so, then when an end-user gets a /48 of PI space, as per ARIN or AfriNIC policies: http://www.arin.net/policy/nrpm.html#six58 http://www.afrinic.net/Registration/afsup-ipv6pi-assignments.htm I guess this means they can't split this prefix, for instance for load balancing in a multihomed situation or for using with two offices in different cities or countries which use different providers. This would mean the end-user needs a separate /48 for each physical office in a different city or country. Can someone confirm this? I also want to confirm or improve my understanding of how ASIC-based FIBs (rather than those which use TCAM) actually cope with classifying packets which match really long rules. I understand that the CRS-1 uses the Tree Bitmap algorithm: http://www.firstpr.com.au/ip/sram-ip-forwarding/#Vargese_CRS_1 I have the final 2004 paper if anyone wants a copy. In this paper, the hardware reference design deals with the most significant 8 bits of address in an on-chip RAM lookup table (actually a 12 bit index). Then the rest of the address bits are processed 6 at a time (stride of 6, in Figure 12). I recognise that the actual CRS-1 algorithm may differ somewhat from this, but still, it seems that to match a packet against a /32 rule will probably take 4 external memory reads. For instance ignore the first 3 bits which are always 001, then use an internal RAM table for the next 11 bits and then the last 18 bits as a 3 * 6 bit stride. For a /48 rule, it seems that with a 6 bit stride, the number of memory accesses goes up to 7 or so. This is a really ugly amount of DRAM cycles to classify each packet passing through a transit router. Maybe on-chip caches could help, but I can't imagine how. I find it impossible to think happily of such cumbersome techniques, but as far as I know, strides beyond 6 bits have various problems. Even if the stride was 12 bits, it would still be 3 or 4 memory accesses per packet. Is the future really this grim? TCAMs are fast but power-hungry and a can of worms in other respects, such as worst-case update time. The fact that Juniper and Cisco use trie-based techniques indicates that TCAMs can't do the job - but these trie-based approaches seem to be so slow. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 08:49:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVS4-0007tp-R3; Thu, 19 Jul 2007 08:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVS4-0007rx-7j for ram@iab.org; Thu, 19 Jul 2007 08:49:52 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBVS3-0005XF-5C for ram@iab.org; Thu, 19 Jul 2007 08:49:52 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id C6F14140C1CA; Thu, 19 Jul 2007 14:49:49 +0200 (CEST) Message-ID: <469F5DE7.5050703@spaghetti.zurich.ibm.com> Date: Thu, 19 Jul 2007 13:49:43 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] IPv6 /32 to /48 prefixes and Tree-Bitmap FIB speed References: <469F5757.9040700@firstpr.com.au> In-Reply-To: <469F5757.9040700@firstpr.com.au> X-Enigmail-Version: 0.95.2 OpenPGP: id=333E7C23 X-Spam-Score: -0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1578233504==" Errors-To: ram-bounces@iab.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1578233504== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB8DF27057A5F8E5C14F3EE27" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB8DF27057A5F8E5C14F3EE27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Robin Whittle wrote: [..] > Is there some formal or informal agreement not to accept > advertisements for prefixes longer than /48? I know > there is such a rule for IPv4 (/24) but am not sure if it is > formalised anywhere. Yes there is. In general a /48 is seen as 'the smallest chunk of globally routeable address space'. Most ISP's and transits follow Gert Doerings filter recommendations: http://www.space.net/~gert/RIPE/ipv6-filters.html I suggest that in addition to the above excellent site, take a peek at http://www.sixxs.net/tools/grh/ as that has a somewhat more complete view of the IPv6 DFZ getting quite a few feeds from global providers. It also has a few other tools that give you different abilities. Oh and not to forget of course that RIPE has the great RIS system (http://ris.ripe.net) which gives yet another view on all of this. Depending on what you are looking for, one of those 3 tools can provide you with the angle you need. GRH shows that there are even /64's being announced successfully, though they don't reach to all ISP's. > If so, then when an end-user gets a /48 of PI space, as per ARIN > or AfriNIC policies: >=20 > http://www.arin.net/policy/nrpm.html#six58 > http://www.afrinic.net/Registration/afsup-ipv6pi-assignments.htm >=20 > I guess this means they can't split this prefix, for instance for > load balancing in a multihomed situation or for using with two > offices in different cities or countries which use different > providers. They indeed can't as it will be filtered. The whole idea of IPv6 is aggregation after all. This is indeed unfortunate as when one wants to do anycast, as for a few hosts one ends up abusing a /48. The other problem is indeed when you have a couple of offices or if you have a number of hosting sites, each needs it's own /48. > This would mean the end-user needs a separate /48 for > each physical office in a different city or country. Can someone > confirm this? Separately physical offices are in effect sites, so that is not an issue at least RIR wise, but one will have to justify that to the RIR. The issue though are the RIR policies and the force that is applied to it. Traffic Engineering, BGP and IPv6 in one sentence with a 'small DFZ' doesn't work unfortunately and this is currently also one of the deployment problems for IPv6. All the policies are made for ISP's, even the ARIN PI ones. They expect 1 prefix to be put into a routing slot in the DFZ, but in effect if you have a /32 you will want to break that up and not get all the traffic to your main site and then have to reroute it to another site. With a /32 or up you can break it into /48s most of the time though and with a /20 you can add a lot of /32's with ease as those will never be filtered. The RIR game thus seems to be to get a huge prefix as then you can split it, or go RIR shopping and get one or multiple prefixes from every RIR (See GRH's DFP pages on that and you will soon spot who is doing that :). For Traffic Engineering and other purposes we really will either have to:= - simply accept that there will be lot of /48's and /64's in the DFZ or: - really quickly come up with an ID/LOC solution that is deployed globally. Greets, Jeroen --------------enigB8DF27057A5F8E5C14F3EE27 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkafXecuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I8O3AJ9CZElQ6jL/bTYkTalqjwi1e0Vy 6gCfUgFuJCNwp8ldSFgIseZ5qWOOi9s= =Zkk/ -----END PGP SIGNATURE----- --------------enigB8DF27057A5F8E5C14F3EE27-- --===============1578233504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1578233504==-- From ram-bounces@iab.org Thu Jul 19 10:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBX5b-0007ze-0H; Thu, 19 Jul 2007 10:34:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBX5Z-0007zU-N8 for ram@iab.org; Thu, 19 Jul 2007 10:34:45 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBX5V-0008Oc-MK for ram@iab.org; Thu, 19 Jul 2007 10:34:45 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id CC52E59E3D; Fri, 20 Jul 2007 00:34:39 +1000 (EST) Message-ID: <469F7673.6070702@firstpr.com.au> Date: Fri, 20 Jul 2007 00:34:27 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [RAM] Tunneling overheads and fragmentation X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Can anyone help me understand the likely problems with tunneling packets and what MTU limits might be exceeded if LISP, eFIT-APT or Ivip is used with IPv4? I understand that fragmentation in IPv4 is very much to be avoided. I understand that in IPv6, each host is supposed to explore how long it can make the packets without getting error messages from some router en-route whose length limit is exceeded. eFIT-APT tunnel endpoints are always within provider networks. With LISP the ETRs and ITRs are also probably in provider networks. With Ivip, ITRs could be in the end-user network, including an ITFH function in the sending host. What sort of limits are there likely to be with the maximum length of IP packets on any of these routes. For instance, if all provider and transit routers happily handle packets significantly longer than whatever hosts normally produce (say 1500 bytes) then adding the encapsulation won't lead to any fragmentation. Is this a reasonable assumption? What about routers in end-user networks, or CE routers of providers? I could imagine some trouble if the main TCP/IP stack of a host produced a packet which was at the maximum length which could be handled by its DSL modem (and the NAT function of that modem/router) but that if an additional item of software in the host added an Ivip header to it, then there would be problems. Likewise if the NAT function in the host had an ITFH function which caused packets to get longer before they actually traversed the "modem" link and went to whatever router was at the other end of it, which might have an MTU limit which then gets exceeded. Perhaps a NAT device with such a function would send out different DHCP responses with smaller MTU and MSS so the hosts would generally be making packets which were suitable for being encapsulated. In Mobile IP, how do mobile nodes handle the extra length of the packets they tunnel to their home agent? Does the additional mobile IP software in the host operating system somehow change the MTU and MSS of the layer above it which is preparing packets, not knowing they are to be further encapsulated? - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 11:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYIY-0001L7-Kx; Thu, 19 Jul 2007 11:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYIX-0001Ih-5t for ram@iab.org; Thu, 19 Jul 2007 11:52:13 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBYIV-0002Gt-UB for ram@iab.org; Thu, 19 Jul 2007 11:52:13 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6JFq1Rx007967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jul 2007 08:52:09 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6JFq1r3024992; Thu, 19 Jul 2007 08:52:01 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6JFppAX024535; Thu, 19 Jul 2007 08:51:53 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:51:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Tunneling overheads and fragmentation Date: Thu, 19 Jul 2007 08:51:51 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED923@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <469F7673.6070702@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Tunneling overheads and fragmentation Thread-Index: AcfKEfkUQzGoWhzSTP6njcVAkts22gAChTxw References: <469F7673.6070702@firstpr.com.au> From: "Templin, Fred L" To: "Robin Whittle" , X-OriginalArrivalTime: 19 Jul 2007 15:51:52.0155 (UTC) FILETIME=[B96382B0:01C7CA1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin, This may not address all of your questions, but here is something that may help with IPv6-in-IPv4 tunnel MTUs: http://www.ietf.org/internet-drafts/draft-templin-linkadapt-06.txt See also RFCs 4459 and 4821. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Robin Whittle [mailto:rw@firstpr.com.au]=20 > Sent: Thursday, July 19, 2007 7:34 AM > To: ram@iab.org > Subject: [RAM] Tunneling overheads and fragmentation >=20 > Can anyone help me understand the likely problems with tunneling > packets and what MTU limits might be exceeded if LISP, eFIT-APT or > Ivip is used with IPv4? >=20 > I understand that fragmentation in IPv4 is very much to be > avoided. I understand that in IPv6, each host is supposed to > explore how long it can make the packets without getting error > messages from some router en-route whose length limit is exceeded. >=20 >=20 > eFIT-APT tunnel endpoints are always within provider networks. > With LISP the ETRs and ITRs are also probably in provider > networks. With Ivip, ITRs could be in the end-user network, > including an ITFH function in the sending host. >=20 > What sort of limits are there likely to be with the maximum length > of IP packets on any of these routes. >=20 > For instance, if all provider and transit routers happily handle > packets significantly longer than whatever hosts normally produce > (say 1500 bytes) then adding the encapsulation won't lead to any > fragmentation. Is this a reasonable assumption? >=20 > What about routers in end-user networks, or CE routers of providers? >=20 > I could imagine some trouble if the main TCP/IP stack of a host > produced a packet which was at the maximum length which could be > handled by its DSL modem (and the NAT function of that > modem/router) but that if an additional item of software in the > host added an Ivip header to it, then there would be problems. >=20 > Likewise if the NAT function in the host had an ITFH function > which caused packets to get longer before they actually traversed > the "modem" link and went to whatever router was at the other end > of it, which might have an MTU limit which then gets exceeded. > Perhaps a NAT device with such a function would send out different > DHCP responses with smaller MTU and MSS so the hosts would > generally be making packets which were suitable for being > encapsulated. >=20 > In Mobile IP, how do mobile nodes handle the extra length of the > packets they tunnel to their home agent? Does the additional > mobile IP software in the host operating system somehow change the > MTU and MSS of the layer above it which is preparing packets, not > knowing they are to be further encapsulated? >=20 >=20 > - Robin >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 12:01:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYRU-0002JA-1K; Thu, 19 Jul 2007 12:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYRS-0002IY-6K for ram@iab.org; Thu, 19 Jul 2007 12:01:26 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBYRR-0002Uw-Na for ram@iab.org; Thu, 19 Jul 2007 12:01:26 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 260EC1C0112; Thu, 19 Jul 2007 18:01:25 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 21C121C010B; Thu, 19 Jul 2007 18:01:25 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 1497058ECD1; Thu, 19 Jul 2007 18:01:25 +0200 (CEST) Date: Thu, 19 Jul 2007 18:01:25 +0200 From: Stephane Bortzmeyer To: Robin Whittle Message-ID: <20070719160125.GA16217@nic.fr> References: <469F7673.6070702@firstpr.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469F7673.6070702@firstpr.com.au> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@iab.org Subject: [RAM] Re: Tunneling overheads and fragmentation X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Fri, Jul 20, 2007 at 12:34:27AM +1000, Robin Whittle wrote a message of 54 lines which said: > Can anyone help me understand the likely problems with tunneling > packets and what MTU limits might be exceeded if LISP, eFIT-APT or > Ivip is used with IPv4? Executive summary: tunnels create a lot of problems (see the RFC indicated by Fred Templin plus RFC 2923). > For instance, if all provider and transit routers happily handle > packets significantly longer than whatever hosts normally produce > (say 1500 bytes) then adding the encapsulation won't lead to any > fragmentation. Is this a reasonable assumption? I do not think so. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 12:13:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYcr-0006ho-Ha; Thu, 19 Jul 2007 12:13:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYcq-0006hS-4l for ram@iab.org; Thu, 19 Jul 2007 12:13:12 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBYco-0002lW-KV for ram@iab.org; Thu, 19 Jul 2007 12:13:12 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l6JG9wv2053523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jul 2007 18:09:58 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <469F5757.9040700@firstpr.com.au> References: <469F5757.9040700@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] IPv6 /32 to /48 prefixes and Tree-Bitmap FIB speed Date: Thu, 19 Jul 2007 18:11:48 +0200 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 19-jul-2007, at 14:21, Robin Whittle wrote: > If someone can help me with a few questions, I would really > Is there some formal or informal agreement not to accept > advertisements for prefixes longer than /48? There are currently 8 prefixes between /35 and /48 given out (not inclusive), 215 /48 and 6 /64. So I'd say that /48 is the new /24. However, don't forget that you need to carry more specifics internally, which could easily be very large numbers of customer / 56s. I'm assuming internal aggregation will keep the number of /64s in check. > I know > there is such a rule for IPv4 (/24) but am not sure if it is > formalised anywhere. It isn't, and in IPv6 things are still up in the air to a large degree. > I guess this means they can't split this prefix, for instance for > load balancing in a multihomed situation or for using with two > offices in different cities or countries which use different > providers. They'll try, but there's a good chance it won't work well enough to depend on it. > This would mean the end-user needs a separate /48 for > each physical office in a different city or country. Can someone > confirm this? As opposed to which situation? > In this > paper, the hardware reference design deals with the most > significant 8 bits of address in an on-chip RAM lookup table > (actually a 12 bit index). Then the rest of the address bits are > processed 6 at a time (stride of 6, in Figure 12). In IPv4 there is a good distribution over the first 8 bits but in IPv6 there isn't, lots of stuff is still in 2001::/16. I think you need to look at the first 24 bits or so if you want to do the same here. > I recognise that the actual CRS-1 algorithm may differ somewhat > from this, but still, it seems that to match a packet against a > /32 rule will probably take 4 external memory reads. For instance > ignore the first 3 bits which are always 001, then use an internal > RAM table for the next 11 bits and then the last 18 bits as a 3 * > 6 bit stride. Just 6 bits? > I find it impossible to think happily of such cumbersome > techniques, but as far as I know, strides beyond 6 bits have > various problems. Even if the stride was 12 bits, it would still > be 3 or 4 memory accesses per packet. > Is the future really this grim? TCAMs are fast but power-hungry > and a can of worms in other respects, such as worst-case update > time. The fact that Juniper and Cisco use trie-based techniques > indicates that TCAMs can't do the job - but these trie-based > approaches seem to be so slow. You can shuffle the bits a bit first so you start looking at the important ones and not the ones that are the same for all addresses first. Or do a hash-based system. It would also help to optimize the address assignment policies. For instance, leaving 7 /48s unused between two ones that are used so there is room for growth is really suboptimal here. Being able to see whether an address will match /32 or shorter or whether it will have to match a /48 could also be helpful. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 12:26:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYp8-0008AW-Ok; Thu, 19 Jul 2007 12:25:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYp7-0008AB-St for ram@iab.org; Thu, 19 Jul 2007 12:25:53 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBYp5-00035Q-SV for ram@iab.org; Thu, 19 Jul 2007 12:25:53 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l6JGMbuI053729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jul 2007 18:22:41 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20070719160125.GA16217@nic.fr> References: <469F7673.6070702@firstpr.com.au> <20070719160125.GA16217@nic.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Re: Tunneling overheads and fragmentation Date: Thu, 19 Jul 2007 18:24:28 +0200 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 19-jul-2007, at 18:01, Stephane Bortzmeyer wrote: >> For instance, if all provider and transit routers happily handle >> packets significantly longer than whatever hosts normally produce >> (say 1500 bytes) then adding the encapsulation won't lead to any >> fragmentation. Is this a reasonable assumption? > I do not think so. Agree, if you assume this, you'll get bitten. However, I think it's a reasonable _requirement_. Hosts are connected by ethernet or PPP with an MTU of 1500 (or smaller) in nearly all cases, but it's just ethernet that lives in the 1970s with its 1500 byte MTU but very little gigabit ethernet equipment sold this century can't do jumboframes to some degree. It would also help to raise the internet MTU in general, of course: http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-00.txt _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 12:30:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYtk-0001NF-34; Thu, 19 Jul 2007 12:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYti-0001IB-Rm for ram@iab.org; Thu, 19 Jul 2007 12:30:38 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBYth-0003BI-CO for ram@iab.org; Thu, 19 Jul 2007 12:30:38 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l6JGUXWB017448; Thu, 19 Jul 2007 09:30:33 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l6JGUXDw017447; Thu, 19 Jul 2007 09:30:33 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 19 Jul 2007 09:30:33 -0700 From: David Meyer To: Stephane Bortzmeyer Subject: Re: [RAM] Re: Tunneling overheads and fragmentation Message-ID: <20070719163033.GA17293@1-4-5.net> References: <469F7673.6070702@firstpr.com.au> <20070719160125.GA16217@nic.fr> MIME-Version: 1.0 In-Reply-To: <20070719160125.GA16217@nic.fr> 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 laugh and I cry, and I'm haunted by...Things I never meant nor wished to say" -- Bob Dylan, "When The Deal Goes Down" User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0438555979==" Errors-To: ram-bounces@iab.org --===============0438555979== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 19, 2007 at 06:01:25PM +0200, Stephane Bortzmeyer wrote: > On Fri, Jul 20, 2007 at 12:34:27AM +1000, > Robin Whittle wrote=20 > a message of 54 lines which said: >=20 > > Can anyone help me understand the likely problems with tunneling > > packets and what MTU limits might be exceeded if LISP, eFIT-APT or > > Ivip is used with IPv4? >=20 > Executive summary: tunnels create a lot of problems (see the RFC > indicated by Fred Templin plus RFC 2923). The whole thing with PMTU discovery continues to come up whenever we debate tunneling. We spent a lot of time trying to document that particular issue in RFC 2784 (GRE).=20 > > For instance, if all provider and transit routers happily handle > > packets significantly longer than whatever hosts normally produce > > (say 1500 bytes) then adding the encapsulation won't lead to any > > fragmentation. Is this a reasonable assumption? >=20 > I do not think so. Agreed. As mentioned above, there is also the interaction with PMTU discovery; basically, it can be nontrivial to find the original source of the packet so you can send a=20 a "fragmentation needed and DF set" back to the source. If indeed you can't find the source (multiple encaps or whatever), then the source's packets (those that have the DF bit set, i.e., doing PMTU discovery) get black-holed. Not sure if that was your question, but in any event... Dave --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGn5GpORgD1qCZ2KcRAq/qAJ9GDw8w50Ln2O/juZSIQKXqpp1onQCdHnka VBT48jE5rX9+WKKaf709k4w= =gnSu -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- --===============0438555979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0438555979==-- From ram-bounces@iab.org Thu Jul 19 12:59:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZKz-0006qE-Jm; Thu, 19 Jul 2007 12:58:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZKy-0006pi-7G for ram@iab.org; Thu, 19 Jul 2007 12:58:48 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBZKw-0003t6-VK for ram@iab.org; Thu, 19 Jul 2007 12:58:48 -0400 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 l6JGwZnA008239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jul 2007 11:58:43 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6JGwYtA006033; Thu, 19 Jul 2007 11:58:34 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6JGwP3E005753; Thu, 19 Jul 2007 11:58:34 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:58:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Date: Thu, 19 Jul 2007 09:58:26 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED924@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <469E976A.5060804@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Thread-Index: AcfJjQNW5GmsNngZTKWjEztI4ywVQAAkOimw References: <469C962B.1090600@firstpr.com.au> <469DBFA0.7010103@cisco.com> <469DEB91.1000805@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1029ED91C@XCH-NW-7V2.nw.nos.boeing.com> <469E976A.5060804@firstpr.com.au> From: "Templin, Fred L" To: "Robin Whittle" , X-OriginalArrivalTime: 19 Jul 2007 16:58:27.0046 (UTC) FILETIME=[06878060:01C7CA26] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin - see below:=20 > Thanks for clarifying my understanding of IPvLX to some extent. I > still don't have anything like a clear enough understanding of it > to compare it with the other schemes. >=20 > Is IPvLX intended to help with IPv4 in respect of multihoming, > portability, TE, splitting up existing space into finer and more > flexibly used sections for more users and/or with reduction in > BPG advertisements and/or churn in IPv4? IPvLX anticipates a future in which new growth within sites=20 will be dominated by IPv6 applications and services, and that the IPv4 growth curve will level off. This does not mean that IPv4 applications and services would disappear, but rather that pressures for multihoming, TE, etc. would be taken off the IPv4 DFZ and instead be satisfied by a map-and-encaps scheme that maps potentially many IPv4 RLOCs to the same IPv6 EID. Then, as more applications and services are transitioned to IPv6, IPv4 address space could be reclaimed and redistributed in finer-grained chunks such that more and more of the IPv4 address space is used as RLOCs for a site (and not EIDs). =20 =20 > If not, then as with Six/One, I don't think IPvLX helps with the > most pressing problems of the foreseeable future - and so is not > comparable to LISP, eFIT-APT or Ivip. >=20 > If your proposal does help with IPv4 communications, with > non-upgraded hosts - for instance resulting in immediate or > long-term reduction in the size of the global BGP routing table, > and/or in improvements to multihoming, portability or TE then it > would be great if you could explain on the list exactly how this > works, with network diagrams, examples of deployment etc. IPvLX leaves existing IPv4 communications alone and encourages future growth in IPv6. It also encourages a longer-term trend toward using IPv4 addresses more as RLOCs and less as EIDs. =20 > Can IPv4 hosts on non-upgraded networks send packets to IPv4 hosts > on upgraded networks? If not, then I think IPvLX suffers from the > same problem as LISP-NERD or LISP-CONS - and so is not > incrementally deployable because early adopters (really any > adopters until adoption is universal) suffer loss of reachability > Early adopters suffer the worst costs or barriers, since hosts in > virtually no other networks will be able to reach their hosts. No; there would be no loss of reachability. Non-upgraded networks could communicate with upgraded networks using IPv4 just as they do today. By proof of concept, Microsoft Teredo is beginning to emerge in "upgraded" networks today vis-a-vis Windows Vista deployment yet IPv4 remains fully functional in those networks. IPvLX very closely parallels the Microsoft Teredo model - both in terms of functional behavior and anticipated deployment model. =20 > Although there is no detailed documentation of how eFIT-APT could > be incrementally deployed (at least in terms of reachability and > what is and is not advertised in BGP), I imagined a way it could > be done while retaining reachability from non-upgraded networks. > However, this defers the reduction in the size of the BPG routing > table until either all networks are upgraded, or until enough of > them are that some upgraded networks don't mind about not being > reachable from those networks which are not - and so stop > advertising their prefixes in BPG. >=20 > How does IPvLX handle the requirement that a multihoming system > short-term changes to traffic flow? I think service restoration > for a multihomed link is an example of what Eliot called > "operational state"? This is an important aspect of architectural > goals in which Ivip differs completely from LISP or eFIT-APT. I didn't understand this. > LISP-NERD/CONS and eFIT-APT all have slow-changing databases which > carry instructions for the ITR-ETR system on how to cope with > short-term traffic flow requirements, such as loss of reachability > on one link, requiring packets to be tunneled to another ETR in > order to restore communications. The short-term decisions are > made by the ITR-ETR and the mapping data does not change at all > during multihoming service restoration. This means a more complex > database and *much* more complex ITR-ETR functionality, with much > more communication between ITRs, ETRs and in some cases recipients > of tunneled packets which are not ETRs which are ready to handle > the packets. This introduces a much greater burden of complexity > in order to adequately protect against attacks and other security > problems. >=20 > In short, LISP-NERD/CONS and eFIT-APT all card-code short-term > behavior into the system itself, and make it configurable to some > extent by parameters in the mapping database. >=20 > Also, LISP-NERD/CONS and eFIT-APT do not attempt to assist with > mobile-IP - because their database distribution systems are too > slow with a mobile host's requirement that traffic flow to one ETR > or another in the different networks it has connections with. >=20 > Ivip is completely different. The database is simple and intended > to be very rapidly changed. Ivip does not attempt any > reachability testing or require its ITRs or ETRs to make any > decisions, such as for TE, multihoming service restoration or for > mobility. This means Ivip can be used to support with mobile IP > just as it supports multihoming restoration, portability, finer > splitting of the address space among many more end-users etc. - > without actually containing any special database information or > ITR functions to support these separate applications. >=20 > Ivip more closely follows what I think is a common IETF > philosophy: single function, open-ended, building blocks which can > be used in combination with other building blocks to solve a wide > variety of problems, without having to create a monolithic system > for each particular problem. (I don't know of a formal statement > of this, but it is evident from the whole nature of TCP/IP design, > DNS, HTTP etc.) I don't see any questions regarding IPvLX in this. =20 > Assuming IPvLX helps with ordinary IPv4 communications, it would > be great if you could explain on this list how IPvLX would be > deployed: >=20 > Give a fully detailed example of the BGP or other benefits it > brings to IPv4, The benefits to IPv4 are that it encourages new growth in IPv6 instead of IPv4. > and of how IPv4 packets flow in both > directions between hosts in firstly two upgraded networks and > secondly in one upgraded and one non-upgraded network. IPv4 works no differently between upgraded and non-upgraded networks. > Describe the possible placement of upgraded or new routers. Upgraded or new routers are deployed as site border routers. =20 > Describe the new features which are required in routers and > how feasible these are to implement in the FIBs of current > routers, with firmware upgrades. The rest has to be done > in the main CPU. In both cases, it is important to discuss > the communications, CPU and memory requirements of these new > features for a reasonably widely deployed scenario. Also, > in the long-term future, can scaling be achieved by > parallel routers, servers etc. rather than having to ramp > up performance of routers which can't have their load split > amongst others. (eFIT-APT seems to suffer here, because all > the ITR and ETR work has to be done in Customer Edge routers > of provider networks.) The neew feature for routers is the mapping engine. =20 > Examples of packets which are used in IPv4 host communications > and separate examples for IPv6. IPv4 host communications is done exactly as it is today. IPv6 host communications is done by tunneling IPv6 over IPv4. > What other servers, databases, distribution systems etc. > are required. The current IPvLX proposal assumes a DNS mapping system; future versions could use a different mapping mechanism. =20 > Then, ideally, you could write something about IPvLX for each of > the underlines headings in my comparison. >=20 > I would link to your message in the list or perhaps splice this > into my page: >=20 > http://www.firstpr.com.au/ip/ivip/comp/ >=20 > - Robin Thanks - Fred fred.l.templin@boeing.com=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 13:15:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZb3-0003lj-TK; Thu, 19 Jul 2007 13:15:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZb3-0003ld-AC for ram@iab.org; Thu, 19 Jul 2007 13:15:25 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBZb1-0004JS-Sf for ram@iab.org; Thu, 19 Jul 2007 13:15:25 -0400 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 l6JHFHWY003792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jul 2007 10:15:21 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6JHFHnp001622; Thu, 19 Jul 2007 10:15:17 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6JHFEZE001533; Thu, 19 Jul 2007 10:15:17 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 10:15:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Date: Thu, 19 Jul 2007 10:15:12 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED925@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED924@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Thread-Index: AcfJjQNW5GmsNngZTKWjEztI4ywVQAAkOimwAAKDNjA= References: <469C962B.1090600@firstpr.com.au><469DBFA0.7010103@cisco.com> <469DEB91.1000805@firstpr.com.au><39C363776A4E8C4A94691D2BD9D1C9A1029ED91C@XCH-NW-7V2.nw.nos.boeing.com><469E976A.5060804@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1029ED924@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Robin Whittle" , X-OriginalArrivalTime: 19 Jul 2007 17:15:12.0874 (UTC) FILETIME=[5E0CACA0:01C7CA28] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > and instead be satisfied by a map-and-encaps > scheme that maps potentially many IPv4 RLOCs to the same IPv6 > EID. Sorry, this was poorly phrased; it should have said that *many* IPv6 EIDs are mapped to *a few* IPv4 RLOCs - else, what would be the benefit of transitioning to IPv6? Fred fred.l.templin@boeing.com=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 15:42:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbtX-0002H4-N1; Thu, 19 Jul 2007 15:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbtW-0002Gx-CJ for ram@iab.org; Thu, 19 Jul 2007 15:42:38 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbtU-0000P5-UF for ram@iab.org; Thu, 19 Jul 2007 15:42:38 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 7B6952C020D0E; Thu, 19 Jul 2007 22:42:35 +0300 (EEST) Date: Thu, 19 Jul 2007 22:42:35 +0300 (EEST) From: Wassim Haddad To: Robin Whittle Subject: Re: [RAM] Tunneling overheads and fragmentation In-Reply-To: <469F7673.6070702@firstpr.com.au> Message-ID: References: <469F7673.6070702@firstpr.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Robin, On Fri, 20 Jul 2007, Robin Whittle wrote: > In Mobile IP, how do mobile nodes handle the extra length of the > packets they tunnel to their home agent? Does the additional > mobile IP software in the host operating system somehow change the > MTU and MSS of the layer above it which is preparing packets, not > knowing they are to be further encapsulated? => There is an ongoing work specific (as for now) to Mobile IP, which removes the tunnel from the bidirectional mode and the overhead from the route optimization. Please check: draft-haddad-mip6-tunneling-optimization-01 Regards, Wassim H. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 21:13:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBh3v-0008Gv-85; Thu, 19 Jul 2007 21:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBh3t-0008Gq-AR for ram@iab.org; Thu, 19 Jul 2007 21:13:41 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBh3r-0008NT-1p for ram@iab.org; Thu, 19 Jul 2007 21:13:41 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 1154259E3D; Fri, 20 Jul 2007 11:13:32 +1000 (EST) Message-ID: <46A00C2F.1030401@firstpr.com.au> Date: Fri, 20 Jul 2007 11:13:19 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared References: <469C962B.1090600@firstpr.com.au> <469DBFA0.7010103@cisco.com> <469DEB91.1000805@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1029ED91C@XCH-NW-7V2.nw.nos.boeing.com> <469E976A.5060804@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1029ED924@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED924@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "Templin, Fred L" X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Thanks Fred for clarifying my understanding of IPvLX. I understand now that it is to support IPv6 user traffic over IPv4 networks, with the aim of encouraging IPv6 adoption and without (I think) further burdening the global BGP routing tables for either IPv4 or IPv6. You wrote, in part: >> How does IPvLX handle the requirement that a multihoming system >> short-term changes to traffic flow? I think service restoration >> for a multihomed link is an example of what Eliot called >> "operational state"? This is an important aspect of architectural >> goals in which Ivip differs completely from LISP or eFIT-APT. > > I didn't understand this. The primary goal of LISP, eFIT-APT and Ivip is to work with IPv4 traffic over the IPv4 routing system - or IPv6 traffic over the IPv6 routing system - and in both cases to enable end-users to achieve multihoming without having to advertise their address space as a separate BGP prefix, and therefore without requiring any change to BGP advertisements when their link from ISP A goes down and they need their packets to come in via a link from ISP B. Ivip enables the user to achieve multihoming service restoration via fast database updates, driven by a user-provided mechanism, whereas LISP and eFIT-APT have slower database distribution systems and have the service restoration function built in to their ITRs, ETRs etc. I now realise that your proposal doesn't mention "multihoming". This, and the fact that your proposal is only for IPv6 user traffic, means that it is trying to solve different problems from those which LISP, eFIT-APT and Ivip are trying to tackle. >> Ivip more closely follows what I think is a common IETF >> philosophy: single function, open-ended, building blocks which can >> be used in combination with other building blocks to solve a wide >> variety of problems, without having to create a monolithic system >> for each particular problem. (I don't know of a formal statement >> of this, but it is evident from the whole nature of TCP/IP design, >> DNS, HTTP etc.) > > I don't see any questions regarding IPvLX in this. OK - I was still discussing the differences between Ivip and the other proposals' approach to multihoming service restoration. >> Assuming IPvLX helps with ordinary IPv4 communications, it would >> be great if you could explain on this list how IPvLX would be >> deployed: >> >> Give a fully detailed example of the BGP or other benefits it >> brings to IPv4, > > The benefits to IPv4 are that it encourages new growth in > IPv6 instead of IPv4. I think any system which makes IPv6 easier to adopt, in a scalable manner, is a good idea. I don't know enough about IPv6 and the various approaches such as 6to4 to be able to fully discern how IPvLX, Teredo, 6to4 and others compare in terms of scalability and functionality. Perhaps if you wrote something comparing the long-term scaling and interoperability of these three systems, and any others which are relevant, this would help me and others through this complex set of issues. I have added links to your message and this discussion from the page where I am maintaining an updated copy of my comparison: http://www.firstpr.com.au/ip/ivip/comp/#IPvLX - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 22:20:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBi6U-00021B-Ni; Thu, 19 Jul 2007 22:20:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBi6T-0001zy-V7 for ram@iab.org; Thu, 19 Jul 2007 22:20:25 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBi6P-0001ri-8V for ram@iab.org; Thu, 19 Jul 2007 22:20:25 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 8FD3B59E3D; Fri, 20 Jul 2007 12:20:19 +1000 (EST) Message-ID: <46A01BD7.80802@firstpr.com.au> Date: Fri, 20 Jul 2007 12:20:07 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] IPv6 /32 to /48 prefixes and Tree-Bitmap FIB speed References: <469F5757.9040700@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Thanks Jeroen and Iljitsch for your helpful responses regarding IPv6 prefix lengths. I got rather lost in the Ghost Route Hunter pages, but I didn't have time to try to fully understand them. Thanks for answering my questions about /48s and for pointing me to the guidelines which some or many people follow - Gert Doering's page: http://www.space.net/~gert/RIPE/ipv6-filters.html As noted in that page, the rules there are not fully updated to recent developments, such as: ipv6 prefix-list ipv6-ebgp-strict permit 2620::/23 ge 24 le 32 route-filter 2620::/23 prefix-length-range /24-/32; which should end in "48" to reflect the fact that this prefix is where ARIN is assigning /48s to AS-end-users. A few of these are listed in the May 2007 report (page 19): http://www.space.net/~gert/RIPE/R54-v6-table.pdf There are a regular series of such reports in that directory. I wrote to Gert Doering about this initially, not realising he was in fact the person who maintains these guidelines. I often wondered whether there was a formal arrangement for the way most networks (or at least sufficient networks to affect global reachability) filter BGP advertisements based on their length. Gert's guidelines above are the closest it comes to a recognised agreement - which is not very formal. The length limit varies according to which part of the address space it is for. For instance, in areas where /32s are assigned, the rules reject advertisements for prefixes longer than /32. Gert also told me there is no formal agreement about the widely accepted practice of refusing to accept advertisements for IPv4 prefixes longer than /24: He wrote: > For IPv4, there are a number of large providers that do not > accept prefixes longer than /24, and thus, have made it a > de-facto rule - but it's not written into any sort of "Internet > book of rules" anywhere that this must be so. He also wrote: > For IPv6, people still very much disagree on what they want to > see in the global BGP table - some just announce /64s, others > filter everything that is more specific than a /32, except for > well-known exceptions like the ARIN PI range, where it's known > that the allocation is done in /48 chunks. He said that /48s shouldn't be split and that there should be a /48 for each "site". However, from the point of view of keeping the global IPv6 BGP routing table small, ideally these sites would just get one or more /48s of PA space from their local provider. (But this doesn't provide portability or traditional network-wide multihoming.) Iljitsch, you wrote, in part: > In IPv4 there is a good distribution over the first 8 bits but > in IPv6 there isn't, lots of stuff is still in 2001::/16. I > think you need to look at the first 24 bits or so if you want to > do the same here. OK - but I think that a simple array for the first "stride" of 24 bits wouldn't fit into on-chip RAM of any ASIC such as Cisco's SPP, unless there was on-chip code to do a second lookup for that smaller subset of the address range, which sounds feasible. >> I recognise that the actual CRS-1 algorithm may differ somewhat >> from this, but still, it seems that to match a packet against a >> /32 rule will probably take 4 external memory reads. For >> instance ignore the first 3 bits which are always 001, then use >> an internal RAM table for the next 11 bits and then the last 18 >> bits as a 3 * 6 bit stride. > Just 6 bits? I was going by the suggested hardware implementation from the 2004 paper - but I guess in high-powered implementations such as Cisco's SPP in the CRS-1, they may have enough RAM to do more bits per stride. I don't fully understand Tree-Bitmap, but perhaps there is some problem with larger strides than 6, something to do with the memory system not being wide enough to read in a single clock cycle all the data they need for the various things which could happen next. > It would also help to optimize the address assignment policies. For > instance, leaving 7 /48s unused between two ones that are used so there > is room for growth is really suboptimal here. Being able to see whether > an address will match /32 or shorter or whether it will have to match a > /48 could also be helpful. Yes. Although the train is just pushing off from the station, the seeds of it tumbling into the ravine at full speed five or ten years from now are clearly apparent. I suggested in a now largely defunct I-D: http://www.firstpr.com.au/ip/sram-ip-forwarding/ that before the train moves any more from the station, that there be an agreement to assign PI address space in a particular area, such as a /10, in a way that this could be easily handled by a single memory access FIB system. (Section 6.3 in the above I-D, although I explain it there in terms of specific fast SRAM chips, rather than what I would write now: as an array in the DRAM of an existing ASIC-based FIB system.) Then, for instance, 32 million /35s could be mapped into that area. The idea is that future routers (by the time the IPv6 global routing table starts to become painfully large) will be equipped to do single external memory cycle classification of all packets in this /10, on the assumption that there is no rule with a longer prefix than /35. This gives rise to a completely different approach to assigning this address space to end-users. Give each end-user one or more (on some reasonable basis - they need to justify it) /35s, starting at the bottom of this /10. Just fill it up from one end to the other. That is 32 million end-user prefixes, with each able to be advertised in any provider network, because we don't care about route aggregation - because we have a RAM-lookup FIB. By the time this process reaches the end of the /10, routers will have more RAM and allocation will continue on the next /10 above the first one. The trouble with this idea is that it solves the FIB problem beautifully, in a way which only makes sense if the BGP control plane could handle millions of routes. Maybe some scheme such as this should be kept in mind, for a future situation where BGP or some new system can cope with such a large number of routes. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 19 23:19:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBj1K-0000DO-HZ; Thu, 19 Jul 2007 23:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBj1J-0000DI-8T for ram@iab.org; Thu, 19 Jul 2007 23:19:09 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBj1G-00031F-Qj for ram@iab.org; Thu, 19 Jul 2007 23:19:09 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id A1DB359E42; Fri, 20 Jul 2007 13:19:01 +1000 (EST) Message-ID: <46A02999.9050501@firstpr.com.au> Date: Fri, 20 Jul 2007 13:18:49 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Tunneling overheads and fragmentation References: <469F7673.6070702@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: "Templin, Fred L" X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Thanks for these great responses! This message also concerns my argument for making the tunneled packet's outer source address be the same as the inner source address (outer SA = inner SA), as discussed in my second message in the thread: "ETRs checking src & dest addresses": http://www1.ietf.org/mail-archive/web/ram/current/msg01705.html The following is part of my To-Do list for Ivip: http://www.firstpr.com.au/ip/ivip/to-do/ Read these I-Ds and RFCs (I use these /html/ links because the indicate later versions at the top of the page, and print with proper page breaks): Link Adaptation for IPv6-in-(foo)*-in-IPv4 Tunnels http://tools.ietf.org/html/draft-templin-linkadapt-06 MTU and Fragmentation Issues with In-the-Network Tunneling http://tools.ietf.org/html/rfc4459 Packetization Layer Path MTU Discovery http://tools.ietf.org/html/rfc4821 TCP Problems with Path MTU Discovery http://tools.ietf.org/html/rfc2923 IPv6 Extensions for Multi-MTU Subnets http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-00 IP Tunneling Optimization in a Mobile Environment http://tools.ietf.org/html/draft-haddad-mip6-tunneling-optimization-01 Generic Routing Encapsulation (GRE) http://tools.ietf.org/html/rfc2784 Dave Meyer wrote: > Agreed. As mentioned above, there is also the interaction > with PMTU discovery; basically, it can be nontrivial to > find the original source of the packet so you can send a > a "fragmentation needed and DF set" back to the > source. If indeed you can't find the source (multiple > encaps or whatever), then the source's packets (those > that have the DF bit set, i.e., doing PMTU discovery) get > black-holed. Not sure if that was your question, but in > any event... I didn't ask specifically, but it is a really important point: Tunnels upset PMTU discovery. Here are some diagrams of left-to-right packet flow, with the outer header Source Address and Destination Address, and the inner SA and DA for the part of the path where the original packet is in a tunnel. The first diagram is for the LISP/eFIT-APT approach of the outer SA being that of the ITR. SH-----IR1----ITR~~~~~TR1~~~~~TR2~~~~~ETR----IR2-----RH Outer SA SH SH ITR ITR ITR SH SH DA RH RH ETR ETR ETR RH RH Inner SA SH SH SH DA RH RH RH ---- Raw ~~~~ Encapsulated Now I consider where an "ICMP Destination Unreachable - Fragmentation Needed" (DUFN) message might be generated. I don't know enough about this process to know if it is generated at the output of an interface, and/or when arriving at an interface (perhaps due to the innards of the router not being able to handle this length). If IR1 generates the DUFN message, all will be well - at least it is not affected by the tunneling system. Likewise if the ITR generates the DUFN when it receives the raw packet. But what if the ITR encapsulates the packet and then when attempting to forward it, generates a DUFN? Does the maximum packet length vary from one outgoing interface to another? How will this part of the router know the problem is the responsibility of a particular sending host and its own internal encapsulation function? If Transit Router TR1 generates the DUFN, the DUFN will be addressed to the ITR. But the ITR can't know what to do with it, since as far as I know, the DUFN doesn't mention anything about the contents of the packet, which is the only place where the Sending Host's (SH's) address is mentioned. Likewise if the DUFN arises from arriving at TR2 or the ETR. If the DUFN is generated at the output of the ETR, it should be OK, because it will be sent to the SH, not the ITR. Likewise if the DUFN is generated at the internal router IR2 or the Destination Host (DH). The best which could be achieved with the above arrangement is that the ITR has to store state that packets sent to a particular address (the ETR's address) should be fragmented before encapsulation. But how long does it retain this state for? It all depends on the routing path, since it could be a cranky old TR2 which is complaining, and that may not be in the path for long. Storing this state and burdening the ITR's FIB with looking for it, for every encapsulation operation, and then splitting the packet and sending two encapsulated packets . . . this is really ugly. Also, I am not sure how well LISP's or eFIT-ETR's communications would work with packets being fragmented. There are some pretty fancy protocols for communication, particularly between multiple ITRs and Default Mappers in eFIT-ETR. (See my comparison message.) Now consider the situation with Ivip's approach of setting the outer SA the same as the inner SA. This would be either with IP-in-IP (which doesn't include the ITR's address) or with UDP encapsulation with explicit mention of the ITRs address, if this was decided to be worth the trouble to help with debugging - which seems quite possible. SH-----IR1----ITR~~~~~TR1~~~~~TR2~~~~~ETR----IR2-----RH Outer SA SH SH SH SH SH SH SH DA RH RH ETR ETR ETR RH RH Inner SA SH SH SH DA RH RH RH Now wherever the DUFN is generated, it will go back to the Sending Host, which I think is what is required. The ITR doesn't have to look out for DUFN messages, or store any state, or do any optional fragmentation. This way, the SA can fine-tune its packet size, per "RH" destination address, to the highest value which avoids fragmentation. Unless I have made some mistakes, then this looks like a second strong reason for keeping "outer SA = inner SA", in addition to the powerful reason (I think) which I raised in the thread "ETRs checking src & dest addresses". - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 20 02:46:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBmFh-0001Ts-GZ; Fri, 20 Jul 2007 02:46:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBmFg-0001Tg-Ia for ram@iab.org; Fri, 20 Jul 2007 02:46:12 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBmFf-0006UI-49 for ram@iab.org; Fri, 20 Jul 2007 02:46:12 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 19 Jul 2007 23:46:10 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAb3n0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,560,1175497200"; d="scan'208"; a="387021629:sNHT33366010" 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 l6K6kA3H020672; Thu, 19 Jul 2007 23:46:10 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6K6k76C017376; Fri, 20 Jul 2007 06:46:07 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); Thu, 19 Jul 2007 23:46:07 -0700 Received: from [192.168.0.3] ([10.21.116.50]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 23:46:06 -0700 In-Reply-To: <469C962B.1090600@firstpr.com.au> References: <469C962B.1090600@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12D6E107-9D58-487A-BC5C-6BAC9495EC96@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Date: Thu, 19 Jul 2007 23:46:00 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Jul 2007 06:46:06.0872 (UTC) FILETIME=[A6179980:01C7CA99] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6481; t=1184913970; x=1185777970; 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[RAM]=20LISP=20NERD/CONS, =20eFIT-APT=20&=20Ivip=20com pared |Sender:=20; bh=sywqXLXkmb0hEsw6FfGASXG2qa/0ymjjuTXTUp+kObU=; b=s6rXp6ir/4VWWLeFf4+iRTW8by2OOqXN3wxxs0ibCaq262mq7d9mwAgudAgwxvadrVQoeX1E 76gN0hDyoVBkLW9UpThWx2Iit7lOEVtoxZbmnPg0pzMHIF8ltrKS5Thi; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > http://tools.ietf.org/html/draft-farinacci-lisp I would suggest http://www.dinof.net/~dino/ietf/draft-farinacci- lisp-02.txt. > http://tools.ietf.org/html/draft-meyer-lisp-cons-00 (July 3) I would suggest http://www.dinof.net/~dino/ietf/draft-meyer-cons-01.txt. > While NERD is "push", in comparison to CONS - which is purely a > query and cache system - the mapping updates are not actually sent > to the ITRs. Each ITR has to poll a server and retrieve the What you state above is not clear if you are talking about NERD or CONS. But in both cases the ITR can get mappings. That is if the ITR has enough storage capacity it can take the entire NERD database. In CONS, the ITRs make requests over TCP connections to their peering CARs that return mapping replies back to them. > LISP-CONS is a "pull" system. ITRs query and cache the mapping > data, via local CARs which also cache. Requests and replies > traverse a mesh of CARs and (non-caching) CDR servers, all linked > via authenticated TCP sessions. So maybe you were talking about about NERD. Just wanted to clarify though. > This will lead to much faster and more reliable query > responses than LISP-CONS - but as with Ivip, raises the > challenging problem of distributing the database updates in > real-time to all these Default Mappers. However, eFIT-APT > has very slow goals regarding the speed of distributing > these updates. I was told by a credible source that most DNS servers cannot handle a DNS query packet with multiple query types in it. So you will need numerous changes to DNS servers to get QSDs to work. In my book, that is a non-starter. > Here are some questions about each scheme, with "LISP" implying > LISP 3.x. There is no concrete information about LISP 3.x other > than that implied by NERD and CONS that I won't consider how LISP > might work with APT. LISP 3.X is not a protocol. It refers to doing encapsulation with an external mapping database service such as NERD, CONS, or APT. The variants are models where LISP 1 and LISP 1.5 use a data- triggered mapping model. LISP 2 uses the directory already deployed on the network which is DNS, and LISP 3 are new models which you see there is a lot of activity on. > Encapsulation of data > --------------------- > > LISP-NERD/CONS: Not documented yet, but presumably using UDP, with > the outer source address being that of the ITR which encapsulated > the packet. (Outer SA = ITR's address.) See the recent messages > "ETRs checking src & dest addresses" about how I think this makes > it harder for the ETR's filtering system to protect against > spoofing of local source addresses. Encapsulation is defined in draft LISP-02. NERD and CONS are control- plane mapping database services only. > LISP-NERD/CONS: As noted above, ITRs have complex functions, > including making decisions on a packet-by-packet basis for MH > service restoration, TE and I think load balancing functions. The > ITR may or may not communicate with the ETR, but I think the ITR > is always ready to accept ICMP messages as sign it is tunneling > the data packets to the wrong address. I beg to differ. The ITR simply does a cache lookup on the DA when the DA has a routing table miss or a default route match. When the cache lookup returns an RLOC it slaps a header on. It's as simple as that. > Since LISP-mapped addresses are not in any prefix which is > advertised in BGP, ITRs must be inside or at the border of > provider or end-user networks. This is not true. If you wanted to put an ITR at a PE edge and the EID-prefixes for each site connected to the PE advertised them via BGP, the ITR could act as an ETR for packets it receives from the provider network. For encapsulating, you still need a mapping database. > LISP-NERD/CONS: ETRs are located in the provider network or at its > border router, or in the end-user's network or at its border (CE) > with the provider network - as long as the address is BGP > reachable. I think ETRs have complex communication functions. NERD and CONS say nothing about where ETRs are placed in the network. And they don't need to either. > Incremental deployability > ------------------------- > > LISP-NERD/CONS: According to current definitions and all my > off-list attempts to understand LISP, LISP-mapped addresses are > not part of BGP advertised prefixes. So in order for a host to > send packets to a host on any LISP-mapped address, the sending > host must be in a network with an ITR. I think this makes LISP Or the EIDs are from PA space or the EIDs are from PI space that continues to get advertised into the network. There will be these PIs that will never be withdrawn. And this is a good thing. We just don't want all sites to do this. > not at all incrementally deployable. Why would an early adopter > want to use LISP-mapped addresses when it will make their hosts > unreachable for any communication initiated by a host on a > non-LISP-upgraded network? This is not true. Remember what else you need for an incrementally deployed design. That is no changes to hosts, no changes to DNS, no changes to core routers. LISP requires *only changes* to CE routers. Or P-routers in the core if you need LISP for ISP-based TE. There are many respects to incrementally deployable not just an non- LISP site talking to a LISP-site. > As with all proposals, there are major challenges in setting up > the infrastructure. Ivip's Replicator and ITR system is > adventurous, but the ITRs are doing a simpler job and the overall > design is simpler than the designs of other proposals. The ETRs > are free-wheeling, low-cost devices and require no coordination. > With sufficient provider networks with ETRs, one or more > independent Ivip or Ivip-like systems could be set up, and work > fine alongside each other (each with their own set of core ITRs, > or perhaps all driving data to a common set). These could > probably run at a profit, because they provide portability, > multihoming (with basic TE) and mobility with full reachability > (and generally pretty good path lengths, if the core-ITRs are well > distributed) from all hosts. I haven't heard how any of the non-LISP proposals deal with ISP-based traffic engineering and multicast. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 20 04:21:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBnk6-00056V-SU; Fri, 20 Jul 2007 04:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBnk5-00056P-WC for ram@iab.org; Fri, 20 Jul 2007 04:21:42 -0400 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBnk5-0000fH-Hh for ram@iab.org; Fri, 20 Jul 2007 04:21:41 -0400 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 4EB2CA0D5; Fri, 20 Jul 2007 04:21:41 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 20 Jul 2007 04:21:41 -0400 X-Sasl-enc: FBbhxS9Tj6LRi9XxhZlspZms/IUpI5w9xF7cc2tCF8TP 1184919699 Received: from [127.0.0.1] (cpe-72-228-47-177.nycap.res.rr.com [72.228.47.177]) by mail.messagingengine.com (Postfix) with ESMTP id 6CAE92BE1; Fri, 20 Jul 2007 04:21:35 -0400 (EDT) Subject: Re: [RAM] IPv6 /32 to /48 prefixes and Tree-Bitmap FIB speed From: Per Heldal To: Robin Whittle In-Reply-To: <46A01BD7.80802@firstpr.com.au> References: <469F5757.9040700@firstpr.com.au> <46A01BD7.80802@firstpr.com.au> Content-Type: text/plain Date: Fri, 20 Jul 2007 10:21:21 +0200 Message-Id: <1184919681.19192.48.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Fri, 2007-07-20 at 12:20 +1000, Robin Whittle wrote: > Thanks for answering my questions about /48s and for pointing me > to the guidelines which some or many people follow - Gert > Doering's page: > > http://www.space.net/~gert/RIPE/ipv6-filters.html > In the absence of scalable IDR and route-certificates you'll also find people using more strict filters in an attempt to achieve operational stability. Such filters aim to keep the maximum numbers of prefixes within the capacity of available hardware. Thus, if a registry allocates blocks out of e.g. a /23 only a small fraction of that /23 may initially be accepted, especially if it is used for PI /48s. The current v6 routing-table may be small, but I'm sure attitudes will change as more people realise the potential impact on their infrastructure as it becomes increasingly common to operate dual-stack networks. A practical approach to the process of building v6 filters would be: 1. Look at IANA's assignments to RIRs 2. Examine policies for each block to check if they are sub-divided into smaller blocks with individual allocation policies. 3. Obtain prefix-length-recommendations from the RIRs' routing policies for each address-block. 4. Examine (download&process) the records of the RIR's allocations to LIRs and end-users to determine the last allocation (highest number) in each block. This, combined with a wish to allow some extra prefix-bits for shorter AS-paths (traffic-engineering) defines a "baseline" for prefix-filters. Note: It's not unusual to use a similar approach for ipv4 -- either for operational filters or in tools used to analyse various aspects of the DFZ. (The task would of course be much simpler if this information was available in a consistent/unified/standardised format from all parties involved ;)) //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 20 05:49:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBp6i-0005v1-3b; Fri, 20 Jul 2007 05:49:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBp6g-0005uv-27 for ram@iab.org; Fri, 20 Jul 2007 05:49:06 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBp6c-0002VA-Ke for ram@iab.org; Fri, 20 Jul 2007 05:49:06 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id AE3EE59E42; Fri, 20 Jul 2007 19:48:58 +1000 (EST) Message-ID: <46A084FE.9000003@firstpr.com.au> Date: Fri, 20 Jul 2007 19:48:46 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared References: <469C962B.1090600@firstpr.com.au> <12D6E107-9D58-487A-BC5C-6BAC9495EC96@cisco.com> In-Reply-To: <12D6E107-9D58-487A-BC5C-6BAC9495EC96@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, Before I respond, I want to mention that I am keen for people with your expertise to discuss the question of how to prevent ETRs being used as a conduit for packets with spoofed source addresses matching the addresses inside the network. This is my second message in the "ETRs checking src & dest addresses" thread, about a week ago: http://www1.ietf.org/mail-archive/web/ram/current/msg01705.html As far as I can see, the best way to do this involves the outer source address being equal to the sending host's address, not the ITR's address as LISP and eFIT-APT uses. A second reason for doing this, regarding MTU auto discovery, is in my recent message "Tunneling overheads and fragmentation". http://www1.ietf.org/mail-archive/web/ram/current/msg01729.html You wrote, in part: >> http://tools.ietf.org/html/draft-meyer-lisp-cons-00 (July 3) > > I would suggest > http://www.dinof.net/~dino/ietf/draft-meyer-cons-01.txt This has the same date as the one on the IETF site. I haven't looked at the 01 version in detail, but I guess you have updated some details of the headers. >> While NERD is "push", in comparison to CONS - which is purely a >> query and cache system - the mapping updates are not actually sent >> to the ITRs. Each ITR has to poll a server and retrieve the > > What you state above is not clear if you are talking about NERD or CONS. I was referring to NERD ITRs polling servers to get the mapping data for an entire area of the LISP-mapped address space, and then polling for updates. > But in both cases the ITR can get mappings. That is if the ITR has > enough storage capacity it can take the entire NERD database. I think that in NERD the ITRs do need to get the full database, since there is no reasonably rapid query system as in LISP-CONS > In CONS, > the ITRs make requests over TCP connections to their peering CARs that > return mapping replies back to them. Yes, if the CAR has the information cached. If not, the CAR launches a query (I guess just one) into the CDR network, which somehow causes the query to reach one or more CARS which are authoritative for whatever EID address is being queried. It is not clear to me how either the initial CAR or the CDR network identifies which two or more CARs are authoritative - maybe the query just propagates and is split up at some CDRs when those CDRs have two paths to peers which are advertising a path to an authoritative server. Also, I don't know how multiple replies from authoritative CARs are either all sent to the querying CAR, or how the CDR network somehow recognises multiple replies and lets only one propagate. >> This will lead to much faster and more reliable query >> responses than LISP-CONS - but as with Ivip, raises the >> challenging problem of distributing the database updates in >> real-time to all these Default Mappers. However, eFIT-APT >> has very slow goals regarding the speed of distributing >> these updates. > > I was told by a credible source that most DNS servers cannot handle a > DNS query packet with multiple query types in it. So you will need > numerous changes to DNS servers to get QSDs to work. In my book, that is > a non-starter. The Query Servers - QSD and QSC (full database and caching) - which I propose for Ivip have nothing to do with nameservers or the DNS. Maybe there is some existing protocol to work from, but I think the requirements are different enough to make it worth creating something from scratch. >> Here are some questions about each scheme, with "LISP" implying >> LISP 3.x. There is no concrete information about LISP 3.x other >> than that implied by NERD and CONS that I won't consider how LISP >> might work with APT. > > LISP 3.X is not a protocol. It refers to doing encapsulation with an > external mapping database service such as NERD, CONS, or APT. Because APT is described as applying to eFIT, that is what I used to compare with other systems. I don't see how APT could be applied to what I know about LISP - since APT has a whole bunch of restrictions on where the ETRs and ITRs are (always combined together in the PE routers, never anywhere else) and specific forms of communication between ITRs, ETRs and Default Mappers which are not present in LISP as far as I know. > The variants are models where LISP 1 and LISP 1.5 use a data-triggered > mapping model. LISP 2 uses the directory already deployed on the network > which is DNS, and LISP 3 are new models which you see there is a lot of > activity on. OK. In one sense, I can imagine "LISP 3.x" applying to any system with a database and communication system separate from the DNS or from data-triggered communications. In this sense, perhaps, eFIT-APT and Ivip are part of "LISP 3.x". But I think it is better to think of LISP-NERD and LISP-CONS as being the two LISP 3.x proposals so far. >> Encapsulation of data >> --------------------- >> >> LISP-NERD/CONS: Not documented yet, but presumably using UDP, with >> the outer source address being that of the ITR which encapsulated >> the packet. (Outer SA = ITR's address.) See the recent messages >> "ETRs checking src & dest addresses" about how I think this makes >> it harder for the ETR's filtering system to protect against >> spoofing of local source addresses. > > Encapsulation is defined in draft LISP-02. NERD and CONS are > control-plane mapping database services only. OK, your LISP-02 was announced a few hours after I posted my comparison. I can't easily see what has changed, but I noticed these: New text at end of definitions of ITR and ETR. On page 9, new text for paragraph starting with "EIDs": They are expected to be used locally for intra-site communication. On page 20, the vertical "Record" bar goes higher. Section 6.1.3 the format has changed for a longer nonce and the Path Vector List is not used for Map Replies. >> LISP-NERD/CONS: As noted above, ITRs have complex functions, >> including making decisions on a packet-by-packet basis for MH >> service restoration, TE and I think load balancing functions. The >> ITR may or may not communicate with the ETR, but I think the ITR >> is always ready to accept ICMP messages as sign it is tunneling >> the data packets to the wrong address. > > I beg to differ. The ITR simply does a cache lookup on the DA when the > DA has a routing table miss or a default route match. When the cache > lookup returns an RLOC it slaps a header on. It's as simple as that. It was my impression that in LISP-CONS, as in LISP 1/1.5 and LISP-NERD that the ITRs have to make decisions regarding choosing another RLOC for service restoration in a multihoming situation. For instance, from LISP-CONS-00 (01 is the same): | Note that LISP-CONS is not designed for the "fast-mobility" | case. That is, it is envisioned that the mappings distributed | by LISP-CONS are reasonably static. LISP-CONS is also not | designed to carry Locator Reachability status information; see | [LISP-01] for details on how LISP determines locator | reachability. LISP-01 (02 is the same) has a bunch of stuff about reachability, including, for instance: | 6.3. Routing Locator Reachability | | There are 4 methods for determining when a Locator is either | reachable or has become unreachable: | | 1. Locator reachability is determined by an ETR by examining | the Loc-Reach-Bits from a LISP header of a Data Message | which is provided by an ITR when an ITR encapsulates data. | | 2. Locator unreachability is determined by an ITR by receiving | ICMP Network or Host Unreachable messages. | | 3. ETR unreachability is determined when a host sends an ICMP | Port Unreachable message. | | 4. Locator reachability is determined by receiving a Map-Reply | message from a ETR's Locator address in response to a | previously sent Map-Request. Does any of this apply to LISP-CONS? Each of these involves an ETR or an ITR in doing something much more complex, involving the central CPU etc. (and also more open to security problems) then simply encapsulating or decapsulating packets. Is it true to say that in LISP-CONS, the ITRs don't accept any messages from anything, including ICMP messages - other than the replies to their queries to CARs? Does it mean that service restoration when an end-user wants the packets to go to an ETR in ISP-B instead of the ETR in ISP-A are all controlled by changing the mapping data? (This is the Ivip approach.) If so, then I don't see how that fits with what I quoted above from LISP-CONS: "the mappings distributed by LISP-CONS are reasonably static". If in LISP-CONS the ITR doesn't send any messages to the ETR, or take any notice of ICMP messages, then I will amend my comparison, because that makes LISP-CONS a conceptually much simpler system, like Ivip, compared to LISP-NERD and eFIT-APT - which both delegate responsibility for service restoration and TE to the ITRs and ETRs in some way. I had thought that in LISP-CONS the mapping data includes the TE control parameters Priority and Weight. I forgot that in the LISP-CONS I-D these are marked as "unused". Is it also true to say that if the mapping data is changed in the authoritative CAR(s) that the only way this propagates to ITRs which currently have the last version of the mapping data is by each ITR's cached data expiring, and the ITR requesting the mapping data again because it is still handling packets for this EID? That is to say, there is no message emanating out of the authoritative CAR to CARs which recently requested mapping information (cache invalidation, or like "Notify" in Ivip)? If so - which is my current understanding - then I think it would be very hard for LISP-CONS to respond quickly to mapping changes, such as with multihoming service restoration, unless the cache times were short - which would burden the entire CAR-CDR network with vast numbers of requests and responses. >> Since LISP-mapped addresses are not in any prefix which is >> advertised in BGP, ITRs must be inside or at the border of >> provider or end-user networks. > > This is not true. If you wanted to put an ITR at a PE edge and the > EID-prefixes for each site connected to the PE advertised them via BGP, > the ITR could act as an ETR for packets it receives from the provider > network. For encapsulating, you still need a mapping database. I don't understand most of this, and I don't understand how it relates to the text quoted above. I don't understand the term "EID-prefixes for each site", because to me the whole idea of an ID/Loc separation system is that there is one or more block of IP addresses (prefixes of EIDs in LISP terminology) which are for hosts which could connected at any ETR-equipped provider network in the Net. The key point is that for sending hosts in non-upgraded networks, how do they send a packet to an address which is now an EID as part of the LISP system? The destination host could be anywhere - in, or connected to, any provider network with an ETR which is configured to handle packets for this host. The only way the packet is going to get to the destination is to be encapsulated by an ITR. But in all versions of LISP, as best I understand it, any address which is an EID is not part of any advertised BGP prefix. So in the non-upgraded network, it is dropped by the first router, since there is no reason to send it anywhere. There is no ITR in the non-upgraded network and that is the end of the story. With Ivip, the packet is forwarded out the border router, because it matches a BGP advertised prefix, and then it is forwarded to the nearest ITR in the core of the network (or perhaps a border router of another network) - since there are lots of such ITRs all advertising the same prefix which this packet matches. >> LISP-NERD/CONS: ETRs are located in the provider network or at its >> border router, or in the end-user's network or at its border (CE) >> with the provider network - as long as the address is BGP >> reachable. I think ETRs have complex communication functions. > > NERD and CONS say nothing about where ETRs are placed in the network. > And they don't need to either. I guess I am extrapolating from the basic LISP I-D. It is hard to figure some of this LISP 3.x stuff out, since the LISP I-D only formally describes variants 1 and 1.5. - and yet LISP-CONS refers to LISP-0x for some of its definitions, such as regarding reachability. >> Incremental deployability >> ------------------------- >> >> LISP-NERD/CONS: According to current definitions and all my >> off-list attempts to understand LISP, LISP-mapped addresses are >> not part of BGP advertised prefixes. So in order for a host to >> send packets to a host on any LISP-mapped address, the sending >> host must be in a network with an ITR. I think this makes LISP > > Or the EIDs are from PA space or the EIDs are from PI space that > continues to get advertised into the network. There will be these PIs > that will never be withdrawn. And this is a good thing. We just don't > want all sites to do this. This appears to be different from everything I knew about LISP - that the EIDs never matched BGP advertised prefixes. If a site Z has a prefix (PI or PA, it doesn't matter) and this is advertised in BGP, then all the packets from non-upgraded networks will be forwarded to Z's border router. Maybe you have an ITR there which tunnels them to the ETR of whatever other network the destination host might be in. That would achieve full reachability, but the total path length from sending host to destination host could be much longer than optimal, and you would be relying on a single border router to be the ITR. Ivip does better than this by having many ITRs in the "core", or at least near the border routers of non-upgraded networks. By using anycast, the packet automatically finds its way to the closest ITR, and then is tunneled on a path to wherever the destination host's ETR is, which is likely to be a close to optimal path length. With Ivip, the total path length will generally be much shorter than with what I understand from what you wrote above: all the packets going to a single site's border router, which tunnels them to an ETR which may be anywhere in the Net. >> not at all incrementally deployable. Why would an early adopter >> want to use LISP-mapped addresses when it will make their hosts >> unreachable for any communication initiated by a host on a >> non-LISP-upgraded network? > > This is not true. Remember what else you need for an incrementally > deployed design. That is no changes to hosts, no changes to DNS, no > changes to core routers. Ivip doesn't involve any changes to DNS. There does need to be some "anycast ITRs in the core" - but they could be multiple border routers of other networks which all (anycast) advertise the prefixes of Ivip-mapped address space. If you could confirm what I wrote above - me trying to express my understand of what you wrote - then it seems you are proposing a single network's border router(s) be the ITR for packets from non-upgraded networks. I think that would remove the major difficulty I see regarding reachability, but it would lead to longer paths in general than using anycast as I propose with Ivip. > LISP requires *only changes* to CE routers. Or > P-routers in the core if you need LISP for ISP-based TE. > > There are many respects to incrementally deployable not just an non-LISP > site talking to a LISP-site. I agree. There are real questions of who is going to write code, build servers and new functions in routers to get the thing going - LISP or Ivip or anything else. >> As with all proposals, there are major challenges in setting up >> the infrastructure. Ivip's Replicator and ITR system is >> adventurous, but the ITRs are doing a simpler job and the overall >> design is simpler than the designs of other proposals. The ETRs >> are free-wheeling, low-cost devices and require no coordination. >> With sufficient provider networks with ETRs, one or more >> independent Ivip or Ivip-like systems could be set up, and work >> fine alongside each other (each with their own set of core ITRs, >> or perhaps all driving data to a common set). These could >> probably run at a profit, because they provide portability, >> multihoming (with basic TE) and mobility with full reachability >> (and generally pretty good path lengths, if the core-ITRs are well >> distributed) from all hosts. > > I haven't heard how any of the non-LISP proposals deal with ISP-based > traffic engineering and multicast. With Ivip, the end-user who has ultimate control of the mapping of their Ivip-mapped addresses, gives their username and password (or whatever they use to control the mapping) to whoever it is they want to control the mapping. Can you give me an example of "ISP-based traffic engineering"? I tend to think of TE concerning incoming traffic being spread over two or more links, and therefore ETRs and their provider networks, under the control of the end-user whose multihomed site is the recipient of those packets. They can easily choose the path of outgoing packets. At present they use BGP to control incoming traffic. With Ivip they directly change their mapping data to make packets for some IP addresses or prefixes be tunneled to one ETR and others to another ETR. Maybe that is what happens with LISP-CONS too. I think LISP-NERD involves the ITRs making decisions about where to tunnel packets, based on various priorities and weights. As far as I know, packets to multicast addresses are not found handled by the Internet. LISP-CONS doesn't mention multicast. My copy of LISP-01 has a bunch of question marks down the side of the "Multicast Considerations" page. Can you explain how multicast packets are, or will be, used such that they are forwarded between BGP routers, and then try to give a better explanation of how LISP handles them? - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 20 10:05:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBt5y-0002yK-0O; Fri, 20 Jul 2007 10:04:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBt5w-0002yF-Nl for ram@iab.org; Fri, 20 Jul 2007 10:04:36 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBt5v-00081j-63 for ram@iab.org; Fri, 20 Jul 2007 10:04:36 -0400 Received: (qmail 98064 invoked by uid 1007); 20 Jul 2007 14:04:33 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=cyzhiA8ts5BwUv+eMiXV5/rMEM6ZkWxPPEthsb+OG/PpcIjCqRI1l+aQMcfx4rQQ ; Date: Fri, 20 Jul 2007 16:04:33 +0200 From: Gert Doering To: Robin Whittle Subject: Re: [RAM] Tunneling overheads and fragmentation Message-ID: <20070720140433.GA69215@Space.Net> References: <469F7673.6070702@firstpr.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469F7673.6070702@firstpr.com.au> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, On Fri, Jul 20, 2007 at 12:34:27AM +1000, Robin Whittle wrote: > For instance, if all provider and transit routers happily handle > packets significantly longer than whatever hosts normally produce > (say 1500 bytes) then adding the encapsulation won't lead to any > fragmentation. Is this a reasonable assumption? No. As of today, too many links and routers still have issues handling more than 1500 bytes of IP packets (like "most FastEthernet interfaces on Cisco routers", which is still considered "high bandwidth" over here). > What about routers in end-user networks, or CE routers of providers? Even worse, due to DSL encapsulation you already end up with an IP MTU of 1492 bytes or less. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 20 10:29:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtTm-0003a6-W0; Fri, 20 Jul 2007 10:29:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtTl-0003a1-6s for ram@iab.org; Fri, 20 Jul 2007 10:29:13 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBtTk-000057-Hi for ram@iab.org; Fri, 20 Jul 2007 10:29:13 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6KET26Z011538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Jul 2007 07:29:10 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6KET1EM009506; Fri, 20 Jul 2007 09:29:01 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6KESceB008857; Fri, 20 Jul 2007 09:29:01 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 07:29:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Date: Fri, 20 Jul 2007 07:29:00 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED929@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <46A00C2F.1030401@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Thread-Index: AcfKazITZjUHbmtESf+p5lE+TbpiKwAbllVA References: <469C962B.1090600@firstpr.com.au> <469DBFA0.7010103@cisco.com> <469DEB91.1000805@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1029ED91C@XCH-NW-7V2.nw.nos.boeing.com> <469E976A.5060804@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1029ED924@XCH-NW-7V2.nw.nos.boeing.com> <46A00C2F.1030401@firstpr.com.au> From: "Templin, Fred L" To: "Robin Whittle" , X-OriginalArrivalTime: 20 Jul 2007 14:29:00.0596 (UTC) FILETIME=[50858F40:01C7CADA] X-Spam-Score: -4.0 (----) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin, Only follow-up for now is that IPvLX does anticipate support for multihomed sites. Sites that are multihomed can publish multiple ETR RLOCs in the mapping service, and ITRs can use any/all of the available RLOCs for TE or fault tolerance purposes. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Robin Whittle [mailto:rw@firstpr.com.au]=20 > Sent: Thursday, July 19, 2007 6:13 PM > To: ram@iab.org > Cc: Templin, Fred L > Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared >=20 > Thanks Fred for clarifying my understanding of IPvLX. >=20 > I understand now that it is to support IPv6 user traffic over IPv4 > networks, with the aim of encouraging IPv6 adoption and without (I > think) further burdening the global BGP routing tables for either > IPv4 or IPv6. >=20 > You wrote, in part: >=20 > >> How does IPvLX handle the requirement that a multihoming system > >> short-term changes to traffic flow? I think service restoration > >> for a multihomed link is an example of what Eliot called > >> "operational state"? This is an important aspect of architectural > >> goals in which Ivip differs completely from LISP or eFIT-APT. > >=20 > > I didn't understand this. >=20 > The primary goal of LISP, eFIT-APT and Ivip is to work with IPv4 > traffic over the IPv4 routing system - or IPv6 traffic over the > IPv6 routing system - and in both cases to enable end-users to > achieve multihoming without having to advertise their address > space as a separate BGP prefix, and therefore without requiring > any change to BGP advertisements when their link from ISP A goes > down and they need their packets to come in via a link from ISP B. >=20 > Ivip enables the user to achieve multihoming service restoration > via fast database updates, driven by a user-provided mechanism, > whereas LISP and eFIT-APT have slower database distribution > systems and have the service restoration function built in to > their ITRs, ETRs etc. >=20 > I now realise that your proposal doesn't mention "multihoming". > This, and the fact that your proposal is only for IPv6 user > traffic, means that it is trying to solve different problems from > those which LISP, eFIT-APT and Ivip are trying to tackle. >=20 >=20 > >> Ivip more closely follows what I think is a common IETF > >> philosophy: single function, open-ended, building blocks which can > >> be used in combination with other building blocks to solve a wide > >> variety of problems, without having to create a monolithic system > >> for each particular problem. (I don't know of a formal statement > >> of this, but it is evident from the whole nature of TCP/IP design, > >> DNS, HTTP etc.) > >=20 > > I don't see any questions regarding IPvLX in this. >=20 > OK - I was still discussing the differences between Ivip and the > other proposals' approach to multihoming service restoration. >=20 >=20 > >> Assuming IPvLX helps with ordinary IPv4 communications, it would > >> be great if you could explain on this list how IPvLX would be > >> deployed: > >> > >> Give a fully detailed example of the BGP or other benefits it > >> brings to IPv4, > >=20 > > The benefits to IPv4 are that it encourages new growth in > > IPv6 instead of IPv4. >=20 > I think any system which makes IPv6 easier to adopt, in a scalable > manner, is a good idea. I don't know enough about IPv6 and the > various approaches such as 6to4 to be able to fully discern how > IPvLX, Teredo, 6to4 and others compare in terms of scalability and > functionality. >=20 > Perhaps if you wrote something comparing the long-term scaling and > interoperability of these three systems, and any others which are > relevant, this would help me and others through this complex set > of issues. >=20 > I have added links to your message and this discussion from the > page where I am maintaining an updated copy of my comparison: >=20 > http://www.firstpr.com.au/ip/ivip/comp/#IPvLX >=20 >=20 > - Robin >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 21 07:49:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICDT1-0005GQ-CY; Sat, 21 Jul 2007 07:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICDSz-0005GG-Jm for ram@iab.org; Sat, 21 Jul 2007 07:49:45 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICDSv-0006dc-JX for ram@iab.org; Sat, 21 Jul 2007 07:49:45 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id DF6EF59DEB; Sat, 21 Jul 2007 21:49:36 +1000 (EST) Message-ID: <46A1F2C4.9040605@firstpr.com.au> Date: Sat, 21 Jul 2007 21:49:24 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared References: <469C962B.1090600@firstpr.com.au> <12D6E107-9D58-487A-BC5C-6BAC9495EC96@cisco.com> <46A084FE.9000003@firstpr.com.au> In-Reply-To: <46A084FE.9000003@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Templin, Fred L" X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Further to my response to Dino's message about my comparison, I have updated the page: http://www.firstpr.com.au/ip/ivip/comp/ to reflect some corrections which are easily visible. Most importantly, I correct my mistake of not recognising that that LISP-CONS does not contain any Priority or Weight information in its mapping - which means that the LISP-CONS ITR has a simple job, with no decisions or involvement in determining reachability. There is a section: http://www.firstpr.com.au/ip/ivip/comp/#LC-suggestions where I point out parts of the current LISP-CONS-01 draft which I think should be altered, because I think they are contradictory or confusing. Although I don't compare IPvLX, there is a section there: http://www.firstpr.com.au/ip/ivip/comp/#IPvLX which links to http://ipvlx.com and to Fred's recent messages which helped me understand this proposal better. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 21 10:41:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICG8T-0003v6-Ka; Sat, 21 Jul 2007 10:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICG8S-0003j8-BB for ram@iab.org; Sat, 21 Jul 2007 10:40:44 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICG8P-0001Pz-US for ram@iab.org; Sat, 21 Jul 2007 10:40:44 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id C217159DEB; Sun, 22 Jul 2007 00:40:34 +1000 (EST) Message-ID: <46A21AD6.2060501@firstpr.com.au> Date: Sun, 22 Jul 2007 00:40:22 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Tunneling overheads and fragmentation References: <469F7673.6070702@firstpr.com.au> <20070720140433.GA69215@Space.Net> In-Reply-To: <20070720140433.GA69215@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I just read: IP Encapsulation within IP http://tools.ietf.org/html/rfc2003 Generic Routing Encapsulation (GRE) http://tools.ietf.org/html/rfc2784 MTU and Fragmentation Issues with In-the-Network Tunneling http://tools.ietf.org/html/rfc4459 and the first few pages of: Packetization Layer Path MTU Discovery http://tools.ietf.org/html/rfc4821 I have added: IPv4 Reassembly Errors at High Data Rates http://tools.ietf.org/html/draft-heffner-frag-harmful-05 IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. ... to the To-Do list: http://www.firstpr.com.au/ip/ivip/to-do/ Gert's response and the responses of others makes me think that these proposals - LISP-NERD/CONS, eFIT-APT and Ivip - cannot succeed in their goal of requiring no changes to hosts, except perhaps where host packet sizes are always controlled by DHCP settings. Even then, I fear that in order to preserve both reachability and efficiency (and any reachability problems which arise from fragmentation), that hosts in all networks, including non-upgraded networks, will need to adopt a somewhat lower MTU setting - for all the packets they send. I wonder to what extent every possible application respects the operating system's MTU. Do operating systems simply refuse to send any packet which is longer? I wonder if there are any widely used applications, such as games, P2P programs etc. which are hard-coded to assume a certain MTU which is close to, or right at, the limit of what can safely be sent across most of the Net. Perhaps, in an optimistic scenario, recognising that some packets are to be encapsulated by ITRs, an ISP network could set up its DHCP system or whatever it is which gives DSL modems their parameters, to reduce the MTU and MSS settings sufficiently that the ITR-applied encapsulation still results in packets which will not be fragmented in most transit and border routers. I am assuming a single level of encapsulation is all that is required. Then, the hosts could generate marginally shorter packets - for all packets sent, including those to non-mapped addresses and the packets which need to be encapsulated will get to the other end without any fragmentation. This really needs to be done for all hosts in all networks - not just hosts in networks which have been upgraded with ITRs and ETRs etc. Because there are no prospects of ramping BGP up to coping with millions of advertised prefixes, every vaguely practical, potentially incrementally deployable proposal for the routing and addressing crisis involves tunneling. I think the most likely way this fragmentation and MTU problem is going to be solved is to back off the MTU and MSS settings on all hosts, for all packets. Even if the host had its own ITFH (Ingress Tunnel Function in Host) function, I don't see how the operating system could tell application programs that there is one MTU and MSS setting for packets going to some addresses and another setting for packets going to other addresses. So unless someone figures out a totally different system, the only way out of the current crisis will be to force all application software on every host on the Net to generate somewhat shorter packets. If so, then I think this would be an argument in favor of the shortest possible encapsulation system, which I think for IPv4 is the IP-in-IP technique (RFC 3003), which adds 20 bytes. UDP encapsulation, as used by LISP and I think eFIT-APT, involves 20 bytes for the IP header, 8 bytes for the UDP header and some number of bytes, such as 4, for extra stuff which presumably precedes the encapsulated packet itself. For instance 32 bits of length and other guff and a 32 bit address of the ITR, to identify the ITR if my proposal for "outer SA = inner SA" is adopted. So that is 32 bytes of overhead. This is where IPv6's long addresses and headers become really ugly. There would be 40 bytes for IP-in-IP and 52 for basic UDP encapsulation. In my previous message: http://www1.ietf.org/mail-archive/web/ram/current/msg01729.html I suggested a second reason (in addition to the original one of making it easy to stop ETRs being used as a back-door around filtering) for using "outer SA = inner SA": to allow ICMP messages to go straight back to the sending host. This would absolve the ITR of the problematic, onerous or impossible task of receiving ICMP messages coming back to it, and figuring out which sending host to send back some ICMP message to. (See RFC 4459.) As far as I know, "outer SA = inner SA" is at odds with standard practice, but I think it has some important benefits. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 21 10:44:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICGBe-0006ap-Sz; Sat, 21 Jul 2007 10:44:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICGBd-0006af-Sr for ram@iab.org; Sat, 21 Jul 2007 10:44:01 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICGBa-0001T6-LS for ram@iab.org; Sat, 21 Jul 2007 10:44:01 -0400 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 7921277; Sat, 21 Jul 2007 10:43:58 -0400 In-Reply-To: <46A21AD6.2060501@firstpr.com.au> References: <469F7673.6070702@firstpr.com.au> <20070720140433.GA69215@Space.Net> <46A21AD6.2060501@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] Tunneling overheads and fragmentation Date: Sat, 21 Jul 2007 10:43:56 -0400 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jul 21, 2007, at 10:40 AM, Robin Whittle wrote: > I just read: > > IP Encapsulation within IP > http://tools.ietf.org/html/rfc2003 > > Generic Routing Encapsulation (GRE) > http://tools.ietf.org/html/rfc2784 > > MTU and Fragmentation Issues with In-the-Network Tunneling > http://tools.ietf.org/html/rfc4459 > > and the first few pages of: > > Packetization Layer Path MTU Discovery > http://tools.ietf.org/html/rfc4821 > > > I have added: > > IPv4 Reassembly Errors at High Data Rates > http://tools.ietf.org/html/draft-heffner-frag-harmful-05 > > IPv4 fragmentation is not sufficiently robust for use under > some conditions in today's Internet. At high data rates, the I would change "some" to "most", at least as a practical matter. Regards Marshall > 16-bit IP identification field is not large enough to prevent > frequent incorrectly assembled IP fragments, and the TCP and > UDP checksums are insufficient to prevent the resulting > corrupted datagrams from being delivered to higher protocol > layers. ... > > to the To-Do list: > > http://www.firstpr.com.au/ip/ivip/to-do/ > > > Gert's response and the responses of others makes me think that > these proposals - LISP-NERD/CONS, eFIT-APT and Ivip - cannot > succeed in their goal of requiring no changes to hosts, except > perhaps where host packet sizes are always controlled by DHCP > settings. > > Even then, I fear that in order to preserve both reachability and > efficiency (and any reachability problems which arise from > fragmentation), that hosts in all networks, including non-upgraded > networks, will need to adopt a somewhat lower MTU setting - for > all the packets they send. > > I wonder to what extent every possible application respects the > operating system's MTU. Do operating systems simply refuse to > send any packet which is longer? I wonder if there are any widely > used applications, such as games, P2P programs etc. which are > hard-coded to assume a certain MTU which is close to, or right at, > the limit of what can safely be sent across most of the Net. > > Perhaps, in an optimistic scenario, recognising that some packets > are to be encapsulated by ITRs, an ISP network could set up its > DHCP system or whatever it is which gives DSL modems their > parameters, to reduce the MTU and MSS settings sufficiently that > the ITR-applied encapsulation still results in packets which will > not be fragmented in most transit and border routers. I am > assuming a single level of encapsulation is all that is required. > > Then, the hosts could generate marginally shorter packets - for > all packets sent, including those to non-mapped addresses and the > packets which need to be encapsulated will get to the other end > without any fragmentation. > > This really needs to be done for all hosts in all networks - not > just hosts in networks which have been upgraded with ITRs and ETRs > etc. > > Because there are no prospects of ramping BGP up to coping with > millions of advertised prefixes, every vaguely practical, > potentially incrementally deployable proposal for the routing and > addressing crisis involves tunneling. > > I think the most likely way this fragmentation and MTU problem is > going to be solved is to back off the MTU and MSS settings on all > hosts, for all packets. Even if the host had its own ITFH > (Ingress Tunnel Function in Host) function, I don't see how the > operating system could tell application programs that there is one > MTU and MSS setting for packets going to some addresses and > another setting for packets going to other addresses. > > So unless someone figures out a totally different system, the only > way out of the current crisis will be to force all application > software on every host on the Net to generate somewhat shorter > packets. > > If so, then I think this would be an argument in favor of the > shortest possible encapsulation system, which I think for IPv4 is > the IP-in-IP technique (RFC 3003), which adds 20 bytes. > > UDP encapsulation, as used by LISP and I think eFIT-APT, involves > 20 bytes for the IP header, 8 bytes for the UDP header and some > number of bytes, such as 4, for extra stuff which presumably > precedes the encapsulated packet itself. For instance 32 bits of > length and other guff and a 32 bit address of the ITR, to identify > the ITR if my proposal for "outer SA = inner SA" is adopted. So > that is 32 bytes of overhead. > > This is where IPv6's long addresses and headers become really > ugly. There would be 40 bytes for IP-in-IP and 52 for basic UDP > encapsulation. > > In my previous message: > http://www1.ietf.org/mail-archive/web/ram/current/msg01729.html > > I suggested a second reason (in addition to the original one of > making it easy to stop ETRs being used as a back-door around > filtering) for using "outer SA = inner SA": to allow ICMP messages > to go straight back to the sending host. This would absolve the > ITR of the problematic, onerous or impossible task of receiving > ICMP messages coming back to it, and figuring out which sending > host to send back some ICMP message to. (See RFC 4459.) > > As far as I know, "outer SA = inner SA" is at odds with standard > practice, but I think it has some important benefits. > > - Robin > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 21 18:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICN00-0006YV-DP; Sat, 21 Jul 2007 18:00:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICMzz-0006YQ-Om for ram@iab.org; Sat, 21 Jul 2007 18:00:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICMzz-0001WS-B3 for ram@iab.org; Sat, 21 Jul 2007 18:00:27 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2007 15:00:26 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEceokarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,567,1175497200"; d="scan'208"; a="186262176:sNHT29408238" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6LM0QNZ017105; Sat, 21 Jul 2007 15:00:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6LM0JTb015861; Sat, 21 Jul 2007 22:00:21 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, 21 Jul 2007 15:00:19 -0700 Received: from [192.168.0.3] ([10.21.85.127]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 15:00:19 -0700 In-Reply-To: <46A084FE.9000003@firstpr.com.au> References: <469C962B.1090600@firstpr.com.au> <12D6E107-9D58-487A-BC5C-6BAC9495EC96@cisco.com> <46A084FE.9000003@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10317478-DD6B-4ED9-93E0-9AD4EE232498@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Date: Sat, 21 Jul 2007 15:00:12 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Jul 2007 22:00:19.0133 (UTC) FILETIME=[870026D0:01C7CBE2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1776; t=1185055226; x=1185919226; 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[RAM]=20LISP=20NERD/CONS, =20eFIT-APT=20&=20Ivip=20com pared |Sender:=20; bh=TjC36IhvVKYMB4XPOscbeLVVw34a/XxvdLiQdu1FZCg=; b=Rq7bWw++SWdlUHDPclWXbF3LIWB1zw6zlziiBM1LQFIs1noiF7SDMoe8zxUpq/NQzXlMB6VU NkBjZeWmJIInRCNj1YuSzMuj48eDjjfDfUt2GETfhgjJ16zc8PRWd7Ypfk21WrDisOArS8Tb9j pL8XQy8kKwejDFUy6ndCkRX+o=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > LISP-01 (02 is the same) has a bunch of stuff about reachability, > including, for instance: > > | 6.3. Routing Locator Reachability > | > | There are 4 methods for determining when a Locator is either > | reachable or has become unreachable: > | > | 1. Locator reachability is determined by an ETR by examining > | the Loc-Reach-Bits from a LISP header of a Data Message > | which is provided by an ITR when an ITR encapsulates data. > | > | 2. Locator unreachability is determined by an ITR by receiving > | ICMP Network or Host Unreachable messages. > | > | 3. ETR unreachability is determined when a host sends an ICMP > | Port Unreachable message. > | > | 4. Locator reachability is determined by receiving a Map-Reply > | message from a ETR's Locator address in response to a > | previously sent Map-Request. > > Does any of this apply to LISP-CONS? Each of these involves an > ETR or an ITR in doing something much more complex, involving the > central CPU etc. (and also more open to security problems) then > simply encapsulating or decapsulating packets. Locator reachability is done outside of the mapping service. So once an ITR gets a mapping, from any database mapping service, it determines reachability from either ICMP unreachables or the loc- reach-bits from returning packets. > Does it mean that service restoration when an end-user wants the > packets to go to an ETR in ISP-B instead of the ETR in ISP-A are > all controlled by changing the mapping data? (This is the Ivip > approach.) No, the mapping data tells you want ETRs are configured for an EID- prefix, regardless if they are up or down at the time the mapping reply is received by any ITR. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 21 18:03:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICN38-00028k-Uh; Sat, 21 Jul 2007 18:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICN36-0001zS-O9 for ram@iab.org; Sat, 21 Jul 2007 18:03:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICN35-0001ed-GY for ram@iab.org; Sat, 21 Jul 2007 18:03:40 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 21 Jul 2007 15:03:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEceokarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,567,1175497200"; d="scan'208"; a="505704428:sNHT25644950" 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 l6LM3cZk018376; Sat, 21 Jul 2007 15:03:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6LM3cA0023885; Sat, 21 Jul 2007 22:03:38 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, 21 Jul 2007 15:03:38 -0700 Received: from [192.168.0.3] ([10.21.85.127]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 15:03:38 -0700 In-Reply-To: <46A1F2C4.9040605@firstpr.com.au> References: <469C962B.1090600@firstpr.com.au> <12D6E107-9D58-487A-BC5C-6BAC9495EC96@cisco.com> <46A084FE.9000003@firstpr.com.au> <46A1F2C4.9040605@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <717ED303-3EE5-4A84-9E9D-90F0F36B2377@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Date: Sat, 21 Jul 2007 15:03:31 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Jul 2007 22:03:38.0195 (UTC) FILETIME=[FDA69A30:01C7CBE2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=432; t=1185055418; x=1185919418; 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[RAM]=20LISP=20NERD/CONS, =20eFIT-APT=20&=20Ivip=20com pared |Sender:=20; bh=r0aypbPWc/jjyDOJlWFKrWk5o98WarLfFZ9P8N7yOP0=; b=E00SueG1c8Y46ELBTSkghg5uhUNcbbk9uEouy9C3t+vbFu4m1MuBOTTKcdOIEfThHW6XAXCe WcWT80j0PgNCwGOmGdTbCsuq6NN7+aLrYuVSInC0/VoAJIH9utT6bz2pWXx66rMNp32tVNVZno 1qkKsrELtgkFeXWY12Le3FsX8=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: "Templin, Fred L" , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Most importantly, I correct my mistake of not recognising that > that LISP-CONS does not contain any Priority or Weight information > in its mapping - which means that the LISP-CONS ITR has a simple > job, with no decisions or involvement in determining reachability. You are mistaken again. ;-) Section 6.4 of the CONS-01 draft illustrates that a priority and weight are associated with each locator record. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 21 22:07:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQql-0000wz-Qn; Sat, 21 Jul 2007 22:07:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQql-0000wt-3G for ram@iab.org; Sat, 21 Jul 2007 22:07:11 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICQqi-0005n8-LM for ram@iab.org; Sat, 21 Jul 2007 22:07:11 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 286C659E4D; Sun, 22 Jul 2007 12:07:04 +1000 (EST) Message-ID: <46A2BBBB.9000706@firstpr.com.au> Date: Sun, 22 Jul 2007 12:06:51 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared References: <469C962B.1090600@firstpr.com.au> <12D6E107-9D58-487A-BC5C-6BAC9495EC96@cisco.com> <46A084FE.9000003@firstpr.com.au> <46A1F2C4.9040605@firstpr.com.au> <717ED303-3EE5-4A84-9E9D-90F0F36B2377@cisco.com> In-Reply-To: <717ED303-3EE5-4A84-9E9D-90F0F36B2377@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, If I was confused about some aspects of LISP-CONS then I figure other people may have been confused too. When I wrote my comparison, it was my impression that in LISP-CONS, as in LISP-NERD LISP 1 and LISP 1.5 (though the I-D says very little about 1.5) that the mapping data contains potentially multiple RLOC addresses, each with a Weight and Priority. This is for the purpose of the ITR making its own decisions about which of the ETRs (one ETR is hopefully at each RLOC location) is currently reachable, including by receiving ICMP messages in response to encapsulated data packets which didn't make it to an ETR and probably also from messages sent by ETRs back to the ITR. So as part of my comparison I wrote (RW1): >> LISP-NERD/CONS: As noted above, ITRs have complex functions, >> including making decisions on a packet-by-packet basis for MH >> service restoration, TE and I think load balancing functions. >> The ITR may or may not communicate with the ETR, but I think >> the ITR is always ready to accept ICMP messages as sign it is >> tunneling the data packets to the wrong address. to which you replied (DF1): > I beg to differ. The ITR simply does a cache lookup on the DA > when the DA has a routing table miss or a default route match. > When the cache lookup returns an RLOC it slaps a header on. It's > as simple as that. which made me think that you were saying, in effect, that "ITRs don't have complex functions, they make no decisions about multihoming service restoration, traffic engineering or load balancing. ITRs don't communicate with the ETR and they don't accept ICMP messages." So I looked closely at the LISP-CONS I-D, in particular at this paragraph in 6.4: Priority, Weight, Unused, Loc-AFI, Locator: See [LISP-01] for details. Oh, so it's just like a Blackberry. and figured the first part of this meant that Priority and Weight were unused. This interpretation was compatible with my understanding of your comment DF1. So I spent several hours carefully reading: http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt http://www.dinof.net/~dino/ietf/draft-meyer-cons-01.txt and revising my comparison: http://www.firstpr.com.au/ip/ivip/comp/ with about 2000 words of text in green - in a version now archived at: http://www.firstpr.com.au/ip/ivip/comp/ archive-1.html (Please delete the spaces - I don't want this page found by search engines.) to make it compatible with my new understanding based on your comments, such as DF1 in: http://www1.ietf.org/mail-archive/web/ram/current/msg01730.html Now I think this was based on my mistaken understanding of DF1, because now you write (DF2): > Locator reachability is done outside of the mapping service. So > once an ITR gets a mapping, from any database mapping service, > it determines reachability from either ICMP unreachables or the > loc-reach-bits from returning packets. and (DF3): > No, the mapping data tells you want ETRs are configured for an > EID-prefix, regardless if they are up or down at the time the > mapping reply is received by any ITR. The understanding I gain from DF2 and DF3 is that the mapping information in LISP-CONS is the same or identical to that in LISP 1 and LISP-NERD, in that it includes potentially multiple RLOCs for each EID, with Weight and Priority for each RLOC, to help the ITR decide which to use, depending on various things such as how it does load balancing, what it finds out about reachability So my paragraph RW1 to which you responded with DF1 seems to have been correct. I don't see how your comment DF1, in the context of RW1, is compatible with your comments DF2 and DF3. Then: >> Most importantly, I correct my mistake of not recognising that >> that LISP-CONS does not contain any Priority or Weight >> information in its mapping - which means that the LISP-CONS ITR >> has a simple job, with no decisions or involvement in >> determining reachability. > You are mistaken again. ;-) Section 6.4 of the CONS-01 draft > illustrates that a priority and weight are associated with each > locator record. So I looked again at: Priority, Weight, Unused, Loc-AFI, Locator: See [LISP-01] for details. and see that this a list of fields, including the "Unused" field, to which we are referred to (now) LISP-02, which indicates that Priority and Weight are used. I have restored the original text of my comparison. I would appreciate it if you wrote to the list explaining what LISP does with multicast packets, because I don't understand section 9 of the LISP I-D. As far as I know, there are no packets to multicast addresses ever being handled by BGP routers, so I can't see why LISP or any of the other schemes should be concerned with them, as you suggest they should, in your message: http://www1.ietf.org/mail-archive/web/ram/current/msg01730.html > I haven't heard how any of the non-LISP proposals deal with > ISP-based traffic engineering and multicast. Also, it would be good if you could give some examples of ISP-based TE. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jul 22 00:12:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICSne-0007HJ-Sc; Sun, 22 Jul 2007 00:12:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICSnd-0007H5-Mc for ram@iab.org; Sun, 22 Jul 2007 00:12:05 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICSnd-0008E6-7a for ram@iab.org; Sun, 22 Jul 2007 00:12:05 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 21 Jul 2007 21:12:04 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAId0okarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,567,1175497200"; d="scan'208"; a="505722755:sNHT27966336" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6M4C4Hk013752; Sat, 21 Jul 2007 21:12:04 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6M4C14w020604; Sun, 22 Jul 2007 04:12:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 21:12:01 -0700 Received: from [192.168.0.3] ([10.21.89.104]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 21:12:00 -0700 In-Reply-To: <46A2BBBB.9000706@firstpr.com.au> References: <469C962B.1090600@firstpr.com.au> <12D6E107-9D58-487A-BC5C-6BAC9495EC96@cisco.com> <46A084FE.9000003@firstpr.com.au> <46A1F2C4.9040605@firstpr.com.au> <717ED303-3EE5-4A84-9E9D-90F0F36B2377@cisco.com> <46A2BBBB.9000706@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Date: Sat, 21 Jul 2007 21:11:54 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Jul 2007 04:12:00.0695 (UTC) FILETIME=[73C47470:01C7CC16] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2034; t=1185077524; x=1185941524; 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[RAM]=20LISP=20NERD/CONS, =20eFIT-APT=20&=20Ivip=20com pared |Sender:=20; bh=ZCWFZb3CPCHSuoiw34NdGlsF4WLPC0g9arGBeT1VMgw=; b=KCAnxC0QDMMllY4I3O2LvVHG2mpVQVAIWpTqct1nZ/9FymhC3nO3UxA2qj2nlrlhnx5gct4u XxWpfSYW13oBFFNItGId6GxKnVoAeWJwjlOFzvdDv6poLyrYs97UNxVwSo9wWEyXUmajf5w1Gt cgeFCuNufHYjOhsjRvXgCIncQ=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > If I was confused about some aspects of LISP-CONS then I figure > other people may have been confused too. > > When I wrote my comparison, it was my impression that in > LISP-CONS, as in LISP-NERD LISP 1 and LISP 1.5 (though the I-D > says very little about 1.5) that the mapping data contains > potentially multiple RLOC addresses, each with a Weight and > Priority. This is for the purpose of the ITR making its own > decisions about which of the ETRs (one ETR is hopefully at each > RLOC location) is currently reachable, including by receiving ICMP > messages in response to encapsulated data packets which didn't > make it to an ETR and probably also from messages sent by ETRs > back to the ITR. > > So as part of my comparison I wrote (RW1): > >>> LISP-NERD/CONS: As noted above, ITRs have complex functions, >>> including making decisions on a packet-by-packet basis for MH >>> service restoration, TE and I think load balancing functions. >>> The ITR may or may not communicate with the ETR, but I think >>> the ITR is always ready to accept ICMP messages as sign it is >>> tunneling the data packets to the wrong address. > > to which you replied (DF1): > >> I beg to differ. The ITR simply does a cache lookup on the DA >> when the DA has a routing table miss or a default route match. >> When the cache lookup returns an RLOC it slaps a header on. It's >> as simple as that. I was talking about forwarding time. Once reachability is determined to a set of locators at control-time, they are programmed in hardware so the ITR forwarding time decision is to just use a preprogrammed encapsulation. > So I looked closely at the LISP-CONS I-D, in particular at this > paragraph in 6.4: > > Priority, Weight, Unused, Loc-AFI, Locator: See [LISP-01] for > details. Oh, so it's just like a Blackberry. These are the names of fields in the packet format description of the Map-Reply. In the CONS draft it is saying to refer to the LISP draft for details. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jul 22 12:22:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICeA9-0007qZ-Ix; Sun, 22 Jul 2007 12:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICeA8-0007qT-2o for ram@iab.org; Sun, 22 Jul 2007 12:20:04 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICeA7-0008Ut-Kt for ram@iab.org; Sun, 22 Jul 2007 12:20:04 -0400 Received: by ug-out-1314.google.com with SMTP id c2so989365ugf for ; Sun, 22 Jul 2007 09:20:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Xeq2IYGB4WQVc+w+w4TpMjt6Lp6F6p+83ipiy4psiFv9j28wrKmnW/L+x3EkYYSgOVbBagMNbqOpmmGrg6wwAamfhdXSjY6LwWDsPlzCU0fNsolxUINi+ViNLNK7lztuQ0osdhkwBSwlI42Vuhu4b5qoYlzjj7Osi3o6F7w6sZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=dlzyUYWDD+UUqk7olNqyrxQnsnJ1w4TRKs8hNps43Blcb7ajbnlFf+3d4YQw9gF0SnaapekMClmlXRGKbS1qj8HW/c+4YJw8ojZ1hQstAOWUjknuHej8HcuIZNSLEW8V16mzpn4CffSPn8BHAd1hHc+pyKENNcT6fsNQQ1/hGmo= Received: by 10.86.65.11 with SMTP id n11mr1854441fga.1185121202553; Sun, 22 Jul 2007 09:20:02 -0700 (PDT) Received: from ?130.129.80.134? ( [130.129.80.134]) by mx.google.com with ESMTPS id 2sm12645956nfv.2007.07.22.09.20.00 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Jul 2007 09:20:01 -0700 (PDT) Message-ID: <46A383AE.50803@gmail.com> Date: Sun, 22 Jul 2007 18:19:58 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Per Heldal Subject: Re: [RAM] IPv6 /32 to /48 prefixes and Tree-Bitmap FIB speed References: <469F5757.9040700@firstpr.com.au> <46A01BD7.80802@firstpr.com.au> <1184919681.19192.48.camel@localhost.localdomain> In-Reply-To: <1184919681.19192.48.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-07-20 10:21, Per Heldal wrote: > On Fri, 2007-07-20 at 12:20 +1000, Robin Whittle wrote: >> Thanks for answering my questions about /48s and for pointing me >> to the guidelines which some or many people follow - Gert >> Doering's page: >> >> http://www.space.net/~gert/RIPE/ipv6-filters.html >> > > In the absence of scalable IDR and route-certificates you'll also find > people using more strict filters in an attempt to achieve operational > stability. Such filters aim to keep the maximum numbers of prefixes > within the capacity of available hardware. Thus, if a registry allocates > blocks out of e.g. a /23 only a small fraction of that /23 may initially > be accepted, especially if it is used for PI /48s. The current v6 > routing-table may be small, but I'm sure attitudes will change as more > people realise the potential impact on their infrastructure as it > becomes increasingly common to operate dual-stack networks. Exactly, and a DFZ with ten million /48s seems to be an unlikely end-point, which is why we are here, I thought. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jul 22 17:43:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICjAl-0001MZ-99; Sun, 22 Jul 2007 17:41:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICjAj-0001MS-TC for ram@iab.org; Sun, 22 Jul 2007 17:41:01 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICjAj-0005Y6-5a for ram@iab.org; Sun, 22 Jul 2007 17:41:01 -0400 Received: by ug-out-1314.google.com with SMTP id c2so1037202ugf for ; Sun, 22 Jul 2007 14:41:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=D0qNvTvPF8PrBMW/UzmH+nAuFMsJPz4L7Ha4jcmUn3SYJ/2Kvytr83jzCUJq3317QQypBJ1eGWxjCJy5VdL+LTSa7rwGq774I09Rf0DgXUaH3QkZRT2xKE7Khqj7Ae7J0Yp+DZkamYZmn/F5ONjWB2k432vuuW2bdaIxVDbBY/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LoMlWGVB7fS826+rBgHTnW6eIbfFEls00othwKQ50CK2Yk6YYl1H8AU9kJologTdqq/9RBpqX1pjSvwsa5vvfl5XfyXMGChJTHSZcznmAgYajLf5U/55i9Vrpmzuksyow9E2JHG/IBaYS/iPo+DggDDVIBICIuZnuynTfEV7/CQ= Received: by 10.66.219.11 with SMTP id r11mr3704543ugg.1185140459988; Sun, 22 Jul 2007 14:40:59 -0700 (PDT) Received: from ?172.28.171.186? ( [67.97.210.2]) by mx.google.com with ESMTPS id c9sm5938949nfi.2007.07.22.14.40.58 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Jul 2007 14:40:59 -0700 (PDT) Message-ID: <46A3CEE9.5080008@gmail.com> Date: Sun, 22 Jul 2007 23:40:57 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] New LISP draft available ... References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> In-Reply-To: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-07-17 19:56, Dino Farinacci wrote: > We have a new LISP-02 draft available. The packet formats are consistent > with CONS-01 as well as the implementation we are testing. > > The draft has been submitted to the ID directory, but you can find a > draft at: > > http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt A few comments on this version... General points that aren't mentioned and perhaps should be: MTU size reduction Fragmentation (in IPv4) Referrals (host A passes an address for host B to host C) > 4.1. Packet Flow Sequence ... > 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. > It does a DNS lookup on host2.xyz.com. An A record is returned. > This address is used as the destination EID and the locally- > assigned address of host1.abc.com is used as the source EID. An > IP packet is built using the EIDs in the IP header and sent to > the default router. 'default router' seems wrong (it would typically be understood to mean the default router on the host's LAN). Doesn't this mean 'a site egress router' (which is ingress to the LISP domain)? > 5.3. Tunnel Header Field Descriptions ... > o The OH header Time to Live field MUST be copied from the IH header > Time to Live field. > > o The OH header Type of Service field SHOULD be copied from the IH > header Type of Service field. Does this apply when encapsulating across versions (4 in 6 or 6 in 4)? In any case the terminology is slightly different in v6 headers. In the v6 case, does it apply to the flow label too? In 6.1.1 and elswhere you give RFC2434 as a reference for AFIs. There's nothing about AFIs in that RFC; in fact AFI documentation is a bit of a mystery. In 6.1.3: > Priority: each RLOC is assigned a priority. Lower values are more > preferable. When multiple RLOCs have the same priority, they are > used in a load-split fashion. A value of 255 means the RLOC MUST > NOT be used. Then why waste bits sending that RLOC? > Weight: when priorities are the same for multiple RLOCs, the weight > indicates how to balance traffic between them. Weight is encoded > as a percentage of total packets that match the mapping entry. If > a non-zero weight value is used for any RLOC, then all RLOCs must > use a non-zero weight value and then the sum of all weight values > MUST equal 100. What did the 3rd grader say after Steve Jobs gave > an iPhone demo to the class? It doesn't add up? > ... If a zero value is used for any RLOC > weight, then all weights MUST be zero and the receiver of the Map- > Reply will decide how to load-split traffic. That MUST condition seems pointless. If there is any zero value, the other values don't matter. > 6.2. Routing Locator Selection ... > o Server-side returns a list of RLOC where a subset of the list has > the same best priority. Client can only use the subset list > according to the weighting assigned by the server-side. In this > case, the server-side controls both the subset list and load- > splitting across its members. That rule doesn't seem viable or enforcable. The client side may simply not desire to take orders on how to load share, and that could be a business issue (if the client has ISP preferences for example). I think it needs to be "Client SHOULD only use the subset list according to the weighting assigned by the server-side." Nit: the citations of RFC3056 and RFC2784 are inverted in the text. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jul 22 22:07:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICnJE-0002fP-UL; Sun, 22 Jul 2007 22:06:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICnJD-0002fJ-Ad for ram@iab.org; Sun, 22 Jul 2007 22:06:03 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICnJB-0001Pn-Ql for ram@iab.org; Sun, 22 Jul 2007 22:06:03 -0400 Received: from [192.168.251.111] (mpwr-static-216.70.191.48.mpowercom.net [216.70.191.48] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l6N22hbi026712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jul 2007 04:02:45 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Sun, 22 Jul 2007 20:47:46 -0500 To: Geoff Huston X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-2.6 required=3.5 tests=BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: RAM Mailing List Subject: [RAM] IDR tutorial and shortest path X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Geoff, Some musings about shortest path determination algorithms that came to mind while listening to your IDR tutorial this afternoon. I think that they're relevant for a wider audience so I'm CCing the RAM list. But first: Bellman wrote a paper in 1956: http://stinet.dtic.mil/oai/oai? &verb=getRecord&metadataPrefix=html&identifier=AD0606258 You can even buy it from the RAND corporation half a century later: http://www.rand.org/pubs/papers/P1000/ [explanation of both algorithms, skip if known] The Bellman-Ford algorithm and the Dijkstra / shortest path first algorithm are often presented as two different approaches to routing. I recently had occasion to read up on those algorithms, and in their pure form, they actually do the exact same thing: determine the shortest path from a certain starting point to another point or all other points. I.e., the problem that they both solve is the "shortest path" problem. The Bellman-Ford approach is communicate known information to neighbors and iterate this process until all information has propagated everywhere, where the number of iterations is the maximum number of hops, either in the topology or supported by the protocol executing the algorithm. Dijkstra's algorithm starts at the starting point and then hunts for short paths from known places towards yet unknown places or over yet unused links. Hence the name "shortest path first". [/end explanation] End result: both algorithms do the exact same thing, but the SPF algorithm is much faster than the Bellman-Ford algorithm, under the same circumstances. So why do we use Bellman-Ford if it's so much slower? Because it is essentially a distributed algorithm where each node only has to do a simple computation over the information that is available locally at that point in time, while the SPF optimizations pretty much require all information to be present before the algorithm can be run. So in the case of distance vector or distance path routing protocols, where only the minimum information required to perform routing is exchanged, Bellman-Ford is great, because you can simply do an iteration as new information becomes available. The downside is the count to infinity problem, which leads to loops in distance vector and the exploration of all loopfree paths in order of increasing length in distance path. And as we've learned with BGP, delays in sending updates slow down convergence while having multiple parallel paths tends to amplify updates, causing additional unnecessary iterations of the route selection process. In link state protocols, all information is flooded to all nodes which then all individually solve the shortest path problem. This means that a fast algorithm like Dijkstra's SPF is preferable over a slower one like Bellman-Ford, and the presence of all information before the algorithm is executed nicely fulfills the requirements of SPF. So the important difference is link state on the one hand versus distance vector and distance path on the other, not Dijkstra versus Bellman-Ford. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 23 18:33:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6Sp-0006BI-TT; Mon, 23 Jul 2007 18:33:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6Sp-0006BD-0X for ram@iab.org; Mon, 23 Jul 2007 18:33:15 -0400 Received: from cheetah.cs.ucla.edu ([131.179.128.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID6Sn-0005fz-Gq for ram@iab.org; Mon, 23 Jul 2007 18:33:14 -0400 Received: from cheetah.cs.ucla.edu (localhost [127.0.0.1]) by cheetah.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l6NMX6Vd010686; Mon, 23 Jul 2007 15:33:06 -0700 (PDT) Received: from localhost (jenster@localhost) by cheetah.cs.ucla.edu (8.13.8+Sun/8.13.8/Submit) with ESMTP id l6NMX1VD010683; Mon, 23 Jul 2007 15:33:01 -0700 (PDT) X-Authentication-Warning: cheetah.cs.ucla.edu: jenster owned process doing -bs Date: Mon, 23 Jul 2007 15:33:01 -0700 (PDT) From: Dan Jen To: ram@iab.org Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: meisel@CS.UCLA.EDU, rw@firstpr.com.au X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin, thank you for putting so much work into this! Michael and I think you've done an excellent job analyzing APT, but there are a few inaccuracies and misunderstandings we wanted to respond to. See below. Robin Whittle wrote: > LISP-APT (APT is only intended for eFIT.) The wording is too strict. While APT was intended for eFIT, its main design concepts are generalizable towards any similar routing architecture. With a few modifications, we expect that APT can be made to work with LISP. In your post, you choose not to "consider how LISP might work with APT", which is fine. We are just pointing out that APT is not limited to ONLY working with eFIT. > the same concept in eFIT-APT: "updated mapping entry" - which are > real-time, local, push messages directed to the caching ITRs (and > for Ivip, the caching Query Servers) which they query. This is inaccurate. Default mappers never push unsolicited mapping entry updates to their tunnel routers. A default mapper will only send mapping entry information to a TR when the TR requests this information (by forwarding a data packet to the default mapper). Thus local mapping entry updates are strictly pull messages. Mapping entry TTLs within a TR cache ensure that tunnel routers pull updated mapping entry info as frequently as desired. Perhaps our paper was unclear on this point. We will try to rectify this in future drafts. > Each transit network is expected to run at least one "Default > Mapper", which may be router (at least it can encapsulate > packets, even if it only has one interface), and which has a > real-time updated copy of the entire eFIT-APT mapping > database. (Except in the future for IPv6 - section 7.4.) Actually, it's likely to be the case with IPv6 that every default mapper still stores the full table. We meant section 7.4 as a contingency plan, just in case the global mapping table actually approaches its theoretical maximum size under IPv6. Note that 10^18 is eight orders of magnitude greater than the human population of the earth, so we aren't likely to actually use all of those prefixes any time soon. > Default Mappers also have the equivalent of an Ivip "Notify": > "M1 can respond with an updated mapping entry". There's > no mention of the ITR having to acknowledge this - and even > if it did, if anycast is used, it would be difficult to ensure > that the ack would go to the correct Default Mapper. Both > Ivip and APT should have a way of ensuring the updated mapping > information really has been received by the ITR (APT) or QSC, > ITRC or ITFH (Ivip) it was sent to. We're not sure what you're referring to here. We don't have any push messages from the default mapper, and, as you mentioned before, the worst thing that can happen if an ICMP mapping response packet is lost is that the next packet goes through the default mapper as well. > Devolving the multihoming link selection problem, and the TE > functions, to the Default Mapper is a good idea, I think, but > involves more ICMP packets to ITRs with "updated mapping > entry" information. As noted above, I don't see any provision > in APT for this to be delivered in a reliable manner. There > also needs to be some crypto or protection against an attacker > spoofing packets with the Default Mapper's address, to ensure > the ITR's cache is not corrupted by someone who wants to steer > packets to their own address. We think perhaps you misunderstood our use of TTLs. The TTL is in theITR, not the default mapper. The default mapper only tells the ITR whatvalue to use. When a TTL expires, the ITR invalidates its corresponding cache entry completely. As you mentioned, the worst thing that happens in the case of a lost ICMP mapping reply packet is that the next packet gets sent to the default mapper as well. In regards to their security, we discuss this in section 7.2 of our draft. ICMP mapping packets never need to travel between ASes, so we insist that they always be dropped at the border routers within transit space. This means that they can only be spoofed in any given AS by a device within that AS. I suppose we could sign them, but we didn't really see a need. > eFIT-APT: Not documented, but APT mentions an ICMP Destination > Unreachable message being generated if the encapsulated packet > does not reach an ETR, so I guess this means UDP encapsulation > with outer SA = ITR (or Default Mapper) address, similar to that > described in LISP-01's description of LISP 1 / 1.5. Not sure if this is correct. It sounds like you believe that Destination Unreachable ICMP packets are generated whenever encapsulated packets are lost. Is this your thought? Is this why you also believe that we expect UDP encapsulation? Destination Unreachable ICMP packets in APT are used in the same way that they are used today. The messages are only generated when the destination router cannot be reached due to a malfunction of some subset of routers. Again, we are not sure if there is a misunderstanding here. > If an end user is with provider X, using some of their PA > addresses, could they go to another provider Y for connectivity, > or X and Y or Y and Z for multihoming, and still have to rely on X > to to the mapping the way they want? > > What if an AS-end-user with their own PI space is currently > connecting with provider X. If they want to move to provider Y, > does this means that X's Default Mapper no longer is > authoritative, and that Y's is? I am confused about exactly how > eFIT-APT works. It's the customer that is ultimately authoritative for their own mapping, even though their transit-space addresses are provider-assigned. We expect that ALL of a customer's providers will announce the same mapping information on their behalf. All of these mappings should be completely identical (and contain all of the customer's ETR addresses at all of their providers). One thing we have discussed (which is not in the draft) to ensure that they are indeed identical is to allow customers to cryptographically sign their mappings. In combination with the misconfiguration detection scheme we discuss in section 7.1, this should prevent providers from being able to affect the global mapping table with a mismatched mapping. > With LISP and Ivip, ETR and ITR functions may often be in the same > device. ETR and ITRs always being in the one device is enforced > by the current definition of eFIT-APT - but I don't see why the > system needs to be so inflexible. You're right, there isn't any good reason. > Having the ITR and ETR functions fixed at > these routers - Provider Edge routers I think - seems likely to > produce a bottleneck and burden these routers with even greater > workloads. This may also preclude doing ETR or ITR functions in > servers, which may be more cost effective than routers with all > the new functionality. We aren't sure we understand -- are you trying to say that the TRs' functionality is too complex for routers but requires too much speed for servers? We believe that this functionality should be well within the capabilities of routers, that was part of the reason we tried to keep TRs as simple as possible. > eFIT-APT: The placement of TRs is specifically limited to the > border routers between providers and their non-provider "customer" > networks. ETRs have complex communication functions, including > detecting failure of the link to the end-user's host or router. > They send messages to their local Default Mapper and to the ITR > function of the TR which encapsulated the packet (which can > include the Default Mapper of the sender's network). We aren't hardware experts, but it seems to us that these aren't particularly complex functions for routers. Routers already detect BGP connection failures. Border link failure detection could also be implemented as a persistent TCP connection. (Note that it is only the customer-edge-to-provider-edge link that needs to be monitored.) Routers also already send ICMP packets in response to certain incoming packets (Destination unreachable and so on). > With eFIT-APT, there would be no > benefit for early adopters (no portability without grave loss of > reachability - and TE only for packets from upgraded networks) and > no benefit for the whole network (removal of prefixes from the BGP > routing table) until virtually all networks had upgraded. Good point. We will include an incremental deployment plan in detail in a future draft. Hopefully, we can address many of your concerns in this area. - Dan and Michael _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jul 23 23:36:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDBC0-00015w-59; Mon, 23 Jul 2007 23:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDBBz-00015r-14 for ram@iab.org; Mon, 23 Jul 2007 23:36:11 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDBBt-00033W-Va for ram@iab.org; Mon, 23 Jul 2007 23:36:11 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id B0D7559DDD; Tue, 24 Jul 2007 13:36:00 +1000 (EST) Message-ID: <46A5738F.103@firstpr.com.au> Date: Tue, 24 Jul 2007 13:35:43 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: meisel@CS.UCLA.EDU, Dan Jen X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Thanks Dan and Michael for your appreciative message and for correcting my misunderstandings. You wrote, in part: > Robin Whittle wrote: > > LISP-APT (APT is only intended for eFIT.) > > The wording is too strict. While APT was intended for eFIT, its main > design concepts are generalizable towards any similar routing > architecture. With a few modifications, we expect that APT can be made > to work with LISP. In your post, you choose not to "consider how LISP > might work with APT", which is fine. We are just pointing out that APT > is not limited to ONLY working with eFIT. I have updated my comparison: http://www.firstpr.com.au/ip/ivip/comp/ to reflect this and other matters you raise. If there is a document which describes how APT applies to LISP, then I or someone else might want to do a comparison between that and LISP-NERD, LISP-CONS, eFIT-APT and Ivip. Alternatively, perhaps someone could write about the differences between LISP 3.x in general and eFIT: what they have in common, what one or the other lacks and/or what one or the other adds. BTW, in my last message I indicated that after the confusion I had with LISP-CONS, I removed all my changes in green from the comparison. However I have retained some changes to reflect what Dino wrote about an ITR encapsulating packets sent by hosts from non-upgraded networks via advertising the LISP-mapped prefix in BGP, from a single provider network. > > the same concept in eFIT-APT: "updated mapping entry" - which are > > real-time, local, push messages directed to the caching ITRs (and > > for Ivip, the caching Query Servers) which they query. > > This is inaccurate. Default mappers never push unsolicited mapping > entry updates to their tunnel routers. A default mapper will only send > mapping entry information to a TR when the TR requests this information > (by forwarding a data packet to the default mapper). Thus local mapping > entry updates are strictly pull messages. Mapping entry TTLs within a TR > cache ensure that tunnel routers pull updated mapping entry info as > frequently as desired. > > Perhaps our paper was unclear on this point. We will try to rectify this > in future drafts. OK - this was my mistake interpreting: At this time, if the mapping information changed in any way since ITR1's prior request, M1 can respond with an updated mapping entry. Looked at in isolation, this seemed to me to indicate that the Default Mapper could choose ("can") whether or not to send an updated mapping entry. I interpreted this as it choosing to send something or not. In fact, as I understand it now, the Default Mapper always responds to a query with the latest mapping data, which may be different from what it sent last time - but it is not really a choice to send or not send something. A more careful reading in the context makes it harder to misinterpret this sentence - it is all to do with the ITR sending a request for mapping (in the form of a user packet which it currently doesn't have mapping data for). Perhaps you could change this to be: At this time, M1 will respond with the mapping information, which may be the same as specified in the previously sent response or which would be different if M1 had received an update message which affected this mapping since it sent the previous mapping information to the ITR. This substantially changes my understanding of the responsiveness of eFIT-APT. I had thought that eFIT-APT had something like Ivip's "Notify" function. Now I understand that of these proposals, only Ivip attempts to push "Notify" messages to caching ITRs which need it - or at least probably need it, on the basis they will probably have to encapsulate more packets which need this mapping, before the caching time for the old, and now incorrect, mapping expires. This means that all three other proposals - LISP-NERD, LISP-CONS and eFIT-APT rely on short caching times to achieve rapid multihoming service restorations. This means the enquiry and response traffic (LISP-CONS and eFIT-APT) or the polling traffic for database update files (LISP-NERD) rises dramatically as the caching time is shortened in an attempt to speed service restoration times. > > Each transit network is expected to run at least one "Default > > Mapper", which may be router (at least it can encapsulate > > packets, even if it only has one interface), and which has a > > real-time updated copy of the entire eFIT-APT mapping > > database. (Except in the future for IPv6 - section 7.4.) > > Actually, it's likely to be the case with IPv6 that every default mapper > still stores the full table. We meant section 7.4 as a contingency plan, > just in case the global mapping table actually approaches its > theoretical maximum size under IPv6. Note that 10^18 is eight orders of > magnitude greater than the human population of the earth, so we aren't > likely to > actually use all of those prefixes any time soon. OK - I have amended this to: (Except perhaps in the future for IPv6 when the mapping database could theoretically grow to immense proportions - section 7.4.) > > Default Mappers also have the equivalent of an Ivip "Notify": > > "M1 can respond with an updated mapping entry". There's > > no mention of the ITR having to acknowledge this - and even > > if it did, if anycast is used, it would be difficult to ensure > > that the ack would go to the correct Default Mapper. Both > > Ivip and APT should have a way of ensuring the updated mapping > > information really has been received by the ITR (APT) or QSC, > > ITRC or ITFH (Ivip) it was sent to. > > We're not sure what you're referring to here. We don't have any push > messages from the default mapper, and, as you mentioned before, the > worst thing that can happen if an ICMP mapping response packet is lost > is that the next packet goes through the default mapper > as well. This is based on the first misunderstanding noted above. I have revised the comparison by putting a strikethrough through this paragraph. My last sentence only refers to my mistaken idea of the Default Mapper pushing updated mapping to the ITR and needing to be sure it got it. This problem does not apply to a response to a query, because as you write, if the response is lost, there will simply be another query - and the Default Mapper always encapsulates the user packets which are the vehicle for the query. > > Devolving the multihoming link selection problem, and the TE > > functions, to the Default Mapper is a good idea, I think, but > > involves more ICMP packets to ITRs with "updated mapping > > entry" information. As noted above, I don't see any provision > > in APT for this to be delivered in a reliable manner. Reliability could have various aspects. Now I know there is no push "Notification" (cache invalidation) there is no need to ensure the mapping responses really are received - so that is one aspect of "reliable". The other aspect of reliability is security - preventing the ITR from taking notice of spoofed packets, which is what I refer to here: > > There > > also needs to be some crypto or protection against an attacker > > spoofing packets with the Default Mapper's address, to ensure > > the ITR's cache is not corrupted by someone who wants to steer > > packets to their own address. > > We think perhaps you misunderstood our use of TTLs. The TTL is in > theITR, not the default mapper. The default mapper only tells the ITR > whatvalue to use. When a TTL expires, the ITR invalidates its > corresponding cache entry completely. As you mentioned, the worst thing > that happens in the case of a lost ICMP mapping reply packet is that the > next packet gets > sent to the default mapper as well. > > In regards to their security, we discuss this in section 7.2 of our > draft. ICMP mapping packets never need to travel between ASes, so we > insist that they always be dropped at the border routers within transit > space. This means that they can only be spoofed in any given AS by a > device within that AS. I suppose we could sign them, but we didn't > really see a need. OK. I will add a note about this to the comparison, quoting some of your message and referring to this message in the RAM archives. I think this places a considerable burden on the border routers of the AS, since they need to do deep packet inspection on every ICMP packet which comes in. > > eFIT-APT: Not documented, but APT mentions an ICMP Destination > > Unreachable message being generated if the encapsulated packet > > does not reach an ETR, so I guess this means UDP encapsulation > > with outer SA = ITR (or Default Mapper) address, similar to that > > described in LISP-01's description of LISP 1 / 1.5. > > Not sure if this is correct. It sounds like you believe that Destination > Unreachable ICMP packets are generated whenever encapsulated packets are > lost. > Is this your thought? Is this why you also believe that we expect UDP > encapsulation? > > Destination Unreachable ICMP packets in APT are used in the same way > that they are used today. The messages are only generated when the > destination router cannot be reached due to a malfunction of some subset > of routers. > > Again, we are not sure if there is a misunderstanding here. I was trying to imply from other aspects of your draft what sort of encapsulation eFIT-APT would use. I can find no mention in: http://tools.ietf.org/html/draft-jen-apt-00 of either UDP or IP-in-IP. Perhaps you use the same encapsulation as LISP: . . . the ingress tunnel router, or "ITR", as defined in [LISP] The reference is to LISP-00 which used IP-in-IP, but now LISP-01/02 uses UDP. What sort of encapsulation do you use? Is the SA (Source Address) of the outer header that of the ITR or of the sending host? LISP uses the ITR's address but Ivip uses the sending host's address, to help with filtering (to prevent ETRs being used to circumvent local address spoofing). I think it also helps with Path MTU auto-discovery, by removing the need for the ITR to handle ICMP packets and to try to figure out which sending host's encapsulated packets resulted in the ICMP packet being sent. > > If an end user is with provider X, using some of their PA > > addresses, could they go to another provider Y for connectivity, > > or X and Y or Y and Z for multihoming, and still have to rely on X > > to to the mapping the way they want? > > > > What if an AS-end-user with their own PI space is currently > > connecting with provider X. If they want to move to provider Y, > > does this means that X's Default Mapper no longer is > > authoritative, and that Y's is? I am confused about exactly how > > eFIT-APT works. > > It's the customer that is ultimately authoritative for their own > mapping, even though their transit-space addresses are > provider-assigned. We expect that ALL of a customer's providers will > announce the same mapping information on their behalf. All of these > mappings should be completely identical (and contain all of the > customer's ETR addresses at all of their providers). One thing we have > discussed (which is not in the draft) to ensure that they are indeed > identical is to allow customers to cryptographically sign their > mappings. In combination with the misconfiguration detection scheme we > discuss in section 7.1, this should prevent providers from being able to > affect the global mapping table with a mismatched mapping. OK - I have a rough idea of what you are proposing. I have quoted this in the comparison page. I understand from this that the end-user needs to have their own server, or secure messaging system, to control the mapping data for their prefix which multiple Default Mappers in multiple provider networks advertise via new BGP messages. Is this a transition arrangement or a permanent one? An end-user leaves ISP-X for ISP-Y and ISP-Z - then all three could be advertising the same mapping information for a while, until the end-user no-longer needs ISP-X? I tried to imagine my own approach to incrementally introducing eFIT-APT, whilst preserving full reachability from hosts in non-upgraded networks. (Any approach which does not achieve this will be non-incrementally deployable and I think will never get off the ground.) I would really appreciate you writing more on incremental adoption, because the best I can imagine for eFIT-APT results in my critique: With eFIT-APT, there would be no benefit for early adopters (no portability without grave loss of reachability - and TE only for packets from upgraded networks) and no benefit for the whole network (removal of prefixes from the BGP routing table) until virtually all networks had upgraded. > > With LISP and Ivip, ETR and ITR functions may often be in the same > > device. ETR and ITRs always being in the one device is enforced > > by the current definition of eFIT-APT - but I don't see why the > > system needs to be so inflexible. > > You're right, there isn't any good reason. OK - removing this would give more flexibility and give your proposal more in common with LISP or Ivip. > > Having the ITR and ETR functions fixed at > > these routers - Provider Edge routers I think - seems likely to > > produce a bottleneck and burden these routers with even greater > > workloads. This may also preclude doing ETR or ITR functions in > > servers, which may be more cost effective than routers with all > > the new functionality. > > We aren't sure we understand -- are you trying to say that the TRs' > functionality is too complex for routers but requires too much speed for > servers? We believe that this functionality should be well within the > capabilities of routers, that was part of the reason we tried to keep > TRs as simple as possible. I think that the complex communications which LISP and eFIT-ETR ITRs engage in, handling ICMP messages etc. - makes them hard to implement on on ordinary router, because these are bound to involve the router's main CPU (as far as I know) and that is busy enough as it is. For Ivip, I can imagine a plain server with suitable software being a full database ITRD, doing up to half a gigabit of ITR encapsulation, because there are no decisions to make about which address to tunnel to, no ICMP messages to take notice of etc. I imagine a motherboard with two gigabit Ethernet interfaces. It appears from: http://docs.rodecker.nl/10-GE_Routing_on_Linux.pdf http://www.rodecker.nl/docs/10-GE_Routing_on_Linux.pdf (which I can't reach right now, but search Google for "10-GE_Routing_on_Linux" and read its cache) that a high-end server can pump 700,000 packets a second, which is 4gigabits in both directions at once for maximum packet size. So my 0.5 gigabit estimate is a very rough and modest guess. That server-based ITR could be a stub, with a single Ethernet link to some other router - so it is not technically a router in the usual sense because it only has one interface and it has no hardware FIB. I also envisage caching ITRs in servers and in sending hosts. With the current definition of eFIT-APT, it would not be practical to use servers at all for ITR functions, because you locate the ITR functions exactly in the CE routers, which have to be real routers with hardware FIBs, multiple interfaces etc. A server can't do all the things a CE router must do, but it could do an Ivip-style ITR function. A server could probably also be used to do the more complex ITR functions of LISP or APT, but not if these functions had to be in a conventional router. > > eFIT-APT: The placement of TRs is specifically limited to the > > border routers between providers and their non-provider "customer" > > networks. ETRs have complex communication functions, including > > detecting failure of the link to the end-user's host or router. > > They send messages to their local Default Mapper and to the ITR > > function of the TR which encapsulated the packet (which can > > include the Default Mapper of the sender's network). > > We aren't hardware experts, but it seems to us that these aren't > particularly complex functions for routers. Routers already detect BGP > connection failures. Border link failure detection could also be > implemented as a persistent TCP connection. (Note that it is only the > customer-edge-to-provider-edge link that needs to be monitored.) Routers > also already send ICMP packets in response to certain incoming packets > (Destination unreachable and so on). I can't say how much of APT's or LISP's ITR functions can be implemented in the hardware FIB of existing routers or to what degree the traffic load would be too burdensome for the central CPUs of existing routers. My aim with Ivip is to keep the ITR and ETR functions simple, with no communication, no reception of ICMP messages etc. other than the communication required for an ITRD to get its full database feed or for an ITRC or ITFH to query a QSD/QSC query server, and receive "Notify" messages pushed from the QSD/QSC to it when mapping changes for some range of addresses for which the ITR is currently caching mapping. > > With eFIT-APT, there would be no > > benefit for early adopters (no portability without grave loss of > > reachability - and TE only for packets from upgraded networks) and > > no benefit for the whole network (removal of prefixes from the BGP > > routing table) until virtually all networks had upgraded. > > Good point. We will include an incremental deployment plan in detail in a > future draft. Hopefully, we can address many of your concerns in this area. That will be good. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 24 03:57:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDFGx-0002Tj-NR; Tue, 24 Jul 2007 03:57:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDFGw-0002Td-DJ for ram@iab.org; Tue, 24 Jul 2007 03:57:34 -0400 Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDFGu-000867-K4 for ram@iab.org; Tue, 24 Jul 2007 03:57:34 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l6O7vONt016914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jul 2007 09:57:24 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l6O7vNm8023985; Tue, 24 Jul 2007 09:57:23 +0200 Date: Tue, 24 Jul 2007 09:57:22 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Dino Farinacci Subject: Re: [RAM] New LISP draft available ... In-Reply-To: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> Message-ID: References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.62 on 129.242.5.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: roger@jorgensen.no, RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Tue, 17 Jul 2007, Dino Farinacci wrote: > We have a new LISP-02 draft available. The packet formats are consistent with > CONS-01 as well as the implementation we are testing. > > The draft has been submitted to the ID directory, but you can find a draft > at: > > http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt > > This version is formatted much better. ;-) > > This draft also reflects comments from Ved Kafle and Olivier Bonaventure. a few more general question/clearification around the draft in general just to see if I understood it correct. Also fun to read those small comments on Steve Jobs and iPhone :) In section 3, you mentio about EID: " The source EID is obtained via existing mechanisms used to set a hosts "local" IP address. LISP uses PI blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner," Why restrict it to PI addresses there? If, because no one know how it is moving on, ULA-C/G are approved and getting into use, they would be almost perfect for this usage. Next thing, EID-prefix, that would be the above mention IP block? Also in Section 4.1 (page 9-10), the example was worded so it could be read that it is Ipv4 only. I know thats not true but maybe change the wording a bit? A change like this could be enough: "This section provides an example of a IPv4 unicast packet flow with the following parameters:" -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 24 17:42:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS9V-0002xb-9V; Tue, 24 Jul 2007 17:42:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS9T-0002xM-8d for ram@iab.org; Tue, 24 Jul 2007 17:42:43 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDS9R-0003ln-Qq for ram@iab.org; Tue, 24 Jul 2007 17:42:43 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 22:42:41 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] New LISP draft available ... Date: Tue, 24 Jul 2007 22:42:40 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA50132C128@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] New LISP draft available ... Thread-Index: AcfNyFWu511SEk0xSR2uRqeuG52TGgAcUVwY References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> From: To: X-OriginalArrivalTime: 24 Jul 2007 21:42:41.0033 (UTC) FILETIME=[8F902790:01C7CE3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org hi =20 what's the relationship between the variants of lisp? Is it considered = that an operator would migrate through the 4 steps lisp 1 -> 1.5 -> 2 -> = 3? Could the variants co-exist? Or are they really 4 independent = proposals? ('independent' meaning you make a choice of which *one* to = deploy) =20 since lisp 1 uses routable EIDs, will it get the benefits hoped for a = locator/ID split approach (in terms of the design goals in = draft-irtf-rrg-design-goals)? =20 sorry if questions have already been covered=20 =20 thanks, phil ________________________________ On Tue, 17 Jul 2007, Dino Farinacci wrote: > We have a new LISP-02 draft available. The packet formats are = consistent with > CONS-01 as well as the implementation we are testing. > > The draft has been submitted to the ID directory, but you can find a = draft > at: > > http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt > > This version is formatted much better. ;-) > > This draft also reflects comments from Ved Kafle and Olivier = Bonaventure. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 24 20:46:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDV0i-000596-5E; Tue, 24 Jul 2007 20:45:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDV0h-000591-PV for ram@iab.org; Tue, 24 Jul 2007 20:45:51 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDV0f-0007Aj-Sl for ram@iab.org; Tue, 24 Jul 2007 20:45:51 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 1D92459E3F; Wed, 25 Jul 2007 10:45:46 +1000 (EST) Message-ID: <46A69D29.5020700@firstpr.com.au> Date: Wed, 25 Jul 2007 10:45:29 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [RAM] Slides: comparision of & challenges to the 4 proposals X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I have some slides: http://www.firstpr.com.au/ip/ivip/slides/RAM-2007-07-25-rw.pdf http://www.firstpr.com.au/ip/ivip/slides/RAM-2007-07-25-rw.ppt with tables of comparison and contrast between the four proposals: LISP-NERD, LISP-CONS, eFIT-APT and Ivip. The tables in these slides are in addition to the comparison text http://www.firstpr.com.au/ip/ivip/comp/ - not just a rehash. I will revise these if anyone points out problems or suggests improvements. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 01:31:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDZSm-0007cp-Vb; Wed, 25 Jul 2007 01:31:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDZSm-0007cj-68 for ram@iab.org; Wed, 25 Jul 2007 01:31:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDZSl-000462-Ny for ram@iab.org; Wed, 25 Jul 2007 01:31:08 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 24 Jul 2007 22:31:07 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAC59pkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,578,1175497200"; d="scan'208"; a="168051148:sNHT56488851" 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 l6P5V6HR026140; Tue, 24 Jul 2007 22:31:06 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6P5V1A2017072; Wed, 25 Jul 2007 05:31:06 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); Wed, 25 Jul 2007 01:31:01 -0400 Received: from [172.28.168.212] ([10.82.219.32]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 01:31:01 -0400 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA50132C128@E03MVZ1-UKDY.domain1.systemhost.net> References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> <75A199C5D243C741BF3D3F1EBCEF9BA50132C128@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8168EC57-DF7E-4EC1-A32C-167EB955A34E@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] New LISP draft available ... Date: Tue, 24 Jul 2007 22:30:54 -0700 To: "" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jul 2007 05:31:01.0119 (UTC) FILETIME=[FC8500F0:01C7CE7C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1375; t=1185341466; x=1186205466; 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[RAM]=20New=20LISP=20draft=20available=20... |Sender:=20; bh=agT8JLUymg3r+oRW+FS2bLLf9AkwUHspLyNfj6AcioM=; b=pmdqYnKV7CvuIZWMKoxeKb72BZj36VDcF6w10NRc1xdqxxttLwgHXHC5Sp2Z0Y0ZqmWVm/Bu c6jNqCZ9FKoXOKF/g5fP8QA/FhMWwKgB4MaGXN0g+24vbt8gfNJsNHHU; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > what's the relationship between the variants of lisp? Is it > considered that an operator They are implementation and deployment alternatives to experiment and learn about the design. We have already learned quite a bit so we can eliminate some of the variants before ever deploying them. > would migrate through the 4 steps lisp 1 -> 1.5 -> 2 -> 3? Could > the variants co-exist? At this point we think we can do a scalable mapping infrastructure with a LISP 1.5 variant that can go multiple ways. Or, a LISP 3 variant that proposes one of (or a hybrid of) CONS, NERD, or APT. > Or are they really 4 independent proposals? ('independent' meaning > you make a choice of which *one* to deploy) The data-plane encapsulation is the same in all of them. The locator reachability mechanism is the same in all of them. What differs is the way you retrieve EID-to-RLOC mappings. In LISP 1.0 and 1.5, it is via data-triggered evens and in LISP 2 and LISP 3, it is purely in the control-plane. > since lisp 1 uses routable EIDs, will it get the benefits hoped for > a locator/ID split approach (in terms of the design goals in draft- > irtf-rrg-design-goals)? LISP 1 and LISP 2 will probably never get deployed. > sorry if questions have already been covered They have, but it's okay to repeat for clarity. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 01:36:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDZY6-00030c-Gl; Wed, 25 Jul 2007 01:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDZY5-00030D-1E for ram@iab.org; Wed, 25 Jul 2007 01:36:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDZY4-0004Cy-Jt for ram@iab.org; Wed, 25 Jul 2007 01:36:37 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2007 01:36:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJd+pkZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,578,1175486400"; d="scan'208"; a="126950328:sNHT27850936" 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 l6P5aawL000948; Wed, 25 Jul 2007 01:36:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6P5aZEZ025954; Wed, 25 Jul 2007 05:36: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); Wed, 25 Jul 2007 01:36:35 -0400 Received: from [172.28.168.212] ([10.82.219.32]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 01:36:35 -0400 In-Reply-To: References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38F0B1BE-DD5C-4492-B316-2E2D6F82072A@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] New LISP draft available ... Date: Tue, 24 Jul 2007 22:36:28 -0700 To: Roger Jorgensen X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jul 2007 05:36:35.0563 (UTC) FILETIME=[C3DD1BB0:01C7CE7D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2049; t=1185341796; x=1186205796; 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[RAM]=20New=20LISP=20draft=20available=20... |Sender:=20 |To:=20Roger=20Jorgensen=20; bh=DxK2XsS0w4+VaZca0hupdmNgDC3v96v74cYibN4LDzk=; b=olDQPe6sf7Ec2dDyDdyKePPlgtiGj1R603N+xqxwI3cuzTkHyI1GGKj78VkkqRXfwNOQEvRB Mk2ZLp9WqWU32U7yn4W8V4W63FdqYoNBebGchI0khV9LO12IZ5FSyEXu; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: roger@jorgensen.no, RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > On Tue, 17 Jul 2007, Dino Farinacci wrote: >> We have a new LISP-02 draft available. The packet formats are >> consistent with CONS-01 as well as the implementation we are testing. >> >> The draft has been submitted to the ID directory, but you can find >> a draft at: >> >> http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt >> >> This version is formatted much better. ;-) >> >> This draft also reflects comments from Ved Kafle and Olivier >> Bonaventure. > > a few more general question/clearification around the draft in > general just to see if I understood it correct. Also fun to read > those small comments on Steve Jobs and iPhone :) Thanks! > In section 3, you mentio about EID: > " The source EID is obtained via existing > mechanisms used to set a hosts "local" IP address. LISP uses PI > blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. Note > that EID blocks may be assigned in a hierarchical manner," > > Why restrict it to PI addresses there? If, because no one know how > it is moving on, ULA-C/G are approved and getting into use, they > would be almost perfect for this usage. We have discovered that a PI address may be used as a locator. We have heard plenty of feedback where a PI prefix may have to stay in the core routing tables. But we would like to keep that to the absolute minimum. But you are right, we don't need a hard and fast rule about PI addresses. > Next thing, EID-prefix, that would be the above mention IP block? Yes. > Also in Section 4.1 (page 9-10), the example was worded so it could > be read that it is Ipv4 only. I know thats not true but maybe > change the wording a bit? A change like this could be enough: > > "This section provides an example of a IPv4 unicast packet flow > with the following parameters:" I realized we used the phrases "IP packet" and "A record" which imply IPv4 but you can see it means either. We can tighten this up in the next rev. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 08:25:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDfvk-0002T0-7p; Wed, 25 Jul 2007 08:25:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDfvj-0002Sr-0t for ram@iab.org; Wed, 25 Jul 2007 08:25:27 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDfvi-0006H4-Fv for ram@iab.org; Wed, 25 Jul 2007 08:25:27 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2007 05:25:21 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEHepkZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,580,1175497200"; d="scan'208"; a="506832903:sNHT26539912" 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 l6PCPKD2025992; Wed, 25 Jul 2007 08:25:20 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6PCPKWK028917; Wed, 25 Jul 2007 12:25:20 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, 25 Jul 2007 08:25:20 -0400 Received: from [127.0.0.1] ([161.44.11.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 08:25:19 -0400 Message-ID: <46A740ED.6050109@employees.org> Date: Wed, 25 Jul 2007 08:24:13 -0400 From: Scott Brim Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070716 Thunderbird/2.0.0.5 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] New LISP draft available ... References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> <46A3CEE9.5080008@gmail.com> In-Reply-To: <46A3CEE9.5080008@gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 12:25:20.0030 (UTC) FILETIME=[DD95CBE0:01C7CEB6] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I didn't see a reply from Dino so ... On 07/22/2007 17:40 PM, Brian E Carpenter allegedly wrote: > General points that aren't mentioned and perhaps should be: > > MTU size reduction > Fragmentation (in IPv4) > Referrals (host A passes an address for host B to host C) This kind of thing is a reason for maintaining current "address" behavior. What host A passes will be what host B believes its address is, and what the LISP system considers to be B's EID. > >> 4.1. Packet Flow Sequence > ... >> 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. >> It does a DNS lookup on host2.xyz.com. An A record is returned. >> This address is used as the destination EID and the locally- >> assigned address of host1.abc.com is used as the source EID. An >> IP packet is built using the EIDs in the IP header and sent to >> the default router. > > 'default router' seems wrong (it would typically be understood to > mean the default router on the host's LAN). Doesn't this mean > 'a site egress router' (which is ingress to the LISP domain)? This is from the point of view of the originating endpoint, so it's not the site egress router. Whatever it uses to get its packets forwarded to the destination -- probably a "default" router, but technically "next hop router" is probably better. > In 6.1.1 and elswhere you give RFC2434 as a reference for > AFIs. There's nothing about AFIs in that RFC; in fact AFI documentation > is a bit of a mystery. Got a better reference? All I know is BGP docs. swb _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 11:43:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDj0P-0008Dm-Bz; Wed, 25 Jul 2007 11:42:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDj0O-0008Al-2B for ram@iab.org; Wed, 25 Jul 2007 11:42:28 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDj0M-00025k-Lk for ram@iab.org; Wed, 25 Jul 2007 11:42:28 -0400 Received: by ug-out-1314.google.com with SMTP id c2so442289ugf for ; Wed, 25 Jul 2007 08:42:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=CPfp00eR7IS05hzneWp5OLle5/ILUtCc/FkrG8N8mUucRmPTcx7ViskqwwprfJZ6A2y65a7Hy7tti13xJL/dwpJfta70HpiGm0A/iZTB7MbuOolGMr1R/B/0RbbXXeUWxMvLQ5dfB80Kcw52GJgsbkU5cC7+hkvm0puTiFVSa0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=rmK7JO4rqtRnFMgv3iW8fRQUpRVaTRMf0SHbzxI3N9pn0VPxpQegJENZPmgfoFgn/kkZYEoLDFVKf63d6kIcK4Yh4tHZTOha0XYjiC4YnStN/cG4lQyC8eviyAc5hnl1aGlJOVmRcQk9E9MdNTWf8p/ygRgQxv4PUxc8LTMWk6c= Received: by 10.67.88.17 with SMTP id q17mr1478632ugl.1185378145014; Wed, 25 Jul 2007 08:42:25 -0700 (PDT) Received: from ?130.129.83.253? ( [130.129.83.253]) by mx.google.com with ESMTPS id d24sm1505031nfh.2007.07.25.08.42.23 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Jul 2007 08:42:24 -0700 (PDT) Message-ID: <46A76F5E.8060701@gmail.com> Date: Wed, 25 Jul 2007 17:42:22 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Scott Brim Subject: Re: [RAM] New LISP draft available ... References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> <46A3CEE9.5080008@gmail.com> <46A740ED.6050109@employees.org> In-Reply-To: <46A740ED.6050109@employees.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Scott, On 2007-07-25 14:24, Scott Brim wrote: > I didn't see a reply from Dino so ... > > On 07/22/2007 17:40 PM, Brian E Carpenter allegedly wrote: >> General points that aren't mentioned and perhaps should be: >> >> MTU size reduction >> Fragmentation (in IPv4) >> Referrals (host A passes an address for host B to host C) > > This kind of thing is a reason for maintaining current "address" > behavior. What host A passes will be what host B believes its address > is, and what the LISP system considers to be B's EID. Sure, but it should be said. > >>> 4.1. Packet Flow Sequence >> ... >>> 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. >>> It does a DNS lookup on host2.xyz.com. An A record is returned. >>> This address is used as the destination EID and the locally- >>> assigned address of host1.abc.com is used as the source EID. An >>> IP packet is built using the EIDs in the IP header and sent to >>> the default router. >> 'default router' seems wrong (it would typically be understood to >> mean the default router on the host's LAN). Doesn't this mean >> 'a site egress router' (which is ingress to the LISP domain)? > > This is from the point of view of the originating endpoint, so it's > not the site egress router. Whatever it uses to get its packets > forwarded to the destination -- probably a "default" router, but > technically "next hop router" is probably better. Yes, but the next line says: 2. The default router is configured as an ITR. Are you saying that all next hop routers are ITRs? I would have thought that only site egresses would be ITRs. > >> In 6.1.1 and elswhere you give RFC2434 as a reference for >> AFIs. There's nothing about AFIs in that RFC; in fact AFI documentation >> is a bit of a mystery. > > Got a better reference? All I know is BGP docs. OK, look at the first page of http://www.iana.org/numbers.html There is now a registry (I think I looked once before and couldn't find it). Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 12:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjbD-0002Wf-Mo; Wed, 25 Jul 2007 12:20:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjbC-0002WF-Td for ram@iab.org; Wed, 25 Jul 2007 12:20:30 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDjbB-0003zO-Hi for ram@iab.org; Wed, 25 Jul 2007 12:20:30 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2007 09:20:28 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAA4Vp0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175497200"; d="scan'208"; a="10442793:sNHT16495542" 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 l6PGKSlE000664; Wed, 25 Jul 2007 09:20:28 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6PGKJT5005500; Wed, 25 Jul 2007 16:20:28 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 09:20:28 -0700 Received: from [130.129.84.246] ([10.21.90.69]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 09:20:28 -0700 In-Reply-To: <46A3CEE9.5080008@gmail.com> References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> <46A3CEE9.5080008@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] New LISP draft available ... Date: Wed, 25 Jul 2007 09:20:21 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jul 2007 16:20:28.0340 (UTC) FILETIME=[B6CB0F40:01C7CED7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5490; t=1185380428; x=1186244428; 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[RAM]=20New=20LISP=20draft=20available=20... |Sender:=20; bh=VMMHrx27lhcVrt2fRi4Vtiou3gLyQ5JgFkalfeIzUew=; b=eS2KOQqQAPC7ABGFTwgAQkl2apCFMrS6bIhP0ZSvik22J+Fh6IgbjbrFl0WuP+0Gwdl3NU3g pQYzZchxQPoQYnEhkjzn9BXJ1NwN58VpaBOpy8lpr34KBXJIcYKWaoaF; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > On 2007-07-17 19:56, Dino Farinacci wrote: >> We have a new LISP-02 draft available. The packet formats are >> consistent with CONS-01 as well as the implementation we are testing. >> The draft has been submitted to the ID directory, but you can find >> a draft at: >> http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt > > A few comments on this version... Thanks for the comments Brian. Sorry for the delay, but I want to add to what Scott said. I didn't disagree with any of his comments. > General points that aren't mentioned and perhaps should be: > > MTU size reduction > Fragmentation (in IPv4) I will add text to the -03 version. Did you have any suggestions? > Referrals (host A passes an address for host B to host C) As Scott said, everything is EID based. Will make that more clear in the document. > > 4.1. Packet Flow Sequence > ... > > 1. host1.abc.com wants to open a TCP connection to > host2.xyz.com. > > It does a DNS lookup on host2.xyz.com. An A record is > returned. > > This address is used as the destination EID and the locally- > > assigned address of host1.abc.com is used as the source > EID. An > > IP packet is built using the EIDs in the IP header and > sent to > > the default router. > > 'default router' seems wrong (it would typically be understood to > mean the default router on the host's LAN). Doesn't this mean > 'a site egress router' (which is ingress to the LISP domain)? The default router is the first-hop router directly connected to the source. In this example, the ITR is placed in the first-hop router but can be placed anywhere, and maybe more ideally in the CE router (the one connected to the CE-PE link). > > 5.3. Tunnel Header Field Descriptions > ... > > o The OH header Time to Live field MUST be copied from the IH > header > > Time to Live field. > > > > o The OH header Type of Service field SHOULD be copied from > the IH > > header Type of Service field. > > Does this apply when encapsulating across versions (4 in 6 or 6 in 4)? Absolutely. > In any case the terminology is slightly different in v6 headers. I will fix that. > In the v6 case, does it apply to the flow label too? I am not sure, depending on the semantic of the flow label which has been rather unclear. What do you think? > In 6.1.1 and elswhere you give RFC2434 as a reference for > AFIs. There's nothing about AFIs in that RFC; in fact AFI > documentation > is a bit of a mystery. I will include a reference to http://www.iana.org/numbers.html. We use the term "AFI" in PIM as well. > In 6.1.3: > > > Priority: each RLOC is assigned a priority. Lower values are > more > > preferable. When multiple RLOCs have the same priority, > they are > > used in a load-split fashion. A value of 255 means the > RLOC MUST > > NOT be used. > > Then why waste bits sending that RLOC? Because the cost of these bits are minimal and we don't want to change the record often. Want to keep the change frequency of mapping records low. Plus the loc-reach-bits in the encapsulation header refer to the position here and *could* override the 255 value. > > Weight: when priorities are the same for multiple RLOCs, the > weight > > indicates how to balance traffic between them. Weight is > encoded > > as a percentage of total packets that match the mapping > entry. If > > a non-zero weight value is used for any RLOC, then all > RLOCs must > > use a non-zero weight value and then the sum of all weight > values > > MUST equal 100. What did the 3rd grader say after Steve > Jobs gave > > an iPhone demo to the class? > > It doesn't add up? You have to read the CONS draft. ;-) > > ... If a zero value is used for any RLOC > > weight, then all weights MUST be zero and the receiver of > the Map- > > Reply will decide how to load-split traffic. > > That MUST condition seems pointless. If there is any zero value, the > other values don't matter. Not true, you could have 3 locators all with non-255 priority, each with 0, 50, and 50 as weights. What is conveyed in this encoding is that the first locator is not used. When all weights are 0, the ITR can load-split to it's liking. > > 6.2. Routing Locator Selection > ... > > o Server-side returns a list of RLOC where a subset of the > list has > > the same best priority. Client can only use the subset list > > according to the weighting assigned by the server-side. In > this > > case, the server-side controls both the subset list and load- > > splitting across its members. > > That rule doesn't seem viable or enforcable. The client side may > simply not desire to take orders on how to load share, and that > could be a business issue (if the client has ISP preferences > for example). I think it needs to be "Client SHOULD only use the > subset list > according to the weighting assigned by the server-side." Well, we do want client spec-compliant implications. I realize there are malicious systems out there but you have to document what the intended rules are. > Nit: the citations of RFC3056 and RFC2784 are inverted in the text. Will fix. Thanks again. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 13:38:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkoj-0001CP-O5; Wed, 25 Jul 2007 13:38:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkoi-0001CF-Iy for ram@iab.org; Wed, 25 Jul 2007 13:38:32 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDkoh-0007L7-MJ for ram@iab.org; Wed, 25 Jul 2007 13:38:32 -0400 Received: by wr-out-0506.google.com with SMTP id 41so134980wry for ; Wed, 25 Jul 2007 10:38:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Y6ffqU9OCmX50jJDg6YaQeGt05+zTwIZlmQiawUNcrmLTLpNlkN0cSgAgo5n/Nu5jLj+8wsRiwDMxVRYzfHLMvz17x2TpMoYIq4n0/ioeANwwnPEdl18UZE3HZ6/BdVwVUoMuxVdVIwJw6R4HPxs27JEbsPt1mLG976vGPhjdXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UDy1iEAxK1ISRyR7qgpr0sN9UMM7CrJ0q6aMljjiEYRZ7sfAPwpJypE/8h0yQbbyst/l56XMFqhg3qzbI/nDCJO40p4JXUlIHmhPT5LqoHU08wnnkCdCQWSoVFcRe6YiWfQhymhlmUnQb9bW6WgH9Sf6Njk1a1zAZVoyE9q0lbM= Received: by 10.90.106.11 with SMTP id e11mr856057agc.1185385111213; Wed, 25 Jul 2007 10:38:31 -0700 (PDT) Received: from ?130.129.83.253? ( [130.129.83.253]) by mx.google.com with ESMTPS id 3sm1055816wrh.2007.07.25.10.38.29 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Jul 2007 10:38:29 -0700 (PDT) Message-ID: <46A78A95.8040500@gmail.com> Date: Wed, 25 Jul 2007 19:38:29 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] New LISP draft available ... References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> <46A3CEE9.5080008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dino, On 2007-07-25 18:20, Dino Farinacci wrote: >> On 2007-07-17 19:56, Dino Farinacci wrote: >>> We have a new LISP-02 draft available. The packet formats are >>> consistent with CONS-01 as well as the implementation we are testing. >>> The draft has been submitted to the ID directory, but you can find a >>> draft at: >>> http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt >> >> A few comments on this version... > > Thanks for the comments Brian. Sorry for the delay, but I want to add to > what Scott said. I didn't disagree with any of his comments. > >> General points that aren't mentioned and perhaps should be: >> >> MTU size reduction >> Fragmentation (in IPv4) > > I will add text to the -03 version. Did you have any suggestions? Not really, except that the extra header (unknown to the sender) will reduce the MTU and we'd like to avoid that causing fragmentation. > >> Referrals (host A passes an address for host B to host C) > > As Scott said, everything is EID based. Will make that more clear in the > document. OK > >> > 4.1. Packet Flow Sequence >> ... >> > 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. >> > It does a DNS lookup on host2.xyz.com. An A record is returned. >> > This address is used as the destination EID and the locally- >> > assigned address of host1.abc.com is used as the source EID. An >> > IP packet is built using the EIDs in the IP header and sent to >> > the default router. >> >> 'default router' seems wrong (it would typically be understood to >> mean the default router on the host's LAN). Doesn't this mean >> 'a site egress router' (which is ingress to the LISP domain)? > > The default router is the first-hop router directly connected to the > source. In this example, the ITR is placed in the first-hop router but > can be placed anywhere, and maybe more ideally in the CE router (the one > connected to the CE-PE link). Fine, so this is a phrasing issue. > >> > 5.3. Tunnel Header Field Descriptions >> ... >> > o The OH header Time to Live field MUST be copied from the IH >> header >> > Time to Live field. >> > >> > o The OH header Type of Service field SHOULD be copied from the IH >> > header Type of Service field. >> >> Does this apply when encapsulating across versions (4 in 6 or 6 in 4)? > > Absolutely. > >> In any case the terminology is slightly different in v6 headers. > > I will fix that. > >> In the v6 case, does it apply to the flow label too? > > I am not sure, depending on the semantic of the flow label which has > been rather unclear. What do you think? RFC 3697 doesn't give any guidance for unencrypted tunnels. The only firm requirement is that the (inner) flow label is delivered unchanged. I can imagine scenarios where you'd want to keep the same label and others where you'd want to treat the tunnel as a flow in itself. So I would vote for MAY copy until we understand more. > >> In 6.1.1 and elswhere you give RFC2434 as a reference for >> AFIs. There's nothing about AFIs in that RFC; in fact AFI documentation >> is a bit of a mystery. > > I will include a reference to http://www.iana.org/numbers.html. We use > the term "AFI" in PIM as well. > >> In 6.1.3: >> >> > Priority: each RLOC is assigned a priority. Lower values are more >> > preferable. When multiple RLOCs have the same priority, they are >> > used in a load-split fashion. A value of 255 means the RLOC MUST >> > NOT be used. >> >> Then why waste bits sending that RLOC? > > Because the cost of these bits are minimal and we don't want to change > the record often. Want to keep the change frequency of mapping records > low. Plus the loc-reach-bits in the encapsulation header refer to the > position here and *could* override the 255 value. OK > >> > Weight: when priorities are the same for multiple RLOCs, the weight >> > indicates how to balance traffic between them. Weight is encoded >> > as a percentage of total packets that match the mapping >> entry. If >> > a non-zero weight value is used for any RLOC, then all RLOCs must >> > use a non-zero weight value and then the sum of all weight values >> > MUST equal 100. What did the 3rd grader say after Steve Jobs >> gave >> > an iPhone demo to the class? >> >> It doesn't add up? > > You have to read the CONS draft. ;-) > >> > ... If a zero value is used for any RLOC >> > weight, then all weights MUST be zero and the receiver of the >> Map- >> > Reply will decide how to load-split traffic. >> >> That MUST condition seems pointless. If there is any zero value, the >> other values don't matter. > > Not true, you could have 3 locators all with non-255 priority, each with > 0, 50, and 50 as weights. What is conveyed in this encoding is that the > first locator is not used. When all weights are 0, the ITR can > load-split to it's liking. OK > >> > 6.2. Routing Locator Selection >> ... >> > o Server-side returns a list of RLOC where a subset of the list has >> > the same best priority. Client can only use the subset list >> > according to the weighting assigned by the server-side. In this >> > case, the server-side controls both the subset list and load- >> > splitting across its members. >> >> That rule doesn't seem viable or enforcable. The client side may >> simply not desire to take orders on how to load share, and that >> could be a business issue (if the client has ISP preferences >> for example). I think it needs to be "Client SHOULD only use the >> subset list >> according to the weighting assigned by the server-side." > > Well, we do want client spec-compliant implications. I realize there are > malicious systems out there but you have to document what the intended > rules are. Maybe I'm disagreeing with that rule then. Is there a *technical* argument for why the server side must determine the weights? > >> Nit: the citations of RFC3056 and RFC2784 are inverted in the text. > > Will fix. Thanks again. You're very welcome. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 14:37:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDljN-00015D-65; Wed, 25 Jul 2007 14:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDljL-000156-Mh for ram@iab.org; Wed, 25 Jul 2007 14:37:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDljK-0001Cx-Gz for ram@iab.org; Wed, 25 Jul 2007 14:37:03 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2007 14:37:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAO40p0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175486400"; d="scan'208"; a="127007494:sNHT31847138" 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 l6PIb2l5001810; Wed, 25 Jul 2007 14:37:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6PIaoFD011763; Wed, 25 Jul 2007 18:37:02 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, 25 Jul 2007 14:36:52 -0400 Received: from [130.129.84.246] ([10.82.208.190]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 14:36:51 -0400 In-Reply-To: <46A78A95.8040500@gmail.com> References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> <46A3CEE9.5080008@gmail.com> <46A78A95.8040500@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10CE716C-FB80-4D54-88AA-FB8262E09076@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] New LISP draft available ... Date: Wed, 25 Jul 2007 11:36:44 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jul 2007 18:36:51.0514 (UTC) FILETIME=[C45851A0:01C7CEEA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2841; t=1185388622; x=1186252622; 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[RAM]=20New=20LISP=20draft=20available=20... |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=md6pdWDQv6VOysbIWf2eu93yYx6SKmA12QH9ARtN8iw=; b=XJp1YTeXNIZgWtIBD8BYT4bCs39NZ5IIRR1ChdXEsM14I9cYNqqEJlL225VoV2PBagEWrcLD +qtzz0RIyTRdOEKpvx6jcPajdE77WjNoJgviZ1QvKXncrAv8s95p6+dd; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >>> MTU size reduction >>> Fragmentation (in IPv4) >> I will add text to the -03 version. Did you have any suggestions? > > Not really, except that the extra header (unknown to the sender) > will reduce the MTU and we'd like to avoid that causing fragmentation. Understand the issue and there is no reliable solution to it. All tunneling protocols have this problem. But I believe in practice it's not a real issue. Hosts send no larger, typically than 1500 byte packets and routers are now more and more on 9K MTU links. >>> 'a site egress router' (which is ingress to the LISP domain)? >> The default router is the first-hop router directly connected to >> the source. In this example, the ITR is placed in the first-hop >> router but can be placed anywhere, and maybe more ideally in the >> CE router (the one connected to the CE-PE link). > > Fine, so this is a phrasing issue. Correct. >>> > 5.3. Tunnel Header Field Descriptions >>> ... >>> > o The OH header Time to Live field MUST be copied from the >>> IH header >>> > Time to Live field. >>> > >>> > o The OH header Type of Service field SHOULD be copied from >>> the IH >>> > header Type of Service field. >>> >>> Does this apply when encapsulating across versions (4 in 6 or 6 >>> in 4)? >> Absolutely. >>> In any case the terminology is slightly different in v6 headers. >> I will fix that. >>> In the v6 case, does it apply to the flow label too? >> I am not sure, depending on the semantic of the flow label which >> has been rather unclear. What do you think? > > RFC 3697 doesn't give any guidance for unencrypted tunnels. > The only firm requirement is that the (inner) flow label > is delivered unchanged. I can imagine scenarios where you'd want > to keep the same label and others where you'd want to treat the > tunnel as a flow in itself. So I would vote for MAY copy until > we understand more. Okay, good suggestion. >>> That rule doesn't seem viable or enforcable. The client side may >>> simply not desire to take orders on how to load share, and that >>> could be a business issue (if the client has ISP preferences >>> for example). I think it needs to be "Client SHOULD only use the >>> subset list >>> according to the weighting assigned by the server-side." >> Well, we do want client spec-compliant implications. I realize >> there are malicious systems out there but you have to document >> what the intended rules are. > > Maybe I'm disagreeing with that rule then. Is there a *technical* > argument > for why the server side must determine the weights? There is a requirement for site-based ETRs to allow to control the data flow to each of the site's locators. This is precisely controlling ingress traffic flow. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 14:59:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDm4l-0005vp-EN; Wed, 25 Jul 2007 14:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDm4k-0005ve-Cq for ram@iab.org; Wed, 25 Jul 2007 14:59:10 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDm4j-0001oY-59 for ram@iab.org; Wed, 25 Jul 2007 14:59:10 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6PIx7JZ010369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jul 2007 11:59:07 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6PIx6Te027428; Wed, 25 Jul 2007 13:59:06 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6PIx10b027247; Wed, 25 Jul 2007 13:59:06 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 11:59:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] New LISP draft available ... Date: Wed, 25 Jul 2007 11:58:38 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED93F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <10CE716C-FB80-4D54-88AA-FB8262E09076@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] New LISP draft available ... Thread-Index: AcfO6tFIUgrjLNYdS/ao+1F5sLGMpAAAk4Pw References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com><46A3CEE9.5080008@gmail.com><46A78A95.8040500@gmail.com> <10CE716C-FB80-4D54-88AA-FB8262E09076@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" , "Brian E Carpenter" X-OriginalArrivalTime: 25 Jul 2007 18:59:05.0827 (UTC) FILETIME=[DFA85330:01C7CEED] X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > > Not really, except that the extra header (unknown to the sender) > > will reduce the MTU and we'd like to avoid that causing=20 > fragmentation. >=20 > Understand the issue and there is no reliable solution to it. All =20 > tunneling protocols have this problem. But I believe in=20 > practice it's =20 > not a real issue. Hosts send no larger, typically than 1500 byte =20 > packets and routers are now more and more on 9K MTU links. There is also the size of the reassembly buffer to consider, i.e., the Maximum Receive Unit (MRU). Nodes are advised to configure an MRU at least as large as the interface MTU, but in some cases that may only be 1500bytes. Fred fred.l.templin@boeing.com=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 15:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmL1-0003JK-MH; Wed, 25 Jul 2007 15:15:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmL0-0003Io-Ss for ram@iab.org; Wed, 25 Jul 2007 15:15:59 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDmL0-0002GO-L0 for ram@iab.org; Wed, 25 Jul 2007 15:15:58 -0400 Received: by wx-out-0506.google.com with SMTP id i28so281443wxd for ; Wed, 25 Jul 2007 12:15:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=btkLEze7Nk2aTO6CgRMGiLVNIxyOQo+laWu7WOuIm16QxAexT3dDOSHCwcESc4KNyjRE3ea1M1w98PnDvEU945coKI1KebAqQ+aFdKgy167DEaxnLu7HVcuJQdXCn7gwr+xsL3HAaTMA+3hFyUOumxl43Gci90vIgF1pKxhh05k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=YR/Su87w/1b9e6DQAMbcQ4Nurr/JfbDNVjA1SQQVzypskHYkZrWIVODDT8pek+e5DjfkWUl+XtldEmgFbPMm0luayw/Gl6kXF4u2mHjXY9RmopgQbQe8kVVXN3COYM7Mqr34VQHRbsb+3JhIcv4QqOQVSje5rWPrHgz8lScG/5Y= Received: by 10.90.118.8 with SMTP id q8mr1016437agc.1185390958291; Wed, 25 Jul 2007 12:15:58 -0700 (PDT) Received: from ?130.129.83.253? ( [130.129.83.253]) by mx.google.com with ESMTPS id 43sm1151116wri.2007.07.25.12.15.57 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Jul 2007 12:15:57 -0700 (PDT) Message-ID: <46A7A16D.7030803@gmail.com> Date: Wed, 25 Jul 2007 21:15:57 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] New LISP draft available ... References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> <46A3CEE9.5080008@gmail.com> <46A78A95.8040500@gmail.com> <10CE716C-FB80-4D54-88AA-FB8262E09076@cisco.com> In-Reply-To: <10CE716C-FB80-4D54-88AA-FB8262E09076@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org All OK except: >>>> That rule doesn't seem viable or enforcable. The client side may >>>> simply not desire to take orders on how to load share, and that >>>> could be a business issue (if the client has ISP preferences >>>> for example). I think it needs to be "Client SHOULD only use the >>>> subset list >>>> according to the weighting assigned by the server-side." >>> Well, we do want client spec-compliant implications. I realize there >>> are malicious systems out there but you have to document what the >>> intended rules are. >> >> Maybe I'm disagreeing with that rule then. Is there a *technical* >> argument >> for why the server side must determine the weights? > > There is a requirement for site-based ETRs to allow to control the data > flow to each of the site's locators. This is precisely controlling > ingress traffic flow. Sorry to harp on but why is that a *technical* requirement? (To be clear, if it's a *business* requirement I still think it should be a SHOULD.) Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 16:48:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnmB-0003Vx-VP; Wed, 25 Jul 2007 16:48:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnm9-0003Vk-VS for ram@iab.org; Wed, 25 Jul 2007 16:48:06 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDnm9-000472-Jq for ram@iab.org; Wed, 25 Jul 2007 16:48:05 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2007 13:48:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGdTp0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175497200"; d="scan'208"; a="188577661:sNHT65628243" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6PKm4Id004625; Wed, 25 Jul 2007 13:48:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6PKlo6g025920; Wed, 25 Jul 2007 20:48:04 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 13:48:02 -0700 Received: from [130.129.22.195] ([10.21.92.253]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 13:48:01 -0700 In-Reply-To: <46A7A16D.7030803@gmail.com> References: <1DFBAD55-CA28-4D44-9F96-218F5F281047@cisco.com> <46A3CEE9.5080008@gmail.com> <46A78A95.8040500@gmail.com> <10CE716C-FB80-4D54-88AA-FB8262E09076@cisco.com> <46A7A16D.7030803@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] New LISP draft available ... Date: Wed, 25 Jul 2007 13:47:55 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jul 2007 20:48:02.0005 (UTC) FILETIME=[1785F050:01C7CEFD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=214; t=1185396485; x=1186260485; 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[RAM]=20New=20LISP=20draft=20available=20... |Sender:=20; bh=2vNGgQmjMX0eY/DNkUW8eAp6SLYrvJ4yGKm5Tyj1MvA=; b=gugIlYQUyj8nksfGq59yRm69wKZOMbn5gGD8Pcm4XbWMoVkfpv7Ync/GNRO4aBAQPO/9vukX Z/Hs1hWbo6uo9KnYo9KdN2Fy22+JFR2knEItKpfBublO2Pup2f2mO2rdWZJyTizcuQBd4azGsN 3eUpl/GYqtp/CsRPsggRpwQE0=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Sorry to harp on but why is that a *technical* requirement? > > (To be clear, if it's a *business* requirement I still think it > should be a SHOULD.) It's a feature that that is highly desirable. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jul 25 21:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDrjg-0001QR-4s; Wed, 25 Jul 2007 21:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDrje-0001NI-8K for ram@iab.org; Wed, 25 Jul 2007 21:01:46 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDrjX-0008U1-UC for ram@iab.org; Wed, 25 Jul 2007 21:01:46 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 15B2159E3F; Thu, 26 Jul 2007 11:01:35 +1000 (EST) Message-ID: <46A7F25A.9010907@firstpr.com.au> Date: Thu, 26 Jul 2007 11:01:14 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Tunneling overheads and fragmentation References: <469F7673.6070702@firstpr.com.au> <20070720140433.GA69215@Space.Net> In-Reply-To: <20070720140433.GA69215@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Gert Doering wrote: RW> For instance, if all provider and transit routers happily handle RW> packets significantly longer than whatever hosts normally produce RW> (say 1500 bytes) then adding the encapsulation won't lead to any RW> fragmentation. Is this a reasonable assumption? > No. As of today, too many links and routers still have issues handling > more than 1500 bytes of IP packets (like "most FastEthernet interfaces on > Cisco routers", which is still considered "high bandwidth" over here). In the thread "New LISP draft available ..." (msg01756), Dino wrote: > All tunneling protocols have this problem. But I believe in > practice it's not a real issue. Hosts send no larger, typically > than 1500 byte packets and routers are now more and more on 9K > MTU links. These two statements don't seem to be reconcilable. The further the ITRs and ETRs are from the sending and receiving hosts, the less routers will be in the tunnel part of the path - and the larger and newer those routers are likely to be, I guess. For scaling purposes - to distribute the encapsulation and decapsulation workload over more devices - we want to have more ITRs and ETRs, which means they will be closer to the hosts (or Customer Edge routers). This is especially true for the ETR, because as I argue in: http://tools.ietf.org/html/draft-whittle-ivip-arch-00#section-14.1.2.5 ETRs must handle packets from ITRs in the same network I think that packets to all LISP/APT/Ivip-mapped addresses sent by hosts in the same network in which the hosts/CE-routers with the destination LISP/APT/Ivip-mapped addresses reside . . . should be forwarded via an ITR tunneling the packets to the right ETR, rather than by the local routing system. Only ITRs are likely to be up-to-date on where the packets should be delivered to. Otherwise (relying on the local routing system to forward raw packets to the destination with the LISP/APT/Ivip-mapped address), the local routing system has to have ITR functionality, which is simple enough in Ivip - follow the database mapping - but very complex for the other proposals. I doubt the local routing system could respond quickly enough to Ivip mapping changes, and I doubt it could implement the functionality of LISP/eFIT-APT ITRs. If this argument is accepted, then ETRs will be very close to the destination, probably with a direct link - since they won't be relying on the local routing system to get raw decapsulated packets to the destination (unless they use a tunnel to the CE router or the LISP/APT/Ivip-mapped host, which requires software in the latter). For scaling (load sharing) reasons, we probably want as many ITRs as possible, which means they will be closer to the sending hosts and that the larger encapsulated packets will flow through more internal routers, which may be older (I guess) with lower capacities and perhaps lower MTU sizes. Gert also wrote: RW> What about routers in end-user networks, or CE routers of RW> providers? > Even worse, due to DSL encapsulation you already end up with an > IP MTU of 1492 bytes or less. Putting an ITR function in a DSL modem (or HFC cable modem) NAT device will require that the device use DHCP to give all hosts on the private network a lower MTU so it can safely encapsulate the packets which are addressed to mapped addresses, and not run into MTU problems on its own DSL/cable link. As far as I can see, this will lead to all application programs being limited to somewhat lower packet lengths, unless somehow the application (and operating system?) can be sure the packet is not affected by LISP/APT/Ivip etc. mapping, and therefore is not going to be encapsulated. Is there a WG working on MTU issues, path MTU discovery etc.? I have added this: IPv6 Extensions for Multi-MTU Subnets tools.ietf.org/html/draft-van-beijnum-multi-mtu-00 to my To-Do reading list: http://www.firstpr.com.au/ip/ivip/to-do/ - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 26 02:19:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDwgE-0006kl-0t; Thu, 26 Jul 2007 02:18:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDwgD-0006kg-1Y for ram@iab.org; Thu, 26 Jul 2007 02:18:33 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDwg8-00050n-Ky for ram@iab.org; Thu, 26 Jul 2007 02:18:32 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id C656659E3F; Thu, 26 Jul 2007 16:18:26 +1000 (EST) Message-ID: <46A83CA7.7070509@firstpr.com.au> Date: Thu, 26 Jul 2007 16:18:15 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [RAM] Quick intro and color multihoming diagram X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I have added a color diagram depicting multihoming service restoration to the Ivip main page and to the Slides: http://www.firstpr.com.au/ip/ivip/ http://www.firstpr.com.au/ip/ivip/slides/RAM-2007-07-26-rw.pdf http://www.firstpr.com.au/ip/ivip/slides/RAM-2007-07-26-rw.ppt I wrote a "Quick Intro" to the "crisis" in routing and addressing and to the most obvious IPv4 and IPv6 compatible proposed solutions: http://www.firstpr.com.au/ip/ivip/quick-intro/ It has more on Ivip than the other proposals, but readers are referred to another page which has links to the I-Ds of LISP-NERD, LISP-CONS and eFIT-APT. There probably nothing there which denizens of this list don't already know - unless it is something I think is true but maybe isn't. The Short Version probably takes 10 minutes to read - or the whole page with Longer Version probably takes 30 minutes. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 26 11:45:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5WR-0002n9-5W; Thu, 26 Jul 2007 11:45:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5WP-0002n3-Oi for ram@iab.org; Thu, 26 Jul 2007 11:45:01 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE5WO-0001HD-Kl for ram@iab.org; Thu, 26 Jul 2007 11:45:01 -0400 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 7945526; Thu, 26 Jul 2007 11:45:00 -0400 In-Reply-To: References: <003d01c7c1ef$2148eb80$bc92f385@nictkafle> <46921DDF.2090105@pi.se> <6FAE671E-A492-46E7-A651-58D8C29C86D6@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] Meeting at IETF-69? Date: Thu, 26 Jul 2007 11:44:56 -0400 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Just for the record, our IAD (Ray Pelletier) has arranged for hotel wireless _for the room_ for the rest of of the day for the RAM meeting Friday. On Jul 9, 2007, at 5:03 PM, Tony Li wrote: > >> Note that the wireless will likely come down at or shortly after >> Noon. I could ask if it could be extended, but generally they >> resist that. > > > Already asked and declined. ;-( > > T Regards Marshall _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jul 26 20:21:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEDZe-0008Ta-TX; Thu, 26 Jul 2007 20:20:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEDZd-0008TV-6O for ram@iab.org; Thu, 26 Jul 2007 20:20:53 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEDZc-0004LZ-Ii for ram@iab.org; Thu, 26 Jul 2007 20:20:53 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6R0Ko3f006069 for ; Thu, 26 Jul 2007 20:20:50 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6R0Knjc163296 for ; Thu, 26 Jul 2007 18:20:49 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6R0Kne2003682 for ; Thu, 26 Jul 2007 18:20:49 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-192-212.wecm.ibm.com [9.67.192.212]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6R0KmuS003645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2007 18:20:49 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l6R0KbZs014836 for ; Thu, 26 Jul 2007 19:20:47 -0500 Message-Id: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> To: ram@iab.org Date: Thu, 26 Jul 2007 19:20:37 -0500 From: Thomas Narten X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [RAM] First cut at routing & addressing problem statement X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org The Routing & Addressing directorate has been working on a strawman problem statement since Prague. I just submitted our first cut as an Internet Draft and it's available at: http://www.cs.duke.edu/~narten/ietf/draft-narten-radir-problem-statement-00.txt We would welcome comments on the document. In particular: - Do folk agree with the problem statement as written, or are we missing something fairly fundamental? - Are there other pressures on the routing system that we have not listed or described completely? - We intentionally did not include improving mobility as a core "problem", as explained in the document. (That doesn't mean we don't recognize that some of the solutions under discussion may also be applicable to mobility scenarios. Rather, we tend to see improved mobility as a possible benefit of certain classes of solutions.) - Are there other views of what folk perceive the core routing and addressing problem to be? Thomas _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 27 10:29:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQoE-0004gW-QS; Fri, 27 Jul 2007 10:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQoD-0004gL-3w for ram@iab.org; Fri, 27 Jul 2007 10:28:49 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQoC-0005SK-Gt for ram@iab.org; Fri, 27 Jul 2007 10:28:49 -0400 Received: from [135.207.28.60] (fpdhcp060.research.att.com [135.207.28.60]) by bigmail.research.att.com (8.13.7+Sun/8.11.6) with ESMTP id l6RESmgN011183 for ; Fri, 27 Jul 2007 10:28:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Ricardo V. Oliveira" Subject: Re: [RAM] First cut at routing & addressing problem statement Date: Fri, 27 Jul 2007 10:32:19 -0400 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Thomas, Some minor comments on the draft: Sec 4.7: "For a large ISP, the internal IPv4 table can be between 50,000 and 150,000 routes." What do you mean by internal IPv4 table? In large IS, the number of routable prefixes in a router can easily reach 250k. The degree of interconnectedness between ASes has increased in recent years. That is, the Internet as whole is becoming "flatter" with an increasing number of possible paths interconnecting sites [ref?] http://www.cs.ucla.edu/~rveloso/papers/fp163_oliveira.pdf has some numbers for this in section 4.3. Thanks, --Ricardo On Jul 26, 2007, at 8:20 PM, Thomas Narten wrote: > The Routing & Addressing directorate has been working on a strawman > problem statement since Prague. I just submitted our first cut as an > Internet Draft and it's available at: > > http://www.cs.duke.edu/~narten/ietf/draft-narten-radir-problem- > statement-00.txt > > We would welcome comments on the document. In particular: > > - Do folk agree with the problem statement as written, or are we > missing something fairly fundamental? > > - Are there other pressures on the routing system that we have not > listed or described completely? > > - We intentionally did not include improving mobility as a core > "problem", as explained in the document. (That doesn't mean we > don't recognize that some of the solutions under discussion may > also be applicable to mobility scenarios. Rather, we tend to see > improved mobility as a possible benefit of certain classes of > solutions.) > > - Are there other views of what folk perceive the core routing and > addressing problem to be? > > Thomas > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 27 11:23:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEReq-00039P-7z; Fri, 27 Jul 2007 11:23:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEReo-00039F-Hl for ram@iab.org; Fri, 27 Jul 2007 11:23:10 -0400 Received: from ns1.nict.go.jp ([133.243.3.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERem-0006lZ-LY for ram@iab.org; Fri, 27 Jul 2007 11:23:10 -0400 Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id l6RFJL8H028234 for ; Sat, 28 Jul 2007 00:19:21 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id l6RFJLnp012413 for ; Sat, 28 Jul 2007 00:19:21 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id l6RFJLU7012410 for ; Sat, 28 Jul 2007 00:19:21 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 150346EE2 for ; Sat, 28 Jul 2007 00:19:21 +0900 (JST) Received: from kaflenote2 (ssh.nict.go.jp [133.243.3.49]) by mail2.nict.go.jp (Postfix) with ESMTP id 0023D6EDD for ; Sat, 28 Jul 2007 00:19:18 +0900 (JST) From: "Ved Kafle" To: Date: Sat, 28 Jul 2007 00:19:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcfQWqZb7iAWQqYWSsCJKfCNfxST5gABnocg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070727151918.0023D6EDD@mail2.nict.go.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [RAM] rrg presentation slides online? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Are the rrg presentation slides going to be available online? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 27 11:31:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERmY-0001pv-EY; Fri, 27 Jul 2007 11:31:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERmX-0001l0-EJ for ram@iab.org; Fri, 27 Jul 2007 11:31:09 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERmU-0006w2-Cq for ram@iab.org; Fri, 27 Jul 2007 11:31:09 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 5CDCE59DEB; Sat, 28 Jul 2007 01:31:04 +1000 (EST) Message-ID: <46AA0FAC.7070909@firstpr.com.au> Date: Sat, 28 Jul 2007 01:30:52 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Subject: [RAM] ITR complexity & security (ICMP) in LISP-NERD/CONS & eFIT-APT X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org This message mainly concerns the difficulty which I think a LISP-NERD, LISP-CONS or eFIT-APT ITR (and eFIT-APT Default Mapper) would have handling ICMP DU messages regarding reachability and Path MTU Discovery. The only way I can imagine these being handled securely seems to involve an impractically large amount of state and processing. None of these difficulties apply to Ivip ITRs because they are not concerned with reachability and because they don't get ICMP DU code 4 messages if a tunneled packet with DF set is too long for a router. I received a critique of my Quick Introduction: http://www.firstpr.com.au/ip/ivip/quick-intro/ Part of the critique stated that there were factual errors in the paragraph quoted below, particularly the notion of the database being "massive" and the ITRs' communications being "complex". LISP-NERD/CONS and eFIT-APT assume this massive database system can't control the ITRs fast enough that multihoming service restoration can be achieved by the end-user, or some system they use to automate this process, changing the mapping in the central database. Therefore, LISP-NERD/CONS and eFIT-APT have a complex database structure which involves the ITR being given a list of ETRs to use, with the ITRs themselves being involved in complex communications and decisions regarding which ETR to tunnel packets to. Here is my response, which is now also on my site, linked to from the paragraph quoted above. I respond to the "massive" critique at the end of this message, since I want to focus on what LISP or eFIT-APT ITRs must do in order to securely determine reachability and in order to support Path MTU Discovery. Ivip ITRs don't do any of this. They don't test for reachability, they don't make decisions to tunnel to one ETR or another, and they are not involved in the ICMP Destination Unreachable (DU) messages generated by routers handling tunneled packets, because Ivip's tunneled packets have the sending host's address as the source address. With LISP and with eFIT-APT, the source address is that of the ITR, so it gets the ICMP DU messages. eFIT-APT definitely does have complex communications between the ITR and its Default Mapper, and with the destination ETR and its Default Mapper potentially sending messages to both the ITR and its Default Mapper. This is in addition to both ITR and Default Mappers (which are themselves ITRs) performing the complex operations I describe below which are necessary, as they are for LISP, to reliably accept ICMP messages regarding reachability and fragmentation. LISP/eFIT-APT ITRs (and Default Mappers for eFIT-APT) will legitimately get ICMP DU messages under at least the following conditions. There may be more situations and more codes. For simplicity I will ignore the codes in RFC 1122 and just work with those in: http://tools.ietf.org/html/rfc792 ICMP Fields: Type 3 Code 0 = net unreachable; 1 = host unreachable; 2 = protocol unreachable; 3 = port unreachable; 4 = fragmentation needed and DF set; 5 = source route failed. The ITR will legitimately get codes 0, 1, 2, 3 or 5 when one of the tunneled packets it sent fails to reach its destination ETR for some reason. (This is not a reliable way of testing the reachability of the ETR, since it maybe the failure to reach it doesn't generate an ICMP DU message, or maybe that message is filtered or lost. Ivip would rely on the user having their own multihoming monitoring system - or paying for someone else's system to do the job - to detect reachability problems and then change the mapping of their prefix so the packets are tunneled to another ETR. That system could involve cryptographically secured challenge and response exchanges which don't rely on ICMP at all.) I understand in LISP and eFIT-APT that ETRs are intended to determine the reachability of their one or more destination hosts/routers (the devices to which the send packets after decapsulating them). An ETR might have multiple such destination hosts, and when it receives from an ITR an encapsulated packet which is addressed to a destination host which is unreachable, I think the ETR is supposed to send some kind of ICMP DU message back to the ITR. This would probably be code 0,1 or 5 - and not 4. Since reachability is so crucial to the functioning of LISP and eFIT-APT, it is vital that the ITRs (and also the Default Mappers for eFIT-APT) reliably reject the attempts of attackers to spoof ICMP DU messages. Otherwise, a single spoofed ICMP DU message could clobber a stream of packets to an ETR, making it a handy DoS technique. In order for the ITR to be able to distinguish between genuine ICMP packets and those spoofed by an attacker, it needs to retain the following items of state, for each packet it tunnels. I will call this a "Tunneled Packet Record". 1 - UDP Source Port: 16 bits. (Assuming this changes - maybe it doesn't or is not regarded as necessary for testing ICMP messages, but I will assume it is necessary.) 2 - UDP Length: 16 bits. 3 - UDP Checksum: 16 bits. 4 - Tunnel Endpoint: The ETR's address = the destination address of the outer packet: 32 bits for IPv4 or 128 bits for IPv6. So the state which needs to be stored for each tunneled packet is: IPv4: 18 bytes IPv6: 54 bytes I will assume it needs to keep these for a second, since a genuine ICMP packet would probably arrive within a second. If this ITR is handling 1Gbps of encapsulated packets, of 100 bytes each, this is a million items of state, as just described, being stored and garbage collected every second. I think this is impractical. When an ICMP DU message arrives, the router's CPU needs to determine whether it is genuine or not. It can't do this with absolute certainty - since an attacker can easily guess a Packet Length, and perhaps a Source Port, and then can try random numbers for the Checksum. This is my understanding of what the ITR must do. The ICMP message contains the IP header (however long that is for IPv4 or IPv6) and then the 8 bytes which follow copied from the packet which gave a router cause to generate the message. Now that LISP has adopted UDP encapsulation - and so as eFIT-APT, since it simply cites the LISP I-D as a reference for encapsulation - these 8 bytes in the ICMP message consist purely of the UDP header which follows the IP header of the tunneled packet. I will call this the ICMP-8 words: UDP Source Port UDP Dest Port UDP Length UDP Checksum To pass the test, the ICMP message must pass the following tests: a - Have a Source Address (SA) matching one of the Tunneled Packet Records' "Tunnel Endpoint". b - Have the ICMP-8 UDP Dest Port equal 4342. c - Have the ICMP-8 UDP Source Port equal the "UDP Source Port" of one of more of the Tunneled Packet Records which passed test (a). d - Have the ICMP-8 UDP Length equal the "UDP Length" of one of more of the Tunneled Packet Records which passed tests (a) and (c). e - Have the ICMP-8 UDP Checksum equal the "UDP Checksum" of one of more of the Tunneled Packet Records which passed tests (a), (c) and (d). This would be a pain if there were a few dozen Tunneled Packet Records, but there could be a million of them at any one time. I think this is not at all practical for any high-speed ITR. Anything less than this will render the ITR an easy target a single spoofed ICMP packet. A few such spoofed packets, with source addresses matching all the ETRs the ITR has in the mapping data for a particular EID, will mean that the ITR will not tunnel packets addressed to this EID, because it considers all the RLOC addresses in the mapping data unreachable. (BTW, I assume that the ITR will periodically send test packets to the ETR in order to see if it is reachable again. If so, then the procedures for testing the validity of ICMP DU messages need to first check to see if it was a response to one of these probes. Such probing is another instance of the complexity of ITR functionality and communications in LISP/eFIT-APT.) Another thing which (I think) LISP/eFIT-APT ITRs must support is Path MTU Discovery. When the ITR receives an ICMP DU message with code 4, it must perform the above series of tests on it and then some further operations, which requires two more items of state to be kept for each tunneled packet: 5 - IP Header of the original packet. 20 bytes for IPv4 or 40 bytes for IPv6. 6 - 8 bytes following that header from the original packet. This brings the total size for each "Tunneled Packet Record" to: IPv4: 46 bytes IPv6: 102 bytes It would be possible to reduce the saving of state by not bothering to save items 5 and 6 above except for those packets with with DF (Don't Fragment) set to 1, since when this DF bit is copied to the outer encapsulating header, it is only these tunneled packets which should generate an ICMP DU code 4 message. This requires the ITR to store state at about 5 to 20% of the volume of bits it is tunneling in packets - and to garbage collect it about a second later. This seems really impractical. Once an ICMP DU code 4 packet passes the first set of tests, then from whichever Tunneled Packet Record which it matches, the ITR reads the Sending Host's Address and creates a new ICMP DU code 4 message, setting its Destination Address to the Source Address of the IP Header from Tunneled Packet Record, its Source Address to the Destination Address of the this IP Header, including the entire IP Header and the "8 bytes following" in the packet and calculating its checksum. I regard this as "complex" ITR functionality! Regarding the database being "massive", I wrote this in the expectation that any new architecture will eventually handle hundreds of millions or maybe more than a billion different "EIDs" (to use LISP terminology). The critique was that a mapping database covering 500,000 EIDs and requiring 50 bytes for each is not "massive". I agree this is not "massive", but I foresee a much wider application of the new architecture than simply multihoming for a few more times the number of AS-end-users as we have today. If a LISP or an eFIT-APT system was built, instead of something with higher speed and broader ambitions such as Ivip, then I believe it wouldn't be long before people started making proposals to speed it up - to make it be more like Ivip so it could support mobility and user's own direct real-time control of multihoming service restoration, rather than entrusting those decisions, and the difficult business of reachability testing, to all the ITRs in the Net, each acting alone. So I stand by my characterisation of the mapping database of any successful new architecture as being "massive". For a given number of end-user mappings, Ivip's would be less massive, since each entry in the database consists of a starting address and a range (more flexible than a prefix length) to specify the Ivip-mapped addresses with a particular mapping - followed by the mapping data which consists a single IP address. With LISP or eFIT-APT, the mapping data consists of multiple RLOC addresses, each with a Weight and a Priority - and perhaps some other stuff. So I stand by what I wrote about the contrast between Ivip and the other proposals in that Ivip has a simple database which needs a rapid response time from the user altering the mapping to the ITRs following the new mapping, while the others assume this can't be done, and so make the database more complex and voluminous, in order to give the ITRs the information they need to make their own multihoming service restoration decisions. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 27 12:53:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IET3h-0001b0-SY; Fri, 27 Jul 2007 12:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IET3g-0001ar-JK for ram@iab.org; Fri, 27 Jul 2007 12:52:56 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IET3g-0000eK-7e for ram@iab.org; Fri, 27 Jul 2007 12:52:56 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B57EF86ADD; Fri, 27 Jul 2007 12:52:55 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] ITR complexity & security (ICMP) in LISP-NERD/CONS & eFIT-APT Message-Id: <20070727165255.B57EF86ADD@mercury.lcs.mit.edu> Date: Fri, 27 Jul 2007 12:52:55 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Robin Whittle > .. handling ICMP DU messages regarding reachability and Path MTU > Discovery. > The only way I can imagine these being handled securely seems to > involve an impractically large amount of state and processing. I'm a bit too crunched for time to really understand this entire message, but I was wondering if you have considered the following approach to this problem: All ITRs/ETRs have their interfaces which face toward the 'core' (i.e. the other ITRs/ETRs in the system) have addresses from some reserved part of the address space (e.g. net 10), addresses which are not functional on the 'site' side of the ITRs/ETRs. (I.e. you can't send a packet to one of the addresses from inside a site.) The ITRs only accept reachability DU messages on those interfaces, destined to the addresses from the reserved space. In other words, there's no way to send them one of these DU packets from a customer site. This should be easier than carefully validating each individual DU, and keeping enough state to do so, right? Yes, this still allows a compromised ITR/ETR to generate bogus traffic, but I think it's a useful reduction in the threat universe. I don't have any clearest best idea on how to validate incoming DU messages from other ITRs/ETRs... Maybe a per-ETR nonce (i.e. only a slight amount of increase in the state in the ITR), which is included in each tunnelled packet, or something like that. If it's 32 bits, and changed every 10 seconds, it would be hard to find by generating random values (and in any case the incoming errors could set off alarm bells), and even if it were found, it would only give you a break-in for a few seconds. In short, I agree this is a problem, and one that needs a solution, but I'm not sure the mechanism you posit is the best solution. In part, you seem to be trying to solve it without changing the protocol (i.e. packet format), and I think that's too hard a constraint. If you really need a screwdriver, go buy one, don't try and make do with a hammer. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 27 13:51:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IETxw-0006qV-TJ; Fri, 27 Jul 2007 13:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IETxv-0006mP-NI for ram@iab.org; Fri, 27 Jul 2007 13:51:03 -0400 Received: from web58708.mail.re1.yahoo.com ([66.196.100.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IETxv-00028U-5S for ram@iab.org; Fri, 27 Jul 2007 13:51:03 -0400 Received: (qmail 32614 invoked by uid 60001); 27 Jul 2007 17:50:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=N4I39Ad2320RewDEHQ437bz2kceCnlDy/aRIT8vCxVA6o7G2NHJ3CAw3eLTax6Oen3iK8lIfVp90grNMAGEC9E1lpSs+bfopgiL/Gq2JYsBamjtW+q8CqZBBcijVQJplAvqmFfDcrOl4vdNEfg7pTBQIuc9c8Y3B2O9fWt63KOU=; X-YMail-OSG: gtALL_QVM1mkb93w7n1.f_n55ItCsuLkpQ1svcoFB3jg7K6Lrh0xRERMqVGl0A11wkCjWsf01d22bbNGmnNW5iuq7x.GAl1f9gYjef1Lbx4ZAG.Di6Wq6BQsjTFADA-- Received: from [24.114.255.3] by web58708.mail.re1.yahoo.com via HTTP; Fri, 27 Jul 2007 10:50:46 PDT Date: Fri, 27 Jul 2007 10:50:46 -0700 (PDT) From: Peter Sherbin Subject: Re: [RAM] First cut at routing & addressing problem statement To: Thomas Narten , ram@iab.org In-Reply-To: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <901157.22509.qm@web58708.mail.re1.yahoo.com> X-Spam-Score: 3.3 (+++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Enjoined reading the statement. Re the "flatter" Internet in 5.1. since around 2000 seemingly there is a trend in changing upstream transit contracts to peering arrangements. By Q1 2007 in the observed example over 80% of traffic is routed via peers. Statement 1. Would it be beneficial to define the targeted number of individual prefixes in DFZ, specify the update rate and then architecture towards those numbers? E.g. assume 1 AS per each 10,000 sq km of Earth's surface and 9 routes per AS. It gives about 450K as the maximum number of DFZ entries providing an idea of the router required processing power. Statement 4. Make it more rigid "Allows end sites to switch providers without configuration changes to internal end site devices". Statement 5. seems redundant Thanks, Peter --- Thomas Narten wrote: > The Routing & Addressing directorate has been working on a strawman > problem statement since Prague. I just submitted our first cut as an > Internet Draft and it's available at: > > http://www.cs.duke.edu/~narten/ietf/draft-narten-radir-problem-statement-00.txt > > We would welcome comments on the document. In particular: > > - Do folk agree with the problem statement as written, or are we > missing something fairly fundamental? > > - Are there other pressures on the routing system that we have not > listed or described completely? > > - We intentionally did not include improving mobility as a core > "problem", as explained in the document. (That doesn't mean we > don't recognize that some of the solutions under discussion may > also be applicable to mobility scenarios. Rather, we tend to see > improved mobility as a possible benefit of certain classes of > solutions.) > > - Are there other views of what folk perceive the core routing and > addressing problem to be? > > Thomas > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > ____________________________________________________________________________________ Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 27 15:03:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEV5c-0004Tg-2v; Fri, 27 Jul 2007 15:03:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEV5b-0004RJ-1f for ram@iab.org; Fri, 27 Jul 2007 15:03:03 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEV5Y-0004F3-B3 for ram@iab.org; Fri, 27 Jul 2007 15:03:03 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 332D759DEB; Sat, 28 Jul 2007 05:02:56 +1000 (EST) Message-ID: <46AA4154.40001@firstpr.com.au> Date: Sat, 28 Jul 2007 05:02:44 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] ITR complexity & security (ICMP) in LISP-NERD/CONS & eFIT-APT References: <20070727165255.B57EF86ADD@mercury.lcs.mit.edu> In-Reply-To: <20070727165255.B57EF86ADD@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Noel Chiappa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Noel, Thanks for your response. In this reply, I discovered what I think are two nasty problems with what I have written so far about "outer SA = inner SA" enabling the sending host to discover reachability and to do Path MTU Discovery, without involving the ITR. I have pointed to this message from: http://www.firstpr.com.au/ip/ivip/to-do/ because of these problems. You wrote: > All ITRs/ETRs have their interfaces which face toward the 'core' (i.e. the > other ITRs/ETRs in the system) have addresses from some reserved part of the > address space (e.g. net 10), addresses which are not functional on the 'site' > side of the ITRs/ETRs. (I.e. you can't send a packet to one of the addresses > from inside a site.) The ITRs only accept reachability DU messages on those > interfaces, destined to the addresses from the reserved space. > > In other words, there's no way to send them one of these DU packets from a > customer site. This should be easier than carefully validating each > individual DU, and keeping enough state to do so, right? > > Yes, this still allows a compromised ITR/ETR to generate bogus traffic, but I > think it's a useful reduction in the threat universe. I think that eFIT-APT is intended to ultimately result in something like this complete separation of core addresses from provider network internal addresses. There isn't any particular address space for the core - it could be just some bunch of prefixes, as far as I know - but once it was fixed, the routers could all be programmed to not allow packets from non-core addresses to core addresses. However, this can only be fully achieved, to my understanding, once every network is upgraded to the new system. As long as it is necessary to accept packets from non-upgraded networks, there is no complete fence around the "core". Even if there was, I think this is a "strength of the weakest link in a chain" approach to security, where one leak can sink the boat - to combine two well-used metaphors. I try to discuss this vision of eFIT-APT, which is my own - not that of the authors - in the "Incremental deployability" section of: http://www.firstpr.com.au/ip/ivip/comp/ I think the "core separation by address range" solution as you suggest would be hard or impossible to incrementally deploy. > I don't have any clearest best idea on how to validate incoming DU messages > from other ITRs/ETRs... Maybe a per-ETR nonce (i.e. only a slight amount of > increase in the state in the ITR), which is included in each tunnelled > packet, or something like that. If it's 32 bits, and changed every 10 > seconds, it would be hard to find by generating random values (and in any > case the incoming errors could set off alarm bells), and even if it were > found, it would only give you a break-in for a few seconds. I don't see a totally rock-solid cryptographic way of doing it with UDP encapsulation, since as far as I know, the ICMP DU message is only required to return the IP header and the following 8 bytes, which is the UDP header. I think that by randomising the UDP port number the encapsulated packet is sent from, the ITR could make it hard for an attacker to stumble upon the right 16 bits of port and the right 16 bits of checksum, even if they could guess the length, which I figure they could pretty easily. That is getting close to 32 bits of crypto-like hard-to-find difficulty. Also, the attacker has to get it right for a packet sent in the last second or so - so I think this combination of two 16 bits of variability would be pretty solid. A workaround for marginally sub-optimal security would be for the ITR to not take drastic action due to a single ICMP DU message - which seems prudent anyway. > In short, I agree this is a problem, and one that needs a solution, but > I'm not sure the mechanism you posit is the best solution. > > In part, you seem to be trying to solve it without changing the protocol > (i.e. packet format), and I think that's too hard a constraint. If you really > need a screwdriver, go buy one, don't try and make do with a hammer. The only reason I am going to all this trouble describing the problem and the difficulty of solving it is to suggest that the whole approach of having the ITR tunnel packets with the outer header Source Address (SA) being its own ITR address, is wrong. I know this is the conventional way to do it, but when I designed Ivip, I copied what I thought LISP was doing, wrongly thinking that it sent the packet with the outer SA = the sending host's address. I think that this "outer SA = inner SA" turns out to have three major benefits (actually maybe two are duds . . . ), including: 1 - The ITR never gets ICMP DU packets for unreachability - those which are generated in the tunneled part of the packet's journey will go straight to the sending host. (This cannot be contemplated for LISP or eFIT-APT - unless the ITR sends probe packets and does reachability by getting a positive response from any ETR which is really reachable. As far as I know, it is a central tenet of LISP and eFIT-APT that the database updates are slow so the ITRs need to test for reachability themselves and make their own real-time decisions about multihoming service restoration at the time they are tunneling traffic.) !! Unfortunately, this may not work for reasons explained in !! the next point . . . Anyway, relying on ICMP is a lousy approach for any host testing for reachability. It is not reliable anyway, in part due to filtering of ICMP messages to reduce security problems. 2 - The ITR never gets ICMP DU packets which result from the sending host's attempt to discover the MTU of the path to its destination host, and where the encapsulated packet is too big for some router. The ICMP packet goes back to the sending host . . . Hmmm, unfortunately, the sending host might not recognise it, because it carries with it a copy of the ITR's outer packet and 8 bytes of whatever comes next (IP header for Ivip's current IP-in-IP encapsulation, or alternatively the UDP header for UDP encapsulation). This does not resemble the IP header and next 8 bytes of the packet the sending host sent - so it should ignore it. !! I just realised this - PMTUD probably *won't* work ~:( PMTUD is unreliable anyway. Still I think the new architecture should not degrade or worse still completely break it. Since the new architecture involves tunneling, there are going to be pervasive MTU problems leading to fragmentation. Maybe while designing a new architecture, there needs to be a fresh approach to PMTUD anyway - which will probably involve changes to host operating systems. But without it, there are going to have to be some changes to hosts, ideally automatic via different DHCP values, so hosts generally send packets which are short enough that when encapsulated they generally won't be fragmented. (This is an IPv4-centric discussion.) 3 - I think it makes it much easier for the ETR to enforce the border routers filtering to stop an attacker from outside the network sending packets which when decapsulated contain sending addresses from the network's own prefixes. I wrote a lot about this on 14 July: http://www1.ietf.org/mail-archive/web/ram/current/msg01705.html - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jul 27 15:09:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEVBd-0000W1-5U; Fri, 27 Jul 2007 15:09:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEVBb-0000Vw-HQ for ram@iab.org; Fri, 27 Jul 2007 15:09:15 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEVBa-0004NF-SX for ram@iab.org; Fri, 27 Jul 2007 15:09:15 -0400 Received: from pmismtp03.mcilink.com ([166.37.158.163]) by firewall.verizonbusiness.com (Iplanet MTA 5.2) with ESMTP id <0JLU00J1WQJ4ZH@firewall.verizonbusiness.com> for ram@iab.org; Fri, 27 Jul 2007 19:09:09 +0000 (GMT) Received: from pmismtp03.mcilink.com ([127.0.0.1]) by pmismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JLU000HRQJ6JW@pmismtp03.mcilink.com> for ram@iab.org; Fri, 27 Jul 2007 19:09:06 +0000 (GMT) Received: from meno.corp.us.uu.net ([153.39.146.71]) by pmismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JLU000CRQJ695@pmismtp03.mcilink.com> for ram@iab.org; Fri, 27 Jul 2007 19:09:06 +0000 (GMT) Date: Fri, 27 Jul 2007 15:09:06 -0400 (EDT) From: Jason Schiller Subject: Re: [RAM] First cut at routing & addressing problem statement In-reply-to: X-Sender: schiller@meno.corp.us.uu.net To: "Ricardo V. Oliveira" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > What do you mean by internal IPv4 table? In large IS, the number of > routable prefixes in a router can easily reach 250k. You can classify the routes in a large ISP as "Internet routes" these prefixes also show up in the Internet table, and internal routes, these are ones that are not advertised outside of the AS. Currently the Internet table (DFZ) is rougly 230K. ISPs carry an additional 50K-150K internal prefixes that don't appear in the Internet table (DFZ). This does not include VPN routes. In IS, the total number of routable prefixes (Internet + internal) in a router can easily reach 380K. I hope that answers your question. Can you please look back at section 4.7 and see if the text is sufficent or if more detail needs to be provided to make this clear. __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller@uu.net UUNET / Verizon jason.schiller@verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Fri, 27 Jul 2007, Ricardo V. Oliveira wrote: > Date: Fri, 27 Jul 2007 10:32:19 -0400 > From: Ricardo V. Oliveira > To: ram@iab.org > Subject: Re: [RAM] First cut at routing & addressing problem statement > > Hi Thomas, > > Some minor comments on the draft: > Sec 4.7: > "For a large ISP, the internal IPv4 table can be between 50,000 and > 150,000 routes." > What do you mean by internal IPv4 table? In large IS, the number of > routable prefixes in a router can easily reach 250k. > > The degree of interconnectedness between ASes has increased in recent > years. That is, the Internet as whole is becoming "flatter" with an > increasing number of possible paths interconnecting sites [ref?] > http://www.cs.ucla.edu/~rveloso/papers/fp163_oliveira.pdf has some > numbers for this in section 4.3. > > Thanks, > > --Ricardo > > > On Jul 26, 2007, at 8:20 PM, Thomas Narten wrote: > > > The Routing & Addressing directorate has been working on a strawman > > problem statement since Prague. I just submitted our first cut as an > > Internet Draft and it's available at: > > > > http://www.cs.duke.edu/~narten/ietf/draft-narten-radir-problem- > > statement-00.txt > > > > We would welcome comments on the document. In particular: > > > > - Do folk agree with the problem statement as written, or are we > > missing something fairly fundamental? > > > > - Are there other pressures on the routing system that we have not > > listed or described completely? > > > > - We intentionally did not include improving mobility as a core > > "problem", as explained in the document. (That doesn't mean we > > don't recognize that some of the solutions under discussion may > > also be applicable to mobility scenarios. Rather, we tend to see > > improved mobility as a possible benefit of certain classes of > > solutions.) > > > > - Are there other views of what folk perceive the core routing and > > addressing problem to be? > > > > Thomas > > > > _______________________________________________ > > RAM mailing list > > RAM@iab.org > > https://www1.ietf.org/mailman/listinfo/ram > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jul 28 02:17:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEfbp-0006bW-PA; Sat, 28 Jul 2007 02:17:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEfbn-0006bL-E2 for ram@iab.org; Sat, 28 Jul 2007 02:16:59 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEfbj-0003yM-8h for ram@iab.org; Sat, 28 Jul 2007 02:16:59 -0400 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 7953884 for ram@iab.org; Sat, 28 Jul 2007 02:16:53 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) To: ram@iab.org Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-7--1009703681 From: Marshall Eubanks Date: Sat, 28 Jul 2007 02:16:49 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a261d4298f5299f93ee7c68f55bfa47 Subject: [RAM] Jabber notes from the IETF 69 meeting X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Here is the complete jabber log from today's meeting - without any editing, and including smiley's, as text and pdf. Enjoy. Regards Marshall Jabber Chat with lixia@jabber.postel.org, jlc69john@jabber.org, dowstreet@jabber.postel.org, mlshore@jabber.org, dudisaki@jabber.org, jgs@jabber.org, mjo@jabber.org.au, kazuya@jabber.org, washad@jabber.org, iljitsch@gmail.com, shep@jabber.psg.com, arifumi@12jabber.net, nm@jabber.org, csp@jabber.org, yoshfuji@jabber.org, gih900@jabber.psg.com, dthaler@jabber.org, yone@jabber.org, cabo--tzi--org@jabber.org, sbrim@jabber.org. 10:17 AM The topic has been set to: 10:17 AM questions interrupt or at the end? lixia: good point haven't discussed tradeoffs that's Dave Meyer (dave meyer?) mike: religion about keeping routing table small, but this comes at a cost solutions... problem: too many entries in GRA, too many updates hm, a GRA is just "globally routable address". I hadn't noticed "space" on that slide. (scribe: not GRAS?) terminology: GRA: globally routable address space if you see anything that's missing or is incorrect, let us know framework will become better over time process not finished yet, what I say is not complete 10:10 AM looked at solutions framework didn't fall out of the blue sky as in sbrim --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Brim prepared with Scott Brim(m?) it's good, as long as they repeat audience questions into the mike lixia about taxonomy (microphone trouble) I can hear --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed if you can't hear me, it's no important lixia: 3.10: solutions required to be deployable from a technical perspective, not touching other perspectives 3.9: clarification: not current level of security as of publication, but level current when solution is deployed rearranged reference 3.8: new criterium: stability 3.6: changed "needed" to "required" 10:05 AM also added: strongly desired that control plane scale independently from... 3.1 terminology change: routing plane -> control plane comments not absorbed yet due to vacation want to go throug the changes we have a draft tony li: design goals change accepted agenda proposal: first dino, then elliot, dave, luigi I mean, audio slides at http://videolab.uoregon.edu/events/ietf/ietf698.m3u agenda bashing no scheduled breaks, no cookies but there will be a break at some point thanks iljitsch is jabber scribe for part of the day Hi, Scott - hope all is well. I'm in TAM ah are any of you actually in the room? 9:55 AM Hi Good morning... 2:05 AM Testing 10:15 AM proposed solutions: proposed solutions a1: only use topologically aggregatable address space = multihoming - > multiple addresses (GSE, shim6, Six/One) tony1athome@jabber.org has joined this chat. a2: move "edge" prefixes out of global routing system by tunneling 10:20 AM dino and lisp folks use ETR/ITR terminology, I didn't egress tunnel router ingress tunnel router (sorry I always mix up itr / etr) Geoff Huston : Beware of false dichotimies geoff: beware of false dichotomies, is there an a3? lixia: not complete, but no a3 at this time Geoff : you have the ability to numberthe network, not the edges juampe.cerezo@gmail.com has joined this chat. This is just categorizing things that have actually been submitted here. There may be more ideas out there, and we're hoping that we can establish dimensions along which we can evaluate new concepts as they are proposed, but we don't have all possible approaches listed. lixia: you can recursively apply a2 Geoff : I think that there are more lixia: send a more precise description Q : Do you have an example ? aaaaaaaaaaa --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed _ keiichi_shima@jabber.org has joined this chat. Geoff : MPLS moves out of those dichitomies Geoff : I was asked for a quick example, I gave one off of the top of my head I don't get his point Geoff : The tokens in the routing system might be how to get rid of the packet relative to you, not necessarily relative to the destination [I am not sure what that means] 10:25 AM maybe it means the packet is tagged with my egress, as opposed to my destination's ingress ?? But that's the way we're all doing it already. ? lixia: For some solutions the mapping happens at the border router lixia: for others, like shim6, it happens inside the host lixia: 3 questions Scott: where is the slide pack that Lixia is using (url?) lixia: Geoff may have more lixia: Q1 How do you get mapping information I don't see it on the web. We were still fixing them this morning. lixia: how do you detect reachability failures Ask her if she has it up for FTP somewhere Geoff: please do send mail about what you said. she's talking - I though you may have a copy --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I do ... I'll send it I'll send mail lixia: I forgot : in some designs, we assume that CE may be the ETR [] lixia: Question 3 : When you detect the failure, how do you handle it lixia: will elaborate more in future slides lixia: also abuse issue and the scalability issue lixia: what is the assumption of the size of the row Question : You don't have how to update mapping info lixia: this will be included later satoru.matsushima@jabber.jp has joined this chat. [questioners please state names !] lixia: Question 1 - elaboration lixia: Suppose that our campus has three providers 10:30 AM lixia: who holds this information lixia: Q1.1 how to inject the mapping information into the system lixia: Q1.2 who holds this information lixia: The holder and the user are not necessarily the same entity lixia: two kinds of updates lixia: one is changes in mapping information, like dropping a provider lixia: this is separate time granularity from the second, which is topology failures lixia: when a router goes down lixia: etc lixia: How does one get mapping information into the system b@bruce-2007.zerlargal.org has joined this chat. lixia: the second way the mapping happens when the packet is injected [I missed the first one] lixia: How you get this information out - some proposals will mention the specifics - the security question arifumi@12jabber.net has left this chat. lixia: is an important consideration, so that you don't get misdirected to the wrong site lixia: You can push or pull this information lixia: push = flood lixia: security is a critical component 10:35 AM lixia: how to detect failures is very important She distinguishes "flood" as general and "push" as more specific, as to who gets sent the information. lixia: we have a routing system to that inside the local address space, or at least this is the defaukt lixia: do not harm is one of the principles Scott - an automated flood of ROW to GRA mappings is just a reinvention of BGP - right? lixia: when the mapping happens at a edge router (this is a new issue we do not have today) i.e. its precisely the same as the automated flood of ROW to nexthop geoff: not necessarily, IMO. BGP works across multiple hops, a system like this wouldn't necessarily have hops lixia: today, a failure along one path results in a prefix withdrawl and the data flow will move to other paths so it could be like iBGP, not eBGP lixia: if the routing system stops at the border of a cloud then BGP updates will not cover a path update [outside of the cloud] lixia: the ETL [?] prefix is not in the routing system arifumi@12jabber.net has joined this chat. lixia: Means for failure detection lixia: given that the routing system cannot handle these failures lixia: how can you detect them ? lixia: if you put the mapping information into the source host - shim6 relies on the upper layers to detect the errors lixia: In A2 a new thing will have to detect these Internet omnia in duo partes divisa est lixia: what I have seen relies on ICMP messages or their equivalent 10:40 AM dudisaki@jabber.org has left this chat. dudisaki@jabber.org has joined this chat. Q : There is another factor - you can rely on symmetric paths who is it? Erik Nordmark lixia: how to handle failures aha we can't assume symmetric paths lixia: when the host handles failures [Erik was hard for me to hear] you should try the audio feed --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I think Erik's point was that at the edge, you see both directions but due to asymmetric paths, you generally don't in the middle aha, got it Erik's point is that the end host (and in some cases routers very close to them) can see symmetric paths and can do more thanks all (iljitsch beat me to it --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed lixia: there is no free lunch. If we take the A2 approach the packets have gone into the system. How do you handle inflight packets when a failure is detected lixia: failures are hopefully not permanent arifumi@12jabber.net has left this chat. lixia: even for Shim6, hosts try to keep up with the status of the different destinations lixia: for A2, we will see later how this is handled Dino ; In the core of the network, how to handle failures is well known lixia: there are two additional factors arifumi@12jabber.net has joined this chat. lixia: one is how to handle packets during lookup delay [on faiure] 10:45 AM lixia: two new factors that introduce packet losses Dino : My comment was about the locatability reachability issue Q : Duplicate detection efforts by multiple hosts is not necessarily a problem [please give names !] Tim Sheppard lixia: There is not a central node - everybody addresses - detects failure and takes corresponding efforts lixia: the mapping stuff introduces new issues that don't exist today/ lixia: if you take the "host take care of itself" approach you wish you could share this information lixia: we have two computers that try and reach Google (for example) lixia: first guy tries address X lixia: it doesn't work, he uses address Y Tim : Google certainly announces multiple addresses csp@jabber.org has left this chat. Tim : You seems to be assuming that hosts are only connected through one network Q : You seem to be assuming that you have to do the mapping before you inject packets into the network I don't see why he thinks that Kevin Fall 10:50 AM Q : If you can encode the destination into the packet you may be able to do this more effeciently Kevin : If we have a world where devices are less and less capable, like mobile devices, putting this into the host makes me uncomfortable this is Erik again now Erik : If it is only X and Y that is easy. If you have 16 things to chose from that is different csp@jabber.org has joined this chat. lixia: You can see that in some of the proposed solutions Summary of questions q1 : How to get mapping info lixia: Her are evaluation criteria [too many to retype] data delivery performance: delay due to mapping lookup, delay due to suboptimal paths, loss due to lack of mapping info, loss during transient failure, traffic concentration Kevin [?] : Does the routing have the ability to pick shortest paths is an important factor (yes this is Kevin Fall) lixia: Should we make dynamics separate benno@jabber.xs4all.nl has joined this chat. lixia: now it is in two places benno@jabber.xs4all.nl has left this chat. Kevin does not seem to be talking about the criteria, but how to measure along the dimensions the criteria invoke. That's fine. We didn't get there very much. benno@jabber.xs4all.nl has joined this chat. lixia: What I hear you saying is that we should have a separate item about this 10:55 AM about dynamicity Erik : I am confused - there is a risk of a solution that solves multi homing but forgets about traffic engineerin g lixia: I don't see that there is a fundamental difference between the two Erik : There are multiple levels at which you might want to do TE lixia: I didn't mention about that Q : There is an area where we need a lot more data ^ Eliot Lear Elliot : If you solve multi homing is that good enough ? And if not, why not ? Sandy Murphy : The security of the router system. Sandy : John Scudder at the last IETF had a functional description of the security of the routing system Sandy : Your slide said security of the mapping info, which is only one part of the security of the routing system it shouldn't be a hierarchy. I learned the term "facet-based categorization" from Melinda. lixia: This is a very important question. We definitely need a document or a framework there Ilijitch : The number of prefixes from the RIR is growing by 7 % / year, while the prefixes in the table is growing by 16% / year 11:00 AM Ilijitch : if people have PI space and they want to announce multiple blocks in mulitple locations - there are only 25 As now and 225,000 prefixes 25k lixia: We will incorporate these comments into the next draft - the first draft who's next? Vogt Christian Vogt thanks yone@jabber.org has left this chat. Christian : I want to present the Six / One solution, which is a combined edge based host based solution Christian : three stakeholders Christian : Edge networks, providers and hosts Christian : Edge networks want to select from multiple providers Christian : another goal of edge networks is to reduce the cost of network configuration Christian : the goals of the host is also to select a particular provider Christian : it is also a goal of the host to adapt Christian : say if the provider changes, or on RTT measurements Christian : there are 3 types of solutions 11:05 AM Christian : current practice is PI space to edge networks, which is globally visible [has a table on his graph] Christian : Each PI address block increases size of address space Christian : Host goals are not met with PI space as the hosts does not see these Christian : Shim6 was developed to solve the routing address space growth Scott: I just uploaded the slides to RRG page http:// www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaChicago (it is the same as the one I sent you last night) OK thanks Christian : With shim6 the edge network cannot select providers, as these are selected by the hosts with the tail slides (on individual proposals) cutoff shhhh --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Christian : Another thing that edge networks may not like is that they don't have PI space Christian : to give the edge networks more capabilites and reduce rehoming costs there Christian : have been recent proposals with PI space and a mapping between PI space in a edge network and provider dependent space in the global network Christian : the goal of Six/One was to meet all of these goals Christian : here is an overview Christian : you can think of six /one as a combination of Shim6 and 8+8 \Christian : Erik Nordmark has a draft to combine these 11:10 AM Christian : draft-nordmark-shim6-esd Christian : Hosts get dependent address space Christian : within the edge network every link gets a subnet ID Christian : hosts then configure one address per subnet prefix b@bruce-2007.zerlargal.org has left this chat. Christian : all of these addresses have a common, cryptographically generated, interface identifies Christian : which is the same across the entire address bunch Christian : the host shows a single stable address to each application Christian : with a variable address on the wire Christian : what is different from shim6 is that the edge network is able to rewrite the routing prefix of a host Christian : Why ? Christian : so that the edge network can change providers Christian : hosts need context of each other's address bunches Christian : this is split into two parts Christian : this figure shows how the rewriting works Christian : both the host and the corresponding host run a six/one instance kazuya@jabber.org has left this chat. Christian : when an application sends a packet, say with routing prefix 1000 11:15 AM Christian : I forgot - there are two cases - one where the addresses are passed through, and the second where they are rewritten Christian : the host is suggesting the provider Christian : at some point the edge network may decide to rewrite the routing prefix of the packets source address to povider number two Christian : the six one instance on the correspondant host recognizes this change Christian : and adopts it Christian : so that the return packet goes through provider 2 Christian : applications don't see the change Christian : when the host sends the next packet its own six/one instance it uses the new routing prefix Erik Nordmark : How do you enforce [symmetric paths] That was Dave Oran Christian : You don't need host specific state to do the re-writing Q : How does the edge network detect that the correspondant host can detect this change jlc69john@jabber.org has left this chat. Christian : I was not talking about discovery of support Q = Tim Sheppard Christian : I was assuming you can rely on the correspondent host to detect this Christian : I am assuming that at this point Tim : This is a neat idea but I am worried if we can ever get there 11:20 AM Tim : I wish we had thought of this years ago Christian : The crucial part is of course to bring this into the hosts Dino : This looks very much like Shim6 Christian : The edge network can decide where the packets go Dino : You mean that there are routers in the edge network doing this ? Dino : You have that Six / One vertical bar. Where is the functionality Christian : The veritical bar is within the host Christian : The rewrite happens within a rotuter, presumabably a border router Dino : Now tell me the difference between the this slide and GSE my last name is spelled "Shepard" (only one 'p') Christian : In GSE the host doesn't see the provider. The source addresses don't show this. They cannot adopt the provider and don't when it is changed juampe.cerezo@gmail.com has left this chat. Christian : The cryptographic indentifier can be used to make sure that these packets belong together the rewriting router has to have state for each connection, right ? Brian Carpenter : I wish that this had come up in the Multi-6 WG Brian : I was waiting on a version of GSE that was plausible dudisaki@jabber.org has left this chat. dudisaki@jabber.org has joined this chat. 11:25 AM Brian : I believe that this is very promising. I am not proposing that we drop Shim6, as Geoff might hit me [laughter]/ Goeff : Shim6 does its own failure detection Christian : Both the host and the edge network can rewrite the addreses. However, the edge network has the final say b@bruce-2007.zerlargal.org has joined this chat. Geoff ; The problem is that the only time you understand true failure is in the host. [I am not sure I got that right] Christian : This is the collision of the goals that we have Christian : The routers only rewrite the source address his point is that if the edge rewrites without seeing the return path, it can rewrite to an address the host rewrote away from to get around failure of the return path Christian : You can only select the providers that the edge network directly connects to so geoff is saying that this breaks shim6 failure avoidance thanks Dave - yes that is my point - the host can see the failure, but the edge router cannot Q : Did you remove anything from Shim 6 ? Christian : No. There is stuff on top of Shim 6 Jari : This is cryptographically slightly different benno@jabber.xs4all.nl has left this chat. juampe.cerezo@gmail.com has joined this chat. Christian : The router in the edge network only needs to rewrite the routing prefix. It doesn't need to keep any host state in the edge network todesgeliebter@gmail.com has joined this chat. dmm613@gmail.com has joined this chat. 11:30 AM Q : Suppose that there is a 3000 prefix. If the host doesn't know about it, the packet will get dropped on the floor. This is different of 8+8 Q=Erik Nordmark [thanks!] Christian : The next slide shows how context gets established Christian : The Six / One has a local context which shows what providers are available, and an incomplete remote context Christian : That context is given an unique context ID chosen by the host. vaf@jabber.org has joined this chat. Christian : With the first packet the host sends there is piggy back information to describe the hosts context Christian : with adiditonal information so that the correspondent host can verify that these belong togther Christian : when the packet arrives, the correspondent host has a complete local and remote context Christian : the correspondent host sends back the corresponding information Christian : after that, each side only sends context ID's Christian : One of the goals was to reduce the cost of reconfiguration when the edge network rehomes 11:35 AM Christian : the basic idea is to split the router configuration into subnet ID (which doesn't have to change) and one set of routing prefixes which does have to change Christian : there doesn't have to be any link specific updates Christian : routers only have to rewrite the subnet prefix leslie-ietf@ecotroph.net has joined this chat. Christian : Six/One only handles changes within one address bunch vaf@jabber.org has left this chat. Christian : Host mobility and host multi-homing and during host network renumbering will cause changes in address bunches Christian : these will require a separate protocol eliot.lear@gmail.com has joined this chat. farinacci@gmail.com has joined this chat. Christian : Middle box interoperablity Christian : Devices like firewalls operate on addresses of hosts Christian : this will still work Christian : these middle boxes can indentify hosts by masking the routing prefix Christian : similar to 8+8 Christian : Identifying a remote corresponding host - by looking at the local host with which it communicates 11:40 AM Christian : the triple of subnet, context and identifier ID can uniquely indentify a host Christian : [Summary slide] hantula@jabber.org has joined this chat. Dino : Have you got any input from operators about the trade off between tunneling and re-writing ? Dino : Did you consider tunneling Q : Back when Mike wrote 8+8 he said that rewriting would be useful for operators Q=Erik Nordmark Q ; This rewriting is a useful way of doing traffic engineering this is Suresh Krishnan 11:45 AM [sorry - interrupt] Suresh asked how it worked with CGAs, and Christian explained HBAs Geoff : I think that there is a tension that Shim 6 does more. When the edge sites are busy rewriting - the host knows about connectivity - the hosts and the edges are trying to do something subtly different Christian : The writing in the edge network can only affect the source address Christian : that does not affect the provider at the correspondant host Christian : the writing is a local think Christian : I assumed that the edge network was aware of which provider has connectivity 11:50 AM Christian : the writting can only affect the local routing Q : You have decided to make the signalling from the host - the host was selecting the path - if you chose to override this, the packet will be going out the provider you want, but you cannot ensure that the correspondent host makes that choice Q=Tim Shepard (with correct spelling this time --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed kazuya@jabber.org has joined this chat. Tim : In Shim6 the end host is making all of the decisions. I almost think that there is some means of communicating the networks desires for traffic engineering to the end host Christian : Another approach is in terms of transistion Christian : It would be easier to cope with legacy hosts if you do not change addresses during a connection Q : The beauty of rewriitng in the router is that this is a router through which the packet is passing, so it could have dropped the packet anyway Q=Erik 11:55 AM Erik: So presumably it has authoriity to change the packet Erik : With PI space it is pretty clear who can select the path. With Shim 6 this is moved to the host. This is a mixed approach Christian : In this approach the host can only suggest Thomas Narten : In this case the host and the edge network do not have consistent information. Some times they will make the wrong decision for the other one Geoff : Here is a simple example. Path A and Path B are completely different. The edgte network wants to TE to Path A. The hosts have found that there is a Geoff : a break in Path A, and want to use Path B. There is no signalling mechanism to share this infromation right Geoff : Unlike what Brian said, we saw some of these proposals [computer battery break] kazuya@jabber.org has left this chat. 12:00 PM kazuya@jabber.org has joined this chat. Q : If the network could signal TE - one way of doing that is by dropping it, or rate limiting it Q=Tim Shepard kazuya@jabber.org has left this chat. Tim : If the host could have a collection of prefixes, there is a real traffic engineering question here. Is that in scope for the RRG ? kazuya@jabber.org has joined this chat. Christian : The ability of the edge network - you can give it full control. It might not have the full view, as Geoff has said jlc69john@jabber.org has joined this chat. Q : If the network is going to rewrite something, the network is saying, you can use this one, the end host has the set of possible paths [this was Dow Street speaking] [I didn't understand that ] I think Dow was saying instead of rewriting, edge could tell host what to rewrite it to (and drop traffic that isn't rewritten by the host) Dino : I was think of the opposite - if we want session reachability, it might be useful if the hosts could tell the routers which paths to Dino : That means more mechanisms I think those who don't remember multi6 are forced to relive it. --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed [even I know you, I may not know your voice !] lixia: My stduents couldn't make it here 12:05 PM lixia: APT lixia: Where does APT sit ? benno@jabber.xs4all.nl has joined this chat. lixia: Its an older sister of LISP lixia: We didn't know that RRG was the venue for this lixia: APT does two parts lixia: distributes mapping information lixia: then what do you do with it to clarify my previous comment - there is not any re-writing in the network. the host selects addresses for the packet - and this selection impacts the path that is taken. lixia: Three types of nodes lixia: standard routers, the routers of today arifumi@12jabber.net has left this chat. lixia: in organge there are the routers that understand this new information lixia: they hold the mapping information however, this host-based selection of addresses is bounded to the set of allowable addresses published by the network. eliot.lear@gmail.com has left this chat. lixia: the ITRs are the users of this information lixia: We submitted a draft for the IETF deadline lixia: but then detected some issues which have been changed lixia: Mappers - these are new device juampe.cerezo@gmail.com has left this chat. arifumi@12jabber.net has joined this chat. lixia: these store entire mapping information 12:10 PM lixia: What if you have multiple mappers lixia: we propose anycast to reach them lixia: each AS should have one lixia: at least Dino : Are you required to use anycast ? lixia: if you have multiple mappers, yes lixia: Mappers tell the ITRs what mapping entries to use lixia: The mappers do control, TE mlshore@jabber.org has left this chat. lixia: In return the ITRs are as simple as possible lixia: The goal for the tunnel routers os minimal changes and stay simple lixia: the brains are in the mappers lixia: Each ITR has one entry for each routable prefix lixia: No mapping entry, tunnel packet to the mapper lixia: the mapper forwards the packets, abnd responds with a mapping entry back to the ITR batfli@jabber.org has joined this chat. lixia: this is influenced by the goal of making the ITR simple lixia: I want feedback on this goal lixia: We hope that there are no changes to other existing routers lixia: Although such changes might be optional; lixia: examples 12:15 PM lixia: edge prefixes are numbers lixia: GRA addresses are letters (in the slide, not literally --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed (though the idea of reducing the routing table to 26 prefixes is strangely appealing) make it binary and reduce to 2 prefixes.... (yeah but half of them are already taken by dns root servers --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed [sorry, interrupt] lixia: [Stepping through situation 1] 12:20 PM lixia: If there is a failure, the mapper learns about it from the BGP =20= stuff lixia: When the mapper sends the new mapping information to the ITR, =20 it sets a new TTL for this [the ttl is a mapping ttl, not a hop count] Q : Does the mapper return all information ? Q =3D Eliot Lear lixia: We assume that the ITR is as simple as possible lixia: So we only send one Elliot : We need to look at this later lixia: If you notice a failure, you just forward packet to the mapper lixia: As I said before, for preferred path, you put a longer TTL lixia: Situation 2 lixia: This is a new failure mode washad@jabber.org has left this chat. lixia: "Michael" has no routable prefix and so then his link fails =20 this does not go into the global routing table so the ITR does know this lixia: How to do the data forwarding Robert asked the load-splitting question in the ITR 12:25 PM lixia: Michael's ETR forwards the packet to its default mapper lixia: Michael's ETR Mapper tries to find an alternate GRA tunnel =20 address lixia: The dat handling lixia: data handling goal is to minimize packet losses lixia: 2 options to inform sender lixia: the first is easier lixia: send an ICMP destination unreachable message to the ITR, which =20= forwards it to its mapper lixia: the second assumes a well known mapping address. The ETR =20 domain mapper sends a message to the ITR's mapper lixia: The source mapper needs to keep information about currently =20 failed things iljitsch@gmail.com has left this chat. 12:30 PM csp@jabber.org has left this chat. You left the chat by logging out or being disconnected. Rejoining chat room=85 sbrim@jabber.org has joined this chat. cabo--tzi--org@jabber.org has joined this chat. yoshfuji@jabber.org has joined this chat. keiichi_shima@jabber.org has joined this chat. leslie-ietf@ecotroph.net has joined this chat. gih900@jabber.psg.com has joined this chat. hantula@jabber.org has joined this chat. batfli@jabber.org has joined this chat. nm@jabber.org has joined this chat. shep@jabber.psg.com has joined this chat. dmm613@gmail.com has joined this chat. arifumi@12jabber.net has joined this chat. b@bruce-2007.zerlargal.org has joined this chat. satoru.matsushima@jabber.jp has joined this chat. farinacci@gmail.com has joined this chat. benno@jabber.xs4all.nl has joined this chat. mjo@jabber.org.au has joined this chat. jgs@jabber.org has joined this chat. kazuya@jabber.org has joined this chat. dowstreet@jabber.postel.org has joined this chat. jlc69john@jabber.org has joined this chat. lixia@jabber.postel.org has joined this chat. 11:50 AM Christian : the writting can only affect the local routing Q : You have decided to make the signalling from the host - the host =20 was selecting the path - if you chose to override this, the packet =20 will be going out the provider you want, but you cannot ensure that =20 the correspondent host makes that choice Q=3DTim Shepard (with correct spelling this time=20= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Tim : In Shim6 the end host is making all of the decisions. I almost think that there is some means of communicating the networks desires for traffic engineering to the end host Christian : Another approach is in terms of transistion Christian : It would be easier to cope with legacy hosts if you do not change addresses during a connection Q : The beauty of rewriitng in the router is that this is a router through which the packet is passing, so it could have dropped the packet anyway Q=Erik 11:55 AM Erik: So presumably it has authoriity to change the packet Erik : With PI space it is pretty clear who can select the path. With Shim 6 this is moved to the host. This is a mixed approach Christian : In this approach the host can only suggest Thomas Narten : In this case the host and the edge network do not have consistent information. Some times they will make the wrong decision for the other one Geoff : Here is a simple example. Path A and Path B are completely different. The edgte network wants to TE to Path A. The hosts have found that there is a Geoff : a break in Path A, and want to use Path B. There is no signalling mechanism to share this infromation right Geoff : Unlike what Brian said, we saw some of these proposals [computer battery break] 12:00 PM Q : If the network could signal TE - one way of doing that is by dropping it, or rate limiting it Q=Tim Shepard Tim : If the host could have a collection of prefixes, there is a real traffic engineering question here. Is that in scope for the RRG ? Christian : The ability of the edge network - you can give it full control. It might not have the full view, as Geoff has said Q : If the network is going to rewrite something, the network is saying, you can use this one, the end host has the set of possible paths [this was Dow Street speaking] [I didn't understand that ] I think Dow was saying instead of rewriting, edge could tell host what to rewrite it to (and drop traffic that isn't rewritten by the host) Dino : I was think of the opposite - if we want session reachability, it might be useful if the hosts could tell the routers which paths to Dino : That means more mechanisms I think those who don't remember multi6 are forced to relive it. --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed [even I know you, I may not know your voice !] 12:05 PM lixia: My stduents couldn't make it here lixia: APT lixia: Where does APT sit ? lixia: Its an older sister of LISP lixia: We didn't know that RRG was the venue for this lixia: APT does two parts lixia: distributes mapping information lixia: then what do you do with it to clarify my previous comment - there is not any re-writing in the network. the host selects addresses for the packet - and this selection impacts the path that is taken. lixia: Three types of nodes lixia: standard routers, the routers of today lixia: in organge there are the routers that understand this new information lixia: they hold the mapping information however, this host-based selection of addresses is bounded to the set of allowable addresses published by the network. lixia: the ITRs are the users of this information lixia: We submitted a draft for the IETF deadline lixia: but then detected some issues which have been changed lixia: Mappers - these are new device lixia: these store entire mapping information 12:10 PM lixia: What if you have multiple mappers lixia: we propose anycast to reach them lixia: each AS should have one lixia: at least Dino : Are you required to use anycast ? lixia: if you have multiple mappers, yes lixia: Mappers tell the ITRs what mapping entries to use lixia: The mappers do control, TE lixia: In return the ITRs are as simple as possible lixia: The goal for the tunnel routers os minimal changes and stay simple lixia: the brains are in the mappers lixia: Each ITR has one entry for each routable prefix lixia: No mapping entry, tunnel packet to the mapper lixia: the mapper forwards the packets, abnd responds with a mapping entry back to the ITR lixia: this is influenced by the goal of making the ITR simple lixia: I want feedback on this goal lixia: We hope that there are no changes to other existing routers lixia: Although such changes might be optional; lixia: examples 12:15 PM lixia: edge prefixes are numbers lixia: GRA addresses are letters (in the slide, not literally --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed (though the idea of reducing the routing table to 26 prefixes is strangely appealing) make it binary and reduce to 2 prefixes.... (yeah but half of them are already taken by dns root servers --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed [sorry, interrupt] lixia: [Stepping through situation 1] 12:20 PM lixia: If there is a failure, the mapper learns about it from the BGP stuff lixia: When the mapper sends the new mapping information to the ITR, it sets a new TTL for this [the ttl is a mapping ttl, not a hop count] Q : Does the mapper return all information ? Q = Eliot Lear lixia: We assume that the ITR is as simple as possible lixia: So we only send one Elliot : We need to look at this later lixia: If you notice a failure, you just forward packet to the mapper lixia: As I said before, for preferred path, you put a longer TTL lixia: Situation 2 lixia: This is a new failure mode lixia: "Michael" has no routable prefix and so then his link fails this does not go into the global routing table so the ITR does know this lixia: How to do the data forwarding Robert asked the load-splitting question in the ITR 12:25 PM lixia: Michael's ETR forwards the packet to its default mapper lixia: Michael's ETR Mapper tries to find an alternate GRA tunnel address lixia: The dat handling lixia: data handling goal is to minimize packet losses lixia: 2 options to inform sender lixia: the first is easier lixia: send an ICMP destination unreachable message to the ITR, which forwards it to its mapper lixia: the second assumes a well known mapping address. The ETR domain mapper sends a message to the ITR's mapper lixia: The source mapper needs to keep information about currently failed things 12:30 PM The topic has been set to: test arifumi@12jabber.net has left this chat. arifumi@12jabber.net has joined this chat. [sorry - Jari and I both lost Internet connection for about 3 minutes] dudisaki@jabber.org has joined this chat. Audio seems to be gone. Please type a lot --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Dave Thaler : My question is whether the new ETR learns the new =20 destination or has to send packets to ETR 2 as if he was a mapper dthaler@jabber.org has joined this chat. I'm losing audio due to drilling in the wall beside me 12:35 PM lixia: This is the question of the brains of the ITRs bensons@jabber.postel.org has joined this chat. lixia: There is the possibility that if ETR 1 knows all of the =20 mapping information for its conencted to it can directly forward =20 packets to ETR 2 My question was whether ETR2 (who can't send packets to destination =20 and has to forward to his default mapper) learns the new mapping (to =20 ETR1 in the example) or whether all traffic continues to go to =20 default mapper gih900@jabber.psg.com has left this chat. lixia: Distributed mappings what does that mean? lixia: between ASes since in situation 3, lots of sources could be sending to the =20 destination and have the same problem, so if he doesn't learn the =20 mapping, lots of traffic ends up going via the default mapper lixia: Quick and dirty solution is to add to BGP lixia: So we propose a new BGP transitive attribute benno@jabber.xs4all.nl has left this chat. and if it does learn the mapping, then it works just like the case =20 where it's an ITR lixia: the mapping entry is the edge prefix to GRA address mapping scott -- is the audio still out? lixia: An edge network sends a singed mapping to al providers, =20 together with its key So ... this pushes "important" mappings to the mappers, mappers pull =20 "less important" mappings from somewhere, and ITRs pull from the =20 mappers. Leslie: I'm getting 404 not found at UoO a provider network floods thier customers mappings to other provider =20 networks by BGP Q : We are securing BGP at some point. Can we secure these mappings Q=3DErik Erik : Presume that secure BGP says, I am allowed to speak on behave =20 of this prefix Erik : Here, I think we need another mechanism 12:40 PM Dino : Are these mappings advertised in line ? lixia: It doesn't use another top[ology Dino : So, you will have to modify all BGP routers lixia: This is a detail that I don;'t remember now Dino : If you don't change the NLRI then youwill have a name space =20 collision lixia: No b@bruce-2007.zerlargal.org has left this chat. Dino : They will Dino : The path attributes are associated with a NLRI lixia: Did I say this was quick and dirty ? Q : At some point you stop advertising customer routers. What is the =20 trigger ? Q : I think it will be much cleaner to define a new SAFI John : I would like to join the people who are encouraging you to =20 abandon this particular use of BGP John : People may filter BGP - this is an unreliable way of =20 transmitting this information 12:45 PM Erik : I have a higher level question. The end result that the =20 mapping information for every end site would be in the RIB of every =20 router of every tier 1 ISP. that was Dave Oran lixia: This was another detail that I didn't want to discuss [laughter] Joel Halpirin : You have said that you have to distribute the whole =20 table - do you have to do this or not ? Halpern lixia: Why not ? audio is back (thanks much!) lixia: We let everybody inject their own piece into the system Dino : Packets go into the default mapper Dino : The ITR doesn't know what to do so it sends it to a default =20 mapper another issue: the data plane of the default mapper needs to be well, =20= huge Dino : If you use anycast, you can't pick which one to send to, so =20 they all have to contain the complete mapper right otherwise how do you know which to talk to? right scott or does a packet chain from one to the other, wandering through the =20 lonely night until it finds a place to call home? well you could have multiple anycast addresses for disjoint address =20 space ranges but then there's a new routing protocol to route map packets nm@jabber.org has left this chat. as long as the default mapper and ITRs agree lionnaduo@jabber.cn has joined this chat. lixia: In defense of pigybacking on BGP right (but could be static config) sure, but the aggregate of those default mappers still add up to one =20 omniscient default mapper right it's just a distributed device at that point iljitsch@gmail.com has joined this chat. 12:50 PM lixia: Mapping updates are far less problematic than BGP routing updates jgs: exactly as long as there's a clear algorithm to select one you're ok -- like =20 5 anycast addresses lixia: APT is not married to BGP and what about any damage done by the new attribute (path explosion, =20 convergence, ....) lixia: If you have a better solution we will be happy to consider sure, you can easily figure out how to distribute it -- but that's =20 not responsive to joel's comment lixia: Mapping information is only accepted from configiured BGP peers correct, APT can't work with CONS as currently defined lixia: Mappers talk to ITRs in the same AS lixia: So, security is local lixia: mapping information does not cross boundaries lixia: border link failure packets can only be sent by GRA packets lixia: You could do something about secure commiunication between =20 mappers lixia: Our current goal is to say that address will not change nm@jabber.org has joined this chat. lixia: edge prefixes may not have mappings to start with we seem to be on schedule lixia: We take the soft state religion lixia: refresh on a regular basis - all infroamtion has a ttl =20 attached to it 12:55 PM lixia: Security issue - how can mappers find other mappers kets lixia: Could send through BGP annioucnement lixia: Keys can be sent through multiple paths bensons@jabber.postel.org has left this chat. lixia: so key spoofing can be detected lixia: by comparing results along different paths lixia: priority is assigned by the owner of the prefix lixia: Once the traffic flows inside the routable space, the ISPs do =20 what they are already doing lixia: Security - publicize all keys lixia: the number of ASes in the routable space is 2 - 3 orders of =20 magnitude than the edge space [this network may drop in 15 seconds] 1:00 PM lixia: We need more data ? from UCN : We are collecting netflow data. If you have software, I =20 can run it on our traces I think it's Luigi Iannone lixia: We could use that. We don't care about the traces, just the =20 distribution yes, it was Luigi from UCL Belgium farinacci@gmail.com has left this chat. cabo--tzi--org@jabber.org has left this chat. lunchtime! dmm613@gmail.com has left this chat. dudisaki@jabber.org has left this chat. lionnaduo@jabber.cn has left this chat. leslie-ietf@ecotroph.net has left this chat. hantula@jabber.org has left this chat. shep@jabber.psg.com has left this chat. kazuya@jabber.org has left this chat. [Mention of a proposal from Cornel U that lixia thinks might be =20 valueable You left the chat by logging out or being disconnected. 2:15 PM Rejoining chat room=85 The topic has been set to: 1:00 PM [Mention of a proposal from Cornel U that lixia thinks might be =20 valueable lunchtime! from UCL Belgium yes, it was Luigi lixia: We could use that. We don't care about the traces, just the =20 distribution I think it's Luigi Iannone ? from UCN : We are collecting netflow data. If you have software, I =20 can run it on our traces lixia: We need more data 12:55 PM [this network may drop in 15 seconds] lixia: the number of ASes in the routable space is 2 - 3 orders of =20 magnitude than the edge space lixia: Security - publicize all keys lixia: Once the traffic flows inside the routable space, the ISPs do =20 what they are already doing lixia: priority is assigned by the owner of the prefix lixia: by comparing results along different paths lixia: so key spoofing can be detected lixia: Keys can be sent through multiple paths lixia: Could send through BGP annioucnement lixia: Security issue - how can mappers find other mappers kets 12:50 PM lixia: refresh on a regular basis - all infroamtion has a ttl =20 attached to it lixia: We take the soft state religion we seem to be on schedule lixia: edge prefixes may not have mappings to start with lixia: Our current goal is to say that address will not change lixia: You could do something about secure commiunication between =20 mappers lixia: border link failure packets can only be sent by GRA packets lixia: mapping information does not cross boundaries lixia: So, security is local lixia: Mappers talk to ITRs in the same AS correct, APT can't work with CONS as currently defined lixia: Mapping information is only accepted from configiured BGP peers sure, you can easily figure out how to distribute it -- but that's =20 not responsive to joel's comment lixia: If you have a better solution we will be happy to consider and what about any damage done by the new attribute (path explosion, =20 convergence, ....) lixia: APT is not married to BGP as long as there's a clear algorithm to select one you're ok -- like =20 5 anycast addresses jgs: exactly lixia: Mapping updates are far less problematic than BGP routing updates 12:45 PM it's just a distributed device at that point right sure, but the aggregate of those default mappers still add up to one =20 omniscient default mapper right (but could be static config) lixia: In defense of pigybacking on BGP as long as the default mapper and ITRs agree but then there's a new routing protocol to route map packets well you could have multiple anycast addresses for disjoint address =20 space ranges or does a packet chain from one to the other, wandering through the =20 lonely night until it finds a place to call home? right scott otherwise how do you know which to talk to? right Dino : If you use anycast, you can't pick which one to send to, so =20 they all have to contain the complete mapper another issue: the data plane of the default mapper needs to be well, =20= huge Dino : The ITR doesn't know what to do so it sends it to a default =20 mapper Dino : Packets go into the default mapper lixia: We let everybody inject their own piece into the system audio is back (thanks much!) lixia: Why not ? Halpern Joel Halpirin : You have said that you have to distribute the whole =20 table - do you have to do this or not ? lixia: This was another detail that I didn't want to discuss [laughter] that was Dave Oran Erik : I have a higher level question. The end result that the =20 mapping information for every end site would be in the RIB of every =20 router of every tier 1 ISP. 12:40 PM John : People may filter BGP - this is an unreliable way of =20 transmitting this information John : I would like to join the people who are encouraging you to =20 abandon this particular use of BGP Q : I think it will be much cleaner to define a new SAFI Q : At some point you stop advertising customer routers. What is the =20 trigger ? lixia: Did I say this was quick and dirty ? Dino : The path attributes are associated with a NLRI Dino : They will lixia: No Dino : If you don't change the NLRI then youwill have a name space =20 collision lixia: This is a detail that I don;'t remember now Dino : So, you will have to modify all BGP routers lixia: It doesn't use another top[ology Dino : Are these mappings advertised in line ? 12:35 PM Erik : Here, I think we need another mechanism Erik : Presume that secure BGP says, I am allowed to speak on behave =20 of this prefix Q=3DErik Can we secure these mappings Q : We are securing BGP at some point. a provider network floods thier customers mappings to other provider =20 networks by BGP Leslie: I'm getting 404 not found at UoO So ... this pushes "important" mappings to the mappers, mappers pull =20 "less important" mappings from somewhere, and ITRs pull from the =20 mappers. lixia: An edge network sends a singed mapping to al providers, =20 together with its key scott -- is the audio still out? lixia: the mapping entry is the edge prefix to GRA address mapping and if it does learn the mapping, then it works just like the case =20 where it's an ITR lixia: So we propose a new BGP transitive attribute lixia: Quick and dirty solution is to add to BGP since in situation 3, lots of sources could be sending to the =20 destination and have the same problem, so if he doesn't learn the =20 mapping, lots of traffic ends up going via the default mapper lixia: between ASes what does that mean? lixia: Distributed mappings My question was whether ETR2 (who can't send packets to destination =20 and has to forward to his default mapper) learns the new mapping (to =20 ETR1 in the example) or whether all traffic continues to go to =20 default mapper lixia: There is the possibility that if ETR 1 knows all of the =20 mapping information for its conencted to it can directly forward =20 packets to ETR 2 lixia: This is the question of the brains of the ITRs 12:30 PM I'm losing audio due to drilling in the wall beside me Dave Thaler : My question is whether the new ETR learns the new =20 destination or has to send packets to ETR 2 as if he was a mapper Audio seems to be gone. Please type a lot=20= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed [sorry - Jari and I both lost Internet connection for about 3 minutes] 2:15 PM lixia@jabber.postel.org has joined this chat. test :blinks we're back!!!! iljitsch@gmail.com has joined this chat. Jim Griffioen Separating Routing and Forwarding Postmodern Internet Jim : Tony asked me to come and talk about our NSF project This is a view of the future mjo@jabber.org.au has joined this chat. Jim : What are we trying to do here ? Jim : Now we are looking at much higher level issues Jim : with lots of stakeholders Jim : with lots of different requirements Jim : We are saying, what if we take a clean slate approach 2:20 PM Jim : we are not interested in backwards compatibility Jim : this is early in the process nm@jabber.org has joined this chat. Jim : with lots of open issues Jim : what we are doing Audio not working satoru.matsushima@jabber.jp has joined this chat. Jim : parts of what we are doing you have seen before Jim : what are the problems now Jim : the hourglass approach is the right way to do it Jim : but routing, forwarding and addressing are entangled Jim : trust issues were largely ignored in the early design Jim : we would like to separate policy from mechanism dmm613@gmail.com has joined this chat. Jim : the service is opaque satoru.matsushima@jabber.jp has left this chat. Jim : some of our work is motivatd by a paper by Dave Clark Jim : tussles between players should be played out on top of the mechanism this leads to kludges, which are now ossified kludges Jim : building blocks Jim : want to implement policy outside of mechanisms Jim : deep packet inspection should never be necessary on the forwarding path Jim : isolate forwarding from any endpoint addresses Jim : avoid hierarchical or topology based indentifiers Jim : we also want to separate customer and provider relatonships from topology 2:25 PM Jim : Assumptions Jim : network infrastructure is deployed to make money Elliot Lear : About allowing users greater control over the path taken by packets Eliot (spelled with one L) asked why, Jim responded saying applications trying to build overlays today to get greater contol Jim : Application developers are building overlay networks to not take the routing offered by the probividers leslie-ietf@ecotroph.net has joined this chat. Joel Halperin : What is a rough order of magnitude about header versus data bits Halpern Jim : Once you send the first packets through, you can often reduce the state in the remaining packets Jim : we are assuming that hardware speeds continue to increase, so we can do significant computing, including cryptographic computing, on a per packet basis Jim : 5 components in building blocks Jim : forwarding directive. Where is this packet heading, and a partial path to get there satoru.matsushima@jabber.jp has joined this chat. batfli@jabber.org has joined this chat. Jim : the idea is that the source has some control over where the packet is going 2:30 PM Jim : motivation directive Jim : why should this packet be forwarded jgs@jabber.org has joined this chat. Jim : we are sttill trying to figure this out Jim : also default motivations, say within a domain Jim : next is the accountability field Jim : we would like to put in an unforgeabile record of who handled the packet "within a domain" would be a scope, not a motivation Oh. Never mind. Jim : another BB is the knobs field - how this packet should be treated. Jim : in the opposite direction we have a dials field to pass information back Jim : I would like to talk here about our routing infrastructure to forward packets between realms Jim : our goal is not to provide an address space, just to do forwarding Jim : terms Jim : endpoint is a destination Jim : forwarding node is inside the network Jim : a realm is a coillection of nodes and channels Jim : a channel is a means of transporting packets Jim : and an end channel is the last hop Jim : every channel is named Jim : nodes are anonymous Jim : every channel has a unique channel ID based on a secret held by the two nodes at each end Jim : naming channels allow for abstracting 2:35 PM Jim : If you name nodes Jim : abstracting them requires heirarchical structure Jim : nodes and realms behave the same way Jim : what does forwarding do Jim : forwarding nodes look at forwarding directives Jim :upon a new packet Jim : verify it passed through channel Jim : if next link is directly attached Jim : send it Jim : if no next channel Jim : it is a path fault Jim : the fauliting node sends the packet to a predetermined Path Fault Handler Jim : the PFH carry out routing policy Jim : but may not route Jim : what about path selection ? does the PFH return a next_hop? Jim : PoMo separates path selection from topology discovery Jim : three components of path selection Jim : first - selected by the source Jim : assume it knows the internal topology of the realm it belongs to keiichi_shima@jabber.org has joined this chat. 2:40 PM second - the destination it also needs to knows the internal topology of the realm it belongs Jim : third are the providers Jim : it is the providers responsibility to get the packet across its realm Jim : let me explain locators Jim : the path into the destinations realm is the locator Jim : a locator defines ingress points and paths to a destination node (an EID). Jim : We don't define specifications, but they are mapped to a node Jim : the transit providers provide translations from partial paths to full paths Jim : how does the source discover topology ? Jim : within a realm it is simple - link state advertisements Jim : the realm only advertises egress links 2:45 PM Jim : we introduce a channel level at a node - there is one associated with the nodes at each end of a channel Jim : the channel level represents the maximum level of all realms containing Jim : the node Jim : whose boundary is crossed by the channel Jim : given channel levels a boarder node is able to generate an advertisements after it border learns the entire topology of the realm it must advertise Jim : topology servers broadcast within their realm - they have to know about all interior and border channels of every realm that contains it it floods its existence and topology Jim : there is a separate set of route servers, where the policy is located Jim : paths are useless unless there is a business relationship Jim : they distribute this information to the sender and all path fault handlers 2:50 PM Jim : in summary we wanted a thin forwarding mechanism Jim : forwarding nodes are dumb Jim : multiple level of abstraction Questions ? Peter Lothberg : So, when the forwarding element needs to learn something they ask the policy server, and they cache it. If I have a long lived flow and the policy changes, how do they learn about it Jim : We have relatively short timers... juampe.cerezo@gmail.com has joined this chat. Christian : Only the hosts have real knowledge of end to end reachability Jim : We wanted to allow the tussles between services and hosts to play out Jim : You could get that capability Christian : This would be an add on to get information to the hosts Jim : Currently the hosts query the route servers anyway, this could be added on. 2:55 PM Ilijitch ; Will all of this information, there is not much information in these packets Jim : We are not designing for today's equipment Ilijitch : Do you have a ballpark figure for the size of the headers Jim : Currently we are using CIDs of 160 bytes juampe.cerezo@gmail.com has left this chat. Ilijitch : You can make many packets large, but with VOIP the data are small and they need to get through Jim : Yes, but these are long lived flows Sue harris : You made some interesting points. Have you gone to see if the statistics you used were validated Jim : Which paper ? The one I posted had no studies on it This is research in early stages. We have not looked at all of those packet flows and how this plays out with them Jim : the question too is how do you write your applications in the future. You may have to rewrite a lot of them 3:00 PM Sue : You should look back on past research on flow lengths, at least how it seems to me, and you should look at past papers Jim : If you have specific papers you suggest please send it to me Kevin : I can order N^2 for a graph with N nodes. Why is it better to label channels than nodes roland.dobbins@gmail.com has joined this chat. Jim : As you add abstraction to the flat name space, you don't have to change the names of nodes Kevin : Have you quantified relatively stable ? Jim : No Christian : Can we re-use route information for multiple flows ? Jim : This is an area we are still working on Christian : Since this is cached on a per flow basis you are introducing a connection based approach Jim : We used a fixed lifetime on how long you store the flow] Nurd before LISP oak@jabber.uninett.no has joined this chat. Different Jim now Eliot "Jim" Lear? 3:05 PM sorry - Eliot Eliot : Draft-lear-lisp-nerd-01 Eliot : A not so novel mapping database Eliot : for use by lisp Eliot : all of these mapping databases do not transmit operational databases data so if a link goes down, you do not change the DB Eliot : principles and assumptions Eliot : relatively static provisiioning data Eliot : the rate is low Eliot : assume that in flight packet loss or delay is bad Eliot : the data does not change hop to hop jlc69john@jabber.org has left this chat. Eliot : scale to 10^7 to 10^8 mappings Eliot : Brian Carpenter's estimate for 2050 Eliot : BGP is not a good candidate, as it is a mechanism for transmitting data that changes hop by hop Eliot : A small number of database authorities Eliot : they sign the databases 3:10 PM Eliot : the way they get the mappings is not described in the draft Eliot : but I envision something like a DNS registrar Eliot : the data does not change often Eliot : how to verify the end user is out of scope Eliot : LISP entries look like mapping data Eliot : you collect them and then sign them Eliot : When an ITR comes up it requests an entire copy of the DB and then caches it Eliot : ITRs then request updates periodically Eliot : it may be possible to use a P2P network to send that Eliot : ITRs can retreive information from each other (other ITRs) remember the ancient days, there was something that would trickle out jpg files via multicast? it barely used any bandwidth Eliot : because the information is signed at the source it doesn't matter how you get them Eliot : there is overlap between LIST-CONS and NERD at the authority Eliot : this is based on IPv4 right now Eliot : 16 butes for the first RLOC sbrim@jabber.org has left this chat. 3:15 PM Eliot : 8 bytes for subsequent RLOCs for 10^7 EIDs in 2050 that is 400 MBytes of data (with 4 RLOCs each) sbrim@jabber.org has joined this chat. if you assume 720 Mbytes of data and a 0.1% change per day, that is [tiny] Eliot : This the best possible use of PKIs Eliot : operators should have a cow about it Eliot : Do we need a pull model ? No Eliot : How many sources are there many ? Eliot : NERD falls apart if there are too many sources Eliot : Who can be these sources ? Eliot : order the number of RIRs Eliot : can we mix and match with other things ? batfli@jabber.org has left this chat. Eliot : Yes. You could for example mix and match NERD and ListCons Dino : This is not that much data - it can be stored in non volitile memory Mark Handley : We have been using P2P to do something very similar dthaler@jabber.org has left this chat. 3:20 PM Mark : We think that there would be no problem with this data. Mark :The general idea of signing this is the right idea Eliot : I didn't use P2P here because I coulldn't describe it in a few sentances Q : I would like to get consensus that handling this is one database is the way to do this. Eliot : Before we dp that I would like to get more data and more analysis John Scudder : You said that this would not be updated frequently Eliot : The whole thing fails apart if this becomes an operational state database Eliot : You can update to the Nerd DB as often as you want, but they control how often updates are propagated down. They are control the signing Ilijitch : There are people who multihome. You need to know which of these connections are up Eliot : This is a general problem with LISP, and I will let Dino handle that. 3:25 PM Eliot : I have to go - thanks ! bensons@jabber.postel.org has joined this chat. jlc69john@jabber.org has joined this chat. Dino : I am going to give two presentations in 45 minutes bensons@jabber.postel.org has left this chat. Dino : First is LISP draft changes - 01 to 02 Dino : Most of the technical description will be in Dave's talk Dino : first LISP draft was in January 2007 Dino : LISP includes multiple variants Dino : back in January we didn't understand how the DB mapping would work Dino : we originally did IP in IP encapsulation Dino : We described TE ITRs Dino : and a data-triggered mapping mechanism Dino : We want to fix the routing table size problem, but this doesn't provide features to the end uses. What we really want to provide ingress TE to end users Dino : Dave Meyer is now co-author Dino : LISP is now AFI agnostic 3:30 PM Dino : IP4 and IPv6 - a single solution - IPv4 has a problem as well Dino : Security was mostly moved into the control section Dino : we added a multicast section Dino : We added UDP encapsulation Dino : people don't like tunneling - there are huge flows (as smaller flows are aggreged aggregated) Dino : We decided to hash on the inner header to produce a source port the LAG router can hash on Dino : this also made it possible to carry a NONCE for ETR anti-spoofer Dino : we are taking a very strong stance to NOT put locatior reachability into the database Dino : In LISP, the outer headers have locators the inner headers have EIDs Dino : check sums are turned off on the inner header- sorry Brian - because they are stupid Dino : we added a nonce Dino : IPv6 looks a lot like IPv4 3:35 PM Dino : NO locator reachability in the mapping services Dino : you cannot depend on ICMP unreachables yoshfuji@jabber.org has joined this chat. Dino : they are commonly turned off Dino : if they come to use, you use them, but don't depend on them' Dino : ITRs know when their partner ITRs go down Dino : green are EIDs and red are locators Dino : let's say that we have 4 locators Dino : 2 are high priority slide (12) Dino : as long as they are up, me the ETR are telling you the ITR to load split lionnaduo@jabber.cn has joined this chat. Dino : each ITR advertises implicitly which ones are up in a loc- reach-bits bitfield (one bit per locator) you can't get any faster than that 3:40 PM If one of the high priority locators goes down, all traffic is sent to the other if both high priority locators go down, then it is ok to use the lower priority ones Q : I thought that locators are routable. If they are, everyone knows their state Dino : Not all of the boxes run BGP Q : Why not Dino : We want to be flexible Jari : You can survive reachability problems if you are receiving ICMP Dino : You cannot know if they are being aggregating Jari : If packets are dropped on the floor in between you don't know it Dino : I am making the assumption that transit ISPs are transiting. That is a strong assumtion I am making Iljitsch : What if I am a multihomed customer ? Everyone who is multihomed has to run an ETR box ? Dino : If you deploy the ITRs at PE and not at the site. 3:45 PM Dino : if there are not running eBGP you would have to read another protocol Dino : if you deploy LISP you can remove BGP Dino : If you have one CE box going to two ISPs, deploy one. If you have two going to two, you need two Dino : Juniper and Cisco have conditional advertisements. If a link goes down they withdraw the advertisements Christian : Do these go to ? Dino : The ITR describes the reachability at the source site reachability-flag is an opportunity scheme, not that it will get all the ITRs status to all interested parties. e.g. site A talks to site B, B may learn the status of all A's ITRs. But site C will not know at time time C starts sending to A. Christrian : Where does the information come from ? Dino : from the internal routing protocol - there are many exisitng mechanisms. Mark Handley : I am confused. You are sending these bits from your ITR to someone's ETR for their ITR to use. Is there a synchronization problem Dino : Most people want to use both paths 3:50 PM Mark : Is the assumption is that the ETR and the ITR are the same box ? Dino : It works much better if they are Dino : Lisp 02 was sent out but didn't quite make the deadline Dino : fixed bugs in packet format Dino : LISP implementation report CISCO has an impklementation started at IETF Prague on DC-OS leslie-ietf@ecotroph.net has left this chat. Dino : hope we don't have to spin silicon Dino : supports both ITR and ETR Dino : support for multiple EID prefixes per site and static cache mappings Dino : supports priority and weight configuration Dino : put some forwarding options in Dino : you can forward if there is a cache miss - that means that it forwards it natively Dino : you may want to glean mapping in the ETR Dino : this may be useful for mobility 3:55 PM Dino : content providers have told me that they want it to work like ARP Dino : with the mapping provided in the first packet Dino : we support sending probes in a separate VRF to support LISP 1.5 Dino : LISP 1.0 will probablynever be deployed Dino : Started unit testing in May 2007 Dino : 02 draft unit testing started in June 2007 [shows unit test topology] In early July gave Titaniums to Dave Meyer and Vince Fuller 4:00 PM Dave's site is behind no firewall Dino : What did we learn Dino : using firewalls gives you another layer of addressing \Dino : firewalls mess around with UDP headers Dino : the ETR didn't care Dino : ITR should encap all packets s/should/should not/ Dino : don't encapsulate if there is no mapping (i.e., sent natively) Dino : packet through a LISP ETR is simpler than to a LISP ETR dmm613@gmail.com has left this chat. 4:05 PM Dino : future testing Dino : ipv6 and v4 concurrently Dino : mix pi and pa addressing Dino : testing with BGP Dino : Lisp 1.5 testing with BGP Dino : any interested implementors ? Dino : let us know Dino : interested in pilot testing Dino : at first on data plane Dino : no production at present Dino : questions ? Suram [?] from NIST : if you get a packet addressed to your EID ? Dino : If you can forward it natively you do 4:10 PM Christian : You need support on both sides if you want to get PI addresses out of the routing table Dino : I f a site is non LISP and it has PI it is injecting into the routing table. Christian :As of now you need an over net transisition. You could learn from anycast - it moves the mapping deeper into the core. this is how I interpret Christian's comment: a (non-LISP) PI site injects its prefix, some part of the net is LISPized, and other part is not. So the question is whether the LISPized part can have a smaller table. Christian : They could set up a business relationship to do this Dino : I am not sure if this would work operationally Christian : It is a transistion mechanism 4:15 PM Christian : There is a disincentive with being an early adopter, because other people who haven't deployed lisp can't reach you nm@jabber.org has left this chat. nm@jabber.org has joined this chat. nm@jabber.org has left this chat. Dino : What if Google deplyed LISP yoshfuji@jabber.org has left this chat. Brian Carpenter :You problem is a legacy site that knows nothing about anything. Your problem is to get that to an ITR - any ITR Brian : You have to figure out how incentivised the ISPs are to put out ITRs where customers can reach them Dino : Do you have a business case for this one candidate answer to whether EID can be PI or PA: one can avoid this confusing question by using different terminology: (1) we are talking about IP addresses; (2) the only question is whether an address is routable in a given scope. Dino : no sorry : Brian : No brian carpenter? [i have to take a bio break - Dave Meyer is next] yes Brian Carpenter Brian is wrong --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=smile.tiff Content-Disposition: inline; filename=smile.tiff TU0AKgAAA5KAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc FoJgb3VM8e68Hl8jj8XlcOpMvmb2n7p77YATuBRWBBBDEjLP1UCupMItVJiel/sX0qcyAx/qczfJ /sj2fj5/X5/GpPcqRhvYYD0n6VLzEMI4AFWgYJoGDRdjOABrn2V4YH+fxciA1ggqkX8OlOLgEvmL sRn+YEOxPEESvnESpF9FJdw6fxcQ2fZXQuXYzQmgYOoGEJwkGAB6H0WATH+fZaBQf5+lxJZ/F1JZ nkGCa6kLKp/l/JcsyWaBCSrKcqwzJZ+ltJZ9FnM5XyOcBAgAeqBhJH5wkVN58laBx/nuWAKSYXAK wwX1AH8YFBmHQB/0PANDUHQsMF7QB9z+f56lbPp8lXPJwENN6Bo+gQPF0OoAGyexWgAsBWgKsBYV WfpiVW+9YmbWJnVrWJl1iZFXVgf54lUAip1Uf57Nif5cjnUiBhAgYLkGKQAFgecGSQYFUHASNUHQ UNUH+Z9umnbpqXFcFUH8Z1UHGS9UG+R9UH0XtUHmVFUEDaBZIGDKBgcIIUgAOhzk6AB8H8YVzGbV Bs3cf5ljxVBrYWcJSWuUVUGqRdUGVUZ/m1bMMGZVB+l9VBzE3gYgBQAGHO+gYEoGFJDC2ABbzLbp pW6cVUHWXmLEhVBmkBn+gn+auFnWXVum9bpoVQfZZ1QQosgAXKBhcgYFLUjgPAoAAslCOAAGXLOl 26btunBnG0qkb9um1bt0KkXdUFAN4AGZrYAC42SBgQnyBgagYPg+CoAC8RgxgAXx5lwAB829bps7 Uw1umxbpl3kWvGkYMQAF/wYAc4gQQ32gaEoEASKIGolQIGHoihiABFEZHZgmOSgAHGeBbYH3WBmO SfcdmABgiMGAAEYgYfR+gYIdT06BgCgfUIRv9moGEyBh0gbxIEKKB+8gTKoEHaB5SgQL9I7vpegg IAAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAEQAEDAAMAAAABAAUAAAEGAAMA AAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAABAAABxwEXAAQAAAABAAADiQEa AAUAAAABAAAESAEbAAUAAAABAAAEUAEcAAMAAAABAAEAAAEoAAMAAAABAAIAAAFSAAMAAAABAAEA AAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed but he's an academic as of next month so he's allowed why is brian wrong? 4:20 PM Within a site, IP routing is going to continue to route subnets etc. which include the things we are calling EIDs. Currently called IP addresses. They are in fact locators. What the various map-and-wrap approaches are doing is reducing the scope within which they are routable So Lixia is exactly correct and if Brian says "no" to her, then he's wrong I thought you were referring to his comment at the mic. which made sense to me I don't have audio anymore and I'm not in the room so, the result is "google rules" --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0664; name=wink.tiff Content-Disposition: inline; filename=wink.tiff TU0AKgAAA6SAACBQOCQWDQICwMJQMNwMRQ6BhyFQMDQeLReMAABwMKkYSgA0I0tBhVMZGkBrvBcG d6PBbmZ6SYfNdGlkLqoix81QMLQMCRmgAYPg8AD1FlYIql5slCPd/u5gP9/vRnVJ8tirVip1V/u1 fv+loN7oykKqhgAfwMD0CBgOzjxRGIILx/tBDVJwKWpOJUVJx31/3+/YDBP++Xi9XW73G52e0wKf xgKIgkgBUv9fF6pNhIZvOv9s59taLSVLQ6bP5zPVJe5rKABVQMMQcCkKHmd3JQL05knGpM07VJnc F/s/iNDj8m6pkb3VMc1/8OpMvib2n7p77YATuBRWBBBDEjLP1UCupMItVJielxqYiv9mpIdP91LE lVJkel//l/qczAY/oyQAf5iv0Yb9GA9J+lS8xDCOABVoGCaBg0XYzgAa59leGB/n8XIgH+YY+hMf 5JCgDJ/lcNYQH+Romgwf5pki8x/mAIL+i6BL+i5HTMRuf5dxufxcRAfZXQ4XYzQwgYOoGEJwkGAB 6H0WESH2WgUH+fhbSyfxdS6Xssn+X8sn6XoTqlMi6kICbikHNsPTLLh/n0Wcsn0V8SHAQIAHqgYS SccJFT6fJWgcf57lgCh/n6XAKw6X1Hn8YFJGHR8Q0vS0O01SdJF7R590cf56lbRZ8lXQ5wENPqBo +gQPF0OoAGyexWgAsBWgKsBYV0fpiV0/dgGbYBnWJYBl2AZFe1+f54lUAip1yf57Nif5cjnWaBhA gYLkGKQAFgecIn+fZgVucBI1udBQ1u4t2mndpqXjd9bn8Z1bnGS9bm+R9bn0XtbnmVFbkDb5ZIGD KBgcIIUgAOhzk6AB8H8YV6mbW5s36f5ljxW5rY0cJSXOUVbmqRdbmVWR/m1dMOmZW5+l9W5zE3iQ gBQAGOu+gYEoGFJDC2ABbn6W12mldpxVudZeZKSFbmaQGn6if5q40dZdXab12mhW59lnW5CiyABc oGFyBgUtSOA8CgACyUI4AAZcx63dpu3acGkbyqRv3abV23uqRd1uUA3gAZm1gALjZIGBCfIGBqBg +D4KgALxGDGABfHmXAAHzdzTb0w12mxdpl4CWvOkYMQAF/yYAdWgQQ4UgaEoEASKIGolXoGHoihi ABFEZJRgmOSgAHGeGinx5OJGOSfj+EABgiMGAAEYgYfScgYIdx2yBgCgfboRx9uIGEyBh0gbxIEK KB/agTKoEHaB5wgQL9m7vw++gIAADgEAAAMAAAABABIAAAEBAAMAAAABABIAAAECAAMAAAAEAAAE UgEDAAMAAAABAAUAAAEGAAMAAAABAAIAAAERAAQAAAABAAAACAEVAAMAAAABAAQAAAEWAAQAAAAB AAABxwEXAAQAAAABAAADnAEaAAUAAAABAAAEWgEbAAUAAAABAAAEYgEcAAMAAAABAAEAAAEoAAMA AAABAAIAAAFSAAMAAAABAAEAAAAAAAAACAAIAAgACAAK/IAAACcQAAr8gAAAJxA= --Apple-Mail-7--1009703681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed All I saw was above: "brian: no" ah. that was two different conversations being interleaved Now I see brian's "no" was to dino's request for a business case (sorry for interuption.) imho the business case is that the Internet growth rate can be increased dramatically if we can deal with the "rate*state" routing info problem, and the bigger the Internet is the more money the big ISPs make. 4:25 PM Dave Meyer Lisp Cons Dave : Cast of thousands Problem statement Dave : just for context Dave : in IPv6 we can split locator and ID Dave : in v4 it is more complicated Dave : Noel calls it a jackup model Dave : you have to jack up the network layer to put more stuff in there 4:30 PM jo--netlab--tkk--fi@jabber.org has joined this chat. [interrupt] Dave : Sca;ability is a big issue Dave :this is a rate * state problem [really d state / dt] chvogt@jabber.org has joined this chat. Dave : State will be big, so rate must be small nm@jabber.org has joined this chat. Dave : Lisp cons is a hybrid Dave : push at the top Dave : mappings get pulled at the lowest level when needed Dave : is NOT a DHT Dave : we can get good EID-prefix aggregation if it is based on allocation not topology Dave : Map requests routed through the logical hierarchy Dave : Content Access Routers or CARs Dave : two types - Querying and replying Dave : the mappings live in the replying cars at the bottom of the hierarchy lionnaduo@jabber.cn has left this chat. Dave : there is no place where the entire database is assembled Dave : at the very bottom is ITRs and ETRs level 0 has qCARs and rCars Dave : above them are CDRs in meshes of meshes 4:35 PM Dave : ETRs tell CARs which aggregate and push them up to a level of CDRs Dave : if there is a map request, and it isn't cached, it goes up until it finds the map, which then is pushed down to the original qCAR and then to the ITR Dave : CDRs can have siblings, parents and children Dave : we have tried hybrid models Dave : I have tried to merge NERD and CONS to lower latency Um ... requests don't travel to ITRs. They travel to replying-CARs which then reply (via the tree) back to the querying-CAR which tells the ITR. Dave : in this case, there is no mesh, but you still pull and push to / from the top level 4:40 PM Dave : CARs are default mappers in this case Dave : Is LISP 1.5 suffiecient ? Dave : This is Vince's Idea CARs are default mappers for control only -- they don't forward packets [but they do forward mappings, don't they ?] Dave : Use BGP on an alternative name space Dave : You run normal BGP on PI space Dave : and BGP on EID prefixes swtich to Dino Dino : Host sends data packet Dino : it's sent on an alternate typology nm@jabber.org has left this chat. Dino : Moving it out of expensive memory for PI BGP to cheaper memory, and maybe even different devices 4:45 PM Dino : This eventually does to the destination ETR, which sends back the mapping Dino : And the next packet uses it hantula@jabber.org has joined this chat. Joel : This seems to imply (1.5) that those who allocate EIDs also pick up a packet forwarding responsibility Joel : We lose some flexibility Vince Fuller : Yes, and no. You use this overlay network to forward query. In that sense this separate typopology is just a way of implementing hte database if you use it for forwarding data then you are correct Dino : We have this trade off that people have told us, you cannot drop a single packet Dino : You can stretch is out, but not drop it. Others have said, you can drop, but we care about latency [Question about how this like DNS]Vince : People are absolutely Vince : People are absolutely terrified about overlaying anything on the DNS 4:50 PM lionnaduo@jabber.cn has joined this chat. Darryl Lewis : There is a difference. When a qCAR makes a recursive lookup, it follows the topology in both directions. There are some interesting security implemtnations about this Mark : It seems there are two route questions : Can the ITR hold the entire mapping database, and will they have to ? Mark : It seem that they will, and that pushes me towards NERD and a push model To Kevin's question: in CONS, all data flows along configured links to neighbors only, for security consideration. next is Luigi in DNS, any resolver can send to any server directly That's true theoretically, not necessarily in practice. (BCP is to ensure that isn't the case) right, it gets complicated Luigi : Thanks for remaining for the last presentation ! Luigi : IT networking lab in Belgium Luigi : starting to talk with Dino to impement LISp Luigi : We asked ourselves about the costs for making lookups and caches nm@jabber.org has joined this chat. Luigi : We started making traces using netflow on our border router, conectect to Belnet with a 1 Gbps link nm@jabber.org has left this chat. Luigi : ~ 10,000 users per day 4:55 PM Luigi : basic assumption is a /BGP granularity for the mapping assign one locator to each BGP prefix Luigi : How many prefixes per day ? sbrim@jabber.org has left this chat. 25,000 to 55,000 per day with a diurnal and a weekly cycle Luigi : outgoing and incoming flow numbers are roughly the same Luigi : per minute granulatiry is very spikey Luigi : 4000 in the night , 11,000 / minute during the day Luigi : the LISP cache overheard units are megabits / second Luigi : cache with 3 RLOCs and 3 minute timeout is 227 KB (night) and 545 KB (day) Luigi : Cache size is 10,000 to 18,000 Luigi : number of cache misses is ~ 1000/ minute 5:00 PM mjo@jabber.org.au has left this chat. Luigi : with 13 minute timeouts Luigi : the cache size doubles Luigi : can reach 1 MB during the day Luigi : with 300 minutes time out 30 min ? 13 -> 30 ? [I believe it was 3, 30 and 300[ [this now is 300 ] [the first was for sure 3 minutes] [yes, 3, 30 and 300 - sorry for typos] Luigi : cumulative distribution function - large majority of the entries last until the time out Luigi : a large number of prefixes are used for short duration flows Luigi : however, a few flows last for up to 24 hours, which is the time interval we used to plot these graphs Mark : Are these short lived flows a natural property of flow, or some sort of scanning Luigi : I don't know. We have a lot of incoming flows that are just a couple of packets Luigi : each entry of a cache is used to handle traffic Luigi : what you see is the CDF of the traffic per entry 5:05 PM Luigi : for 3 minute cache, 99% are used for < 1 MB of traffic Luigi : there are a few that are used for GB of traffic - mostly physicists pulling things from CERN Luigi : the lookups in a pull model Luigi : 500 per minute to 3000 per minute Luigi : when we receive an encapsulated packet we can glean the mapping from the inner and outer addresses one question about the cache size is: instead of constant timeout value, what about some simple adaptation scheme based on usage? Luigi : when we send a flow or receive a flow and don't have a mapping, and then perform a lookup - a full PULL model Luigi : 1500 lookups at night to 4000 in the day, and up toi 48.74 Kbps lookup flow for the 3 minute cache 5:10 PM Luigi : the longer the time out the more likely a flow can find a mapping in the cache Luigi : how does this compare to DNS traffic ? Luigi : dns lookups outbound Luigi : 2000 per minute during the night, up to 15,000 per minute (also during the night) Luigi : although the average is greater during the day Luigi : so, this is more than LISP, and we could use the DNS as a mapping system Luigi : questions ? Luigi : if you want to run my scripts Luigi : you can Dino : CONS is per site queries while DNS is per host queries DIno : I think that the DNS tree is very wide and flat Tony : I wanted to high lite a few things Tony : in doing an ID locator split we are making some trade offs lionnaduo@jabber.cn has left this chat. Tony : in today's PI world we depend on the routing plane for reachability 5:15 PM Tony : we are trying to compensate for this in moving to a split Tony : we need to be clear with people and make sure that they know that this will not be like PI space today Tony : a lot of the table growth is due to self-deaggregation, and we need to understand better why people do that Tony : we very much want to be doing analysis on proposals that we do have in havd hand Tony : I would very much like folks to continue to focus on the conceptual level Tony : this is the IRTF satoru.matsushima@jabber.jp has left this chat. Tony : if you are talking about packet formats, you are probably not doing research Dave Meyer : It seems worthwhile to get experience Tony : I wasn't disputing experience Dino : Unless you get into the details people misunderstand your proposals Tony : I encourage you to try and keep them at a conceptual level too Tony : I wanted to talk about meeting next time. We could change from the Friday of IETF week [general silence] Tony : Papers, please Tony : green sheets, please Tony : Thanks ! keiichi_shima@jabber.org has left this chat. hantula@jabber.org has left this chat. 5:20 PM lixia@jabber.postel.org has left this chat. todesgeliebter@gmail.com has left this chat. todesgeliebter@gmail.com has joined this chat. roland.dobbins@gmail.com has left this chat. todesgeliebter@gmail.com has left this chat. satoru.matsushima@jabber.jp has joined this chat. arifumi@12jabber.net has left this chat. satoru.matsushima@jabber.jp has left this chat. jo--netlab--tkk--fi@jabber.org has left this chat. oak@jabber.uninett.no has left this chat. 5:25 PM You left the chat by logging out or being disconnected. --Apple-Mail-7--1009703681 Content-Transfer-Encoding: base64 Content-Type: application/pdf; x-unix-mode=0644; name=RAM-IETF69.pdf Content-Disposition: inline; filename=RAM-IETF69.pdf JVBERi0xLjMKJcTl8uXrp/Og0MTGCjIgMCBvYmoKPDwgL0xlbmd0aCA0IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeNq9Wl1v4zYWfdevIPLSKRBrRFKkqDxsp53uFlOgwLYNsC8D LGiJtphIokekkvH8+r2UHduS3ESJtUUG8UiyRJ77ce65V/mCfkdfUEJQwkOME44ZirlAPKahEISm qFHoP6hG73+xGK0tev8RPjOLMLJZdxtOwzRNMQv8bYvefavnno0ZPTx7/8woZP6piyiMIsYiJigR wW0Gz4jChMdJxFIUwc/ieHi6A5RV6KdbhPHuS/BJEngijtBthd7/C4dRgNHtCr37VS6XqkEfC+nQ o3YFKvVXLT/cdafDjbFOlaFp1tforsx4emeK+ulidzY3j9Y1Srlzt1SlLUyjejd8H9zeoX/egjl2 2EiCI0JhM6/HFjxhg3OEHpChHbK8zbWV97q3+t3a9o6rO3NyHMr2Gt3Lb+1W9r71KG0h894pXd5p Z7Piw7qSugwzU42gxTxNeSzERdA4RpQPodlCbQ72tuvd6rLRq7bSHzDZX6mVu0Z11dt2Zje9462x xaq908+5iEY8ZjFHb4q+YAeDChSnQxhrXaRRNAKSu0KWqhnss+6HUSaXZrFw3/RiAce9S3bZ6OrZ mIuxEGlyWcxRijgZInKm3mLpClP1d3vXymqjwkw16ps5DZl7pXVW6P/aQlf9mLPSmaYNK+ls27t6 txkB4oQIyiN6aRIlbAho+WHZtJlakChKwm+qKWWzlvvsXqq6PmTPVxvLsgzr8ho5kyu7VqVWSwdu PEGbVxXH9PTMg1w956mEpxQn8WXAIHR9EvaBlcrCBhdaudUHlRnXmE2xyxjYuHFhqWRv6ytIr1pm mT49WcjatWXfb0vpPlOaDIAIHAsmUnIREBbhM0gGuYv6HJRGjKZ8mLzBq0oHFlA48Cg0VG1Nbc/x PliwrmXeHqIjq69RY0pZ52FulksNt52Y0cj7py+2tQYnuLA2kDSQ4HBQyiUk+v39YnG0KUADSvI/ yUW0RAiBw3gIDRzIB4YkgqWMxGdWC6aXYCLOrdbnteLBrN1pTepHEjiCphG+jI0JMBem0XAjyXuS vI+Sa/D2DU7Qj78NbYBjKujOBsFbZQgkM45PbRD4pW8LBbyx0RnklAVmUTWyysGpm0FET8MfvLAJ j59Pwx90Sx9kmRdl0RuMT/fGpwhUWJLslibHJN7LiSFcoHaaMEbjNyQw2eMliIH2EzQV8XFpelj6 S6usg4S1SNfA1027ccg0CPSgA6eoOv/hJO/ehhwdkKc8mIgcxwzK2ktFOpgMPOVD4J3SvUFrY3K0 MQB+PpwEeoAJOCeuEDyDC1Ya4irkg6q/cwjkb9Zaq3LkGpkrs1rZI8JLwPlorIJTcJ3kOkXW6UaS UhZ52feCLYPnPIhDAlyf7lftqy1oWr6z6GfAi35TW9XM6EBGg8kpyinjOJkpUGHloUM/v8s9xMpD /OHz9zOiBNtPTceIcf5inzYdZUKGKCt9r26gDS71GtgIgb5vHehjtdH1GsRD6/ynk8tSIVuB1gSp 1XqO0haBilDWM5aE/9o58zjF0w1EUojT2cIgxUMDWVO2HVGHYXisTJdCpN1MIJgEETPMUyJmgkif phFHiJvGgH+BSZwxqJL1FuqPa7TytQn98seP18cL7SaXTtn5fA10NfT1WVqLwc+EMHaZFZ5oDVYd 0lrhm3mPFkFo37XWoat1aZYQ8tsuD7oUkHneKGuvQvQJJFPu+b42TmfA9ld2IzN1hSCJPEMiaHRy Fc5oqFhM5saUMRxzHs8VMrEYk6PNGr0E6gD83mp/zkqRlCeTwYo0FZTwubDykVQDeVbp2pRmvb3x UEG8/FVgoC4IZrSD4NPtwAVLCJnLDmKk3PQKbU0LHQLArbdQAnxl2ImBSlvrD0HBas8amWkalUFb X0I70Vp0X5vH+awSR2yyVTDGlJO5MgFWHlpl1chKPZrmHj3qsoQmypdF+HAQNsg8wC+nqxlDIibx KzSSIIwndC70JD5TOjIf954FVrrWtgAq3PqBzqMnwU/Iyq0PCX8dDLOBeDixxZmxOyY04mn0mgFD MO40BUVxPOo0fYMZ9RrsUYMZXOIZdtpgBs97Jo0TAk96A8yznmEj1iqNuQdf+Er0pGAOewguDsKE H6AGLxUjQoFUuZgLasL/OgVz3dXkFZAz8kLWrLp2elm2IF/vt/NlIYuiabKF0Qjzl7qxqbIFVh3G tOxEWrc2Ohmc/Fs1mdq4Vpao0bAyjkMGCmr/UEx3K3OEmQhj7OcTlMJXREITv/77TxUOfjb+SX+o Ujr9oD5CAYRFFAjDzD8zeoM/exYkEZpiwSSiKRWCXDaKOViQjCz4Eyw6Y2DQdDI9JwSnYPKZ2BlW HrOz2sgGWKB7x/hnZpxDHu7nd9Wsco0xMSkbElCSIrm0Wzv4ko2n8l6M+NESaHmLSgOSBD6BAkCq qY3yvWqba1VnCvUGcKajCd8Lz2iUZLKGxRR6PGhx5oqE8bixm7rtu3snv5raVHOy4fQBYxcDvOu/ 5sE6njBCdOvMv1kytUIOJDoI9DmjnZNp3E8IpyJO43minY+Z6xPKZI0KJZu3Ub8nfAGajsQkFLBb /jdRP4+jqZN4THDE9xT5upcf54LlsDA9ypZdUwOGBN3QmbJS16jjkdogXW1M42TtTjw7Ah+8LnpY +gz43lsnEvGYxm962Ub2Lz566Fl6fhj/HLiXY7UHLhHT37H4f1TQ4E3oxr5N9jXoiI6GoPiP8hdK wJdW+3IIfL9UKFeb0my79n3VmApJ5FRW1DqDzNmoxm6gg4Xov+6aF2farOt4DVSKBvVeikYpVDWe MnqZoxBPR0Pok33Y+dyUYDLZTUnsZ6xe1cziJlh67Kb0BmWl/0sasL131W6qlLVNo2qHSvWgSi/l rYJT2m19TYfDDRD7/obdVHr3xafbHgv/OnPvfN+DDv44IGWc4CR+yx8KkeAADK6Piu0usFQ+o8Ni PsVh3RiIMFCVZDZ/xXzorwZYspH1GhKpUSvVeDk1I1TOJsdmyiMigCPnwsrZODYFBKN6RBkEnmp0 C1XeOrnUJcTh86CDVxSFRMRTi0KEBaYcc3xZ3B5Bi9FQh4YcErLYufiqVipX+ZUnzasnBr36e2Y4 Ijo3w4nY/2+GI/D0GU4KQJl4aco+ebBxWProCFla40fLKvdR10A7U26hbNldEfMDtszUcB7qVSlB 7FooXQr6GSAgBb9qB1/3pc2/uppN/go6XeynCSX+DzJnEvuC8nGsYnQyoN+H7c3h1eXOMIt/9C11 tMbv/wPlTrY2CmVuZHN0cmVhbQplbmRvYmoKNCAwIG9iagoyNDM5CmVuZG9iagoxIDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTEgMCBSIC9SZXNvdXJjZXMgMyAwIFIgL0NvbnRlbnRzIDIg MCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagozIDAgb2JqCjw8IC9Qcm9jU2V0 IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9D czEKNSAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjMuMCA4 IDAgUiAvRjEuMCA2IDAgUgovRjIuMCA3IDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xIDkgMCBSID4+ ID4+CmVuZG9iago5IDAgb2JqCjw8IC9MZW5ndGggMTAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMTggL0hlaWdodAoxOCAvQ29sb3JTcGFjZSAxMyAwIFIgL1NNYXNr IDE0IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVh bQp42q2ST0iTcRjHv4d2EMTLfAmvEfKCF08NIcodgw5RVvRWnqKD/YEOrn/ESt1mLZieypNY6Uxb DgzbnPuDGqzNzZfpYpvlll6yoRCzyfbyvk+/d71iDbz543N4vs/v+Rx+/B7gAM67y1i2Hc07T0uh G1KwI+88tWw5MnJp3/muE0h0NUhiL22FaDtOpZQKKzaDkmhLPGl4dLxa6TmJrxaORCvlhmltlNb/ gUXWFK1soEqM3QYF2inVp5Luo8wu6Qp/+/72hVt7yus2FAcO0+c7FDNR3CS+NIgDBhJNDFawyJoU NbEBNjZ4VrMiNyGPNtGsQPMCfRKc12qd12spLDBYwSJr0pxAIUF+2xTu0KzVB5AmmhVvK/mNFDQ6 r9Q4r9ZQyMhgBYsUMJLPqHhapffNq/c1K/8UZXej9IGXPbwyzS9260WLnoI8Q+zRs6h4eXmKL0/y 5YnGDatm/XSg5KrbcdfLHk4JcEqIU+Y4qsAKNfo5ycP9dtWXxus27Jq18gxFFwouXcGtk+d1FNZR TEfxClE1suavsUPbLl1xDBmbZgXuojAOKYRcP34MgRZBS6DlCktQ4lh/gawDZT8Ko/B2apZDwNYQ lFkoMaQdiN7DFwe+v0HuFZJ2RDqR6YeyADmAzUH0nt/7Mp8Z8hQoAVpDfgbJPsQeqyQdyE+DVkEi pEl8fPjfblxoQeQ5KKje0jdQTtVVsqAMKA7yIWzHOUP1Kra1YMaCkr/yrvSulQJFUfLC140zx/bd fLMArw3ZEez4VLLDajRfxIGcP6OUgX0KZW5kc3RyZWFtCmVuZG9iagoxMCAwIG9iago1OTEKZW5k b2JqCjE0IDAgb2JqCjw8IC9MZW5ndGggMTUgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMTggL0hlaWdodAoxOCAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQml0c1Bl ckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42mNgAAJWIWklJRkh NgYoYBbNWHX9y5frq7LEWMACbLYrv/8Hg++r7NlBKmz2/IeDPfZAVSIr/yOBVRIMrOnfkUW+Z7EJ oCj5/3+1sNR1VJHrsopfUEW+qih+RRNRlbuJKnJTQXwDqsgmSb6SH8gCPyoEODW3I4vs1ONiF408 jRA4EyPBwcIrH7fvJ4T/c3+SIh8rExu/nG3Xwcc/fjw+2GOnKMDGxMjEyiuuZuURGOhprSHOBxQA AJ871LQKZW5kc3RyZWFtCmVuZG9iagoxNSAwIG9iagoxODkKZW5kb2JqCjEyIDAgb2JqCjw8IC9U eXBlIC9FeHRHU3RhdGUgL0FBUEw6QUEgZmFsc2UgPj4KZW5kb2JqCjE2IDAgb2JqCjw8IC9MZW5n dGggMTcgMCBSIC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp42n2ST0gUURzHv7MlQqwFZSZS8E62B1cG7WAdjN31b8q2rGumCLLOvtkdnZ2d 3sxuJR5CiC5B1jG6WNFJOoYHDx0CDxGCYl0i6CgZBIKXkO03M7vuiNqDN+8zv/+/33tAXShtmnqA AXnDFsn+KLs7PsHqN1CHBgRBK61YZiSRGHaZbHFk7X2F5Jyb4eP1/10NghICElWAxqzH1xye9njA 4fu2aRNPOqzk0hlik7hNpJIx4lfEZ7M+nvZxhlsK8TLxTcUUFCeQIh4oKVkn5g6xbGQ0g+SXibsy lpInJt/AU2cWXpn2ENB9BTj1uSabsIDld8Cl1pos1AxcHANWOmuy3aQ7H6lp3VI7O1yRFIwCdT/K 5d1WoP4FsP+8XP77ulzef0M5vgMfdaUoSpUZSdIXwOvDXY393OBCU5hzXwlRUDWd+0Z6vNrr14tH 9SWrdBJ7M3FXF7BE9zB2Bhh6DLz8CVx9D1z4ACQagNR1BB6hum3+wM0TK5gPhZbN2axDljtY2Dk6 WYReCGexQt4s2lywQUNpb2NpXWeuqcUEt7go8Uw78nqx2u852kFujI7QSfMKqNzqrbA0k0n30N2g nXgjw3t6nXdBvKhqfYPOhdD+pIq+UY+l85o9mPI40G3o8eEKwyjEb3sxsWPa0WQ1vlUa6a3KZ9K3 EnS2kPzGbGHIsWki39BcLjXmsZSay8XiFV7FOHRwaDDoa4AhiX5EEYYJgQJU0mhkoZGUuzaC2MLs sZY6Ej5mpN8mn23X5x6K5O143UE0joW2gwhM/ib/lrfkJfmt/GuxpRiqaRbElKasP/tDcZ3M1bgV baUmL75CeSOk1ZElaf6gJ8tXqa861VhsqUVycvAn8T1fl9yXKYxpN9Ksm6nk6iz6RnzZTpoe2a7N rzbXcm2dXpncDK7NH5pV4UhX/KCrw/81O78//wfNsAFoCmVuZHN0cmVhbQplbmRvYmoKMTcgMCBv YmoKNzA2CmVuZG9iagoxMyAwIG9iagpbIC9JQ0NCYXNlZCAxNiAwIFIgXQplbmRvYmoKMTggMCBv YmoKPDwgL0xlbmd0aCAxOSAwIFIgL04gMSAvQWx0ZXJuYXRlIC9EZXZpY2VHcmF5IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42pVTTWsTURS9M1bchCqipXT1lkWSMH4srLuYpGnSEmOa ohFBx5mXZJr58s0kmtBVN25EuxIXbgR/QJcuunBR6EZRKNVf4KJ+gCh0KZ6ZicnYKuqF996Z+869 99z7GKKxddV1TZkRWbYvCtVM/Wr9GjvyhmQapwTBVM1zM5XKQoBtx+Z0wPbekhSc26kgF/2fHda5 p+F8geXc8V2fSFKAT7Rr1SxwDnhcc0XgrwHP6Z5mAT8hOnR8EBvYyQK3uTA0VhBqj1WE0zDMuNa/ 3f+TBbOJ0LfLYc/SxEutI7qDa0l6ReTzu37wkXXcnjCaLZ+dnpk5z1LsjKKcZRlMiLOsY7kdnwtW tLV0kqmmyUKqxwT3uOhyPU2W2fnZ21GsBLeXFnFOE8kfuJcfYMnV1dw88Dn4J3SeywNfgH+zYcwW gdNYmw0xu4TzFPzM8Iu1yC9v2GZ5IfLLJdspXwJOgvPY9S9WgfEO8n2vu5gf5Pm6rJYqOCfAKbWd +YAzCY7fb9WuAB+D/2a/lS1Hfuk71ckkTgbZ2G1iNEcqCbKwq5QiF9ihBu4N8AwqhCwOr0EetcEv AL8PsRpmGkWYVInhgLmL2N0w9jZ1wI2ikalMq0llXfmkPFPeKZ+VHeUp0Me1qc606z56sCpuGNrr h1+QL6g8yhepYANVUWYNFf+k0sedvU9jBsukJrzWcA7eIEKFSg9RHXCDjKl4Rw17bWrI6xELFPJ7 5b1YdT7UOap9K8zfDrV1Q4aHPRPTEL1D1N0ybkdqwd5a2ZiMV90Ze359O7G1sm82ejjdbNhPH8yD M4q/jTOs18Ryhmz+24lq8fq/5MHf+gOfsfBRCmVuZHN0cmVhbQplbmRvYmoKMTkgMCBvYmoKNjMx CmVuZG9iago1IDAgb2JqClsgL0lDQ0Jhc2VkIDE4IDAgUiBdCmVuZG9iagoyMSAwIG9iago8PCAv TGVuZ3RoIDIzIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNq9Wllv20gSfuev KMxLMoBC9U22gN3MTjab8UOwm8TAvgQYtKS21DHJVnjY8fz6raask7Ktg1k/2JZEdd1ffVXkd/gE 3yFhkJI4ITLF/4RKQXEdMy0oh9LCf6GA4YeKwqyC4Tv8O6mAQjUJX0sYiQkhKonC197sfO9m52wl ldo6mwu1PvvxTBLO/A54sRKoi44IvvVm/TKcRLnicZpyvD6H36/xNbQX4V8JqZRwncPwXywmqOD1 Dbx22TdXV5P5CH6Nrr/B+2tU6U3QWCZapyxVcL0jEo4QyZZ6UQYyiWXKdSo2ovla9MTnuS3qCgpf gxlXvhzbKTzYGqaNhdrDnZmY2vlioxk5Q5sdByQietoBsOOAhAtKpEyeFxkddAAccEAi9h1wb4o6 2DnzUM9L38zwj4XJ3BQzW/VotOZHGy0Yp0lC+7JZ847NFubmzoKBaWlu6v6s1Jh2R1qJ59BEsb6s RMn7Vta+eIDMjWBqKzcrMMIm6zGimtOjI8qZUnhmb8bix/t13CYsmMnELmo77dFMSY4OKQZUpFT0 ZaUk+1aamS2mBhalX/jKZCO4cWWFUOUKPwh1W4DNMufrAUwxvweQNW7mevSF0vu+qMaly7cdEcKd Mp7SlMjLHEFjRgR+C6Uu/UDXUq8gt6YYgGmmzgfZUT/2pSlKil60T/KEEs3TF8VFR9nXSt2xr8oc Fi2YeiM4IjEWUKIVXn0fmjGDd1/aw0isefsj4Mu7Y82PUB+tWw1SFlSItcB/IQdKWcwRg+nWuxl8 aVnC0aGkVMRSMJHsHM0IjwUV6tmjX+ITjOhYcK3pztE84Rt3ro6OwtGtq1resuMqJDHLBssoYYm6 KJSPjjwYynldL0bD4R0G1GdmHDe+tDNfxHbaDO1doB5DZ+ub9pfSaZzzZlOwO5zrrOyONtlN0Vo4 ujtJTYTer+BjuN4hKNuIXmFZtMKysanmrphtFdjJZkY7RYzhVHA0v2IYfkV4b3auZG/sLDwGb47h zpBYjktrbqsBsk2YeH/rsMjHTR2gG1n2vcsyGAda0l4Wyr/yuYWFd0WPJIViqh4H41pShHLWD4wH sfvFUWPXvq02GNemnhKMJPQszr+RGmFYH3mf6KRBh3CmeChLL6MnAqUcklnBNzMe2xKzoHQY3Rtf wsKUNfiblmpPzUOfsU07DPSjzRxW2nZ0T2gSu0YqGVPFCU5kQdJ+OP9wA/gy8XUNb2DuF5jJmNDo gHtkJTHA1ascXAHX//i4MfgSWymh++36qUJnVKSCJ7InavYoepebzbeqJ7owjJSRNYZFz5SoUlom OCGfkDbRMyW6FruJqUFgMjhIYLY++AYJdt1gVB9CIEP2lt7nbw80rFiGltXWM5NcJYk+Q0X6qCKF sAOg+Pm+dnqEIz3mEzzZMaOLwiD5ViuJngoDS1KO3Ib2FYWV1O3KerpBRidblbD9BhlmRWrqObab 7SXMkuzioalm5+FxtDQOCUCccMm3pW+s++D9FHJfFkgE4jg+EM02naIz0wkOpVNEaZessRF5IZ1O RY8dxzMin3f8FtlHbpJQLTTXFzXCteOjjfSNvde2qnfI18H65URpkpyRddsO56gVo/sKUDKircd/ EuVlPH2KC/42y43L4onPO6yQcZ4qhPjoIs/zJCaKad1qEe11i+UIj4yw8lkT9ovV6GgKfESiyQ7T /2jKah768ftmHEjX0uhoVeZUYj0ozi9JNuThJE5xchBbGtBnTO4R09oR7ohAR7sLG6FQAL0M2rbi nKgOK6Aj8AX2y6YK6+SFz/zMTdoOamYzHAVNbcYZttjptLRVBdXCTCz8DfImqx2iAlYnvPn78uUC r9tbkGuCSnGaXrYgxxe6y2eWGuGE8vX1hy/vB4BzWq6Q4Lkfw38X9uuvu6gR7aIGtg3OE6XOSSga rWCD4gSKSdVJpS3U/G3JrmNfzmBukGzjsIQ5Vs+Rd07mpo5/FrRwps6AFpVQprjoDVpQi31oMWyE zfTOwi92OrO/wKK0N+4HxtE37dAxy/zYZMjcmoD9UD1Utc1h/AB1UxRhVpi9wOcO9oNT+Rz2Ay7Y gX6AFPTpDnwpr0Zw2ufVLwcN6xo5h7psPNyO2UqJTczCBhdp9hQyVy1wRMxuqxYx3l9/Hl5df4ba lggFATweBnAFUzctXvW5EuBJGh3VMDa8UAslwn7ggOjohExedwxUYT8b7KzFxGVetglryz6N1smJ RlPCuaaqP5t1B9qw/H6q0YKq6HTYSnVCpezc2ojOhS1BO3uyr68rX5YPmN0muzcPFeTuBzQLcHUJ Q7B1ud1xLmZIgssTGRIRAuNFEnEuRYr2gr9WYWsQsv7mBv5oKmxwMILf7X0YvxGzb0yGaDB1k7mv Xe76vDNLhRRnZARXGEpFaG8ZIcV+RsyCN0YwPugFH7wwCNul5fLUFGD42x4ZpUj4GYySJVQwnvbF KNdKbFpF5n44M2qfV0AFkBPWdtAukUMH4WFp3HIfTBPbZ5JodmqDEIEmUML7Akuh2eF6GbWbqfaO flhJmbHLXP0QHmoomhy5YXizsPW9L28Hrd/CG4EbVc8SHSIlQfHsIqJDdTiRStJpbt8aky9sPMHk /ctvMur/S2Il6wyK7YJri1V3Vo6MKckZO2O3th1WdETarlKXKkQ7a4lgd1icIxDCxNR25kv3VyCr dbhXFEoe03z5CMdqHzm2toCqGeeurtF1ARNiuG6hITfh4721ltYENZXiokoNHhSdpUbuUaibWrOk 3C0+DVp2d29f4Udzv1jagkbcWzSwAFuFMdBVc0S33BZVmI6xD3q87H6OeLe+7s5kDToE8/l+z6BU CMk4ZRcbJDttaeKL8FgFatSiLY6uaMVqnF+CD+o39chJH6OCqIAfVq4dbRd4qZnMcQJBCzE4cY+4 JLsPUz2HS8upn3CdHhxgzsIl2X2o6hGjAyyFqJV20pSVu7Nh6l8swm/Wpw+6z1a95ANCE43oJrqN KjqpijdO0PwpcL5qq/Z2me+PzTpUJVZJj05QlJ3sBEmS0LCTvpygug9hPWZCZbH6TWtzmMcnLvAY G+4ILvp9uJCq7mNZLzVqqRLOD+/+zioIxTuQ+Anz4J9+06cDlP0wgb3A2z6Nl4fvbD/dzhiTWl34 fOVWM1Nd8DSbny3EHv7HlgFTm7CJcSg7PDATnsldHkv5UrYCxnnM8ZPwJFrM0MFJEjQYXuU0Qo/i SZ9tZmoEl3c+wzaZ46TkJuHM9sYUTbHTXfRwC2P6Gev+7Gxqoh0KpUXS3mc552ZNtKJQQXT3rtGt ddgZ3Z9hL2lOWAN++h9JkZo2CmVuZHN0cmVhbQplbmRvYmoKMjMgMCBvYmoKMjQ4MQplbmRvYmoK MjAgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMSAwIFIgL1Jlc291cmNlcyAyMiAwIFIg L0NvbnRlbnRzIDIxIDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMjIgMCBv YmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0Nv bG9yU3BhY2UgPDwgL0NzMgoxMyAwIFIgL0NzMSA1IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczEg MTIgMCBSID4+IC9Gb250IDw8IC9GMy4wIDggMCBSCi9GNC4wIDI0IDAgUiAvRjEuMCA2IDAgUiAv RjIuMCA3IDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xIDkgMCBSID4+ID4+CmVuZG9iagoyNiAwIG9i ago8PCAvTGVuZ3RoIDI4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNq9Wl2P 27YSffevmPuUFtgoJEWJ1L6kbW7Su0ADJM0CwUWTB9ri2spKoiNKcba/vkPK9vpLycrLFEhsr62P 4eHMmTMz+gxv4TMIBpJGXJBEUuCphDSWUcIyzqDR8B5qePa7pTC38OwFvs8sULAzd5qgWZRlWRpP 3GlP9867+ea1SbK99vqaxF3zM5BIpO7wbELwq6fbP92VGCFxREWKx1fw2zXQGPxB+J4ATTMK1xU8 e8UighZe38BPr1VjF6os4WU3VfWtvYSfJ9ef4OU12kYiQqhgjMUshuu9W8MDbs2ATNytGVpBIhkn Gd8xgW5N+F2bmxu4hNdv/ngHlfmiLZiuBXMD7cJYDXkxWxStqQptd2w7w6A9LAQlk+9jAbtYEC5i LrlMj+49eQgYcAQG2jAExhWslAVlb3UON6YBBZ+7YnYL+quqlqW+wAPm6osGU+N/PMOjpaE1S/ex uoOFVnlIuFh2CJedNkX1yyc1neomMs38EC6WcEZTlpy49WQEWoiNzCT3JhyidQW5qZ+0MNctLAoL S1PUbchVcznWSWhKUsrR8set+t5HuBzykWu/4be6tlDUfvsbDJyinoO9s62uoCrmixamGhZmhUd6 mJoi3zjLUs1u3Te6VG3xxV3rIPgFk4TGIntU8DsYU3a4hjvTXUBtWqj1TFurmqK827PEGZhri8vB r0wdclMlHbOpT33oM0aSk9t6bujLIx786wpU5TGxHTL/aqFaRAFfKq1q+/EegW0+iBKXEZyBlMUk zYgYgc1kbR5dm0eByRgNy8ShYZRcYhT/+voek72MhDz6uA2RlG/T0uRh3MIlQxh58u31Th7MLVsT 7lddqTuMnGIN/27AING0aj5HZl4V7cKRrZ436MQXyNdglktMWrlzYfxhx4Of2IPoSpI4i8VJphgV XZIdMQRygDMInj+H37rei570S1ipO1jpJ+hfzt1z49gC16jKBvPFXQTPAwaa5GJ0oKVZkgrBRag4 k3ztzvHWhrL4WqhLeIVZ1ZpK40vZuQ3qAarUculAWeC7Y1YfhBqmpsl14wlWNyExStPRGGUJSYTI kmAYpekARk55GFx+g75dFreI1aKo0gvnMRt8itoWufYYoVoLmXylTMZDEydSsDiYQkMbBqCJUZC5 4Ea/CbjmjPDDNc+LRUbIhguXdh7NTHXIh0mK5macHtx/8jAu2axbsIhxKrwZh5Tybmba9hKzkkbu KPpYsaXbeseKfaL6w0HjfuysC6EPP3VN+fzDzyHxYfFon0CGz2Lcz1A+kblq6KRP9MIMEwdGB6qY yjQ65No5G7t2GiexFCdlwVli1BWup5f+lsL/UGTmBlDZeaG5IdKiRhapQou4LKVj6xGK1YhkJ9Xs WfUImjBUj1jtlYPpVflKTyN4794xdJAycL8+xHF6oLWdponjx2ntmLNvWPfVbQcaVOELBim6Z43f RDso4c0nj9oVSXYaDJMHuShJiRBx/Egld++iGxOOXHRx75+5bvXMVT5qtlDToizaO7hRRYm6Oyib Z6OLZooVV5aROJiTZkdF86/2FpDFobjBdI5ZG0Ur+mq39Nn+1fUbr4o8z4eDguHCxkKRSjIUEedA 4Uw4WUlfwrLUyjWaDAZunSNzFSWoqWtC+SLMeYxVRR6FxOOYzB+U6DnlMpFHTZUzE70z4xAT9AlX K6jy1tHFU7hybbhuvvAwbHObgplZ3u1UNM/e6Gaml22nSmgKtI1y3+lc35bGvW0pxFJGicSdBe4a nVLIzFn47Kqik/8ad6U/122AF6Y06CK6bYqZuyY5o7rdB33Th3iYE3r1kDDEO5ZschYvn/DCdL3x +1kDoiiCqyfIk94Fi3aflcdS4/6y5VHbd8jX9lKSJDwhlD8uJe342nHL437BLuaGlzy2080oIWM6 3X0ikhz1QaBG970FR3noyhHt3LRw6dp2vgTNtS3mNRZZK4wsa7tK94L6xUsfcdO+vnp5/Sf89TEg CVGajVaUjBMmaRJIUToThhTlurzCSusS3i90vZu5HRzrhH2xm9gXqs5Lp71CohTLM0p0nknfsA5S czgbBmBaOTmJhDk1jWr7msO51U3Xuiair9BsSDCS0T0diutIZSqCuUwy1NJRpTWYuDvrKlTbYSwh s/hCdabKjc7zv4RERIzv4CAaWRJsRuBMGPIOxyLrat0Ty9KH1HoAYIu/9eZzY1YhQcmSsYMTwZBa UA4EAyVLDtPNllIu4f+OS3yt5uXMekDSLXMfRDula0BQGOWjYydhJBYu+MOAwjZ97iNP8SWhJxPX 9a5nZZfrHFCI7bY7T0weCBdplohRKuF49ECdNGLx0TjUqtY0XVSp1nau96g2kuXT0hcun0xRu2a7 Mx5LuTY6YaufUZyzd5PdveMZjHTohKeor53oGV1Un947b8Jkb2S06UHqxm6qGNs6F65VpS385+O3 ZORkpPumcrSmojTtfS6MqNqaMKwWKJYsm3ToWk79+ichwtdxk8N/BNEnsaAkOxm/53Q31jacAuBd 5wdPvW40XQMzVS0766OkXTRaw7IxX1ANNPbfmSTideITk0SM8R82SWQxI4eTxO8LWjyJi1AbtLXg RCo2mGbK3PZs9UPaoq5dMl6eCXTQYGnXN2wGWsQR3STaov60kfEn+sT4ef0EQP8gQ0iAEjkeoETE lAVTa2jCMELsX/ITIc4QrYRTIniomgZtGMDh2g8TSzdw3Sh41PT4B1Y0h8+MeC/BZAe6blHeh8Qo Gy3sKYkppzKYXEMThuTaysBtUaOXoH7vZWvIMo/TZHyYcCZpsFmTM2Fg7e6Zt17v1XPtn306wSHr gXXemP4ntc1/IWGK+fgwEpzzLA3WGkAbviXp8Z/VS+WbA22BcTJvVN2VGDxu5tGYqo8gPTN1foHk U8wWvmA0S1Oa+Y8YizCejB/iYoGB5SEPRj5ow2Ce1jV6S/+kB8wNelhuViHJl4vxg1yaiYymabDg EkODXN3OQi41o+M5lFF5aqfPXermieOjpfYDa/e4MRLKwMh6WIqcqoVZKlKWZfSRtbAElpCjx/Cm v0ybbqaf4qki+ls3GMNzVbqhxfdK4bf/AGjsQtUKZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9iagoy MzE1CmVuZG9iagoyNSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDExIDAgUiAvUmVzb3Vy Y2VzIDI3IDAgUiAvQ29udGVudHMgMjYgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVu ZG9iagoyNyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9J bWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxCjUgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMSAx MiAwIFIgPj4gL0ZvbnQgPDwgL0YzLjAgOCAwIFIgL0YxLjAgNiAwIFIKL0YyLjAgNyAwIFIgPj4g L1hPYmplY3QgPDwgL0ltMSA5IDAgUiA+PiA+PgplbmRvYmoKMzAgMCBvYmoKPDwgL0xlbmd0aCAz MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjavVrbjts4En3XVxB52QmQdkiK IsUAiyQzyM4GmOxMZhsYLJI8KBJts1sXh5Ta6b/fIiVfZTstS7voB9vdauuwLqdOVekb+oi+IUFR HCLGY8RDgYxCf6ESvfzVErSw6OUv8JpaRJBN3ZWCyJmUkrf/cMND7j7GcQD/N+99He+u3Xxp92XY fdk3hGeCM4EjCb/A6Gb7MYCvoJyRGXzgKC3Qz7eIhO1F8BohGlGObgv08h90hgHa7Rz99CExdpnk OXrXfE3Ke/sKPUe3d8G7WwAFX40JCRnHEUW3l26NTt2auouCG3glIZ7FYSTZHoRwCyHX33XyCtVL haxKqzJD6+TRfyyS1UqXC7SEV1VatF6q0v9hlaT3qkbaIl3eqbRW2fPg9g551PgKqIdWYlHwJCuh rZUwxViEIo569w6eZiZ0bCYWtWYiWwyf3qNCW6syb4HPYch3Z/YYAETIoit9FWxAUCwugDC2RlWp vuyOj6848qG5OXtCUB4eVVLKKWNy1En3zb3B0IvKf1Zr9Fg1aAHhVi99wM0rUyS1rkpUNTW6QbYq ICJNtapskkOQagBeqNJf4YN6pVI915DAN8fniARmIR/pMWdDIY/xd+nUGF0/om+Nsg7Pzm1bTplF wCqBR8M5p/E1WEjnT4Io4KKR7MVNYvS8KfQbQu+Sr1+VmZVgz2ViUa7mnWHTZVLPDgEGG9IbndOc sME5LYWkLAzJVDkNGM4EGZw+KZEuVpWpk7JGQIJWZ8r4KHsBAQYWSmofh1lV/q320QhkkGnjyQ/V lY+0tamALfeoEE5BIsYpZdfxd7CNME57EWZ1rS7xwMDixFk8uDiFcDIas6mK0xZCz0P/AdOn4KNV Y5eoMvAKqI75YMIaxLkYGq+EMSII4yduHVwVrlycMYY3wt/RPK+qKesuj/nwHGVURHEYT5aj8Tl5 suVSl6wohbc6TXJIVcjaEth+Z4hDam19Q0PMJRYDTBT0uRX0IRWYHnMrwa/CCL39cILcPXcGI/0C 2nWbmMET/SJCySUj0RWkcNIvWww9vyyhQAP9ZaoGKkTzROeNUdZ56UGZxx2pThioIoyPA9V+Nbp4 09W2yiz2DdLWEpCHnkNHJSc4PZYx8xCOw+DfUAAyDWW+XDTaLsEGz0AkisNqEIeYiehHfvlBOaDs Eg4ghWcIKvtClVDBcqhsGXrmKMP/tqhMp4hOKFjixBDYaZQcYoJdQJe+cCggYNbLypVRC4kNFffQ W1yQMOaCBlfWlU3RFNEuWYOdLNsrGbMnF9CT5HAYloKgofwZR4KDypGjTrqfp4IEp/N0rUDvPSjg TgOy2XV19tHWqmi1C6gb7TWP1zF55ag1yTLIZHAQdHvqhau6cFWuEtsJxqPgESzmUsixQkf0KwDc y6HK1Dxp7usJJU+Mo8GSB3o8LPlkkmcLoeewrEJl5US6KRybQpFD1bztvo0uU73KlZ2QVGPaU+gL vZQYb1h1ZRczqLa9EMaUYY5peMwawbAYFnQGvCY8kB61plVdI2jfQAEmTV1B7oLo7rNrGEHKE0nG savk55EAuTov/Pn7Xy5vfv3z7WZG4iveXQO5AQmmdPnQNaBw8fGYgHAqOGajm864z64///oHWMno xbJ+PWWeRGJ4nkjJGBeT5Ul0Tg1vh1LH06rE+UJlC+UZTxn0+ae2Y3ACslRreGMb5YixS7VDRxG4 O2PRWD6LBT0G7nm4rrLk8fPzKb0ke/XnXAYfZg0jUK9pOOqke/m7gbELSz1TM6Sh1q+gX9ZW5e14 0SaF8moA3l9KaxoKwiMSjwLICDsP8DCtS/W9Xlar864JhpKrJPjYNTq/A4ukyzeLAjTzsV/aeRC0 Vhz6wJFTNjHDoHzlHopdKC5UNZ+/8tFfqhSqfWJ0/vgCvf/w+ww5NllX5h7yJTUVKIGiyWtXd0D0 rywIuY2EyPW9OqkJuAwlJjIaS3WS9qrkumryzM1i9nC3CseBO/RdMKYwAo3t+S540iiAEqiInEzV fW0h9If2jkWcJ7rGCyW5G0E5sbBK6iWUIgs+c1MSuAayb66/o7Wul5lJ1m1r4JVVUidunLDuaToc URmRsRwoo1732E5pK0+EqAIQxgO2UyadiIcnHaGMCiCccWS4l3OiN9KyFXAhSl38oq+qTR4NufbC p6GCd7tSOlrWSTl4kIUFJ5C3bLJlCmA4N3htBe1RR2JryGBXvt3fvlYmg+AAdk5QmlfNhBOvEKTY EOP4jQEDKRKenNJfM+VzEI6LUe0EjePeZgWJqbqNhouNFPLFuER2qd3+FX0C2/nGrWsOvI2+TGmk cPA6DpokHjNGJjNSGF1YWr67/Q19ev1lQ29QhZytdHkitC4OCbGIIfU9V42ZEmJns4g8eQNzV+nS LxW3O5jg9BzxGkcG+44UePB8gsfYTfivqKGnHekhBCcc+UElINnnldlWsnaieLA0G7vrDEHnDt91 cgqScWxB2JkgPjdJXegH38l0xHdEimlStuOAMsv9lMaq7bR1wmyHVmBwtlMSEz6R1nEALkya3Q7I r+HacTOYoUCvpzw+Hb73gS+G7jSaiuwAwvlq6c6+auqDfnd/I67LbhVpq8akTgtbvyJf6oKDGMy1 cpMkf8Vhj4V5SPzPSKkeEtbrdxvoxw3Kk0dl7N6uwIFQxlRmX/QFYx3IydBlCSURZGU8WQBvEPT8 19026JRExCIK7IJGjH4DEvHefXc1532J3tJu2AH1BWLFS4lu/rDnB6umzKEYD13P8FgILnA00XrG QejbolbG1dyqKHXi5EHWVKCkjFNYmX7QNkHK1lPaQcrB0jsigsTyxBL5OuntMJwdm0Gded/GglVQ eHbs8P6XD3+gwjXVC/cL4yJEG6S+Nfohyf9vu9aQkujErpXhg12rN1sYcyyoGxIM1in7z86EcIqQ bp602C2NsiaD8LjXexF8+eGZzpcS0zhufRlcCwpzD2rvUbAfgOrrSXRWT44ZjISUDx6MYCEkNE90 MrKl/QfHPqJX6HapQEH6x3ra2cI8SWsI5BtfQJ2IMG4ICbFuH4tC1Uan3fhhuvSHEB5KgzGB9tI9 eDoRDbosOkogt3Z1M/B6StUUYnp81Ax0bK7MpcOyOI5iMnLKwPCMyFiEHsTxYd8ZfY/+VZmsSMz9 lOel5AqRzIVgbCqVCBAuP5DRNQr/gxYhZEPrO4WihqUcmfTbsAYAve56mezu+PG/HpkM/AplbmRz dHJlYW0KZW5kb2JqCjMyIDAgb2JqCjI0MDkKZW5kb2JqCjI5IDAgb2JqCjw8IC9UeXBlIC9QYWdl IC9QYXJlbnQgMTEgMCBSIC9SZXNvdXJjZXMgMzEgMCBSIC9Db250ZW50cyAzMCAwIFIgL01lZGlh Qm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjMxIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEy IDAgUiA+PiAvRm9udCA8PCAvRjMuMCA4IDAgUiAvRjEuMCA2IDAgUiAvRjIuMCA3IDAgUiA+PiA+ PgplbmRvYmoKMzQgMCBvYmoKPDwgL0xlbmd0aCAzNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCnjavVrfc9s2En7nX7HXlyYzjkyAJED6XpJr0tZzk5mm55m7Tt0HiIQkxCShEKQV /fe3ACVKomTHlJj6RT8skruL3W+//YAv8Am+AKcQ+xPuRzG+C1kMLEgmNAlJAJWE/0IJ178YAnMD 1z/ha2qAgEntZZz6E9/3eeDZy95sr0vsdbODe7Mw3r93ENHu3pt7+vaeXwB/zEK0JfF8/OpN99He KaA8tveKIC3gX3eABrof4WsEQYA/uivg+mc68dHCuxm8MtNKFW8/i+lUVhNdzW/gtXf3GT7coW3W 8iAK0GfG4O7g0fCCR1PwPftoilaQiR8ncbhnAulMWElIRfljDcKYppBg1kUh60qlsBT1wrwGZ4+H 9pxhxKH/PMaHe/v+fxSVWYg8hw/NVJQPBv2Hrf94a5/4YRAzRp5/tPeE/7D135/E6Hm4NQH9DzoT cvVViRtYLWQJ9ULCQpsaFqLMcmlgJlTeVNLsrcrFUUi418uC56Jgs4CwmMQRP5UF3rez4EQUEt7P gj8/VOoBVsKg61UGM10B5kKtYSFF9deI7oeUeN8uggP3OfGxjrEgL3O/KwI0oe/+WjdgFrrJM6ir tcsD0WRKw0zKbK8mr3+TVSqXdSNyqBRaQ8JJZBGlfRAJWmsY4HfuHxRYlEyiOI65ten6tiDee23v 9LvMRa0e5U861+h/W3J4zyER9k5GOCR9mFH5Z1WbdPF2XmBCT1JdHBca5Sxm3lk404WYT3xGk8TZ 4PXq7BajqsoHsIn2o4GlVmXtEq5eCASf2gVdZnN5BW41pISprheQqUqmtdKlgWlTQ9a4tNwtibM+ oCEPKb0IJm3oItaHB9HDw9a6uSxlhRW7hkxb7FQtdhQqQ9gYs1p4NLRaKMUEjxgbrVp41K8WsRBX MNfodj2mr0nY9zXD3Mhl9Yy3AWVhcAIavCF5G/oTksQ8cDb0nT3IV7VJV5erZdY2i/tX2C1sChhd 2GZqsHFUuqllZeBRIpykuTYua/Gy4v617bcuvw97PUMOgiWUXJrEkR/3fejlMFh7rRGZhkJXci+k +HDvkkWMKN8DH+8FCUt8ZDiuI13U4rt87SzYuY9Lhl0VsF7tk71x0jWKyPB0pSQOuE+DsfIVjeg7 e9+hPUwlpmrbxlV9VhdjwYTg+xgihs/k9ru/qYtF/KiLfYss+iwJWZJwfmEX63gS2uCdZotYyDgd IBqUSBEqLOW8KdPFBG5ngHy6Fg/SQcQ7CmK5rLTAxbCflyJ9kLXlWI8SAbTEW5RHzcxPOAmxg0bn AIG3dcOGMD7qZtYIsza1LCbwq15ZALDtrKW7aMwsV/NF3dnpSLHYsmDrbyZr7MYyGxH3mR95Q1c6 iSOGwxq5rI52K402PDEXbCcAEJWdDZZy1ti2X2L3W8qqEKUs95pgNytOIjsttlnJGI3pGfVANpYS oGhtwI5pq6jUrCnUW0I3kFNKO7sYyOXMNilcsBTb1eSEgda8s5bO21+60B9epDFDBGThGZ3m9NI5 G7wTSycfMXvtJPOfhSrYlWvWpuX3Gh6kXEKzhJWq29o0tagbA3rmPmVqNsMSx5afSVOrUjgGOmbW Y08bnPVJGPqISqNl/VYNOM56jNo7emXBbKXQIstWEOhlhUFctYmlzAY2RsUCHg8djhmOcz6h8VjD MeNH9Om9Qpj/J9y2JD9FxrRNE6y3la4ertqw6C2QdqCBQVpJtP2h1KtyzDgNExFc9nAacewqdLTs 2aoIT3RHC5gYHRBZpmz1INmYibTWlXkeL3lMOU2i5DLEREAPOAbrpYj5Gfk9jvrfHzN5QIdiJqFI vcIgHgsyWxNOQaajJKaXzVs2kDWVKueQa/2AwJkh81uPqA5yR2W9IaUf8gTxMKRjqYP8mE3/qUtb zVjMf+1mhxNZS2iA9NPnlyVtjJSes6P5hfg3yAbffdx5f5iS3qWhj8MuJb0Xogl2IqxSlowW+60N x2iCGFLK1RY82gEceXOlsybdZidmpTGj6rSxHwxtRZwHYZJEwVitCE042Ypu4OMa2xDO9BsJTUx1 04oSuU5FLaYqV/UaKomDx/aDMqYZU5qKKR0anyhMGE2C0Vp1TGk/Pp8wOO+bZa4wDHIzrWDvATlD SoMYNl1D0eS1WuZywwfdEFdjhqXSGGwPSO4F4Mw2zWUxZrhCMpjZBCwgEaejhSs8hjeMgzA4i+II D6UokLL8Y0y1P2b+YJGEkIBGVosYSSNBG/pu36kChwK5XIpqTPYa8+GcPsIeRrkfjsXKYv4Up7/b aRY1pniK4FEhJyt1JuGNHZaq9VRna8vXkLpaEfPNpoC6fTAnHFp1w/S0ywiHOkKj6FLtMk6OugDS bTRnqcvMko9NHR8qlhftyiZbkvjsovUUGkQxRpLLFJq9RetsOEWloRDLpfXd1M1stut8xnVFB+ub ptjuRcivymAz0JlYX4+Y3ElAByd3HFDk8qPtWyZb6nwUJjVzOlYnvP3ghHn3MRXtuKZqI/PZDztB zl6wUqZ9k7q9P/TGDi12BuitOE94RNkgfndSk0vCo6FJlZjShRMYnk7rl/Cqw+Vi7GVjhrfnJPfx L+Bwpn7q9deLsad222WrgVpuh0Rm2W6WtFsr1drBjCMv8IvWc2zV96+sIiG/igIb1v3rMdM6Hq4+ Mp5ENDyxH38mZqMNT+kwqsI8njdrDIuyImSLzfC/8SIQIpcfHgHGEnqyGs4pbGvCU4VtUU0ai2sb oUVCY/Yi8ceYkaCDKX8S8ZCENBgtEjQ4RVZutoWQyqoWqrQktSx1U9o20BHarnM/L7AQ/DspIw6a VWk4sSELjg4UpWa5R+7+Rjk6RBoCQ0cSFkZ8o4l5FysrOwtIN0m3y/dHe6ShMFZXmcr2sJVt6g7z 2knENSq7tKkuS7fLgv+tdDNfOF1mozWOme988FEkjJYfIbCPlu+cnxrhtuE6Ga12x+rR7Wtm+oAi TeXMqrP2F6r8jDHsxKveXjuzJ/wuPS8S+snRROU29Pak4edbujdkubBqh54fJJyEaGU80vnBnQlk 71xPSzvtFsFqsbYA7Q76tO18PIEQJ8KkLxB+e5b0k4BHl2lU3SS5seDA+3/LR1XCzwdHC76nPIjN JjohD0b+95MHQ8LoEHnQHctBqowdYix1cGfCIUzctrTfHmWRZWoHWbd3t9uxg64cNzKh/Xkh1g5U pvkOQrA12ZMwvfLh9vwtuRgmCGd963GOlanCETxf7yL36f+XZO3gCmVuZHN0cmVhbQplbmRvYmoK MzYgMCBvYmoKMjQyMwplbmRvYmoKMzMgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMSAw IFIgL1Jlc291cmNlcyAzNSAwIFIgL0NvbnRlbnRzIDM0IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIg NzkyXSA+PgplbmRvYmoKMzUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIg L0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMQo1IDAgUiA+PiAvRXh0R1N0YXRl IDw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMy4wIDggMCBSIC9GMS4wIDYgMCBSCi9GMi4w IDcgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEgOSAwIFIgPj4gPj4KZW5kb2JqCjM4IDAgb2JqCjw8 IC9MZW5ndGggNDAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42s1aW2/byBV+ 568YLFBkF7CVmSHnQr8kaet03TZAszGQBpstMCJH0sQkR+HFjvbX98xQV0q2Q5Fd1C+WaZE81+98 55z5it6jr0hQJMIJZlKGEkVcIh7xSRwRwlGp0UdUoJd/qwiaV+jlX+B3UiGCqsTfRuJJHMeMBO62 y4P7Zk89G3Oyffb6mdg98yvCE8EjgVkcYLh0uf3TPSmMifDvQ0mO/nyLSIj8l+A3QxGB67c5evmW TjBIeDtDP75TZbVQWYaum6kq7qor9FNw+wVd34JseIKxkDGNOQvR7cGr0Xe8miIcuFdTkAJPZMji aE8EshXhH/reFOgK3czQg0YLda+RQg+2zFL0sNBggxS+kOgKKfic6Qo+FGn7IVFLNc30BcrMnUa5 nZps+/WLjiYsooJxIgZpAkakOO5qsGzq2hRzVC9MhUxRW/gEmtiqRrm6A8lzjZoisfnMlrUTeE+y M8Q58CmlMuj4NK3Bo7p8/UVNp7qc2HIOXkX7tpA8klEsyNHLg++xBVp7NcITEksReiG6NmltUaHr 0twhNVfg4sI+jKl4JILng3mr9qXTG0cyjgXnfJjiu3AGIbqKe4V9NJvaGcAW2Qr928fsJ4gL5S9q Va0m7jsr27QhD5AAJisAQiB8EogdwIfS5ts7UjObQTIU9c6EW1yYMIcMXkMqhMQ0inpYN1grSNYK EkThP87CPOwql1TLvbACySv0xZpCp23sJyDs5ISATryzHB7sO1xS1NfhgmEecx/oQf+kP+FvL0Pw 8m24lSEz34y6Qp/AkYkqUKX12mfw2ULi25lHg2Vpl+DUFC5mTW1sUTlRg3FyIcSkTy44y3ABN0Wn cD04xzDwsG6sfGjyXJUrZ4Cvja5ancfL/5Di3jpz0JqfTI7zlKa4q/RXArn/s31wWTzXDv+XS1ca TDGzYyofxr3BT0SYsTgmY2EfyNBqf5QLP+vSF2t9r7JGOcejpDS1Lo0a0wZM9i8AlAoofkyOZgR2 VPl+ra0FvxcrFwOlrldL/duYaoujujd9PS2bRF9ScPLkd11mqpyr7FThj0MXBTzuCBH0wkOKyYQQ YLZemEP1gx9TVSvgYJm515D8S10C6QFrJPrKXVUrlDbaWWaTGZm1d83y4vCfe9jo8hZLCa+j51E3 l9wtdQvjI5Cqmqld1iZXGVqqegGsMbNALNdiZCq5c/i1n8Xbb5Se8pWqqAyUZTRTJmtK4KJwafY5 DPkh/QTiwShlw+hnBPef0iJBiQULF/Bql217Pj8jzg+iLSK4b8sQwk2UYjJWy7AVodsy/PrqNwDb v1og2K7ClrbxLNzTKXdBQTtgap+GSwOOrBZAv6EQtZ52pArqtcmXjpR7Bya1LUfM1IjG/al5xKCU 8igei5qDEF3rff5x5U3WEvTWlm/BoZ9/GlP5qDc6E8whbSQZqzyDCI8UqA8L27j2Uvv+DKWrQuUG iGqllwpSSD/NsUEKIkNMh3FsjEFCHnWdM9VFYTfx8a2KwF6TIvtjmXYkw75Mm4QELO/UGYdotyKc ItrQRa47Kwjb+gFyG1BaVztxTrmMxZhJIcOgv2X2XQboG8W7fAqedVmmZ/W+w9CjDguGJBvE457D Al/YpqXJn8AZV1Mlls8EcfCcw8AKMpbRnghdlE4dPhe2dp1R7rB4CuissjsH1WoKmO2xesMPL9AU rixaAp1DmwwlFanM+umKPhrpcMwJHTrRYSHtip6aXENdh47lQDoIuXt7pyfoFrz5okK+zB9QFQJF ngJbGURVKIlOSlXAmz8CXJm0eFH79qL2AzLPtPImWXQCLBgOXNssCA6Ai0Xy/xG4GBe9gQvD0yUb bULQinAKuD66qcANWmhV+rFPpVaeU1btvACKUdWWpfUIdFOMAO0gcTapYqonixOhgMIxFsNqE4Av 9EhH0x+CrxhDb949BmPBQM7A8Y5srrH1GRgjmAjKKB8LxbYS7JRuDb+mCEAnR+RInMR9RxgALpRy KsfiSCDCYwNMpHLXVswaN7W6XEONI82oNJVvi9R2mNWGMPx176bdTVYbwPDchbeDc+gAAayqDnqD HqGM4mgofANpPO2zbSN2EDEMfmjEBnXAnJ58bYJ0MQeog1JRoPmYgcJo/3GPIJxTEY416QAZHmHT N1DjXUHajj73QmXWFKmCWgoVfzvCTjRwgPpB68IXV+BwY5pK9B6FAneJBA35aDklyCM5desN40Zj PkeWmVto3esMLAUFYGGSha8MuZkv4G/XlAILSi26vR7TQjHu3ZnxUBAhR5sWgwiPx1LLblzMOGDZ 1D1Vj2gCgXsDL7TlLJYnZ1BnmUAcrxHfbyOkHU1AnKj1ChTIAcBKCgmVAZPOrduKqnrMaao4Z48Y hziC50djDSvE8R7xP+g6M6DzP4E2jaluv+2hh4lQxDE9MZk5NwJO7A4zr+vVZjPoC+phPd3Qxbm1 KZQb28wX6BV6U6TIzFybdQERs/L91qsxzcV5X3PhGFplGYej7VqFW9t2VkyqSFfoXVMuQWefPFCE kqZ0U7/13s1NBXWJqlUFLHoypkkk603eZBhTX0dHiiDJTlvkCv3dLgr0IWnS1O1i2h47UxU0INe3 b6HDSNvanDiMdaVZV9DjLj3irg3XNWSn9RYCsiHiQ8mbiI9gcDPHbV321Cz7eZJ/4DF5MCV5wmPB HupLID6CDGrn9zwmj6ckG499sg2EaWZSML0y6ZH9D3cQLVnYHC+whUbQLNanfUWhcImIhEN9JY8n Eqey7XHfBednm+/Q930XPDvhYpJEQFzYs2oH39cbbkXYqW/qdc/uGMvUNe0Lo0tVJgt3ugO4nSrb wQewXF3m6IeZSnR9OVWupUqgt5/b0vzudzY/tMc93unMAGMeE6ik6M/3cBiHYLyxgApEeITv3a63 EKodYu22MZsjA+3ES89MYWoNob6mQalNGkcRkQV462IToyHG4WBskht43Uk9K6GZebDlXdvjPA1O QR8vxTjqvWjjDAhYONrZvK0IuwC/ycwXUwPStMW1aHJINpfsy1LvtdbBWiDoohh02OeipRMooII/ IdA3XW3ORWn0y80vLnbmpX3wo4YVEuhP6CVaQd55iMz0+uyNPlzItmcBCLTHHEdnzY+DTZQziZ8R 9xCVBOUChzQcNH9w8XJcScy6n3YnDDt2IXxjlz9oegjwcTQ9JFcY/w+nh/FeiQi+j5AJxmSICRk4 PtxFwHGJ2MsgIOhLbV3T7ye8/7pB1RLqgT8aCI5bbTt+VQCvd2OS7ZRgmtnkzm+84JKp3aXO8QJO OWgih2JezI8oJbzaV6hqOwR0AwzPOyhDbyq/kXM6UMouIK2O0823iphD2MfDBHT3nxLx2/7+bzBP dNW+A8UmAydWyeL1PFcmmyQ274AxkUIQgelALBYTzClQ4p0Mu9pD2d14SjJA6z5keL1FpXFEQzYS G97JcLwr0ejBgCSmSGwJlMCtQSD2Ko3A9K7u752zLvS3GqWlmtVtgKKZKav1lfFoFMP0aAb7HAMV nGIScTaQRm0YqBOhG/kPC/ui8ibYa/ff/xdEL9V8CmVuZHN0cmVhbQplbmRvYmoKNDAgMCBvYmoK MjY2MgplbmRvYmoKMzcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMSAwIFIgL1Jlc291 cmNlcyAzOSAwIFIgL0NvbnRlbnRzIDM4IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+Pgpl bmRvYmoKMzkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwg L0NzMSA1IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMy4w IDggMCBSIC9GMS4wIDYgMCBSIC9GMi4wIDcgMCBSID4+ID4+CmVuZG9iago0MiAwIG9iago8PCAv TGVuZ3RoIDQ0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNq1Wlt32zYSfuev wNsmZ2MJ90ue2k2z3ZyebtvYZ/uw3geIgiXGFKmQlBX31+8AlEjqYtq0mFyOLYkCZj4MPnwzg6/o D/QVKYqUnnBCFGeIS40kJxOhNZWocOhPlKHpzyVBixJNP8DPuEQElXH4GsUTjDHlkf/a1e57hPnv 3R2ObQjpjo1VM/ZuTOzH/IrwREmusDARhreumpd+JC4knxhOOIpX6B83CCYKD8FPgQTmBN2s0PSf dILBwps79GZeLW3qih++2NnMFZO8WLxHb6ObL+jjDVjnbZdCEIKlQTcHk6MXTE4RjvzkFBGOJ8Ro xTpGkMaI/+SL6i1qJu2fKXreTYmP3fzVFiU4mqKPm5nN7ktwEuaLGieNwoobKV7nJLgZnGR4opkw vGNC6+SHZZGUVWIz1O/u8FVV5tjdclYkq5411UYQTRm9bE0ZOKeN5h0TWnchrgDn1s0miCfCh/GV N4MabagBl4ebQXYIEEQpbBcwwcDiraKuCY955jogoKUtUeruKlQtkxLFS1tNztjnrfNrEg206GBN CLzfrkn0dAi2ayIwZkZp8Yrop7upD0KwMeFcCL5Hn9DWZgBFjtaFK53/denQdfINTdFvmUNlnm6q JM/eoe0yiZcIELMozlezJHNz5OYLh2a2hF+XeVkdhhcRghEDNlwSXR5Eqo89qKfc2zYiZxCuhnKG JhTOA/+9cTijMeH8glXLwsGyVPbeLfN07op2c0X4FTYcui9l437U534brwpT5UN2tHjdm3De/Y8+ 4jJXbfPivnwHQZs/JB4EZLM6BstODF4MhxbRi6Khc0wyYDPBz23f6CXRcAKHZ4IXwtFs5dKlLq7Q XZGv0GqTVsk6dS1UIwJEMR8KkGAalIRQYwEEJvQBZLMcCK1Ai9ymKL+rGasBDNgM4CrcfBO7QHyx ZzF4bPcEvM5uGZOHvAYhD7rsMiUkBO3xYLEp7PPMFg1aKspewGwH8kDAWcQJvlQetEu1N+EpZnNh mUq/AP5FOFL8gZOWeSesLVrbokriTWqLJqrHDGpOhwY1A3UsQNeOFtSc9iGVtLDYJrIbxAApO7fr akxIJBm8z7ExkBiNRoRgQh8kpX1ESQ3CPiS8tMsWDk6JvEB5hj7f3KCVs+WmcCsQOqPyoMbD8VFS KC5Hw0fjZzYXpJEW/jNUPa5d2GR7AdWB4ow+J5RB3oeHCJzoVJ5rAIqak7OdkPdYoB9/fUqBRxeu DCNsuKLRSlMtx1I0jQnnVybeFIXX3evCxsBqzm/t3z+hcm39mZQfnlgdGb5I8xl48YgekjKZpW7E cGZsMAMqojFlmowVzoydMOB/feJmUWXBWb+fffa2KOx6+b8xXReDmU5KCkNTM5rropfpPlpYfwgQ O59DxlaiWZrH9yjJ4gK4DfZ1mfzl/Obefx4CaUyE1GCuY0JTJdloxyOY0IfQv/wpWCsJT3igAIH3 K7RNqmW7syCW9idmieY5AOefK13QgeWogGkzFDCtATAsx9tN2vQBdr1MVhKyBwDCPbg0X0Ny7fVW nj7UsrjI4ZzIFocxBZsv31bLEZHiWB8jlSbfEruv3qxhsVy6q2QdRphRjCtFXlFE6wDmP1EgW4Il h4BFb67jvKp8weTLBsJrs05zO/c4ATxlCnojpBKfP/8M6hQIu2ueMEQZqTXa+sONRh+uw5R4Ylj4 w9H1hyG4cWxqOyNvJ7zNNYJ3KZtgmIei9t0UXYfi8osPbU7FhBHli3mdoYGSJsQA0w0Y+uR8FJxM KBFUHQ7NXzD0c8sICeW5oRX2gMDznaGjAYCEoRUNgBwNbUKkRMc2++WttcvB8nohA0FKqOZG4Msk X7P4Z4IUvVlW1fr9dLrdbtmkyvO0nCSuuvM7Zgq7dbOeJkV1N2237BAkYEJK9whoCYhjwDxq3x0U bX5IQyeUgbLX7dDRChHBwtgcXTA0EaYeO+pa7YtLx4N6hcsVPCv0RYqvxuek/g2qbrpN7pMpUAMQ Qza3H0DB2UV+RnM3gcIh9Vb6FYK7S2bqrEHo9k2dPgbisqvmJMwzB+QWSsCP+QalFlguSxbL6vbt mBTPT/TVmS5FQ55XddsMNPRZRR4NYfe2T8FPe0+//YJ2rYoRfZXDs0LNJVWGjnXwc9mrlP70kqgM p78PgW6qgWKb1YooFF2a6uG7XbyUdTZZfwzn4GHpiGKusdQX1/65OqmNzR5b4TZi5Z+bk/rY09rj wFdDqSBMicvKZB3tYU7yxSBdvdeVTdK93Lh9A0lQks0TWJiNTf0SgZGgem/fQlJZ5Xd3I8ayIGrI vvWkyrgmRl+aFjWbFiw4hqVcwp/Oakx/d0Xs1pVHo0hgVsIngsLI9YCE1bNKRDGehF8YZ55giPBT Tz+tSPRT7gf67FJbJQ/uQ57m4KWriiT2Q+JXcPIhjuyFDaY2vjghElPzmvboWU4AE6IeTvhxVzGv ll7xAylWR0XzlX0MuVKa3Lv6ILGha/gIaVT2twotLWQN+zxrzBAUcnAeRYQ0XI6WmoMJvUW2HC2S Xcp0hFkOXBnbtZ0laVK5ul216zsUbpmvPNZxyEVDpW5M2NTgJpYyPgFlo9UmheptYoWAmTmXARRx XQrbMdlxzg6gWYi/9drDNQNw/Zeajw+7NCAjuVd5F55A4jR1TjKw4uCs9IY1Zee5W4PM837UZsHj obUR6nX7r4y4wPI0a36WUigkS8q3Y8ZZYHmaiZzr7Piy1HXybeovFvhqA+yXlXMV8pbWHYxy1wIa Ex6qBtOGUlpIokeDh/a29ENp3jd0MpQ/uOIhcdsx/eeDaVP6f1qPtv8l76VNn26A2gwnzn3oS/jr Jz4fse1tk9APDQEU5Krfcfrvekyc5GCe5EyCWNOj9bikPOHJ29uD2m+R3KN/58V8ZYF16nr4vLB3 oem3u5VzXL/8rh0dqcmZjg7B37GjI40e2tEBeDFI9NHuqDQmnI/nsCJX2W6ZrkJ+deXK+YjBqshw UmPSCExH29SKqOeK8CVaALu35+H3akkoNpziGIwmRhOGivUynJcxOxlwoBsc0P0jCGmgPUDK7+Zy M4MP0aefxoRHDGc2QwVktqOdgGBC7wm4V77Z+Rs3oOYIN+QiLUcV67FmsSnqEtg+Rteg5HaLsS5c MKm99ocuScW4ULUh0TlDvvXflSWcGSU4e0Wjo6VuYnxUqBPqnv0wKyAjuYL0WE3+ckVqi4VNn7w0 Gz15aXZwuEbdcDV4aIoMco1IUPuvuK97PlyDCdGTl8q6enUXMJDThTwm6JWVvzAbF4/rKg8d6iQO nfqFy1xhKzd/d1xCEgpMOqvHByUr+vQqWZJVrrgLeYjn4GQfyZ06jTCw32sRE70SO9ibR5OHy87u 5RW6p2ks2sWFftENtqOrHPCXGXZZW7CNC318gy06pPn93Yy2th4XeVm/9uAXLb/MNlm87Fh7qSzS +ytjA2QRVwqIno0li3T/rbXmglq5zLfhrIMsPg13mf2Njj0w/sqLv+IAWX4K+yZcgxzvLNTDb7Jp KbFhdLRmvO6/yRZKHhY92CI5wCWv9cM26VaH/vg/GDapFwplbmRzdHJlYW0KZW5kb2JqCjQ0IDAg b2JqCjI2NjgKZW5kb2JqCjQxIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNDUgMCBSIC9S ZXNvdXJjZXMgNDMgMCBSIC9Db250ZW50cyA0MiAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0g Pj4KZW5kb2JqCjQzIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFn ZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczIKMTMgMCBSIC9DczEgNSAwIFIgPj4gL0V4 dEdTdGF0ZSA8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA2IDAgUgovRjIuMCA3IDAg UiA+PiAvWE9iamVjdCA8PCAvSW0xIDkgMCBSID4+ID4+CmVuZG9iago0NyAwIG9iago8PCAvTGVu Z3RoIDQ5IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNq1W9uO28gRfedXFPbF NrCW+0J2kwMEm2TX2eRhd2FYgBHEeWhRPRI9EimzKcvar09VU3dqOMNRB5jBWKLErj5ddarqFP0V PsBX0AJ/RiKLuUghVimoWI80S1INtYVPUMK7Xx2HmYN3P+Pf3AEHl7dfYyPGWJxF9LW37fcUS+h7 9+f3lllyem8lD/fe3ZPRPb8CG2n8CEuyiOFbbw8v6U6JYGqUiCyFfAl/HwOX4D+EfxNI0pTBeAnv /iFGDC0c38Pr30zt5maxgPfriSkf3B28icZf4P0YbSPLZap0GisYn60Mz1hZAItoZYFGsFEqkyw+ sYAfLPh5XheuKUwJd7CZmwYKB9Pi/t7Wtmzgvq6W4ObFUtH7DV1v5hbsdGahtM2mqh/ogpksLDQV Irapi8b6z5xthHMpEjy+mzZCEOIuLjZQV+umKGewqu1nKdUb2C/7lgAUWqlM6It1o+etC+26ml1d +DtU92BgXrnmZK8v2OGZk2RcRk87CZw5CY/xN42vLB09e5MnXoIm9HnJp/kWfgq5YymG7lgnMpUa gzXUjqXo27GrHnH9HC/nc1PiW6u6+lZMbe1CIpPwocgopmIudRYMmYT3IUPO7xAOO4W8Khv7vaGg sCafQ4Vo1a+QG6bT2joHk3WZz21QeDQbHCoSeYhnOhg8updQmzmSI/641aJAZi2RItFxYGXqJigQ aTYUCJGpJKUkFwqINHsSCE/PZ+ktU1zEGMo3pQXBVY8VszWmcTevNg6ddeNDuM1SlDMoiB0BEwU5 CMVYOpjKuMTEGIzKyIS+g5hgWHoQKHLBlFP/Iq9qjNFVVU4JFX+pXpeY3Fzx/V1VWnRd15gyt8fj O1RFo4TqIp9smdRMsyzVA3CMdpvhu81wPM9kRFiKTsZ9MH+ut+avX8xkYutRVaOpxsHC3jetgyEV N6MrJpKBLzrb6PRsYwkDzzYVnPM4oaonGu7eV87WmxA9Xr5ZPDP8WSHd5KYpqhKcLafIwUg5+YNt fgRntrAp0Acuy6azak3GKfexdEu1xvi53RfFE0d/OcJ1xZ24kExlTEfDrThxJiQXRR/brx+163N+ xxP4229XLBjqLdFVJtBqqLfEWqG/SBW9CPUr3qJV1MME/4J7jKCqgbdEAUiSBn8pO+XGWYfvUtxv /BWiiF0axyv0uZXBfxJ3oBvN5j9edC2p0FmG8N5W7CuWdZLrnrCcxXJjejRv661qib2x5Q7YKACl c5a1MTegBkuVxCqM9y8dPfsgWxN6cuuOzanQWM9m1vnAprf3RWm4WgMT9uAUp0SqpU5CZTgSAXrg wDrdVUvce4X1VrdkXyIBTm2OqFw2rI8yos9tKmY8Y9mLnDra7yJRSc8ufEPpW+fzLILNp+S7cIpe yAt0cvFFkxO9brMCuk21rvNDjJ8sfysNcsWH0mCG6QcJJBQLogWXLIjnvmrjAsr1EksJor1nbzp6 OkSepfMcq06qArEcF8j98MJdR5e7TtlTlIGlHZyWdvjiohY0GD9tLYhsOyuLP6071FnY8oYklWxw A6NiKUTGVTBWyXpJlhKPmVYrDJYioNyDGX8wnSZKJ0KlwToGNOG54kdtm3Vd7opJmFXeIXwJcEg1 IEKiI3U0mD4Uk3S/UOhI3esXx1rbwbQqX2H2sW0+CR4lIlHR4JoywQ7kqu76MjQS1S8g2/JYj7S9 B70sSRjaeU2BIVRtyk5riRdg7ez+C5v/i4CsRFeweVRAZjehhgtdW+374f7RTb6wVzq8L0TP0r4S TK08C1aWiq7Y8r4uHuD3qp4uDZZad/DPaoNBAdtqDbbEdgNP+T9uu1zapi5ydIhm7v4bMEBkV35p qnLLcR2sCE90g06YxIKrpKOaDhsTYM4dKbzMvSGXpdaYOHRjHPxivln4ozZlwDJLCg2D8yf6AotD lVlS6L5m89/oAS07eq24pYcVluEXEecnNmksVZLeZJmUcY9lOSDlNL4BmFa7xPZ2pwneFv7npxKr wfO+hAmpJA808DuacNz8h0Nc7rj2rD2a2sbmzTHjX6kGaehx+BhWg2c7EEIl2P/f3PtL1WHOXT7t k4ww+DRWR6S9DFbcTgVIQQKk1OpSNfqyyFX2pZqXT2mQj6tKN7E+zagHsn4iYiaR4EKx/sGEx1Ql 4riyQjTM4oHSqplgfoVp4fLqm6231OO69WpV1SHL6JjHl8w/RR9e2LqH9aWQcapkd/oQDeHAmI14 lmrpjegG219gXCzh49yuVqaehtyyHDwojjPi1jhYNRhL+bQvGOfWS3IEqgKIO2q72HabTbunFyLl I7uEBCwRL5iSiUxnwaQrPwvoA8wsj3h5DjY7WvFqVkgw9ODRstA0F5DhwNCd0TKFyh2Md1NTg1mJ HkiZWgMT5BAPD2apusASoriHjfX+ZJFWYGabVsbunVDtRwq3zadopBCnnbaQ8zvBekYK0Y1HlrD4 QP7RM48sValgLBj5H0y4PDIM9cLN6UTmhhR6kgSaVs7Eg9xatBPMrArowIkY/pyMTvH0eahnI8iE vmgeE7/V67wwCz/xJ5dGRPJqXTtfe07qNszJ2/2jAbvGOSTpJbEYrqyJjEkVTFlL4g7p/VKU1T7Q F1X14MCXBst1PodF8WAxXxZLFRIGNZju0Fd0fH2K9TIYFH/KWzrPFu0GFccp3F6wDxtK6eDnaJTE QiJcKki6cvXORahxXFpTHjqS3aCSRBtbU+Bc6WGqQ1z9FBKm4SK1lFwkPOXBcOqK1Cc4zUlZ8Dh9 LL7DO/ijtBRXTZEjA01MPYJPHr+i7fvu12VOuqVZFM02IE7qJZK2EIwHexqJTHgq1hCY4oAMQUJP RRRH9TIkIMNVbJ1pybUMxsGqX8UeH56KogS+WtnygIfBUGso1n4kgRRLUzMxEyzgsSSratL720gM CddwmVvRPIRn4fynK3Pv4ux3eobMoiXLlpD3j0rnFiZIP3anf3vycQsib5oc/frxfUiAdHIJkMP+ ct/prtxslFfLDkZJEmMDGN+mcSZ6JDLsibwVlxrncgsLgy1caZa2fewRkcJa/Qdqf7H7/QE+v65K 3/1ZeLV69fnN42pbNBiVLB6stmmuskymodQ21X1I/Ky9K8kRjvMRUuBOB0b7EdrIx+P5TN4epkv0 FOP5NjTW+frG/ySAAOruk4Pkxt6aLZUjpOr4GeiZtd7BW9v8+KfwhW4r1p3oHR/+B/0YFRIKZW5k c3RyZWFtCmVuZG9iago0OSAwIG9iagoyNDA1CmVuZG9iago0NiAwIG9iago8PCAvVHlwZSAvUGFn ZSAvUGFyZW50IDQ1IDAgUiAvUmVzb3VyY2VzIDQ4IDAgUiAvQ29udGVudHMgNDcgMCBSIC9NZWRp YUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago0OCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg L1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAx MiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgNiAwIFIgL0YyLjAgNyAwIFIgPj4gPj4KZW5kb2JqCjUx IDAgb2JqCjw8IC9MZW5ndGggNTMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 2r1a227byhV951dMn3oOaiucC+eSomiay0lTIC2CGAiKNA8jcSRNLHGUIWVF5+u7h5QoUpRlU2KL GLFNk+KafVl77T3zA31CP5AgSPCRlIQShhiXiDM6wljAT96gLyhDL97nGM1y9OINfJ/kCKN8Uj5G 4vKB2/qJCJ6Y1vfFoyTcCY+T8PhtPIpjRmMlJVbobgLvjkeCMxEnCsXw7/bwqyBRIhM2IjRhaLJE r+8QxtVN8B0rAR/NBQC+W6IXv+FRDKDupuiX72u9XJnRxHjzu3s1W2q7GE3cEs11jhZmWqBibnM0 meti9Gt09x29uwMb1HgD2vhJZKiDjEYVMooCKkYrVKRG9VH7fK4XC/RuPdbZff4S/Yr2Lw9GkQnn lAoOr456vprsjEIARTySNFFsDyFqGubN3Nu8sDpDL9Hd3KCJ364KN/N6NbcTZLPUZIX9D6W8jYwS SRQmNOpvlAMySkkDWXTkMuPRBGCNDVrnJkWFQ0t9b1C+hlgqwFHwn8kNWunJvSnytuUwYxQzwq6C F3yWiDqSogrW2CxcNgM4MwMAfOO1PQIk2gcIagZIcHQ7QLS30/XSvsLkux6PjR9lpjgOkgQzwWOs rlorTvhIxFLJEsaxK2ChkPMbbwsLS/duXYBzQuqAU+b6AZxS6AIy3Hlk9GSOJi7LzKSwLrtB3s7m BfrrIasuSqSWnVQS9UwkCNeYU8VPvDq6KJFUcswwr31IojfaryBjwDwv0Qe0sfl8H6tAL3OdgmmW ENAryKwQv+jjelHYW46+vB/QQBKzvgZKKKUYczqUgQDCaQOVZoHI2egqmFyGNHowPodgQW6K3n9+ V1ks3LRa6HVuxwtzgpOrGlLWDip5LAhJLkjAQ+0gmIbaIWl8DDxdpzbX9/bVLgedn52vG7dVWqqY SMkvcCaOalAxL0Ex/lxQ353NAls+AgsoO+YqFpegglDYoZIUMHFyjAnjl+CEv308hNbZChr1jmuh nlFBo1biy4QSnEh0ETlG3bjeQzgV11AarHkwjYyHL4jtLVp5t7Q5xPsIbtNLlLkiXFu5cG0X7wal cAV9ntslv0HgyvZKIMJxIjDBlywlatQ0qejxEt4bN52iZcnUc1sgoKivkHrwq/HfXrRLXHQNM4Fk aHgweg4zMYk5IU/owujZxFQjaKzeGVj9y8ryKHUG/AaCwm0yNAWdGPRGaoqqng3I0ori3iydcIZp MhRJA4JjWzTl4GtXzMsiNXd5gXSWlr+YdGYQyJCN8/elQKuEgSn/qNPUgyjLR+jvbgOp4G/Ky+1I FkQoUI/8qpwMBmSdItwCVwoUeHtHvUKhY1IFFXGNYgLjtSDs9GGmFyjX2xMc2KhYhAtOlMIXRHWj 25Gg1hTv+HD8auzXE3NLwNSj341faD/Ti+dUiGEbHiXjvg0PeEpiSelQDU8FIepy3Z/LZgcoGMTF MtD0vqMAQbLYosICBW7dGq2hAfKgbkPw+7WpCSFwe1Ynx2hIWlCqDy1UAghaXmjIBuMF1SlyX+uy VfZfH9DMFZXNSn3/bTgDiBjL3ryoMBYSoA9jgADhHDHe7Up7cP/ELRZ2L17DhZnTi7wu6aE7GtI2 VPS1DadCEKaSwWxDxXnbmF2DmFep1CwPuVv7yb5K5EPaJeHHdknBBQvjG/q4oyxo+Eq6aRP1IRsW j7CSgpYgji0TAmUFfFvUFGOnhyq6Mw00Q7aYg81QbkylB8PfirXP0EoX8xuQI+1K66AaHxVVpqgi lJMri6qIRaf/2bnrIAUCDgc49EZv0RSkbUA0M6ARwPPAlHuS3GVEYylDulyq3jQheAJ6kg6WClKd S4V/Q/0IbivTIDcLUJClPaDqPNhQVg5Fp6VbUuvhVnhmN0YJY5YBDYdj2T9XBKgVCiw7VK4AiGPT 5SGGQm2GVAEBVTdGpVAZe6Pv4Xop0ffxpR+cTXU2GZJhMekw7MzOVRzvjbPKZ2FyfGwgklAVc8Iv 6HEbBhJkRBgWJQzUGcKFmEZvw7ztFm3NnlBytNzuSOb2kKMh8IBOygs7e92g8boRbm3+kIRTcllz 2aQPzDpydDcuBEAgH549Lo2e9hR/pryMGtMAzpOEMHSh8I+OCKCGcFjtJ0j8tzYtxaM3SwfO0tkW YhjCuaTK0GUiPuRAVGDRmwpjpQRlMbuy+DVMIc5y4T/dKEiDSjnnxRrSHCRT4VahSFQmGdIgSvaX SVKFXYOhagNAOLbHP7S3DfXY2mkBZFAjFkFLww+pnU7BVllxfu6ZqDiR4mQ96zH3jIFuSHdcOzaQ r3vS+5kzQDjKFs8ZfCYx2IFcNWHEKqxTkO4w9txG3v+rsw16um9ny6E2QK8+VGe7gxA9LcP3fWpL YpSSJDMmLbdwmhI9PBS4auVNOTdp+ZZQrCi8/7oqkcj2Ilr+/TlCH4pj3SYxiQm/rrYGt/HO5DNM +7I/FqUtginujVkFwq6KaLWtdcKA5/MSXiSv3I3AipQJ0GXVwqUmn4VJ8xi8+/wMKJFJkChMxurK TYmkxNbdA0uXSwjxfpgG25EQFOMTOxJAIf+zHQlBiey9IwEfLZIrc6hBBDWEtgb5vF6tXH7YKa8q r0YUan83uUtJILkE8k74VRsMlOIzyEJ2Tw8idZ9995nbID0OLbAtqpFxta0PnTFY8mh8rERC+EUB 05KqlHV2AkIPGzZhVhCvLtsPj0WbjbCIORaSXDc9DiK/iWA3PXbOj2qFUMuAIJLkn+SA4pnux8ZP NIEtyycsEfLJqfVToXtoAml3dv3pL++8vQe56NOlBp59dMX9U/VZ0+g2XVIaK3blTKWZqrIjZ75W Xd0fvp3zbdRzpar3Nil8MAst/mArVeqpIWFmfhZB8aYGunq3yYERNmHiUYTrs3Cix0D5HS9sPjfp gL0B6z9e5gwrcXor/6LegD01Xjbos/2JXqB/ZaYsoRotHLQItXk20DHMd2bbBII/jJR0OReB+gum g47/qMlnMUliLq+lTkY71Bl2SAC9zaDsrxamMGX3W5g95uE2kQVLcO9NZAIaEj5/oF3kA4THPAg+ 2TsLiHxmH0wWzLPO7I91bRP04S0oIqjSGRpvT20mnRKXEDyEnZ7n9znsAncw3pkxPehpjwMlwzZV TPK+TRXG0JCQ0q2DNFUVhEebqi92tyF+4jykFDjhFF/VohCG20gavol+8SCYdqqoFlAQOml+kHcr O5tt0RhugkScOr/U4cxC6GuOGqpYhu0CdeXxSJHE8bGAgeZk4u3Y1Bjz0wxwlXpJsOo7+kskuOjS MwfViqNGpNQITkdK2NBBOrWpLVw4END0Ru4Oc/+J897kK1cesz0Mbh+Mt9NtdVuLwTG0DpJxei2B J5R2x8vhNO3hdOv5w6295VeSkL6ihCtGMZd4KFFSQ3jEZ3OTNVsP7T3Qdn7zmKOqwlyXu6pChzJ4 WMWn/wKxDpS/CmVuZHN0cmVhbQplbmRvYmoKNTMgMCBvYmoKMjU3NQplbmRvYmoKNTAgMCBvYmoK PDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0NSAwIFIgL1Jlc291cmNlcyA1MiAwIFIgL0NvbnRlbnRz IDUxIDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKNTIgMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA1IDAgUiA+PiAvRXh0R1N0 YXRlCjw8IC9HczEgMTIgMCBSIC9HczIgNTQgMCBSID4+IC9Gb250IDw8IC9GMS4wIDYgMCBSIC9G Mi4wIDcgMCBSID4+ID4+CmVuZG9iago1NCAwIG9iago8PCAvVHlwZSAvRXh0R1N0YXRlIC9BQVBM OkFBIHRydWUgPj4KZW5kb2JqCjU2IDAgb2JqCjw8IC9MZW5ndGggNTggMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp42r1a247bOBJ911fwbSbYtMOLxEsGi811M4NFdhGkgXmYzAMt 0zZjWXJ0ibv/fouUbMuW27EszQBBut22pcOqw1OnivqGPqFvSFAkySQUOJIEhVwizuQkoiqkKDfo d5SiFx8KghYFevEWfsYFIqiI3dcEUROlVEQC97W75nvMfW1+6dKy/oy/dHNJ7C6JJxgzEbJQqii4 j+ECeCK4+7qCD2B0d3gJV+ahEhMW0QjFa/TmHhFafwh+RkhEnKP7NXrxbzLBAUH3c/RzbtZZaVCc paV5KJ+h+6/o/T3gxOj6ewXNvVhzL+bvJaP6XnSCUX2vjzovljpJ0PtqqtNV8RK17gfLlJxRSSgf tEzC8ESySIUeQrBbbgPh7TK3RWl1il6icunWneem2GTpzKQlWmZFiQqTzgo01fHq5BM2XSCbzrN8 rUubpc+CW2KFzsWK4zDoGSsqRBQqxs7cOrglVgABXYiVnpcmh3jo8jkyOl6iws4MytLksYlXQyD0 27ufijEjQ1nfyLAQK8XD0QJD2aXA/C+FMMw9UxaZTgq01QUqM9jKsyo2DYOAVfCZ3ECQvjDGW/GZ YEIEkSJCN3I+cHDDKLwAd1HlnrBouzSpR2RmC3McNYKlgriJoQrDmThVmNSU2yxfwfKX2doUh9vu ZW4SOaG7czAow1xhcRKN4AoYpIFBEJUMgESdOBDykkXo9cdD+I+F9hauBm2uCtxX8UIVMuyKyn0c jKF4NYTgkuJNdWFjBLtXI+uZWmwSW/q38qxyu3zHUkAa7JFyxQlhA3nKlDxGep6nNnWwqikwB/QE ffl5u7QgObPMFOlPJTraPliEIYkioW4DFhyYKzsCuNTfjYtQvNTpwnx5hnQ6A80zIHn1hoZ4uaKw yU13W2NKMWVkECwakrPAHgzozD4m6BjncQ0PhqivwKzF6OAaRnPATCHFl9cdXM3oPYQnGQ2maceM XSCmBlL1iBKbroDeJrad9IDckYhHYTgoPyEmF3DGqNrMdNmWvK7GBD0zQukVGnO00gjMIxSZaNBK 2xnZQTifkVpEitob7BKSm21uy7ocNhu7u2nQkNoTUloDDM4BfLhYdeDqIRRhOajqEKUmLkFMnt48 MUVizZ015fwVWIAyzzbLiQvBEqzC18ymZgaBATGG/VtO/qrqJCLRszoRDI4AtNXfORhenPYIDt6g TZzP9uGFd1M1cdIZxK2RNFA7CxFKvfjq2QwMOTj0Ko2XhyJ1Lq80UhIKxA2tTMtNUA7QRWd3f9fz V1/1dGrySZYvfC4TMy//jkwq2tdnKByGknqGj+IzaghP+oxfneNdZ1MLzuLRV03fWa2rpLR34AJd 0XR/nVW5+9W/ebCJabWGqLo3jisqg3KqJB1a6CXmp7ncWghdrKvC7AkHZDsiWkvFg8FdjaSH3ji4 MoNQVDHlbKy6uofwZF2FYPi45OZbZaHIarA9Gw0WzYB2Z2UWZ8kZhrd2n1QyjCSnw7Yf5k5WJTih E7gmsVk5SYzOXy3W2iaTOFv/SFJrteeESzd86Z9FErRwAaqWojWo5hqYq+PYXg9qXHWQgvfWeWjb OGZj6fwewXmd/2hnIO1omj04o2+gGppcT51SXJ4+Bb12mIr6+iTBoigiko/lk/YQzu+wd+a7jUFo ErsyaNdvNfriNo+ImBSYDzJFoBc7U3QGDZgyCAc4NZeA0hXeneQBLGhvnCx3vGtwu+opEh7nJPhx NwFc4vSKCh5cR809hKdUzxa16MFf4H9XkEYcZinWe5glKFybUDLWNMtPDH8k++v9DnUOTLuG3I1H 7fyx5gSaPqK1LlauRO/mBuf74EHshd24Y+8Z2C1Lf/0dgm5Oot5milOOMeHRWGNqgHBpTF3YtU10 7too+Q959YQ++DEdBblu6a0pUIhDpSgdNAVqL12QS3T8raGd94tof1TRHsh773jnGJlkmWekrodZ SRbrpH7bNQ8nYq+gs2GM8KFmUsmOrNaDGVsC0PW6Sm18PAI4dkrBhakn6jv1DCTw8szUM8Ru6olu 8Rs/ZJHERPZlUeQ8WHTTes+x6ADh6alnmdtN4if19fjh+f7AwvUh1vOsOyQSXFKqiBzEEqb4BaAm dyNOJ7JAlW+Vgd73oLba87cVvIEVSGIm+lYg6DpI6E+HRqlADsKlZP3xuVqvdf6IigSy8uflDoMr ARuZDWwwFIDqnhZAH1hWiT7t8f8uHy+h9PcuTIKFIGtipC6/gXDU5b+zaeYafDfXe8wqtMhKP2q1 6aYq0TyHbqe2k1leID0FY9BsP+2OC+dzNIU237hjqCpNoYNrBgEnJ2IhJzgcqs0SS961vHduEOlu +6/xKqkkOOqpgSD5PJSD3H3QytQeQCdT7+zMJwrkzh3Z5ofAt9YfDJQVQsO+8wyAzQRXfKR5xgHC IQKfYPlv3DG+P/f86Pqsbe4cBNgo5AbR2s78kXYznnas2GZVMnPnB1Vh5lWC5ll+IPR4rYAkYacV mAGUxOQtwenELIygj1PkhkOEVsxCPCFKCuZBdGL2z/e5XaH/ZvkMVHg15oo57f2MA+eCCiHHKj2E 0y5HfkH3TssPFIAXepf+rX50nmGW+VYn1/PuOZ+Uigo60CIIcQFjjEy6gKrjZ6JPq1bQOyOy4//P cjA4rjHu8YqQDZuStDgoO47V11b497kCn79E/wFzsEzBHBw72OCqJwd6DvWkQ6TEOQ8dXe+he2eC nk5GLk+rvPfB+PbycWqgaXcs8kcBbdYjdFZ+RpdXm/LPEalHGetPPckJU4KOxTzanSk0jNPFyrgj i63r4twMCF75HvLth9fFc29YDpbVPGwS7T3hr29ej1kiaNRbMAnj0LTIaCzBpFFHjD4Y5+KgNXcW OF3V9bM+hffCWRrwGVla//3z0q4Rrx9SWGe5maDfjx5BKiy0xkjDd0+OrEH5obMOhzpAyjsOcFoV jy2xv/Ng/JRglWbbnWcFt5SauLTf3fnV4TOFz/0Ofo28zP14osxgmajI1sbFZeHazBJ6uZN1KUYE oWLwumTn4ZmZnc8hCWk5oq2lSvUeEBHXNVA2mjLtIJzvFu+XztM1dbtFrN1houur/XmyhujEdS9S ZFUe74+RR9ywjMi+GzaE9poLMtZ410G4PAmBTel3Y+r6tkNMNnn23XcHzfDsMGPTzWOxY8ap/xCC gwtUgozmBNnlIUTZppVTtXqY6BVvzEBEvHcgWEQUU2q0QET84gAWamFRrc1sr/PH+8s97Kq3TgbB JdeDzz2V3LTkdOjKMaNKDpU/1n12sC3YVz1hGgyctQIK2TnmBJ8YHc9aP/0faGa0aAplbmRzdHJl YW0KZW5kb2JqCjU4IDAgb2JqCjI0ODAKZW5kb2JqCjU1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgNDUgMCBSIC9SZXNvdXJjZXMgNTcgMCBSIC9Db250ZW50cyA1NiAwIFIgL01lZGlhQm94 ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjU3IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4 dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAg UiA+PiAvRm9udCA8PCAvRjEuMCA2IDAgUiAvRjIuMCA3IDAgUiA+PiA+PgplbmRvYmoKNjAgMCBv YmoKPDwgL0xlbmd0aCA2MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjazVrZ jts4Fn3XV/Bt0kCVihRFLQUMprNNTz2kkaUGjUHSD7RM20xJoiPK5Xi+fu6lvMiSK7FLAnoCJHYk WTo8dzv3Ut/IB/KNxAFJAj/gIkgZCaOERDz24yiMGakU+YOU5OY3y8jckpvX8JlZwojN8GdxQH1K aZp4+LPr7e8igb+bHd07Yky07s3TYH/v7T0p3vMboe7JVKQehUPX+/+6xzEu/CThnGQFeXVPGCfu IvgUJAkpJ/cFufln4FNAeD8jL97Jyi5knpO3q4ksH+wt+cW7/0re3gM2RC4ET8MoCsj90aPJGY8O CPXw0QGgoH7CRRq2ILA9hNeLSttay5LcknqhyLrSda3LOcngkCnzDZGzmcpqdzI3mcxJZVZ4RQvq M/AdUxME3s+pIW1qQhHiX3bi0d7PqSF9aoKgS80HoOQ/ZkUW8lGRqcr0VE1JbUghH5Sjw+p5CRCR rVllCndsYWxNrg9f19ISq3JgEC/Dwx0TR2kUsTAeZGKkkEdd/EtZLwCKnpENrCIDOArhm0dVVbAW AKPtlYO0lNmDAqwa+J4oMjeIFazcnKzMI1xeubusZVlfkQmccveUZWlqokq7qnoLC4DTJAkHL0zQ 7sLqhWygZaaqlF2acqrKuuEbjWOJuwJWrDM1ppvGYddNp/CkXFW/fpWTiap8U827jipYxDkLee/h 3jk87Bw1pD5Lk5g7ED1H/fu9LsinhVrKakq+vFhrMLzjBuLWLlXjomhuUuuibaib96rK1LJeYVhr wMdCH9JsuH004w2+iPCYbVNuJAIfjsQO5c1dwbw3Bu+0S5O+wER581HlstaP6rXJTQUPrSud4SOu kROWwip42M1r56RUtuWEkYAmPhoFikKHjwf539VGtmwCIWzJV/BqDGCkIQP/8Fs0tHP8s9zEa7mJ YJRcmM0CDo6SNsnMuzRW+slsjwA48RoE6CG35K4EN9FF5KJHldMmZoAQCBv0EYRoZu4sJjyrTWl9 cgfHC7wQuCsfyC78IOThl52opwA2ZIOjXgQ9L7cGXLdQsrQIMTNFsSp1Jvd5tVT12lQPFpBbDWmB zExF6krOvnAeHaNMgzANkoANQsl5cBJnBsTOwdVU5ZCZI65bZoeHe0OykQjbesI7x81EEmF0/3jZ 3vluFv5QTryE2gBeQuQSSojMFugtuiS1qgpnQrBNafFqU46YpEV0sZYAzZeCSAzG0hIiCn7Eyx1U WrPKp1hqlbQaKAIvycwS1Bdm7lzNZbZx7mJ31XtqCFZayFvlXBE5nYKDW9WJPoYFFyw8OPjinpaY rpw3S4BZlihmwGbkKZtdLI1FKi6VxkHM4iAM+FjSeA/hWP/dQ+xOlFzVG/TYSoE81jUQgX4Mp1AK g/m03SVFdHELNG1P1Av4Ml+Q9UKD/7ekVi9xJmkUiiROh9ouomlfB1oLxrsi1hANPuR8rxG1lVku XU3cA5PlZi03I8ZjFCSXiSanECijiaARGuVi1zopmwDGMS8eyKa3lX44PLgjYRAHg8IcpTR+RsZs CZUEnx/2CgVjt0KQl++OEXiDdMgR8xG7NBMKwRj2VWNlQoDQXTVyfks+GegrlF0VcgItJnglKjQI s4XBANu4hNjkuoNvjumUCb2UGhpD6UypCIcJ+RY3CT3FDSSdP7AKvL8D6S4zheRAtgC2auAly5Ws IJ0Y1583jeWWonrhN79EhUeifTIqoOGbdrJNGMSQ5CkbnG3SnldvBQ9WLx/S5y4hFvo7oNhJgT21 3mBTwtl97fDO9PKUpZGI+Fg6aA/hiXpfNrbY66D9cGA/Y7Gr+VzZMT085pePVBgPIf6jsYIfIHRp uV+YAgL9d1nVqk1NJq060CLLpiSp6Xwv63cKyNUtECEoHLHpP/brKAloHEaDFRDcowtdl9BPFBKV jw/pC3oR7KWx8KtNMznZz4XWlQGJsGugmj4EDjdq2JRjjiTiSFxqZh5wVKij5XiA0OXqN2VmMzDv v7Y9oiRWF8scLPpd4qdP3uNs6qWztPv6isgK7YpnawURMdWzGfy6dEnEuULdnTBBO8NpEITP0oDe biVIYtzTTDuvw3mXxWp0/xb/bWA3kBp97vxxZlbOZdt9sRzTymlyuZUjYCcczchp8pSRJZlUSj6g JG7ouXJmReaQshVEdmNiR1tDTmnaw9NCYa3XtsDrO7I44jwGtT80oBPWy0VAX6W2VbLE+a0cuatJ OOt2NXZS6eJY9x41cDTlsXjeWtGwzmawwiRNwtbzD2uu9HxRP73Ecyrg8RLFmaMurzXwpmGMs5Nh q9x7ZtKfD+88899lriElrzEuX1VYjK3U0yuyVvBlTdxAqZl2WTfmXhorczti3II+ekbcQseSpmMF LkDo0vMZ06xrTyeyho9NE8B/npiHHjohQBbTmEIzdQEpXr8XYgKHtmC184a2uZrVJ0e253dnT42R vVZ3ltJeqLDgllLy/l2nMR1zdJ0y8X82uk55eOnomnPKmSsPF48zTzpsA8HrDmLuZu0h73aI0dQQ rM3XqKug5rgxzdQ0M2HpOqfJpplz4DFdXxFQY5UEMZHrQrvh8bCAPywC+Qu3hbqlG1v5dpBpophc vPkUsTiAijLQOIcpSgPCe3Lz6YfDlCdTyIXB06SQNOEDU8iooZM6kXLhrk8E3cq23g/f9Tkg6O36 zFot52H6h8PcPG+GuRg2y0q5rZLjsQfk15gGnHlDQoPHaQtlN0S+q2YfetcsQDXKDzs3bThMwJ8g HDYVFDQ8Rdl2Kni8fdMxWBJGYZo+owK2swQUm153+W2l3EYIQRZ8crcdKIOmtm5jYNdDfvz4G/nH jwv1ExXqwjrtKlRK+y38X1uhUirYxRUq4mFIBR+pQm0heE+Ne7A3lBOd62bPoDfIuN69OkHm+tGN 92YrAJ+Zsq5M7uP2UIEy/TDuOG6JeAAhQBM+sCVKab9vR6wOzKNWa2jjLGmkNFoYpfOJSXXL8WIe hTx5Vq/GvIPjCed4SU+Qfc2zKP1qFuVf5nuMXr6xD50zFXQsdbSF8DN1BEQ07/BAP+32rEDuYLeD +/fzq+6lVm7c4Z1bruy2Le5u7UN7GgZDd6hSxnozY9BuV8evJKBd3StWqnalyVirJ3kz5h6xQ0sZ JL+OSVWuTe3jnP3XeSF17kO71Jsg8zDlae8Fggt3pwT1gyCh3MHo1qHPzgT4+tgbsyaf6kop9zKP e1Hjz7N7eMDg/YQCcb5w8baiANpKUIVsiFz22l4temXm8x2Z6mn5t5qsyqmqbC13E7be2r0B5o87 1cQ7742uACIhHrZ9sBfVBxCH1d9tX7VB07s3CF2IghywtZLT/VZ07eLWVZdG19UKjNa8d+iGkYfw 13V/uCZ4EEP/PDyi+938lxdoL+y7Tgi5phmgcTgofJLw5JOzXeOHvtOsHvcaoAvcaeAvv4yYQAIa XrzPAsJfCMZHGvEghC4Jb3RpsCw452lcaStFoBE2Fh3CvRi6Vs2c1irrtipAeUMFbcTLFfpMo0Qm CosCKAP8TbcqQMWnfOhOIuTS5JQaaYbsLec+vHVht29VuJIAzn3A9eF/VPxmCQplbmRzdHJlYW0K ZW5kb2JqCjYyIDAgb2JqCjI2NzMKZW5kb2JqCjU5IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJl bnQgNDUgMCBSIC9SZXNvdXJjZXMgNjEgMCBSIC9Db250ZW50cyA2MCAwIFIgL01lZGlhQm94Clsw IDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjYxIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAv SW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEKNSAwIFIgPj4gL0V4 dEdTdGF0ZSA8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA2IDAgUiAvRjIuMCA3IDAg Ugo+PiAvWE9iamVjdCA8PCAvSW0xIDkgMCBSID4+ID4+CmVuZG9iago2NCAwIG9iago8PCAvTGVu Z3RoIDY2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNq9Wk1z4kgSvetX5J52 J8KW60P11Zfp3hnPhCO2N3p6iJjDxh4ElI1sSUWrhGn212+WhDHYQFtQ3RdjGyG9ynr58mUWX+AP +AKKgdJpRqnKOGRSg8xoKrRmEhoLf0ENV797Cncern7B14kHCn7SfYyR7gOX609wneAnbo/elajN Xdd3I+FuX4CkSmaKCIP/IHC5+TMJd1KKp/gnTCr45wgo76/BVwGGcQWjCq5+YylBaKNb+MfHvPGz vCzhejHO6wf/Dn6C0X1yPUJoJCVEisxoxQ2Mjj0Z9jyZrZ/MEspJqrkw2RYCukHwa1E7eAejWd5C ZfPaQ+Vw3ZWdzPK68JUPgKAHlAxGsbt+STfrT/qnF+V90frJ7P1dlRdlOnFVH4H+gZddCCjLlDHy eAiSYyFAHColkhmzBYJvQnAD7ayoH/Cn8xaWMwdTV/+9xe2vbDW2DVSLsi0k5IEzrpnYKbQO3y2L RwtFm8JPyRPiq08W35+3i7yEpkC8NEsFM9kaC+U9XgmZIN0bDKTWCFpqEWBf3VQ0+dWFO322Zd7i E35xpWuKyrZNMQn3JG/nQrJ3FzR9Gwthw0JijFKGUZqcTkPYpqHGO+3S8D/20dZwAw+1W8LKLS7w 9ypfQe3azf8aeHTFxMLf/rsFD6ORnMFJTshWNJJvRSMwklJBDZfmPEJugrFB8EzIsvha5O/g4wp8 O13YuvUwcYtyGkhZ5Q+BdDCzjd3i3ZNEpSKIVAeTcSINqthgutA1TApMcwRI5UvRoOwdEfDp43Ng djTyXKHgnL8Uim9uitAkI1zG2pQnBK825cOn0ZZEw5kLFQwfk7w1F9d6SLXQksdaaQdh30r/ChRD KbQ+LBo8ku7no4wj+GCqOWFnUQ7TAbNLv6Tc2Na1e3+fj1GQ068+wxCldQmz3MO9K+qgybMC8wTr WLoHZUfLE3Yr2d4trYYoZxcSnkmhOQZ6sEzt360OQrJnt25QJPIaXDnFguUL3+KLu4V/3fz5aVct dyOQDOJrRuQbIpDsqiUROjPiJAeTvArABsFruiJXi04iu3rRBkPz+fPvsESGtDMLWF8WXf3uiPIM 8twczphIhrJC4p0VM3z4duxlBUI4rFZ9BrdLB/O8aWMuPMuGLpwywoUi2Z4nJ6esO8sOrHuKCdAU 40WLS6/y+byo76CocfMr9FSujhgEyQcHQQpDjTaxgiAPlSpkfY12FvNg6oJ/Ci/Lop2hfYgYAM1e BmDqlhh9a9snuZ47lKMydc3dS2fJMyKyTL80KckQeWQkSynXUnVgXtYNdOqTMm+K2xVUK5g39rFw i+CnqgqNFVyGKGGZw9IRrGZer9DYXy6bou0p00lHbTF9mocUtrQtoGdSUo016zRXnATwIYLmlb8K D8VmpAVvSzsJyj6dNtZ7ZHMvYBaTefJgA/68Xpe+/lpkNxQVvtv69XW44Z0Y4iUtmsd6dxlnbr+g J6gfk4YZIiOpH0I4kACjGbIQ2tUc44a1sHZTG1H/BB+sfwQJSjkTLNbS+SEB9C3yIm+m0DgUwcZf dGRY/xGC0bppvjpu56SUTJ9n5hCuEYK85HfIx0VVvKdsrRCYYZ2VK+1t+/2NnAjN28CdU0Ji15fJ SEauh7DPyKHmoFDm9Z1dS1MYO2xvXpfMixp9XrfJfbhqu/w+BU5oPbjACWwquJKRChwiOFzgVqiT 5bSLz3et85KoM8qcxK5GEE4jlTlJXo3xZm5pH21z0bMh1I7Lce6xK3quCpj0z2UELxq7QKJulhXC 5zEF8ZKdCoetJvbUoRk7q8JJRl8pQFm6ZT4u7Ram+WJcFn6GkMar3br7jbZTK2VUps9TKp4GpK8H pLYsXJuWNm+eh5Q/UKukkHBCeyE59oqRtKqHkOxPQLgZffYbjVr4p/IS4rKdidEmdlKJoRM7og0V TGexpkMbCPuaUL8YV0XbIotzmDY5cuTJst1cj36Dqc2nZVHbiNJkhvsQFQa6iqlIPkSaQz4EW7C+ D5naFnUoCJKrgt32C8z45ayYzDCZHi2MLV4Uzhzu7DRebBTlwz1aOPzRWazmHCEcmu9iwQrp0vUg vi/0oY5PsUeZHB/ukowTozU152geNSponmLmpebdL/JqbtMJ2o//ubfK3lqLGd5PnHBgRdfjnjAC DKgy8WbX+KMGgHjdYC3WWLNJWFEcLe4hHNBi5JBvw+kddrZFs98RvZzYJ2cdGcA2qZLNkYHSZM+R ASVHjgyGW6PdRDdq8GQSPaoy/Bxvs70xTwD2zNFD833bTWA6qeuOE+dlvz8oAPHkTlM5vBvPFNNC xpI7TQ8NaJcW5o2bhzPWvF5Nct/2x6j5JAwobBUxDHzwUIISjk2LjtWz4MuBKHTL/fAn+Fk40esJ 4WLaAS2Gj2W50VJk0RYvDrkBTAQ00j7i+FGrQQW+IzwhVBkiYq1W8QPfqfiAEhySvrFfFijHXae1 2GL/zxHDYNjwWbxEC7H3HPGkMJhD54jHpO8CVjFHcobSwfpnqNKC7ekeT9M/Q+k37F5rEc2mc+rm 80+FGut2U4TTmo4oEePCyXBBpDrTIpYmIIKDQ9oNG8IBxcRhDFx5AaPr4w6Yc2OY0ud9v4EGaNmr +XtVojw39mmw45q7H9jxY789vOM3lAlsCSK5zB7C3mPmGuWsXTT1bu+PwfFFFRIbf8MS74txaeN9 c8zobPAXQsIXx7SikVr+DYK9/L1zeblp89tFXdvyedbuoSrqosIr+vbWd0c2vs1X65hFy3NKMC1O SHSmOI10JttBODyuhXGTF3XPmfXhWmwTjAgYGz4QyQS2aiTSwUyH4UAUroMBxMTpFAWdXyf6q449 nTcMvOkGo/PG3hZfY8Yloycc2OvMSBqNHNmh6vhvt1MFVxdPebQ+6FxPqXu2xAyKHFwaCVq+DFfF o5FFkiMp0y85EGSZN1O/dfqL9ikfo5Y01s9djW91p/v5biBhjNdutb5//B/sfv4ECmVuZHN0cmVh bQplbmRvYmoKNjYgMCBvYmoKMjIyOQplbmRvYmoKNjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh cmVudCA0NSAwIFIgL1Jlc291cmNlcyA2NSAwIFIgL0NvbnRlbnRzIDY0IDAgUiAvTWVkaWFCb3gK WzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKNjUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMQo1IDAgUiA+PiAv RXh0R1N0YXRlIDw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMy4wIDggMCBSIC9GMS4wIDYg MCBSCi9GMi4wIDcgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEgOSAwIFIgPj4gPj4KZW5kb2JqCjY4 IDAgb2JqCjw8IC9MZW5ndGggNzAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 2r1aXXPbNhZ956/A9GWbmYTGN8Ds7GzaNJt6ppnJh2f60OQBkiAJNkUq/Kjj/vq9AGWZpkzHlNBm nJEsi+TBwcW5517gK/qAviJF4SelGSdUIy41klylCgutUGXR76hAZ29rglY1OnsNr/MaEVTPu8tw uOBFd4XEIoErlo/eVYn9XXd3w/5uL3CKsSJcEE0VupijrwlOFVyDRQbfwP4Lt7/CrTUnIqVMcDTf oJ8vEKHdl+BVIAJ3Euhig87+x1KMSHKxRD82JWrWFp1ffHyGLi7RmwtAuUeQCo/BQ+CKacEVDxDQ GITkIQhkB4EgSgKIjHQgiAeBPIiZaT4zpu4QhGFLrhWDgSePPhN955lMDp6ZdM90ry7NbGartKxW aG1qdFm6wi6ADVej+do06QOEBDoGHCRPwMN2eFiYBkJwh4buGXhnqnpt8hy9aWemuKpfomdJnwzC KGMcbj2dCwiBpAsBwnCqmch4HwPbY8jdN2dedgT4n2KZt7aYAyezmxAkq9LkqFyijblyxeo2blDt Ntvc3uHFR4AcEESz5PsE3YsWgjPu4+vw0cmTl8g9fmg2ws85ujZFg5bWLmZmfoXKoqPMsxOVBK6n koC5EIpmD9CQTFCKezRwPULD7xaty62FsZvGhwKol4H/RekXT7GyNQJpKf0fkP3m6sZHTFW2ja3q qCxJNTlUGAM9y7J4sSLVCEk/5c26bFdrVLfz9Z6YjVutGzSzqNw2rixM/u+ojGg5ffEwSTnh8RjR coQR+814tejFwCDbBDyUYZlhNYGL5FD5NQMkFNNhtiH0JayQ9+/G9D05dQYoyfb6njxx5TKhMSxd ekSCfXgK9iAOp2Cxsmhb2aX7BsEYFm27mUVel5RNVy9GwBYpRqKpF4AY4eDtx5+QWSwqW9c7DnLb xNYmKumQgwXIZW6rnvfosxBcj2CaK61OI4HjlGRgnzoUwxXw+UdXhPRd525hn4NoNyh3MHyYnZue 8zh7b6u53TYt5P3KARzCUxG8a3gSYR0ciajKPBLImUJy/6EUHtTZ+YYkv5T+Th9tbhr3p31d5mXl Nrap3NzfEx+xxgcsazp0U7NXs6qd2xcUHG/6l61yU61Mfo/tpGNbZRpnisjjfFXHdkIxSQlRsOB6 aPps75KAZxz4Nt5DVXbRzm9dlM+L4b2Z5dbnTSr9AgVPLHvx2NnwDAZ1mg0UmD4G14sC2Jm6qXy2 8vHQj0/KJRVS0OQEwrppy+TQkpvt1pociPj8rPfMaWNNDgOEETEMEJdfuqaer1+tNsbl6bzcHIiR JhKqLu8uThgoYSrFkmZZByMZiBEYaYgIsAKuMNUNMsWii4suBvYancK/ISHJCbrEWNYjJHmaLnFG KdeZOi1B9XRpj6K/Um6sWaNZ20BFli/9OoHlsQn6bPLKmgUUIsBZ4SuSRVHDwgHlqm31Jyj3MbrF qUw1QBWwKESqNYWF90/pFuQoNDVDglPTAqyRODEq71IkvCSDWfijLqvq5jkUgJARqnbbfHnyakye EHxKP23YyZ09pUpQ/qBhf9Kgk4NBqzFf8Menxm63nS5XnXN3EEbepiPy5Z8yrQxQHppWiv9O08oJ mWxaNdaaYBXPtO5BHFbdy12RCanJoCWodluBc/HZc+PzRgUGzlQgCWYGydSL6rIqN+HvP799D9ms XS5jejvO8PQqi1DJebwqCzCMFedrW/S5qW2xqMMHhb0OH/oQd8WyrDZdcN/1AZ978mrbeJ79t+83 ojBAlAqm/ajVmPQdAOdiCP/i4jcEmEJD5XHRSabNluRTOm5+nB6fzHz7I1LHbY+hp7Se8qbJu6C+ nRb4oLPkxndY0Lxsi+ZL1NjVbErsejYE3DuTD5anR8YuCN2AjQ/oJfqltHU/cCvbtFWBPLJ+tP43 Jh3gh4d0NGVxQwzY9o19xBIRJYTvUR/REO6RonEqKZakQ3KflARI+Q96kzuIht9A3462xfDQZDhs Sib7D7glZDkaz34AiGS0v2jqut3cdRhDs9mvlHrXcvbvtmVdO6ia7hxDhIDg07WdaBD3eO1ngDAi 7Z9KdG1RWUBh5lUd3kVtvQuRTdUGqijHmYinDUIcVAZv8rAGQlgU1m/TlCgvyysUQgOCAly6raIS oaY3sLSCvKgFj9bAEqNGFfzQTdn6NOGgXOw5Iv/pZVs3Po9em2qBtmZ+ZZvbBN/palSisskdeJhh LBn4oXhEZaMt+Bqdo9q4BZpZoAQY8gbDl9ZQ3FhPT7PuWNu2PuXmZbGCxANOJCZJkkxvyguhsOIy 2rKSZKwp/2lf49Cog2Zi8qApVRLreGNmYmTMF7ttzs7k7pYP2pQL+2iVh2kG7hcS/2llnm9IeHji YC/82gBBi+HmdG6XTX9rOnnS1vSTpiy5N2UKo+mbR0pT6V1QEsUTdBiSB+bsh3cOhm/zHwInRRka p6Fn2rXKQgetDkJXoJAVXHEV5rbuyFt4e+mt9ar07Y1yuMsO5oZkSpzWXvVD0AdhFzbQ83LmW1L9 du+4pZt+sEDhyWUOA+fCdSajlTl7DHchXe9ry24Croryeljindy/UJRN7V8QX9dkSkVrX+wxHETu r37EJQw/MLEwjbnNzxAIMTVX8YNiZmkqV5j53D3c7e62QSgH50JPq2R4lrIME97BGFYyH0sQNMiw 9VU4ZWMh05rFi3qbuyashq+trUMO2u1NjR1JSo7vtx0cD0q6fpsS+qF+22ObxEc4l8FEKTH1EBCU X5DPeLxDQEqNZced0P6rhqd/vA3VrjK/85OuAUW1S9Pmzd/gK1XGp3fYOCVQh0WzD+q2Efsdgt51 3Yqmct25l6WDRGR83wKqkgJKk7Dh3LRFYfPbfeeYXGnCJnOVScpoxG4kYBi1WkHyIGkXizyy3mlG p5//IZywLF6UAIaRkQehvx12d37OhQDZuMJt3F/71ZSX/iBCVGIEmVyWScnhMsmilWVajPXz6e7w U2Cja+2FfkZcDdEKTyeBKSqzmCSo8aOWFqSigmIdosKa2kUevc6mtzAoJUxHXBt67BhS6F6BRp6/ fvce0og/IdjVoG1RWQPq6n39BoTSrOy97YnrNWjvXU5yzTBNwpNVd3LxxB2KDB/I/y7t7dLdnrsP /wef5wIDCmVuZHN0cmVhbQplbmRvYmoKNzAgMCBvYmoKMjM0NAplbmRvYmoKNjcgMCBvYmoKPDwg L1R5cGUgL1BhZ2UgL1BhcmVudCA3MSAwIFIgL1Jlc291cmNlcyA2OSAwIFIgL0NvbnRlbnRzIDY4 IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKNjkgMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwg L0NzMQo1IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMy4w IDggMCBSIC9GMS4wIDYgMCBSCi9GMi4wIDcgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEgOSAwIFIg Pj4gPj4KZW5kb2JqCjczIDAgb2JqCjw8IC9MZW5ndGggNzUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp42q1abW/bOBL+rl/Bb7cLNA7fJQU4oHu93iEf9tB2DSwOKHCgZdpiIoku KdV1f/0NJVuxpXRrWy5QJLEk8uHMMzPPjPwFfURfUExRLGZM0BQLxGWCJOczyWOcIqfRn6hC9//2 BK09un8HPzOPCPJZ+xjF7QN3+ye4jOCJ1cmqDGN+tKpM437V/Wo4rPYF4VkcNhUpfIDRXf9nBCul WNJZyglHWYn+MUeEdTfBT4EITilD8xLd/4vOMICbr9Avvyvnc1UU6H2zUNWzf0C/ovlT9H4O4GBt THCcciY4mv/V3ui1vWm4KbqDn4ThWcJEyo8xsB5DYb4Z9YDqXCOvM1stkfK+KbVHCm01YHuu7LZC pdpsTLVGarl02vsZmsMD7+ef0NKWynTXtUO/RvMn1OPHHAsBCMU1B4g649HOeCwZAve6WgaQANWr tUa1bQ/xOP/0N7+HE6wJaKKPsNLlCAbuEzEgiH7uvqPjx0lKEg7Lzy/mDkWH45/4rwXxmv+CO7xt XKYPrqi0BvuAVZ613iBTrawrVW1shdTCNjXKGud0VRc7tFKm0EuwHjjYv3iwp/5MBPK3J5JwJEoo ucCc0f5EZH8igihJw1niPRdJfxZTPJnaZ/nbNXCqmGW2RLnyqNCrOqDzKMtVPTvlGKEMyxTHVzgY EEV7RAkLiJJ0iIjQB4bRh98HjiXwDzMx3DQ6b9ODGSgHy8JCeGSIzG/ePqnFQruZdeufGwE2ialI E3mNFaIDIAK5sAVERnb4r20OCHQLAC12qLDrdcgJgU3WoYUOfyyNhyxS6azWyyHKhBEOVqaTUFJB O5RMDFF+0k/WVAFFC9FZW35mhAycx3nMUtgquooxPYdZwCBIjyHap6WFM+XQeQFWF2EH951CwjHs KXHSxVV0JSaStphkPMSUQcTf3dXfzd0dILoUHGRwlsRMTrMXTgK2hA2x7azPV82TuRhVymOSJBMN xgOoNB2CetbGZLn5n89NqS5AdnUuIGnakpqQEakL7Quj74yuV2+hQNfObvJZpesfYDmNOCETliR0 Yl5I4w4cI0Nwa5OnGB8stPHrPmn/DBlorBTK+rS0DeoPYPF4CCtXVd0U53muk1ttYohZIkAgoiuJ HnWJoTWVHOX0hao/MxYPaCw5hJYgybRKwuTre54RVQO+JHHC0pRMy9CkdUs8qiLV2Ykx2uNhjEtB GJqQeiKKSUffdBRbPteb88h7CiuB3XiC04m4unJLySislmUpCRvIoB/nnWivNkEEpGIyqACJjkJK ObNqSvOW0L29fpyCTm1FZSzplZTqYYVMD7D4OKreLlyT6TsK5599165Qbq2Ks/nOYwmamqfT8mMS yggVI757VVvXzEB2++aklDxtzszeRCYimRiNOCQHGo/IvwKXVirLzE95dooK9iQJwxNVHMYBVTqi /kJXlT3Y6Zvn0F/NquLMkpIA/elEYAS3UcnwKATKJ3uUv2aqOc+JREKFmip6SacPGB1FwNPaX1Dn uvYFtBNnnE4rdDjpILER75/V92anLkXFEkkSEMGTUMEKHSox4vvSbn3ttK77jG99rc/PFSCBOUsm 875L+iweMf+pyGT6ZPPq0qItIYEBM6YC66okSP2RAg0jhuuMdrvuHDrHEfUJeRAY/XbUnZ+M6/AV oupk6EM4xWfM7PoTt+EuWMqlpNfN7KLRzOcFw8u53+XO+NqoCnWDu60zdd22vfCRrYodUqsVdODt xcJmqoBeuAl3HGGdOhEjnKXRWQPNF+NwwcP/1wpadM5Ac2yccfL5CEYJ44pcfdVoqTOzDPy0qFTP uhtzmnUFGIO9Vg5qXvgsB1aju5dft0BtrwuwYbgtfDzwskylbBuPCV5ujShGrN6oOgcsZoV2cIwM 8LTDTftVOweHaWPtTYtpo7JnUGFbAxZfaLS2h2lMe9HZr3C7a1fZQkP0Bi3gUrumghpbI135xo1O RhNOk4RPP5kcJZI6TGXaCZJ1TvuNrZa6qjuLB/d41N4BRzaZvilVUzKk6hK2KrQbMhSqNWOEs0kj W4lnjDAex93WI4b+fW5K9Af0Hsot0edftgYc3poEQtZvdMfNNqXWpjx20P0H7TK9qZsQ0QYAEj4T FEB0exPWAZSIBRUDjT9D0BOEtx5gCIB5/1iS6J82rPRJF6o2X/U7W1gHu9TOZGFNfMVo99TY4tDP nJ8XoErA2iS68j3HKC0AhGhg9GDyB/RYgd1NKVsW6mrZcc+EFwbP7esNwGhX7dWQOryxlZ+hR/i8 DDeGEfkzOtAYYgeeHIQPBrQB39TwEXTcrVogQ6lV5QNGkOtlU5lM9SkKOrKtdc8eoHsD8YVW1qHa qdVnxuQpzJTylCaUTILJGH0daAamXYMu0K6FZk+sfeR52D2aFNeC855q0XlUE4kMEXOrVzIvEF4v z79BogWmILWBfKyyPDDGVKjWrmy9CO6pfLjbVrdMeEKyS2uzZGEg92qfcl1tFuN51LFlHqFw2aZY hsqllTdgJGBKZjegZ0JCLPRaZbuWMv5QDJcWhcIFQrNa68O7SD2IQRLqFzh5egjGowq2bFpKK7R/ xxHchn7ktsv1pkjlpXqTxiSmnLKb6c0ew6mkCi8YF1o19S7Q1mnQnKYGUwQyw6WgL8GDxh+yY+B5 eD27v1Dn8Ms6R9vcQBAciZdRBk1SyUUSp5PdJwkeSyvvwX9vkLfIAI9a/nVC0dnNpm1kemSq2m3V 7pZRKWl6hgzp3ggRnAhoncTNhAhsPhYi7515fpnXvfLG97oGLhrMp9sGDtz6WgMn/rqBm1Yg2kbs wgIhQq/Jxc0qRI/h5dzB7A/oDwsiXfumVAto2Uw3ToUIy22IrV2bDrtM98LKm9IxIZcWCRxD8Uzx K19Jia6UajIhr1kHMs6foQp8eARFrDIdzAOpAuxVg2WyQisHucS2HW/XqO2NVOez7smg85DsM1EJ /dNykGo4jUUsMZmeasavFvaqJ5Sv8GWZQzoszTeAcVADN/yCComD6Dz/CyrdO1SSyrZM34jqHYYf l/yqc0cvhvp+ux9c+Ga91v6mNI/ZxVqIQ9KENCBvpoUAw9Aw89yWEO//Ua7Wx8bJlNcvhlFVV5P0 ct0L/IMMagsXCJGgH0MffUpumVAcczldBsXj96tH3yaaQRqDtiQ0qqH26103juinLVtnw7dC9s1U 15LAx50qttVRm//x/9Mr3b8KZW5kc3RyZWFtCmVuZG9iago3NSAwIG9iagoyMzk3CmVuZG9iago3 MiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDcxIDAgUiAvUmVzb3VyY2VzIDc0IDAgUiAv Q29udGVudHMgNzMgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago3NCAwIG9i ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxCjUgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMSAxMiAwIFIgPj4gL0Zv bnQgPDwgL0YzLjAgOCAwIFIgL0YxLjAgNiAwIFIKL0YyLjAgNyAwIFIgPj4gL1hPYmplY3QgPDwg L0ltMSA5IDAgUiA+PiA+PgplbmRvYmoKNzcgMCBvYmoKPDwgL0xlbmd0aCA3OSAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjatVpZj9s4En7Xr+A+bQbodniIEhlgsTs5JtPABsjh xTxM8kBbtM20DkeS2/G/3ypKvuR20raUPMRuWRLr/OqrIr+RD+QbiTmJ1ShkLA4FCSNFopCNpFI8 IqUlf5GcPH9bMTKvyPNX8DmtCCPV1D/G9EhrTXmAj902z8VK43OzH707juPdu9t3UnznN0JHcRTG VOqAwqXb3Z/4Jh3TGB/WZJqRl2PCBPE3wacksEQUkXFGnv/BRxREHM/Is3emrBYmTcmb1cTk99UL 8lsw/krejEE4OqJUcKFkxCUZH61NnrA2JzTAtTmIQUdKSB0eysB2Mry1xWxGXpA/LWjsKmJI5bJl aon9bvBzRN6bekF+JyZPmq8viYFbpwX+Wtt0QxI3m8HTeT0i4wU8mMxr29GESiUo52DlK1RpbA2q eDMq2lUht/W6KO/J2uR1ReqCjN/g/43cjUyLooKfFuYBPF+sQJN6YWr4b6v0gbRXSNhxtNbBzx1N jh0dgX3CR5YOfu5n8oiftT7nZ0MmpTX3xOWtgW68Z9F2aLRVZVsve8M15skLCIp5Dgq4fE4yO12Y 3FUZ3n/sZhUJEVPKewUs2lCBLTsKgAFBmnoB8rh8VhaZqV2RH9ixs+jlGaoE72ZoNSld9p+vZjKx 5ago550MZVSL+Mr0RN96t4GKSqvwUIC91qWbL+rzSnbWCp6gpGTkSdEZ7LwqIxrGQvCeeu7DcyfD aXj+L0/dvSVrTM+XpTM5qYxLbsjawpc1qYrMkmKGmQuBuiyLZVGZtBoyfVVMr0hfphXm3ED5CzJ0 DfQ3Au6qtiWZmBo+Nk0ef9mrvitVI4nF6hbjkwsaaRpfYJSgFYy1gjHClUCR1EnpYPwFpeT9u70x jqolmLGnKzQVu1gNnugKQQXAn7oiTx53xU6Gvd4fIE7vfAySbemZFqs0aUESy88tKXKIYrPBYE0K hE1fcQC8JlAwIW6XeM3VN6QoSWmgYKYuczVe7BfMey28BVkcdKR3B3ByqXeCI++IE0KTgJKpLbtO iVjMASfVFQi9VyeiI8FECNTsYOmtWsGzD/8au4x8WtilKZMnA+YjawbdIJSSXIgHPOI0jmXQx3tH MShl14uo7C4Kkd20IegpjoE/0tROsUBiAC5L+1mIqBUyaCkZ4EJMuWB9giwQsT4Us5sq3211c0Cz gFVDftSlmR3I05ZSCf942M9okoY/MtqU2HzucmtLn2fHPlNhFD4K4U/HDR8u0Qn1+raylXcF2mFE 7qoWC6C2TYslMtLSu/Hjx7fk30OWMq3UxaUsEmFIpRislIEMXXu8WpQODAK1/YUn52biUldv2rqO /cMeWG/JpliRKdw7dxDZriazFUg/LfK6LFIwZk0ypEjAUesm+LstFEQVVaIvI+We1R7rgcJ6aR6c XQONrkjDYhbwDVnLMQoFfVzJKWeXlkIOL6OSDlYK9zL8sBRCns+bgldAuq9LB7UNaRsw93x+0721 Mht/eetl7D88xz92o0SqHXLd343iBKOgUjdiWeiDPJSiA/FCZWsPn0VVuQm0xEtojIbkmpzKsJug NnVFPUqtOamiUoRaaM56+TOGG0MNsN+sfsIyve3XoP/rYk0+1aUFE1RLIJrgpS+Dqh6LS7GJAgdl IWVDYRPKcGKAO5K4JP9nTVZ5YsuqNtthwbDaax48jTtJpiIOwd/L6wfcCZfuKn2HKZffe5+vzTYp oUBVtTUJpkCTyD5TPTw3ZKO24CyfMb5fO0h45//6/Ayth2x3X/N3RvT9idAsoizql9ZKee3U48pN u1EEbw2Vd30PNopOZDQ6LQme5GP8NKaobY6Mf8vSPv82ZBQxLi/NoRDIqZRssPqOMnSN8NrlBdYF H0tNZLWlHdqeosL4uCVuhj29HztVFvAV6BGQw+miJQM3GEJNZZ9YrApQaPGZbllQFCCd9S4LEIiP VfdmbHgQ7HixLLANB5RcuOmiqQkQ7IP6VV7M2yIZahULPZxfpTrj1zHGeGZNXpGsAGK/mwcOWhqZ OkFIl351dTVdHOp+2/SXPIy1jvqRd/xB+EEcLt4oL04wsoaYwPlUAW19k+aZzSa2JNkqrV3kZ+NA 6Kc2afAwbWjr6CByn7+38PuyXkEvVDqQmIUjyXXYCsNEI3FEhNIjgb/ANzVSioFwIPfzu4wFrwt8 00ebmhpWeFWkRemAZJVuiu+kV0x8ju3PKb+07aVaxzEQFDZU44tCdHu4v+0DQOoduc+hWAFrvIHv mdl4/r+9VpKHwk0t+ceX49FU0Hs6thWXBUfTMQ4R89h0TP5gOtZ3XM25kJdsKHmNmcTZiR5qQ2kv wz5RUvfdmRfk3YZUdbKy+RZAMVkyc++5ATbCQ4IFP+XRPwpWbwqpoBiKaDDA5Fs2fWKK39+PB1X2 MubcIiRTUkWnZT+4NjO31PlE27/8tCcpbIWKEyj3gw41OD+lzj9VX4QRYns4nPqan1H/DuId+tgi he4BlK9wYg/s5793n94PaQWBKHthxDMqVajlYBEPMpyLAbvtojwke1aM061121gDhK+2cy83KG0Q gl6eHPDumOvhkgOEOA8FTWrU6wKoY1kPq3yoLw4KnIjEw209owxndE8gGUo3AfIMxNG0GyA5BEG7 kzukISJ1sSEiqXETbzhDROqMISAD8qZjTgo/+IKPtasXUBkHNYKKT2YMxbryM53tlja0Y9DXtDvb x4PgkErok+NeXTKn4YgJFcWNON09GyDI09SUbrYh2QZ3KR5csUK6kGXAG6BJrPcnEGpA1Q3w6dt2 EIHj84NZ4oh0WkMeRUyx/p2hnzc93hlC44qbLID3SVJCDwtxvR3lL8303qIGzfgIB512uyHjMvi1 rtr7wO3bncEa2FF+rEjvIAj5FXjII801jQbDQxDiTCqMFxCNpN4swXZQJfMisYMiYiguRkQaKs4E l3w49cU5SPTjRVMm25nCzdGAAYcmRWI2gxpEXoyMNJYRdA3hgPEgz0EjJDVgkcnnts395szP3iY+ V45Gs4gOdv2rKkkYx5d3FtCzi3i4zgLntmcryQagCKdTYKNfXFRDHfWoJxHHcd3JqO76ehLqkzMA i2JtH2x500QFQvTtxFQ2OQBfyKk9WuNpDDwN2MxqDnZ8jg95MQV9YqR6lxLJTk71QBgVa4N7S3up lqtJ6qoFCNUOjnclbkhvSq6vIcqR0EINBgSS6/ORTe7GH6sdAKyqLSS2JwB/RYjL8HJ0VJpJPDww nFFCdb6tqlaTDHcVEmJIUppZvaMcd2/Gf5DEmiR1+aDDFRnFl5cMnATGPB7OKNE5DISGomHUia0h yTHb8ZCgq6qV3Q7p/cGAiYWbcFQ9t8mg9lHR5RxDKkVVOFzLKbfH804HcVAVMHVu20OTmFBYMBNg 29ODQPnwf3Ixe6UKZW5kc3RyZWFtCmVuZG9iago3OSAwIG9iagoyNTUxCmVuZG9iago3NiAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDcxIDAgUiAvUmVzb3VyY2VzIDc4IDAgUiAvQ29udGVu dHMgNzcgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago3OCAwIG9iago8PCAv UHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFj ZSA8PCAvQ3MxCjUgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwg L0YzLjAgOCAwIFIgL0YxLjAgNiAwIFIKL0YyLjAgNyAwIFIgPj4gL1hPYmplY3QgPDwgL0ltMSA5 IDAgUiA+PiA+PgplbmRvYmoKODEgMCBvYmoKPDwgL0xlbmd0aCA4MyAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCnjavVrbbttIEn3nV9TjBHDkvpDsbi8Gs5mJNzCQLHIRkIckDy2p ZTGhSIWXONqv3ypSN0uiEdLtBA5kS1Sz+tSpqlPV/A7v4DsoAUqPQs5VKCGMNcQhH0VaixgKBx8h g8tXJYfbEi7/wddpCRzKafM1wZovPG+/obQJ8Bvz+6vqODpclcvdqpvVGK32HdhIxaFikcE3GDzf /RngSpzJ0Iy4UjBdwt9jwEWai/A1Ai5iFsF4CZf/ESOGxo3n8McbW5QLm6ZwXU9s9q28gmcw/hpc j9E4XJsxNEQzQV986OZw7uaCLgqe4yuXbKRlZMJDI+TOiDT5mdgrqBaudFBWOW7cZVWCL0u7WiXZ LSTZPC+Wtkry7Fkw/gqNfTtgRhFBQ+ZyIVlsmOphbbCxlm+g4iC0JDsFb+3kOzu5uOIM3r4hiI5M IANY0B+jIwdJvXNQ8JCDYOcg3LFSRj684aDTPXDinq0JJ+75uLAVJHNY5zUs7A90Tp1WySptveSK cu8ZBo9GIlLBL1F1jwTDxYWO4lMsgl+j6ikWkerA4s7BqshXOfLVZuupLSuocgxYO10QjZdeoVBx XyhwRRkJHZ+5dzAMCRV3INFs+cUHKBd5nc5aYuSZ8wqAiXoDIA3m09AjAKYra2FQpA4J4HPHiod9 dtyQnzGuzNk8PWzHaMNx/nuZZDlcwQtMzJQECve9xiQ9I+rXB5Hwl1copOztfKwx6H7pDwopO5z/ UDq8gLXzmhNVJHrnRMOVjkSoveVENKIDizfttqFyaA8mQbgZvy/hjqrGtoxjVS8SV24I4xUbxfsn Sa5DrBf+aKJ4BzTjxY4VMMthmiMOeXoB42uvGBjWv2YaLiLJjD9+GNYBwk2GGaOqi2xPDouZxJZQ JkuKG/wNK2qZTFKv1NDM9KdGjN8jd3qihiaEO6lxm9sUUOA2wFR1lrkUiryuiC55CcskS5Z4xXRh s1uMHpvNUCXb9QY3r1gJPSCMMEFSsfCFldDdDQJMCptkLXOSlklPoD512F99qjDCZokJb5GERnTg cE2aCwMI605JYqvJq+uGQY0cI+5YjCLUqG6e/PSKTNxfjAqmQxN7DKa4S4z+N79XatYX22ha2ek3 12j0PWO8wqJ7S1SmlQxxW/7aFTTigcBpN00kubPFrGzea2FBpWInmFMKV67yDD+6S6oF2PtQwgSv hT1mLed5GHEt1JDhQLDdAuFn2EnV2PgKaX4gdAe0ufcdZbjpOwLhUkiJraW3CcjOhjN+Skqgn2ye 1i6boraerBsYmhKRz9En38glG2SeoAIYOaACmFBwf52H6RxB3MCdzSqYOzdr6JhnLWSEjlcQBkwf wihS6NrIWzibzunDRweLfIVSgbQ1UoFUFP7H5mwrETB4cvoA3M+krIgxGz3hFaUBgwkpWaiM8ceV zsHEi7Ra5PXtAsoaS+IWmGVyu6hg4iBf0TDRpv/yisiASQWTsQg9yifTOalwPy1li/I3TVAl42cn qNETTlAlE70nqExGmmHoCl8z1L0Rpy6Y3W5VmWtFbFYvJ37jkiKsd/aS3IQcZbyv7EVGdGDw6v0L sLMZqo1yg0Hqqso3BqfzgBmmy9QVJ4OzSKLS1upR3o/ZSHIUCaq99THtP/+x6VXKNJm5C8zUFaQJ 7hldsj4QVZdvXTF1q6rGYl8kaA4PR5FAz7R34rI1JwbB9YjR2RPIiI3wPR6TUZc3Sx68zGml9y61 VfLD/ZOneZEsXVUkU1qTDQjsI2gNP5ZQk39PinrqnguUhKP/uSK1xa1NR3lxu0M7aNFWBlthsnag mCK0A8H4iHOFMurAmkO0N5mfEEe8LQmnws3q6VY6UTFsfm+6JCyWIqao/CxlfEBCKupKGtzUQO0X bAQuEw+ZS5kANUxZFVSiiA+H/BRhLKKYJn/DAWvcxrfnbnyXGakjsCkC8fnZL2vs4zsFpwThIjwm SJJ+TapyujhtgniMLURM0RcM354aRVoaHe5uHhzmHdTMyAOs+klmsZGxTauDbGg9v0vHI/zXDUPQ OwXxUENnCrrPMilEqI16FMsOU9Du1odBsXZ2AZO6ArRhTiFBB1XtCC4tnJ1ho4FAZdRxzLISYwST VOmKHzSFGpCiZByNNsnKcHpT/7YMxWMNfQsgCjEdseao6RGBdlgB0YrgyAmfyrygqUSSYe4v6lX1 xWNvK7lWvXtbmueHZ/X4oN52b8NJ2f/0oXLtPKFaFK0wT5BFpMKBf/ldmlQweUaTiqc81cfgZr01 qWZac6b8adKdEadN9XzTQ2IRsjC3SVoXqFEOZkapswXNXCdYNimRzot82Xz+96u3WLfq+dyndBPS DJlBx2HorYkiGzqfgnCHY2fMkNlmmJa5u3PPq8B+kHVB4JWuIpzp6qNpGpoYK3S7eew4TYooPDZ/ PH69OWJIyoeTTtDPW0r+QtK5V+44C8PYnDmT7FPu7nlLnQT1p+YopUpbUm/dgm+04tvSAAWmeZ1V X7xy14i+B/cRrm3is93nQO4acYzGO7iCl7krD4m7OYsjyw7Z6vPwXkp+0oWN82wNr5NjFLiKolCr xz3HFPORieiAurnzKQh/wnWaoPdfYz7zuk3Z/+BVh1TVhLdxIRnRPS60ZVkv9wPDZnZMkfHEZ68S P+ydy7mmJ6+8hQNe1IHLh5ye48ozbLkoi3t+bAl7Sd03FwglQmYif7lAxieNwHXaxEBDi8y1T++k ef4NGmogKVCVO7/hodWAwzGsgzoK/YVHpzC9aZ/hwbKQYEt4oIDo3a91WW3PzJ76FFGGrPdAnUXY tGBv729wh0Z0TdRLuIHSJjOYOIQEESJBQe0zNjOO4KkWLWqrmkpsmme3WGhQeXgFSfSfsUeRYsrf 04BkQ1dO2fU0Yr/pd/8HyX4ByAplbmRzdHJlYW0KZW5kb2JqCjgzIDAgb2JqCjIxNjYKZW5kb2Jq CjgwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNzEgMCBSIC9SZXNvdXJjZXMgODIgMCBS IC9Db250ZW50cyA4MSAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjgyIDAg b2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9D b2xvclNwYWNlIDw8IC9DczEKNSAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR3MxIDEyIDAgUiA+PiAv Rm9udCA8PCAvRjMuMCA4IDAgUiAvRjEuMCA2IDAgUgovRjIuMCA3IDAgUiA+PiAvWE9iamVjdCA8 PCAvSW0xIDkgMCBSID4+ID4+CmVuZG9iago4NSAwIG9iago8PCAvTGVuZ3RoIDg3IDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNrFWl2P00oSffevaN0XQILQX7a7eVm4wLJzpZFg 7kj7sOxDJ+nMNOPYwe0QZn/9VnWcxLGTIYm9dwUSygyxq09VnXOq7O/kC/lOUk7SeCRirmlMZKJI IuUokSnVpLTknyQnrz95Ru48ef0e/p14woifhK9xGr7wqv6GTCL4xuypqyYq3l61vhrFq30ndJTi TWMNP6Dk1fZjBFdiVGv8QUwmc/L7LWFi/Z/g3xg+SCnJ7Zy8/jsfUQjudkaeX5vS35ssIx+XY5M/ +DfkBbn9Fn28heDg2pRxniZUkdunbk0O3ZrXt+YRE3SkRKxlMwSxDSFzP515Q27vnSfw15DcrsjM uGwJAMyLqcWICEYU0QviaEGQiC0E0VMQkB0EVKSK4/fOhn+LAdnDYBNDB4Pfrt3k3tjsN3JvPMkL UhbLyowzSxalnbmfxORT4gtS3ducIF6Zyx8CVh5+Bp+nhcXvVeSuIC6vCvIi2jsKF5TpNL4sndH6 KAHGVLWPADGRu6wYmyxE7fI7EkLfgdnOXnR+9nR6QgFvjwwnpoIxJZVOeh15L3ubGNg2hnVGyNXt zToBD3mxCvlonD3qW7kxS86vXBpDuOlglbuNoVO5/8ATF3D8gMTUVIbMinJlyikUQiMjvRs4FnHU KoGZKV1uJhP39m4OrTCaFPMmElgFqeaSacUvqMAGElKPhKZMrsPYr4Lo+U0xtmVFjH+w04BCVpjp K7/IXBW64fvS+soVOTTmplx2QW5JfhRHQPObZk00TS+AjNUxs4grgdHGrF2zjL/hMfl8fSAE1Jlu oqJzE5Woc3oVT0wVUGMs+WC9uo2hU6810T7zcPebTan6kJeFmTzYCqvZVcCodmaWWUXmZrGw5aCV rNLoJDVuNrTkjPFDZBadXsZNgFR6EkDX4fSkKh3QGyAzcyBEJicmq2yZm8qSTzfvSLXMc5sRM52W 1vshsUpocjZWOuGCo90YCCuI4ah1CZQHop1Ps4H5LuHx2ScXTDKhh6sSiOHIyQPRb44NpgPE34UC mbvczd1/tt2UFd7bYUtCynOBoUkiFWiYuIDcjiBz1M5yUiyQ7QMaLgeGmRNv8+mwHJIk4nwQRMoT PSQIR/0s0unMlb7CqrDGu4FPr/jZp1ecM6EG7A00FQcPj9lGjrx6f/0ZZAS0H4gS9X+Zl9YAu6Kv nwNRmjuLRVJ7gpdkdQ/cu9MkV7VlEu6cgg25aCqLNocIAOoO/deyV8sdeSpZ0VnJShv+9UQ/wMC3 STAEg/mB9Kh/RfC9nRSYMu+XkBYYRFcWYkMznwc8kOJqbRsFzv8YDD94zrzGq50oSeMYIox7JyoV rB04lhcG2a2gZ630RUP0WhrDNebRWb2WKg3DF1x+qPljHcQxCfbFspzYTSpya6eBfB+sXdQMvO4/ M4b5lEyWZWnzKnsM83Ow7JDghkQ1LDm53JJHbUtO1pY8TZIDllzQPUseUORMCiWwCaJLxwDCZbin ott71iMk4lYVCzcJG4extTm0AZrfZjIHngxSrc+eDFLGaZoo1quT9kppE8QO/wo4+uBEtkk/+IeE o+ZcPpARHuJQLG5nAobY2XLu3jL+zYxhkhzltgpJyeysWm93QDOqUafHeMp13WPRpUFRzIsS7OSg vhUuX/dMJ6xOtUS9iEdtev60vUfoGB1zLdRwvLONYVcs//JFWT6SV+QPwCjs5a7IuKju0elW5CrH uQiwAkXJ7STQDhBQTT0C7fESyu3fT7INjZmmXKmkH93QZBRw7BLOdDl13jy4t3Vyi/LuSHKjE6ng hORGe8nVtE0Ffly6eSOidnLjJGEpWNgLCquZXEBBaSW3MURNYN4BMAUQoZ0HBRlbGG1yOyKfMzCx QJiPCwvKmxVVkyQ/W1CfRbU0WQQV8Z0wOYIylPVdmViHlhAh1UhxEcdEJPFIS6o5Bvj6as7IhwKv dGMzUKof9n2RFQCGhbF7gtfsr+KanaXia7MJtKe0HKyZ1jHsFeIH88OChJsMdPsNuX5s7Mo82GEL xqYM7gYfDaDrgjyUud/+qOmuocuwhvd232ERnEAqNBO9d9+ay84CGK3+etINd8YQORhJ4mYEQlyZ YNRaG6SDHa/BLgnZr+EZVhvUVafdq4Dw/6/bg0ztd/u9yatlZo73O4N5FXW3X7tLPkrTWKltEHvt fvVsjrQd/H3o/Oky+Olp6bKw2Kg3titsk7H1boqD285dD+MUIezokFMMz2u6TvEXy9t+oqs1P/dh A9VUwZ/hHpNtYzj6qBBzsmWKYhY+j0sYx/zmE0xDTzt6KhTXqTxrROu2HFMaNVZSqtqpGtvcF7nf FPgC3IHN/vrek5Sn5Nw9IpMskcFz91HabUbrGKLD41tpNykFjLwbu8xVj/DZVMiiyKgszOJApRBy nd/NWN4c79Bn4QqjvTSJQWhVkvadxSWVnboEl2fzSYWZxPUJmZicTF0Jxg/Hy/Uip6MPA27CJE1Y exPWZfuOssMMmiSC91sESjpiWqViHUW7/JtajjK4EXNAgJOvz1f3BYL1rCJtCW1KOrrrg5qeKMpQ 1ftquqRdjt2kDW4anqzvPQf6+qJtQTaV+PX5Or9sIxr2p5kvMgvfgLrcHB9LuCrN7KsQSetICdSo pKzfkSQ/fKgJDiSAK6SkUwwC5EqkvZ6QBihVd7Au8H2EkNTDD9MOEbOUUvCYsZ7DjwzEzGgHijt3 rynd8rK/w+fGBwfu/xUlMy7PpmQuYeDH1cVAlLyO4RAlf3Ae5o7xElmtLm7/9D74rJeRJJPitNEv 2taownUHOKtL30aKWqPfLoZdWaxQcMJbHEF65tbkfxvwFRZQVH728iuBoRe8RTzU8msXRCfrY1ut cAn47k/byXbUQ6CYYo1jR6cJFEzLYKNj3s9SNgRqG0VjdHP5xCJXeweje5Ab8RJH++Ah1ytlIIJi mU1xD4AyFV5tql906agUDLL4i31Sl1wkWqjeMsV0h8a8mePbYcU4s/OX+G7YeuTECkZZDSrVtEq7 sx3WHw330InoJ6lw1cPRTkh4arFcgCAgjD+cqXHcE4Zd1/d2Rpyd/ZiYxZRLxdlQzwgxhiPt9mXp Jg+hcsAugt31Rbbc7D2gxMw0+I/fP30e0ixycf5D45RzJdNUDvXQGIM4gsmfBVmFkoY5wNavgwIC WK85NKmDDjNVLU2/2qbQWKVK9LQQKYYr9YHJLi827PXTS4BvlGd/qYPg3Xesfs2qUiYUDFEa9Xin d49VIYqohQ1WNBCRq6X0AAuFV1jh96uifIA5eOmBq9zDmjwnuGRdrUfC6pkPD9Fvb3YofvkvzHoW 3AplbmRzdHJlYW0KZW5kb2JqCjg3IDAgb2JqCjI0ODIKZW5kb2JqCjg0IDAgb2JqCjw8IC9UeXBl IC9QYWdlIC9QYXJlbnQgNzEgMCBSIC9SZXNvdXJjZXMgODYgMCBSIC9Db250ZW50cyA4NSAwIFIg L01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjg2IDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEK NSAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjMuMCA4IDAg UiAvRjEuMCA2IDAgUgovRjIuMCA3IDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xIDkgMCBSID4+ID4+ CmVuZG9iago4OSAwIG9iago8PCAvTGVuZ3RoIDkxIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeNq1Wm2TmzgS/s6v6MuXzVZlHIQQoFxdbZLNbtZX+zJJ5ip1tbkPMsi2MoAchOP1 /fprCYzxy8wNY/LJbxhaTz/d/XRLX+AdfIE4gMSfxD5L8F0YJRBRPgl4SChUEj5CCc/fGgILA89/ xNfUAAGT2r/FgT/xfZ8nnv3bVfM/ypn93/zg3hHntHdv6u/v3d7Tt/f8AnhxFKIt3PPxq6vuo70T IRFlE2tXWsDrG8A37iJ8ZUDCIInhpoDnPwcTH028mcPT30RlliLP4af1TJS35gV87918hp9u0Di8 t0/8kHBCKdwcPBse8OwAfM8+G3+i/iShjId9G2hnQ67+UuIF1EsJhVitVLkAWdbVFpRxX8psIWFV ybn6C2oNb9+/ApFllTRmd/3eZv8Rhh6CRP3IOwIplyZX8krJev5Sprqu9Go5KWWNYEH3YPQzDThL eBIe2eA9DCxowYopghXyqLGlAYu0tnhPDT6/hqurHThinSkNplboQ72uf+hZdD8U3gOgCNgD+IIP 9Dq++AlJ/Cjkj+MLMuaYL50NJ3x5VTbMQEdsdHULRpaZAQEGCSGzjkrIGJEjffRXlcnKPMMvFhKR q2Cj6iWo2sCt3I7KoDA8ZpCZVap4+VnMZrKa6GpxwhzOSBQTdubZ3sOZQ5Emjn/OhkPmwNMPGiaT CZIGmbNam6U08EQVK13Voqyf7PAyFrBdKDq82jf4H3T7k9yGXe9vPeBwHVHASBxSdlG6cBiy5Nj+ zsB5pQswupAb9KJ8BqLMYHrzvrXQ/dpbwGRU18bxcNfGPOTBiK6N42NofnUJ6gVMvysAyV1b3od+ CKWuYa7XiI+o4V/6j1Gh4Cd58nxy2EOREJr4gX8pFL3kwKNjKEQX6l1i+ERpfEhTxlnMwuQilgbh vXZondkErdCOdG1qZGtlDmJMuxx0bKyB2RZev70e01MhYUM85dK4T3jsB8xS7ejp3pBa1vNVSNgx Ru/gBXzEEoZCx8h0XVna4totWW14w0qrsh41fjEvDiQt3hBhCMPROIsmHOPwoyhh02Igbe4ynRIy o66e0ePVZzWuXVZ35K+WCn7CUJ+yy2QNhgvhSUwbO45lzbt//FSp2weLl7sX63WLxUuGsj6iJMDK 05DeG65eTp3tjPD66sWuE3l/jfp1XVhvW7Y3nrfcN2KLNXcKokDZkusNKhlMFmYlxS3oEmZyKb5K 0PO2jjtVPCpHOBma1lkSUM6DYLwQ4eQ4RFrUfnEFf2oXX97amCklAiTKJpkWMl2KUpliD0jXPE2Y bZ9cSxOgrOZ+PAAqrzWXtOYSCBJLZOaflGISvAh9uP5tD9FB/+Z7lzqIBWHHa+9hDsJOlcQoQx7R EJx3UGfDft1vVKnRQa9OEhj2al9lVSuDjlIl5KqU8MOYjGUhHVzekigISJCw0aobGnFHmzKtIdPS lN/VsEZYdlyt9epPnevFqJ0Hi4KhwRtidUtIEI0WvGjDHdz4oJ/BVq+x70JzXBrDzFboTM23Nte5 9FdhD4tKaVRQEjKUHySwAojR8UBJyB30uLFpXNm+NZO1UHlTEKbImfLvSJlKFrKYWX2oN2OCEvn+ cPXOCYv88ZQQ2nAHU6ZzRxTEACGwOX3hsgr8/ut7m/tlaX/e00hAKbCUmpVIJaQ6z5VRuhwVLsIH cygMkig+22Q8Ei7C7+DQ7/regufbBiV2GeqCiofxYI2gJyp+9nJWrVN5hTETT/4rq1xUC5FbKYne MZDLed2IFXRkX80f1sXHuMg7cBELYSijGWNYHK0S8B4zrDp1kbPBO8Pom6XcusT3OInrnWdlTIcu mTEa8YB5jxzPna44bovvuRXDStRL7ObqSs0wrRvX6QljdKpEjXLADeCEi+rWSm+UYOWt6B4SrFgH CWGjKaTGhnPB+kZlmN5R5jdBscEQ+bJW6a0bY2WqqrfjyqOYDBb0hGPjEifjZXq04Vzv/6rf57uM b1AWdYLRjgN2s5OdMJjAR1sf2+E3EmuxwB/HBYwOLo1BGGHsnxXYjwSM+ucA2zU+qm5E1Axl9jpd QppLUTpRiSriE6XR4biLJJiYkgvnXTS817zSlWG5gQ+vfp7eneSGb1rFIR+yaeX6Hax12PGQ0Tat Ohv26/2nXpbOIxu9zjNsa26dnP2MVHbUXEm9yiVsltplPVmmel2JheW0JbrdlUDbUeE0aeBwATRm CednpdawMXoc0WPDVwJjK11jlXb9iJ67ceOYDkuCoQ5jLGGYf5PxHJYEdzjsuvFLgfnXBcphdcSn xEFELiqP/cEw2nFcHnNMY67VuWo8b7V/CeuykrkSM0sZNM3OdypRmkI1w/zmynKuq0LUB9r22w44 Yp6cG3CwbzngSAgbOuBAGRdHUTDegCM5HVa3E6jpruVYqoXt43P5VeZYwaWxfpk42SOxktvxXl43 3Vx/Z7vnRMB3R4EQsCBhJL58/ywJTjIWGlptnW1G1bLNW1hB2oT1fvra0q65qqm2+8+13ccgMP1w Peo4HmvSsIG0m1iEPmUxvXB20xtHu8p4iJVzm5Vmb6yz/8BQHHXZUTy4myTYeZPxBhJown0DCbv0 3aTqaC6hMtuUbwQqNis3lEGJZuDPXKwXS+TMf0YFKhm8xxjFjIWMjDeMRhtOSwmG/C8iX6lK2Zry byzoLisYgeLeAbXdfdVg1HZALtBQEmCWr12uv4JMH1x7pAMCgmtJ6MXpgJ+OWjLdVBVduW3iew+O eAP9xsmJZjsb1/3FBpRRLMDRZRqgF9adEfs1W5/Jqry/B/eGLZUmg89UMR74/oXqrk/RzoaTYP64 3P4/7w4XeJydHCM7cwji8FxITLEHTC50bu8QRGdDb+ffnYRCRs8EdtOfbA5H8F2D9LdP3485YOBx NHTA4CeYSVgQkNEkSmPEWadLVCV1U7lnOttihf8sUydDFNb0TQkrJVNb+NujPmZralmMmbg5Z8N3 ESlhriyNlLg5Z3eMl6+RILI2sNB7DDI5F1awNaeGRsSC+SQcPE9IEI1wvIMy1ga4e0w3vXnf7VHd lnqDJUo01V2D0Xba0JytU+5L8S2xoqcnFIoiIvTlokARMkl1cYxVzMMwjOILsWJkwgJOGxNOMkur hJQxa9kcVM1ELWCVi7Ldiz8mkNuYdud8UGFvZJ4/g+V6IUfFig3e7KOEEO6PN9izNty/hdNseW5T Yepm8y8VlmUrO/DcLFW6BF064WMZhq/PLOFqOywXvU3CVJeoQcvjMQ+Pgoj5/FJ1hKIjOm0A7E5S scJEujtJOGIJZX7CBpZQ4nP62L6wO1bb1c+9AfslV9jQ1iMeH2bED+FBhyW93h4jipk4IqOts7Oh dzLPxvJGITGXmOpa/d2mPUtIWxBEfouvvbHyu/8BnJiIpwplbmRzdHJlYW0KZW5kb2JqCjkxIDAg b2JqCjI1MzMKZW5kb2JqCjg4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNzEgMCBSIC9S ZXNvdXJjZXMgOTAgMCBSIC9Db250ZW50cyA4OSAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0g Pj4KZW5kb2JqCjkwIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl IDw8IC9DczEgNSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAv RjMuMCA4IDAgUiAvRjEuMCA2IDAgUiAvRjIuMCA3IDAgUiA+PiA+PgplbmRvYmoKOTMgMCBvYmoK PDwgL0xlbmd0aCA5NSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjavVrbbttI En3nV/RbNoCt9I3s7mCwO5lgJhgsspOZGBgMkJcW2ZJoU2yFpOLo77eqKUvU1aZExA82JEvkqdup U9X8Sv4kX4niRCcjGmstNJGJJokQIyMZS0jlyN+kJG8+1IxMa/LmPfxNa8JIneLXFDMjYwzlEX7t dv09yfB7k3PXpoxvrr2+JsVrfiV0pBKpaGwiCm/dbl7ilRjnSo7gFUnn5Jc7wgQJH4K/MWEx44Lc zcmb3/iIAsS7CfnXxFZ5adM0/3k6t3kxSv38LXkd3d2TX+8AH1yeUsqkMomknNztACAvAMBblGAN k2YkDFyrC4RtgFT5dNaAhb5pXpOn29O9O15gsuT7JtfjKp//fG/HY1eNfDXt2ovmJlpQQMgusZbQ aG2tANO00bKLYWutr0jmXU0sWdj0wTUkndm8JJPKz4kvHWk8aWaOePhV3ZBHW2YO4jSFNyu/nM7C Pwv4YLEiZXDcsmzyguRN15bLDFiHKzgvTqI94F+ESDrxAXcZxSmNefLs3aIzd2Osvd2+n8os+Kiw afBJaouCzPzc/ec6M/dyRMXRXo5kzcwWrtrNkq7ZjDLFj1kd9fAxk3TEjFaiBbFv/KMDa1d+SVK/ LDIys98cmS+LJl8Ujthyldq6ITbLKlfXkEsTTKq8vvd5uXmb1At0XWXLqasH9ZmR0fN1teOxhErN 1LE8iV7usW5ZGbnvsZ9Kn/17SDM5EwepMZ8nTOzQ5U49xEIaYY7SRw87YzaKuREthH0zx8sGGaDE X5V7hSVSukcC1NAgSSwq3/jUF1gx+B5kjV2siaaTBJu+MoqxswSql0Jq4Hrdw3HRGjxbg2eEQ1kA bm4OqrmbHpDPNSncBE3JayTAZnQEHEK7KI7RThylJn1LnCpuZMJjIIcreLRb44Bin0/RBx5iBn+R 0zM3sVDhGLCFq6DIM/L73V8Q4Gnl3BYdeifaC52KE6WZFhf4ikWb0NF4FPyVHNRWkfuytNnSP3ks LUMIkW9c9kOCqA/ky0db1TNsCr8ux7Z8qLshvA00bUBPKTAmjS4PoaAjLWIjNxiiN7+JjmO+5/Yt +b3E6LmyhrY9IYt8uhpDxWE9+pL88uHTkKpGUP6idN7RNdBfYy0uU3FbXdNJ5w2KfRX3JTBU27XG jtSNbfIUXpdBPXRBMaFiASV2FSZu9DlM0y+vT/t+707RC3yP1L7r+/tpfUAj0VZPQkOI8VYX0kjU CiQ+SoTirItga2O9rNwNWfcFYAugi6ltQiY2M1/vEwvoApCLBaoEslxgn0DR6edlXqe5A/nw9PHd YGngdJYkVwUruFAcaJ0W16BximXvGgG6ECq+LlDdAonl0QIZ1Ewl+qWjgEsLxvVw6agOBEregCi5 X6I8RUnaVDmkJjSJzH3LQY5aTFP4tUCpel6QaOCt2Ijr9EgQVEIf6JG8uM+bOp1txdxzHS30FC5o Yqi6pNGuywAwaUwQSQ8KgfG3MSWfPu42+5NdtH/vkJy/oIvubgBMAjFQWl+3AOi00Q2Igzb6EYgA m+ZykQGBgfLBTYmtQCnCNAPKdly4eWgnkEGhr25k7/obQ8p/KVlf+S+lig1uhgaS/wBhP0Wgvt8S 992mTbEa1NqE9pzpaKwTuKgcbqgDDOSsRF7PO2nhIClsMfVV3szm2MJqV7i0CZ0MhuZXkDf+gdze kiJ/cGDfwcA8qOuUifpKU8Ziw5Mr58RuTSlzoqbefbojwGWlx/5fVTmSmw+adEgXGN23VnQsDOVS DVYrRh8kD0xQj9hr7BhoApOAZHZup6CIMFHGqyCYcHq2zbpNgXxd2GYGFbYofA1Tz82ekGaCw3xP 2dU6KGYHYhVE8jdXTV2Zgp4bwc858dqf/GPB+pM/sr9MrlyHbvN0g+FwhJqEdVdYdFmYHJoGZuDa F8DvMEM9OvKIohUmihk0iVVYCPqyzjMQjgMmchwf0OAxRdVZGDMq2uVlby3X3YBuFRUgOC7wwzIQ 2p6zdV6syME4RQUDIo2NuW6e4uYclOkSqRWKaeYfMQZbgYf7ZyDcdgyxqAGRcoBtFximb2GFe+9d Af/Yha0UpJhR/PqKOtxbAO/MYaQZUnPHL11ERNsq0rFSUkl5nezultETiJMSKi8nvkKxBMUD9O9L SBmbpm6BUjwcNUD5TPJpDgHNgpRaOJgNh6ylhPLeq3WYwnBRrNhgu/WEHuHZqgK1cBN6I5TUq4Y8 +uoBGAaY//0f//uMciNdwodKUFkwuBzUGldMU3PdVC9ZfA4kTCFDpm3CWe+0BeJXXDA2WNpuQBxN W1xNNLZ4QKYIi888LLlJbeeOvPs8aGpK2luyUS0ZpfFgkg0wnHDGZ38DghYSMG9WWLyFT20xqPlx b8VKlYGrG3plYXbtj09J1vkRDgsnpthR0srDMAiCrswsqNlhGUvp3n4xCUgkJc1wflH6hF/GvgK5 AzNN+QBjcV5gL16f7ARlEEged664xQN1++Gvd4cnPwN4yajeXtLQsYwwyXBeMuqEl/7ZHJpmMBf6 uWtmmEztDBDKyhHUBfmyzNM2uUBtPjpXPi1Ih3SWYkl/pmFcaaMHYxrFkhO++mNZPTU6MvW2QLbB adqu2iXd00ly0N6h+mZ4mnx+bRdrBcE27Mq9nUHkgj9/jvjjDqFUzEjvzFdGKc3iwU6hWhDHTqFc BqPtonKT/DuQ5RyCiCFrHx1oKbWNbmOrJoidNdRokERXtIX18gUSUKekz8mL6OX7oxbC3mMUUPIu rIiAGKHU63TmsmXhBq1x3b+dJglu4wUfjBCVPtVO/4bZyz64Vkv5SRPO5ByMZgXIf18O6QlNL2ig OhZSDCgsAMQJT0BpAJ3NMA8svJguC1uRMczTNbkliBEUR+XtPDQFpBZLmqbA7ZDFtMEsys+fWVxw PnCE+8L5gOby2PlAfOZ8ILo6fnJLcNFLMxl6sRbPPTYS9YifPDUlfN6K4nrpIGa4hUDl83SyOcnL rH1wbvPW0OpHJ/1HB84Tdfwg67KGrpNTo8P7IHxAAGabxwVxtrdlmftlWrqwDRnSG5fsvg34Ih7Q Gyd33/91q1YZP4niJ59snqTDZe8zj0XxhCXG0OvkDDNJeLZGm4NDv7Era19udowLXzeu+OEPSRkm e0sbxXFxxwZTNi2GY8qm9lDHK1IvvJ+gmF/HNHONS5tzi5L+W3IjRO8tudaKMyrMYEekGxCHM+AK h5eFDU8EQzODRIY2Fc7IsnwycUHK72X1n/8HHjxAWAplbmRzdHJlYW0KZW5kb2JqCjk1IDAgb2Jq CjI0MzMKZW5kb2JqCjkyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgOTYgMCBSIC9SZXNv dXJjZXMgOTQgMCBSIC9Db250ZW50cyA5MyAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4K ZW5kb2JqCjk0IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjMu MCA4IDAgUiAvRjEuMCA2IDAgUiAvRjIuMCA3IDAgUiA+PiA+PgplbmRvYmoKOTggMCBvYmoKPDwg L0xlbmd0aCAxMDAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42tVa25LiRhJ9 r6/IfbIdMTB1r1K/eNYT3o2O8NienXY4Ntb7IEQB6hYSo4vbPV/vLEGDkKAbIeyeeSIQSDqZdfLk peojvIePYDhYNeaBZNyC1Ba0kGNDlTWQO/gVUnj974LBvIDXb/EzKoBBEfnbDKf1DaP1HZoqgnfM 9p/KLWs+VQfbp26eRv3TPgIdGy3xDwFeoDDafiX4JMYDasf4HaIlfHcDTKz/hJ8KmAoUh5slvP4X H1MEdzODr9+FebEIkwS+ryZheldcwTdwc0u+v0Fw+GxKjdGGW6vg5qmXw6GXc/8nMsJPJujYChXI JgixBZHEf8ThFazyOMvj8gHiAsKiiOepm8LkAcqFg+w+dTlks/rLKnez+I9vyM0t1EDpGeBanjGM nOQZaHjGWhsYIzsvJ6d5BjqeMeyIZ35KI1dbXubhbBZHMEuy+wLitIin6x/yrCrDSeKgWIWRe1Vf u/7wcwHTDO4XYekvPECIlNq5zVvBBDOMHjDipOUlayNqD1rdBh8muQunDwghTuc75z2zWs/zWFOq +vKYCU2lf9mFaLzD0FmsDy6qahqPYFVNkjiKPznw0O7cQ7FDNZi0mnLZn7RIMmmUvRRpPYgjfvAU TKvlZB23//zgPGEPkNWHO0dnCcjyqcsL/+9lOE/jsqrJHa5vaoQ72sEUrqhhwVDeaiqCNn43nW+g XZS03umnk9YbqYylLJDnctbbSPbW6hEC20L4X7lA96euvM/yO3Q7RmuerfxCMQWFi7J0Wvx/4wby fpeLxspnozqyuMKVMD1XgniUbIOSAUf1QHxGtvGxK0rh53e7hdjLhn5VyLAYCth2VciJMWSlDAJj +RmUOBJDwTHh/xVDyGEWXGao3NOwDC+Y9DRjtI9+eNOFZcYG8lA1QM6SD8TQXvJvYZZnS/jl7Y9Q O8AnrShLEheVmEc8V38TwuzLAbVK4QvpWbFCHoEJLp4Clt3XSzCG6xk8ZBUswt9RJ7JZeY8QX8E1 RChVeZVCXEKWQlblLdGSqLwBY3qwaDHeCRSsDCJXXFKwmBRtwZqiGicuf3MbTlDWx1k+v2qZqLlV WLwOspBJOmaBNaIJYmfpNaaDOL1DL39VwA9VPI/hOkzTLG3KNRkcHJr3FwalMMOKi+nCFsMhXYiy KplCVdQpshz7S9Ms/apEFmLAhBPMsY8lIxLjFdxWxfrCNC7KPJ5UZZylF5UT26mhZ2Eep2EUxW/m yzBOxlG2bCuKFspwQdtiSvokOWRMMBYBZXINY58x5OsHbz8G5X24IczJYXIwbe2bzSmF3mYzyo3k ipEBqX3PakRBWnGyUdEf4DuXzONqeSCH7rI4lQKzELZ6tT9IL0SNNM58zHKmtytAjnoE5bOAxM08 KbEEiTyJ96mBjTLHbnnTnJyNCdcHMQnexhRhjIxG5ad4NEIha2ja08iaBQgZHjVIgrbOHFTZffYE VAbSDhOahspuQezYk1RptCjjpfvHriY9xBttLNNW2B6OIAd4w8e1M7Rp45gul5qJZ2iz19JikYKV JOfnjCwYaVB5Dcl2EtC0QgkN7+LnKLOPSmMHyoweimrjqCDoLBjKeRpOq+wRVpSegEpaKhi2UsNQ UV2jEkx1ULkiid0oduXsDXYTJTYXizGWcCdAU4ZabdVAaMw3FkJ0+I1tZVkl4Qlh3xiGsYBzcVZD xjZDBO8su3aW7HC9WLjVI6BVMX9KJRugqDDUUIzk82CRR0epNSzd4ftd+Kl6ON1TnQ7tDIEkO4EU 9sSh5S5xKIpxZqQ+I28cLsTWGMhe4/zOpb6C8tOKEFbI66wIk3Xr8jbLU5fAL3Vl1ioSmWRaSaoH ZX6hdBMbOVQkrqvkApbxfFHCxMHvYVI5P3Z5uhDQ3HA/zSNnkrxmEzMbNgW27bj/Yue04Y6rqeNH vEk2n/vmzhetWY5o/RdU2Qg1Dfs+Nx3vZhDnDx32QZL10EGyTi/Fr1DImkOHdXUvMGUGB9t+cno1 otYCLnlnFPMfd5vFqTe89kqeZcvfUJtbqsixI7JCDot16ZO+lB3Db3y/kK3iqI7wiXMpFKjVZdZu dR79P4gkG/9r2q7Mnh/69C019msuacy5kjKsYG9ICmJoF+yfjaRssZ0hKfSMyXJrdQJ9ZO7QGjac VgY/M2zQdCyY8IxovPlYGXzYRNK76FdMndYzkgM948DZyq5nVN1y7XjPeAGjhexv9LH5wACrRUf2 eswHzjBbiRPEhvQfJD1nc0Nsthi+iEESLjg5KgDQe9r4TB/cFABleI9p4yVNDtiLj+JVwD7PUfwB YJ/PKF5T9deP4jWXvQ9unLZL1WPHWx/d6e3uUu1VbqS9YSioDqgZ1tdbX8Jq2dmkYfxKqdOLx/56 jiLRR88H7+MekPMthL77uBdULG30yx8+QBBf9OED3d34/WsOHxhGX/zEzBbDy52YMTx48WNeHsQX e8xLGyn/tmNeRosXP664A3G544rv/wSvaQOACmVuZHN0cmVhbQplbmRvYmoKMTAwIDAgb2JqCjE4 NjEKZW5kb2JqCjk3IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgOTYgMCBSIC9SZXNvdXJj ZXMgOTkgMCBSIC9Db250ZW50cyA5OCAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5k b2JqCjk5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9D czEgNSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjMuMCA4 IDAgUiAvRjEuMCA2IDAgUiAvRjIuMCA3IDAgUiA+PiA+PgplbmRvYmoKMTAyIDAgb2JqCjw8IC9M ZW5ndGggMTA0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNq9WtGO27YSfddX 8C0NsOuIpEhKQXHbNLc3KIrcps0CRYG80BJtay2JjiRn47+/M5RXa8v2xrKZm4fN2mtLw8MzZ84M 9Zn8ST4TxYiKJxGlKuIkkjGREZ2IOGaS1Ib8TSry6l1Dybwhr97C/2lDKGlS9zUWui/cdt9QcRLA N2Z7V2VhEu1cFT7TX3V7tRCv9pmEEyUjFYoE3gjJbf8ygCtRLiI+gR8kLckvd/C6+xD8LwiVKmbk riSv/sMmIQR3NyM/vNd1s9BFQX5dT3W1bF6Tl+TuPvj1DoKDa4dhHCtGQ56Qu+duTo7dnOGHgluK fwonMRewwp0geB9EkX/N9Wsy3ZDUlitd59UcFt+si7YhurDwKstnM1ObqiUr3S6al8HdPXExhhfE tQ9KHNLgLFDIEyiKiSRR9Mi9g3MwIUNMIIYTmDSWLM2GNCtrZwhLqisyNSQzrUlbk3kFgoVjgaA0 EQkX3B8QkCnHgfjdbJrH1TdIhHZR2/V8QUqgSb4qzHdgBk9GA8KYVACJP0Aw844C8tauiwyhyHoo fnn3geiqyu06rUwJIHlFQ8Sj80QKmcQcRG148+A88TiEQ8Qn4Pho0nWdtxuSN83akFuysA+OL6Ve rUzdEEifjNh2Yer+raVpdwjT6+xEoNJ228lDmYRqBHjBNn66jZ8SFnOMXEVd5LSPnLLXIiQf3j+B tif1kI3XbllCe70PztyyJBY84iF9fsnBiC1LTmlbbWag8gtiK6LhxXxd6JpMdZM3sH0YY17NaqvL NodPLDTUAtK2BdFtq9OFAdpbknuleELD8RSXYcglZ94oDkGcwOtvQ1q9hB8LkEA7a0nT6tYAckU+ B4i8IsEOpK+Z1nm5u3zHFplEUAWuIougExZG8C1322GSPKDcmxI3G5QfiNDg3q8L43W50Xhti1Wi VEyFv42PTmmbyeZQ3iBd8q+mAfXakMq2kBFfjJMy8AUN4gN0qFvykLcLr9hINboKgnCCgY29VUGI 4QQ0f6xrAsLvrOHcatCMDgrAqF3olugsA41pABUIF1FLF7qa+yVPLMeTR0Bh54n0R55YnkDoH7sG W41eIQNcbGnaBRpJPbVrUBCsmgZtd5mvqzzVTmunpn0wpi+dHsFSYShGgwUiI4WKEl9gYRCnWhBb Z2AQirxakpnOCwRnpVM0Cs5M2KrY9A4U+pV3f715/LtXlFg0vidJ4OrJkcJ9MUosOoHSVnSwPtu6 7DiTWZAml2C1hXwDdlUZdHLGLy4RH69FcUTdhvvRIozhlAW1N11CdTaUFDbVhdflSzY+eSKpGKce aSFP9e/vt7a61cUSRfi3u78a4EjnV3RpyJuPXtGIDxr3DDS/MPXQpdAwiqlS19kUGU445ZFS3a2H PiW1UITS9oa8+XCHUvECKrGtl64ck7d//PcjAQO7rVSgIZn5xLncgWMSMkXjMLlu0MK5cFHGx4Os TLaDzAVw7O8A5NX4eZJQKlJR5Gue9BTEUT4OZQrS0mm4TlOzaqGJgA6jhPpXzcBDg9pnroleGc9l j9IDP30/b36+19OpqSe2ng8pK2nIBRXyujaMsonkitEugiEbGljvDdmgP4DSZqDxAmAOaBlykNBE XErMoAuFseS5UOZYaNGQYNcO0pHlTVvn0zW0N3lLbm8J/OoM3YuuyICnW9mqycEBw6fvrSngD/th KyVxSMeuCtvtHeeHyV668YrPXBLjZ7MJ+CLQd3+pJE5J+28zxxPXcmj0hy24pMYWa5dU0KM5fw3G aAE5t8E9SXF7wEt5zSJ1qPhlKSn/eV6CWZvAtgzzKBY8ASOjriv/0KIKlvAuhCEZdJWRB9drOEut K1B3XWpo2TJbGXSJWAAr84CTiy2pP/2A00pivq4K2wCENwPyUs4SRr81hTmHvLE4JG/1xdRzU6WQ /RP49+nlaSIHozcJevkziBzsj5GpSJi8brW7RO5jOCAyVue805BS1+BP3RgJNP8pta7nKWP8rOmJ iCVlLJKexid43wNyog3Fdq9BFtbmBU7R0sLomuhibsGqLtxspTEFuBeChIVEf4FqvETdLfKlgTUB qVPd9O20X1fPIjY2raNIiYRS6SutIYQhclCfX0OC6hTsmtfVSnpBBywSrmJvc3Tlku1Z07ReZbqF lk7jSSWwpcApyqq208KglUqxGlfOLNWgejvf+D8N1BVT6shAPRLfcaCuWBINB+rP2zgOl+aUxd5s XB/B06pzNEX3a8zOHd+UQYvxJU+hXHfGiaxs7vVACNbFz+u/aAjkFd6aL/hlCEGdzxePbizwsjYc 6JfBCL/Oo0TgtX1tdBfBEb/eOWHY1/m8NnM8ALAzeMM2eCo80+ui7c+3mhZdGWg25CaKPKq7Lau8 SXOcXz1+fM960BisOpXyaufBIzlcQBeXT9fMpSDnzQCgmRIxD1lwoVk+pKHcTjIHNARvh1vUjVxx VNg6uQTX5VqrvcSAtOBMYGoEF8fEaNy3/B0cwV5n9Zy7+/adgiHgcURGT+ASybmKrkJ+t3hBDMGJ NqVCUpuqcUmxyuebqU6XWJxs9WjyfPncKOSnqbffiYJoy26bL0+pXer1tz7l8wZKQLBFcdM4DZrh 8/BDRWy0dxMglRy6G1/eDUIYorHVyGrH82L/9ehUwMa0NrUFaiK+547RvsccP4roOY0AlW5A6a0P gNsOEfmxstm/+psGHpYmw6EVOlX9wbUIJi+wfMeFt7/z7iExyM+mP+jqTkYfnws66F3IzNbolO7R EfUnhA3svyE1ng765YA67yhdKiEiQZk3EqiDKRsuG49p9JbreBiaV90IFL0BpAOKh3tI5oY8gGoY 9yze4/NF+EdQGVNsSOVK3boCh4ETusOpIew4g/42vs5HsPi59VSZW0uBGwexD3IqCiECelXVcfuX PIntlugpVruFLc1PF5fW4JAobu/3iTLDZyF1mubH1dT1hiEFZGCx1zkbGiUTnsC1ukCOO5smtW17 2ZKDo7khOCXn5EYM4XG1HRAFl27mU270933aU0f6hxycA46gM+vkZFnB7w+LPF243OjOtX7y6SKE CE8hEIxsob4x6N1dvgif66C8OHMhkzHz7O6ggdIkjP0dDfUxPK3z33llST/PXjd9eegPQl5Aq5yn y+22b2Wxe8wSz3edRG7c42muzHSj7hZ1dF8Ak0QyKcLk6kYK2pbhKlCI8VHpwnTe5dmuajwpZXig REdM3b7HTaIokuo6j7tj6voQdufs3dOb7gHP153N1a3T/2rbBB8Y38qYrNk+O4Ym4YYs1rtP//z5 P0q2bQ4KZW5kc3RyZWFtCmVuZG9iagoxMDQgMCBvYmoKMjQ2OAplbmRvYmoKMTAxIDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgOTYgMCBSIC9SZXNvdXJjZXMgMTAzIDAgUiAvQ29udGVudHMg MTAyIDAgUgovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMTAzIDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0V4dEdT dGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjMuMCA4IDAgUiAvRjEuMCA2IDAgUiAv RjIuMCA3IDAgUiA+PiA+PgplbmRvYmoKMTA2IDAgb2JqCjw8IC9MZW5ndGggMTA4IDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNq9Wtty2zgSfddX9OYlSZWtACBAgtnaSjmTTEZb c3EST6W2JvsASZDEmCIUgoxGf7/dpCTLumRMC7MviWyRRuN09+nTDXyF9/AVEgGJ7kvOExmBjDXE kveV1iKG0sInKODFO89h6uHFD/j/yAMHP2peE6x54bJ9I9FpD9+YAKPv8SVBL30F1k9imTCV4hcM Lu9+xD/BJdeyn0r8u3N4fQM8ah/iUU8BT2LB4WYOL34UfYbL3kzg2S+m9DOT5/C2Hpri1r+E53Dz Bd7e4GZYnzGhlY4kU3Az2l2794C1xXpt/CpifR2pVO7awNc29J69yQoHL+FmZmFw8wHGzvriaQW3 hVvCcmYqqBz+EryDrAJvi7GnD/hLA2M7MXVewdwsFrZ83tuavmdvJ6ygwUqyXkesECmudJwcWbv3 OKwku48VbLC6NqNbW3mYIiYFIlEhdn8jFujwDlhcEhiaS60EOXtv8d5jAwefboyItkbk2Z+ZeQmf LOS2AvvNlquhG68Qki92VBEoWQluWcAisyN7h5Rf+crOgyKU6H2E/LDM5vshEidRwrmOv79g7/uo KN4XTOJbzbr7EWLqcYZR4WGIMQKfn1Uz8g/M69HsH5+fB910mnQNC65SwRiT4VIkTU5FxWwFhavg VcgtJzze3/IYAc5tuedpEamIKXaeo2PWj3gkk6Rded/TP5kcE71Yr9sLsr8ImX7e68J6caKUVGjt OTvddWlrw72d/tvZHGi7WZkVSH//cTXMzDfMZJONMaWxRqw2v6JikfmqzIZ1ZZt0X85cjp/MEP+9 pEqy++xOdOBmIsFxLzp6BJCipTbKT9qETPc3MSbywbx05Tou4XRc9rr6LdYPqOy9e6nIYyb5eTu9 57aNCQeZeEO7XhoPBvc9syVWqspkeeu3AXprTOV+aYpq7bxR7T38kZt6Oqts+d+gCayThyUwk5JF qonFUBmsk/2QaBAgZN5QNP5WmiLkXjWLO0sYxZI4FmkwftbsgLbeltkt5vCgTUEDs2xKQZFj/c7h a219lbmi38hB1Hqomj2pmgYqymaSN1kxxWo+ceXc0MOAn/YSWShUrjxRZyeyFgcarBEajW0+Q4pZ ujofw5D0RWPgh8FrcJNWjkDpkIXKu5+rDH/iMPh43b8zeNMJsL4ird9kp4hYnLKkg/29tf187QgO AokMdxAduICLlygtr3+5c/7WBDIAle+5oaeiLR/1Hhp6qBeRe4PVka0Nu3VkRuXj2rpFTpG0gs9R FN+PHIWrJCLmZ0WOkN+1I6eYeP3uGstRUxIy4kaoi9LmWVOmlmgaxkyFjODnWVVRwLdP3kV9UKpI RFeqSJWMsMvl4agCHz3ur8E6x/LstqnZX9w61RatI7HAgymJLkauLs2U0KIaTy0i2j52RQveXq1P lE7To1q0I0XogwRbmLLKRnVuSqi9JVeit08X/F5nh6VMdSn4DSXKWMYqSYNV/K0Nd/t+33gLwS5u qUdfZmgOMiM1HzDKrSkw7qnG28O8w65ISS31WeZF8rvmFVRvCruEj1c/DoK6Q8iu7uCpRF2gZTh3 bGy4746rCrybY65g0rQy2VduAWaM9ajKPOUK6q0KHynX1cr3sXnCaosZQ0mGUno6xS+DNlKpjDr3 jlJifeAqGOGgDScU6xvsKgbYXKxa3iCF9rXOsJ1GMkGBWlarwGjEortSi+JUBAQjFidmTSTEFqaa ganWXZVv2NZ470aZqewY85y+hl9//jAICovmXWHRCiVsKsPN4NCG07isGoYLuGXNGOueF0LHyVHi fNSWyYYTefGrC7pXnnZ2L0+5isPNj8iGE+4dTBqyRPGAzeloZoppO02gIKcPBX3dFLh1H1MYZFm/ MCMLI5fnSK1BNZpmke4cGoLqjIrCwRV9t8knHbvf3bvinwhgaed2PrQ0+lgGBUUlXWMIq0iiuYjD gaKSEzH00V00QXQXJih+5m6cTVZAFlILsK65QUFJ4u7z+lgIjj1zqHk9GXEiVAbV9oyHxPFmKoSq 5A+Xu+kqKBSp6tzY0OFdmqTh4iNVJ+Ljqmw4xW+nGn6ry7CqYpOTZyhZX/2fJgWac35kUhCpv3FS gImoO08KtIjSVASbON/ZcDCk+smW9mLb0SwtNg/omE3Ezi3VhcyHPErSXHY+VWFxhFGgdBIsebk8 OFZZI3JN87i5bend21GNIUw0hmLZE1JmTszmlggTcp1fWHML2H8PbUN/NNOgQrEo7ST7Myhs8UNO Zhq0GEeZiDkTbLRLix+0Xv8iwAKezWiuu57NcB5jrZMyXKLoAyb7wRSUF+tIuE9mIf0rmOycFqh9 EoYIhMsLwY722J9s0xE1IFBDTQlhdvvuflAoRNRdN0eaCRasXSQbDg6eMavdt2xMIs9WS1fe0nQ1 2ZuupipRZw55doarx+xwbkyDCxq0bwYb/q6+Iim15L1vrIfhqpnShfSUFA+6FhCh3JDHu/nHXAug dfdR+dn6PLMovp7OYWrbibLEaKajyImrizEF7O/ut6Dbj/mDti8lWSyC7T4+kDEfHfT7/XXtqT2y FDzJ5gtXVqaontyLjs0ZE0bNxeYDvoO59SS3HnucI69NSjffG+9RmCcyEudOl7VIDjiXeGU5a6QJ DaQGNx/WFjZ27GygTzj3QnkzlY+4BaRZLMNJabThRFNxVYAdT+2Wetp7YgZowIlaZHNqSEcC+Tb3 0cOVw2wgPmhmWFnl4dYG7UBQJOzDtsnFPRIQqdKpluemAUvjWLcLHwTOyFUVXF5uRrvtXSFfUXuK beiroPuOROdxBZM85VG4cUUUiRPhsnuSbIuqXG0gaYKolacULO8+XGFLNi4p89fPBwVJ8QdfR6Dr Gn/V5nXQrLj0QQVHMskmdHBD/Tnk1pTFLlIX7dyLDnaagvkFy+v6UA4fGhlPR3FIS/jE0+ZEE5kp KFpJ5+EoS4TQuGEZTAKiESdiCovMkmLHLZzfHDSREmxOcbMqoynhZoQeFBaddr+HxwQWXR4u0/Sp 25nv9w5OvMvr5tJG1pRbTC76L7Dwkkw/MK8SruJYyGBphSsfsG5WNLdP6bpI3V5YiS4gd1hrsB/2 ri5HmG2jzTUSqlzrUtVe60V+LtrXCMV2jEi3WGnejNE2zO384uAeW6TEuYeLDZBCHKoPIgmybD3E O8ITm81h6E8Oj3pTnqo0js47iRZKHLdvBE3prxcwdYTjt8wcux8dUBlJybuPbJiKJWPh5q1oxIkM HKIkssjbVx/tTkv+/n95fa7XCmVuZHN0cmVhbQplbmRvYmoKMTA4IDAgb2JqCjI0NDIKZW5kb2Jq CjEwNSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDk2IDAgUiAvUmVzb3VyY2VzIDEwNyAw IFIgL0NvbnRlbnRzIDEwNiAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjEw NyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUg MCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgL0dzMiA1NCAwIFIgPj4gL0ZvbnQgPDwg L0YzLjAgOCAwIFIgL0YxLjAgNiAwIFIgL0YyLjAKNyAwIFIgPj4gPj4KZW5kb2JqCjExMCAwIG9i ago8PCAvTGVuZ3RoIDExMiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaxVpb c9s2Fn7nrzj7lM1MwwAgiYtftrtN00ln0klTz+Rh0wdIgizaJCETpFX9+z0gJYqi5Ni02KzHY1Gy SJz7950D3MPvcA+C4W/IVEyZhJhL4LEIBUmkgNLAFyjg7S+Owo2Dtz/h69wBBTdvbyMhIUTJwN/2 pr2Pk8Tftzx+tiBHz45Y9+zdM4l/5j2QUOBXSKICgh+96d76J9FYMh4mEcxz+M810Aia7+BrAlTG nMB1Dm/fs5CghNdL+KeblWl+Ba+D61v4+RoF8uJKQoSkLILro/Xg6fUYkMCvxyChISMxfqu3LO2W 3ax0BQtrHFT+Kje6+Ndr6GQYLDxeUaGGin7UpVvpLIOf65ku7lxfZ3w0oSwWkil1ic40IqGMEhX3 RYg6EbL0r1RfwbvUVWU6qyuzgFyv12lx4zrdAzJegIHuSna6B+3CCzRyZkpUGfpuTmJKFJXJ81cM DipDqzInYUSjWIj+ygc/f9zCfW1cldoCNtrBZmWqlSlRhs8MvmIYWJjr4lUFzhQLWOv5nakwJiws /E2Fbm7U+K+Vbj5e2nKjy4W/XKVuELYikjGTyWVhi3ok+DrQY2GWus6qxl+m/PoaMqPLwkevgcJs 9n5ElVAyVI5CWjT/NH/pfJ0ZvMOWnfY+DKtSL79GET9WgUWC8oTKS1SIOT+vxBzmtkCr1qax5Y31 f49CglJOWKxY8JLloWdBxrvFg3MWfDzXnxF9x/GexMkzch2Ocp3GlMeSXqJmP9dRhOB8rl+juw2k baCsrXPpLM3SatuWvXTpYwXvuCvsxjVhYZfNV/fxlBYY8XmbBngFaeUGdYskCVFMcnFx1O+r9EEJ DBdTzH2dwkBJK5+qsEhLM6+ybZeKvaT1yrBeQF9ayhKhgpGuJQrRS5JzNSB4kWsfLePXvgDtPNvV uJ37ZqVOsTrs3n24/uwOVunQPEw8nrfYExGuiBifCnQnNAUmIy+uSoZZT9lVRODTx4OdjvgECS50 Et8XmgPerHRR1Zke4A0lHNXE4nQJ3LBQKsLZ0cIHXT+8yiGzzmeOrhcpwkhtGjQp0yxr86nxyMZH 0My4dIGpZiaMWB7RMRHb5C/qwyUG20QRiyIMzfJOPxiMV88B4Ar6mJweIHkPZT6JB+jWB2MsQjss PkauiCM5VvRi8OXxSQQPuUFTZgCFwPrZOBNL5x5XJnQlPyk+e7J87D/OqYjwcd9cL/g2Zh7IMi47 1P/fTSg7Y/JG/ZlB6C5MCJ/QTQ7je7s2aIDMVj2XvP1kyrlZV7XOoExRMBqHSdPANIvSqBWMY90Q YXuVYN9Bhb9C+d5+yGnwzvonfTYZuv7B/GQzi/obJK9z/8yLkRujHkYmC1OoRCTVVMjN5c7JB2v/ 19my3MIb+FWjkp57foCZrVa+sFTwoahMWZjKU6kCgXAPzHpm6woiyJFeVcb9+US9TyIuhLqs3nuW h98bRgu7oslRuW9gkYsYk5P5KA3GGa63JKGh95ugasjuGkz88VbPZqYMkedUJgttedOUilubFp5C eLycI+0JzyPR5Z0P8v8hEj1JFwRlRHBJL8nefkB1MhwcguFQTdjfiUQMtWzq0t76aPYh8FIRM8yd y3REhaSScV+Cg45XM4TXu30bG0xQfoXwLUQwivtRhFGleDyZMwU/GVyYV0joZwhG/8Cfb2a5H6Mk iYouynIvkRTqhOmk2S32AvPVjze5TrNwbvNHci04z/pe4J6g7x5J6diui0QEKwjxQ4KxNei8e1oZ gr5Zfk1z+KVM2866nwNMUEmemu48ERlCDJY+8og1RW/FS1m1jMiYWuazPEZcoYpNFfydBAcV/zBr XSIXQCL9GeGuodmIj+/bThDfTki/ZKxGM+lEJuz88ORFTBpFGFrgE0JbbhdIATomMKXOXI7VOaJx Ijhnk+nMT/DL5xS2u7bYIue+80PLpqfCkmMa91c6u9vxH1uX8Nsf72Fd2lskR1OaRoqxpsGEp0pN NwpAEYam2c8ANDyk2Cft+v1lXdWl+TY2cCVVohi7DBxIw8caHY8Fy29tjw+Euv6+6NAoNpLZ++mA aojYJODQihCcBvIXP3nTCOIbDONy64uYnxBYaEZ1U+5CYLc1ZheioQyYgERdtvNyZIWYnk/n3+zG G8DbIbP2rinlFeT1fAWr9MbPAzLzYDIMblcbN2EiK05G17iYRYhskyWyOt2Pao2ySZs2r2omd67S d2ZlMyz2k+ovRuMatm0ipmfJy8v0F+oZ+i/S5RIzoqigNPd1Wpocrye1hBqNdrHiTNKIT2YJ9Qja fWlTw2lfH36AzW5a70sGRgXW+3lmdAEu0xW+WyPe6fnq+/T8Cpneac/P/sYRL+ILHUlGiSCUC8mm YqMHEU5itvVUYdFBnpFhs40QlxZNj+ZpqfNMZY2std15mS6AFUnGlzLUScTxVMNeL8J5s1Q7ZmJ0 mW33Y28M07lx396L8IcaZKQUvYyZKC8cP2mfi/6Y4rtyEkVkMpaTRAnDpyfJRJxkJ0LwROG1a1Ps cfe526TBk8FKSfw89YNeDkcxkYTDy4etQV/9ToQT9X153SXywvo+cjISpppjLGfG+Mfjsj4Jo0yg qC88RuDz+HhcdpBgONH3NWtjy7sjhXspGexTMhZcJSJ+wdmULiUD2soSnUC/05Ut6zDXlavdKs27 Me7t+vsmKE3k2ATlpDl8oqZK0FaEMwm61mWbnCehClvrm6sH4zdoEHXM0mLvN9m4V1EhxmIvR4jh kZoKejsJzqatN8QOW2aZ36Eq7GZCjKWKjyeJLCHtmHESjEURHsNYAytblzeZdq5jgfszASW2URgq ertrL9MJxyGK0WSsWZTwx3LOnvZ6kVlQhPNmmdXYMrTjwR/2p0T2o0K9WCBDazfoMXCwo9DFTWYW U5omiseaRki0TkwnY2UowiMRU9au2mE7VhHffOvyxniGdlNg3Vh0x8Ya2rYwDj+f0jZI1sbaBnk8 J4ROZpskepTIb2ydLSBL75oBo2unzf7cVJbOt7AsbQ65QQwqUpc/tfXCWYxevYjEkiRsjHa6I7/I c06j/9Pei2JyNFAmCrsxyabCyVaC4HxJdKZ8SOfNqTe71vf1AQ3h9/8BYXjPkQplbmRzdHJlYW0K ZW5kb2JqCjExMiAwIG9iagoyMzMxCmVuZG9iagoxMDkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh cmVudCA5NiAwIFIgL1Jlc291cmNlcyAxMTEgMCBSIC9Db250ZW50cyAxMTAgMCBSCi9NZWRpYUJv eCBbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoxMTEgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9U ZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMQo1IDAgUiA+ PiAvRXh0R1N0YXRlIDw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMy4wIDggMCBSIC9GMS4w IDYgMCBSCi9GMi4wIDcgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEgOSAwIFIgPj4gPj4KZW5kb2Jq CjExNCAwIG9iago8PCAvTGVuZ3RoIDExNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCnjaxVpNc+M2Er3zV6ByylTNaPBBgMCcspOd/apks6lyVS5zgUhYok0RDEFa0b/fBijJskhr TAmbrSnbY0sim6+7X7/uxu/oV/Q7yiiSYoG5lEyiVEgkGFuolBCBWoN+QzX6+HdH0Mqhjz/Cz9wh glzuP5ZRHD7wYf+JlCTwiftLV8WKHq+6vxpecH+9D3iBMROpTAlHd3nyO7yQiTTDXCEM/z48/wrX JjzN0gVlHOUb9PkOETK8CX4S5b8YTtHdBn38G1nghKC7e/S9051t+8VGd65363Kjf3jQy6VpFw8N WmuHKnPfoW5dOpSvdbd4h+4e0Jc7eJqjpWBngsE4NNM4tjeOIe5No2wwjR5N+1m3bq2rCn3pl7p+ dJ/Q8909LinOUk6z9PK9k6l70/294SWGF5JxlZ7aAPCgwYZ/lRv0CTm7McjeI9u3aGvbRwRwbGxX PumuQMsd0qjRjWn9f/+qnwz6sdLt47vkaOzt6KQ0OaCD3oZORlOVMoix8b2Tb9z7FXRSOo1O1ztX GYeWptsaU6Om0jvTOuTWtq8AHzP8pQD4OmRr1NnGg9mtDdoYiKq6dJuoYAkyFyzJsjQlOIsHliDn YIUkqowuHCCAHqu+WBn3Hm3XZb5GGvK/tltknSu/MiZO8FhgIhiWXLErkAHrksE6xrNL1oF79iad IHN2w2S+KyRG33bFi2eFtAaWFTc96wtPHEw4D9tlX1ZFWa/QsrL54+ixk1siUKmTx07eEoGCUpkR LuKR2cGG8+fe6rrzEVhumspsDPzS2KrMdz49XVkEojvmpYuZmCmRsxMT8lJkVEVLTLBhGpbCmAZo PH80HSpr15i8K4Gs9iRWmyfP75CkJjfO6XYXmAwo7N62W92GQGp0t46KF8vmExnlkpJ4RAY2TONV Olvp7sXz37d2g3S9Q6YuGltCZOmiaAEuEzeMuJgJC8GCKwoyKBoqPlGnUNFPtizQujStbnNgdl0h 2/qKZyu72qGldkC0ZV1A2o15HisiQBqK24g+xfSSnVCZX2f4t9DNmTMyjt7kjORZmUA940ReSfHe ZefeONgwojqDdOXskfKcaXTrgzbvXQearoVoLVDT2ifgvRY0OES0rUEGN24I5oPjnt00IdAJ5Uxk mZrxPMlIoFPAA55EjQoz/UQ5+s/P08IbwLg1mziWc4U3Iyl8yXjC+2jDuQP/4ly/aTwRR2UQ6Brm Eiv31+aSR6MQsGH6mWuQ0aHHqO9b7bq2z7se1CGIx8I0lfVCGkJ5ox9BPtva7KICk86lViwESRVO 41VosOEcmC9VVdoO/WR064Ni6RsJMMlufdXpnW82Vq2BxG5RbuuutcC6vl77+uyLMuoArdq3Z0OB jxtMgp9jVnSAmGkPrbRtV+eoKc6pohPdWfI2DhxQS/GCKJmxwYoxah60r9+DlqkqiJptCUhAxKCf vr5D2j36P61375EPO6jSjYWyVCCndx5V3TQgCnVIPdS14W8QdkE0v1TsYCelIsPqpqoVkMxGktW7 EZpH3zIVeuctWIE+O3W2rY7IRhhDcDWbDSWhoLgiKvejDSM2fPYJcMGTqWzjQ9/3jsdmZg/YgUVC r1lDGPgMCPnQQvL4N770oWRQl+FJbvahIKMpgb2/N60Jg5KQkK1dlqHguomituDJYe4FaGREyitM OpbVhCi1CGbREaaVcVVpPpSmu//B5BZYo1kvALYw9noA+eqJ9nnwlUzX32siLjmNOHgjmjvagYYI S06vmAhOR9xgQ/Ii4qyp0D90BRFW1hB7vwEIvgZpH0Ar4JHWKybfKupVXXY99I068PLaaP8KhKHr oWTpTqNlGZdxhRCzGRcuxjDHIhrhCjEqUwNcddRHlXxuQcZSEUWziW4nuTY85Cv6+pc6N2hnexDW dRGSe9zTUC7gmyQ3MQsV6pI1resOlR2sCAH6PtiV6xpitIPaDwTU5wMDus63AOXQvr8cPgGTK+hN bmfB8fClNRtd1sOYYNAgF7qwZGaYZETOnLNhIbMMqjaPNmjLXpus+C4MSpT2Wj7ICE8la90WW/9n UCemcKGUl3VvwmSqzqHAO/Me+d7NBC8W9sxVkjGwn93sqoyNCpYrgdJCJL/UbBgTzrm6Yir6nFcs m75n7lvU3G6aUJ3fewyqPlT0vN01nV21ulmX+elbQAVo5NcO+6nVUrsyKs9mfPYgXXFGU0nSaN1A xsl0VPEABcjZGpIekvl8nBsThwzPbhczzBRV8bYvYMM0Difzt6Js/dTyySygXJuhZwwKZh8gvjSH yPFTD7+zartSV/sOaVDWnf/cxWkHTjMBSj29bdzhpwfwUHJUQ7+1j7wgzAbjmPR3vU40JvtZDPFe l3iUpEvdAS1kz64OgIgUFAEn8gpeOJn/MDF9z/JE0/zJ0hTamrnSlEO551yyaNJ0sCGZ2DpC8YYm Qg9BrruhtNu+hSrvYQo72xfTgG3IiWEmMIz5HVoBmKs/a7onx7N0+onh/+V0D5Jhbj/LKUmhpVfR +tmjDecu3K/QQzt7oK6YvA1pOXuaBcGLOYu3P/HNwrQqWu8Oy6VTjl4eNyqmuMzDnAiSZpLeFphk 6I+lHAnWh5X7/1GPwnIO9QRAvPq4YnU77bfBgORVNeu6rgRbnidjY73o3cMYz26yicILF2xa9YHS wB/Qe795rzMZFC9zR9HZYwnBmMSSsuTKvc7YB4cx/WjL5pc6hbnXfdWdsIh776eXYc5Zem1cWN9y 7Y1MYjCKCrPpZA4qDCuapjIam6pUvLY3+KMbiiFEaJ7bvu70sqzKbjfuymnGQGvgG0+U4ItWmaqI uWhUYvaiUQqo3Iyn0RaNSry+aNwGKq/Kx9DCQo/mmxJoXPsa+HxlvCsMgiJn28KPzbZrC5RaF5Up TiRJzOqnZHpe/dyyLTcXthIZUIy6/RgUoCNVEPj++xlg352l53d75KDwaagdtoG23w+s9Ulix4OF QpVgc2FhIAgYFWkkWIIN57D8sl6gf4dDJpuyLhZRn5jOPjxIuOQCk1jbzmDDKwcmwNegy9Hnzwfu eqzt0k0MEoWQgOGNwzmqxCWbgLPQB7S22xea7PkgYxcWT5Hdk86esmQEKgrHNJ570lemLPspqW0a 68rOHHQ6KPatb7OefNIWJdTjCYdlQgma0tsmjNDOX7LSO8zTrXZ+CARMuxn6iSV4Lt5eEG4t8Ow+ CvSoEopGqvwnNpw76Z9nxafT1SMKze6wkvHHlg9rv5enCqLGcaZmxzEw6/TS8cowHi+QAY59P3Xc EBzOKUMuVzEPOML91ewDjmA4zjhP42Hw2vbYR8HK6srzbNgI28PJJy9T9if1kAOUoAI/9C68o7An A8aYUBEy6wjO0PGCmM6yiTp83WIrGPHKkXbTnkbGr/8FzUMbXQplbmRzdHJlYW0KZW5kb2JqCjEx NiAwIG9iagoyNTQxCmVuZG9iagoxMTMgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA5NiAw IFIgL1Jlc291cmNlcyAxMTUgMCBSIC9Db250ZW50cyAxMTQgMCBSCi9NZWRpYUJveCBbMCAwIDYx MiA3OTJdID4+CmVuZG9iagoxMTUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0Nv bG9yU3BhY2UgPDwgL0NzMSA1IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9G b250IDw8IC9GMS4wIDYgMCBSIC9GMi4wIDcgMCBSID4+ID4+CmVuZG9iagoxMTggMCBvYmoKPDwg L0xlbmd0aCAxMjAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42rVa247bOBJ9 91fwbSfAxuH9kpcZ7E6ykwUCZIAG5iXAgJbpFtOy6BblOP77LUpu221bnZbNfeqrparDqlOnqviI /kSPSFGk5JQQJYlAXGokOZtqTZlBjUN/oRq9+08k6D6id/+Gr0VEBMWi+xgxU2MMppP0sbe7z2mS Prd46dmEk/2zd8/E6ZmPCE+V5AoLM8Hwq7f7H9OTiCRYT+FZqFiif90hwlD3T/BVIIoJk+huid59 pFMMJt4t0C+fbRNLW1Xow3pm64f4Hr2Z3H1DH+7AODzFWGmiFDcG3T17N3rFuynCk/Ru+BPDU82E 4cc2kL0N//VL9B65er4Kvm6Rj8iiuYutr23rQ/0GdQZNwKArrDhBQAh4++QnCKBjBDTRilL1EwQm AwigCwh0NlxAYBGajW3mvr5HdZi7BISvo4fv2tKh2rWb0DwcHc/taCg++Xk8PEeDESMk4RfePfl5 PFxCQ/HLaFiIf1st+3Aogq8qV6RwQGHRwQO/rueoKG1duypmhcWwsbAIxihmWOeDxbAhWHYu98As na1jgqRt4JtVaNoUPitbPLg2KyiU0LGgKCaoAk+ygQI2DIACkWDrRCHH6KSsqWxsURlWWaFgZDQU ihFCjMwHBSMDNPrdNdtjFGq7dPOs7gs8mjUkg6JHM7ov8GX3d8wApdPWod4uwzpvFkgz1nfDKVR3 KPnZfJfmNUdf2sQP69o/rt3+l59+z4qG1uM5AUM91RkjQetTNGY2ujmCSmFRdEXjgABcNUezbccI UEWfoqRFzhZloo2cqDCsRueHZpzrfEUVTBhID7tM9eGpaiKwKWyS8EB2FqGEFKl8HMDYS8+pSOIT bMGECiaVGiMIJztbyc5WgigEAFhJz2ocfc8E+vL5gM4z8Qu8c+vZcLxXwJPXnQ2FUqyoYtn0396G 08P5tEDbsO4Iu4/QrFEpRjOXFFRwEL/5wlIMMNdR8KUcXYL0e1z7BnK0dL6xTVH6wlYI/mldtOvG ZQVGjScxqTU3NB+lgw0vljPQNZ0YjmjmSvu9bwhiipON3WYFw4zmLsU5xcqIfGCYAfLalMDY8wCA HHVK85DTf07k+I5IgL4hLJv/YMOr+sOIqhAeUhU7hgOyBvLoe17y4ExcUehB+dB8NQ1suAjLetVV +tptdm1PVsfF6A5ZMokFlvlYE2y4HA8g9/xii3wLjsckedqyCev78qm8ZwVCje6JoffjjKp8OKiB ltgv4PR/tKjy9UPqePocqLaQGi3ou7zdD/D+GCCSZMJJNFGM2TlHTF4zRbuEhRnohGPqgX3WHBBk dLvLOdaQ/vlUPtgwfPahP/7/Q9QLhkcfNpittcxXDsGGAdd3o9KVbUu0sOsq76nz8XpRKYh1k4/5 wIbLrif5kzz27X5YmgK/H/n0VQC1IWHTuLlrXQNdD/Djl4TUx4QU+gM0VeWarIhJPZ4iFfjI8mkH sGEYsS8f/0CFbZotCusWQanoZ4Wh8kVWESm0uoIiNTMGmCMbRYIVl6GYgfNLu4Ww6UHI2k1IPFpA CskUpxnTBmx4QUDbWTr9jjSie5qp/5oVA3qmFuOs8cvfvtnZzDXT0NyfUYeW0Efc2GKDu9po3ltw ikDXNzxlQeOgi+xV44/27zKs8vrPrxCNSkMO5OsoJR8QjV/C5wAHv7KNbQGRkzhYNGEJzAmcEO63 IKRiEdJQMSs68ortCuGE5luugAlDLNk4h4qwhJ7C1W23WHmOUFYk9HgpqQwW0F2IbDQJRlzG4itj 8vkumCrNmRT6tl2w5C+9u4kteruD2+1ntjGsm8LtoZjcjr3CZOwgUDCmBScq2yBwb8PZOCzG9dIl gfdQh01PW74GGVPb6pCdaekHf9htSVs0c1Wo7+G/w4sDXLCRK6L1TQNc0jtAzkrsg/O+KP3fsfRL e0T43TriW+hkWFuCbgW13k4Phl45WkYHyybHo2XFLoyWOX5htHzy0vGXK5TAYy9XaCMF05Jku1yh ztdi0RUBWsK3Xayc36rYEdnktmR62ki9PpnAUgaHJPIl0/lWDHLCVjF1hy61BuGabMrJ92r8uoxL hiEr8mlDpQcbBN/Mu8Vp10M14bufuyar/3r8YowZQpXE+aaIemgz1nfTz3yHYIggBKKfeeg0tymC 7lNjeegxbdGEGOGzsQ+crGjR8Z2E0MYona+d1HSgk6jAeahQ7seqsr5GVShsGzJHCxfjs0VwpmQ+ oQg2DLfTnTAEIgmn1BoPN5e6Kyg9OFmxkXz8qEFoJnG+cSzYMHRDaecxYHIuIhUIeYPlTSWPUv2S GbVLF+fuIXuhv0lXCvsNWjqv2I+Fjg6rnx59/cXW6MOn37++mWY9J83Gzw8Fwf3kK5PC13qg2/kL ojbU/2gvnRNJVMmZyXdO51bUIOxXrvDdy5+3w1RKCFhzhTI5YED1KQaT47cXfa7+s5sHQZ5uu+K3 tKtVkqgpSlJkPJdJtylEg+lYhciNUOTKZEmJfRIKewsu8Vl3gzAtk/b1b/dd/5dqx23diGBlm9aD fNrn1GJd7X7KmT+Gjr9pR6SWOXfz3bMuYVaGDdpPlfoOdT8xOejKrJMlw/H4VQwFD1S+S5hm6PrK xoOGrA/3djtBFf1yVTloP7rlXGxt65CdA0Ktj26ZZixZ8bnikgsRAjR2vrpoxAtLix6aUKfl5BMK Ebm+ViWIjuD483/Tr386CmVuZHN0cmVhbQplbmRvYmoKMTIwIDAgb2JqCjIwMjAKZW5kb2JqCjEx NyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEyMSAwIFIgL1Jlc291cmNlcyAxMTkgMCBS IC9Db250ZW50cyAxMTggMCBSCi9NZWRpYUJveCBbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoxMTkg MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA1IDAg UiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDYgMCBSIC9G Mi4wIDcgMCBSID4+ID4+CmVuZG9iagoxMjMgMCBvYmoKPDwgL0xlbmd0aCAxMjUgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42r1abY/jthH+rl/Bb22APZ8oiqS4/ZCgl7TdoEHu kEUPAfqFlrgWb/XiE6V1nF/fGUl+t7crmwkO2L21JXL4zMzDZ4b8Sj6Rr0RGJGEzKWIZKhKLhAgm ZhHjkSKNIZ9JRd7/01GycOT9B/idOkKJS/E1GYWzMAxVEuBr78b3GMf3ng7GFjSie2OzZDf2OGY4 4zjqOxiRRpwJKVXwmMIQ4WAaVySEf+92f8LYVEgezUIBI5Tk74+E0uEh+B0lgkShkpw8luT9P+gs DCh5fCJ/je5jTj7+9A15/EJ+eAQrtxbg/CF5+6TBOCkbJ2WE45QqGqaEZ8gw5U+6cbkuCvJDN9fV s7snu9kRQSFCRWUYXbHgaJwbvmLhLGFcxYMNwWbZow0/2pLck5UhtmqbOutSQzRJc11VpiCFeYGf uoWPqjoz5B1pcwMOso7UFTzoXJ1a3ZqMrGyb45f9cw5f+SbYWwqlPIpVIslVKwmGlQCKFEAhRysw Os2JqTJSP+1M3wPyaM7gDXMeeI6GEX+D5/aXGyYx52Ei+E3r3fPczoZjzyHmh+5qzLIxzlSt678s 9W+27MrxS8SowGd0UTqS1lWrbWWrxZ75V9h8hFccBxMjnQFlRCyhZ+YOrol0tOEyXhijXhcs2NQF J1GYyER4XLBg5xe8ymtnyLzuqkw3a0zdtKmdg5ydr/ejxysgSTQVEKk4CwWP/QGSROcBWdgXUx3m DBAWIKSbzDQD0QFKel4Y0tZkYSrTAMcRXRGdvZimtc6UfXrppxZesK1P6GhIj6Fz88aW333R87lp ZnWzOIKOJlGkqBA3IgcwJSqJBxOOkZvXiI3XdUbh1BDhgoWKKektRMCG44UWRjfVQJzgYttgCCzr ol6skTrx4546wemk7Fy7iwiv2DA1FRsRUcgfmvjDhqkLBLrBw5kG1u7IvKl1lmoAA0WArRAl24w4 9YphTXL90ifTc1WvILPqru23IdAcprF1c7R7SiaTGEy9VSwAJMdr0KAThmDeMIBDxwIJADcOJrc5 qJdxZ3S+s1tOIsZ3vWsVTwCTU9cG16lANOIYFgjn/zImD92guAANQ8VtIibmr01c1xli7Ij5zbrW VCg/wUWbIBuhCLxgr5DWgkmyBPbo8Lws2Zs7mAC9ohdlyaCrNeTVUvcbjjMtxmYD2WI22XYH+zk+ iUwEENm039GLOkUV7jNSYQOdrGkoFyC8lDcOAhvOo7XUbQ5QAQ6dM4VxjnRV/2sPxnnnbIWfNabQ ra0rl9ulV4Si6SwNDA1VHfOHUKQuxtOaZJBSjZ1j+AAxQ55VT3VT9mAgGWMMQZ2AXIg5h3YjsORJ d0ULlF1lBUTcDrJXSvIrquOjkpxG8UmFE93z8JWSPLjZg2JXkgdvlKmcJRFNuDdG2Npw7EHYSF1X lqjZoTpf6QrLbE36HRbcuAK1CnUbKQ3uY9aVXkM7oZOTXzLBuYr8hXZygSr3Fj82GyDls66c+0SA hZPpT9AkTpTwBgCYcB6AEtLTLqE62ZX0c0h0nWJiewWBTmY4KCGkUpG/uhZsOEbhU2dcT+he18qS iWuNJJC5Ut6YACw4Xum3exPezHaMy6lsBwNyzmTib40bG3Zr/GiwiP533eZQ3i4gvH+pe5HT1xH7 yQ4bPZbdpDIGNCPsX32tRlxdGiTFxbDnafd8VE0wJsKIxurmcoLJE0bak2GDQLsb5CtakuoUvrXt jDw8kYehBNIg1cDSwr4AmZ8qblDbMUiE2xQ3oxeMxdJrMG5jM24dCwOiMofvsnqwe4B1KNL8Vj9M TSZVGBh+CM68VT9gxHla/WwGHw16EZgVfJrXTUtaW4IOms1mr0qhkPMQ5olukkJU4YgQradt7i+d LpdmloLA/b3+blFqW8zSugSbHflSg9TNBpEHPm3PWTr1FGPrwmDfhfGbeuFHZQHlMoqxbRP4OMUY bQj2wfmQN6B1ra7Ajz9XxdDYzGsHheXoU130zYfCZAvTV/x9ldn/avAEQc9tYdu1z3CPp/fBYyVC xaS/Lmh8qQ/+easpAQWwCAgAMWs756CSInPTrgxwMLKaTVFkAVADoPD8stBrAvzgFa3pTXTOoGhQ /rRGfKmH/mvdkbTuiowsoCYfGkR6+UeEzPTGOe7QUZJ4DJnTxvl+ej0iyax6MOZjUzwjQ0GJ4Jyp Mfuw8YkSDyeXJzwSIZceE4uHF8qTD13TgEw54KCvHbYX++7xfjMH0Fuv9PpuJO4tpllmENLZn1V6 cyrPlN78jyy9OYunitFYwO4YnQ3068To1obdsh8K+8W2aU7+Rj5bMAXN6fv+h92Tu12jqarxJADe 2A/8oQnuQGfp9Nl4Dn4+nSdFBFWZ9Hdwwjm7uKtgNY6gQGVuF3i0jBoeqCDT6784Yr52doky3isk cjJrChVHiYr9deL4aW97G0z35PuarGEPGWuAORi21M0zVgDisAKIwaYklrddlGAhf82uRdeYwSnY ALS/m83RVm50hh0/QCrw5Ro1mapjwQUTzKNr1P+l6pUZu8kYrx8evu8PhagIyXzdmtdboGHMQpUk VN0o/GUv/EUopwj/wjy1f4bsF5GYKvsZA1kS9m70I/sHG4ILGdZLNFAjpX7GOy/VesO9pNDNwtyR eTccUJL//PzwsQ/3TLe6d7srcR3bwv2oJmeK4/2lm9sHIj4pPLGVsRFObQ7aYJH7vLgkuJp6cYnx mFJ240WtA6/xCycUv2LfAZ0y7JToh9d6IzSBT4RktxFjRF8zrF65y/C/RWccwS+TtyVNsOM+poD5 VEyuvPEXnMAvT5qKv3TY6GhA0Y9pUwLr92204Twem6vgh2UNf7kZ+RfuWbh5LfDKHwSrM/DgsGG4 FvQOPA5Eg08cOixmeC/l9it/Qp3sYB1eX1qhAnvRhc36s0+PeSMpnZo3IE7jOAz95c3WhhOJlVsg vKVemoZ8C9WY6a9iPoC/HFbzuc5AfoFnuswavKbpuYcn2eQeXgxji0j629DBhmNs+qrU4mGvM7rp 5TiB/2APr9ULA3G8ae+hNi3q+hlP09qdwK+3av0M9wD/01jR20KZ8dcWANzT70BHyl3GjFLJrwjp HXS92077QHnf8gHMsJvjsJ2zvcXr9TBRXtPYScKISe4vYi51dpDFvo7nSUBuNcbQ2AxHRls1tu3Z ryF6uSxsOtwkGAs88tS1oKVnI4uO15wOiQG0IWNxfN0tmuDAhfJEGgIbN2awEU8W2lHIl2fK9hkP rm8cnFyjD4bGgVQnsLL78PDM/tP/AN48sCwKZW5kc3RyZWFtCmVuZG9iagoxMjUgMCBvYmoKMjQ1 MQplbmRvYmoKMTIyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTIxIDAgUiAvUmVzb3Vy Y2VzIDEyNCAwIFIgL0NvbnRlbnRzIDEyMyAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gPj4K ZW5kb2JqCjEyNCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8 PCAvQ3MxIDUgMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0Yx LjAgNiAwIFIgL0YyLjAgNyAwIFIgPj4gPj4KZW5kb2JqCjEyNyAwIG9iago8PCAvTGVuZ3RoIDEy OSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaxVpdj9u4FX3Xr7jYl+0CHUf8 pvKyu0m227S7QRYZICjQLkDLtK0ZSXREOtP8+17K4/G3M7IZFBjEjmFLh+eee++5pD7BH/AJFAUt RrTghGrgUoNkfKRyoRV0Fj5CCy9+9QRmHl68xtfSAwFfxp8pmvc/uHn8Ra4z/MV096oyJ9tXZfrp qo9Xy+PVPkE+UpLjFwr8IIebp/9meCWimNZ4MQFlA69ugbDVl/BVACWa5HDbwIu/0VGO4G6n8Jff Tefnpq7hl+XYtPf+JfwAt3fZL7cILh/luZSikIQVcHvu3nDs3jR+KbvBV8LykWai4NsYyBOGD0sL L+Ffbgl+7pb1BGrn7mFsyntwLSyMD0iFt6Yr5/GDfzOmfshu7+AJJFVaF3jpy0BmkSAKrNDnQLoH qG07C3P/VzAB30dYc/y0CuCtbTwEB7uwlOKaCkqvgtXHjfJ9OI1FGO0EvuyxhtB6whZmYTsfY4l4 MsRzAYg98XCGILKvi2dDQF5oxjgn8vzNs5PqgQP19CB2mPhH1aB63k57KubmswW/sGWFKpG74ZAi p1ypq6JBhTiHpXzkfRWW5WxmYyiiVhCVxXChWFAmjd1Cdn1gJM2eldUbKjhnheL0WMJkz8nqw7hI us/FP+3nqo2RgdK04LqJ7eDdnxSmrgMDs84s5vBQhTm8g9ZNrB/Bx/kXqHzkaGxDwK8jVbUZ2xrK uWlbW2OO4ZvdLKNEca4Kdn2SKbm/hB7XhrmnQjwSsRTf9DnONIpcYX6W2cDbk0cmCZCCRADFhsNs BaBzNSb5aOLG46r1P80aU9Wj0jWocw93rmrtBClBzpCgMDqCFHFm1yusQIxrhWXPUxj2SM7117Jt QOY/YdjP/J9X2WYmEzBjHzpThgq7BGonzO2RZiEYoQIBXtcsKD+HDKtwa5pYiUyJhTrim7j2+7Cq TwgtCnpme4Txi35X0yTPWU7IVT23jxsVB21sCnuqzi8I0Z48OB9qK5RmUSAqma14wnBYgP4eOY8h +LQ0bVg1hh2tFloWFF1EdiGYVWeQYhtMtgcGE7WztQnVZ1t/AR/MuLbwY9IoSDYkChcvdId1ybKj SfnObZb2/DtlR1alKQxsbgr/CJHiqnDurFLT/VW+nneVD5WJ+nqN/z5YDO/NEtt855bBQtVim2tM X4liw2uWdajQCBzWI5JrRbEbX1WOOBPbaA+9q0+qNdqXz4GDRE60wB6XKuM3GPa1dxsbIv5hWExn TYwNvmLOVYjuwXX3VTvDOSKhBaM5zYdaMCFzoRRRqSxYxABnVPqhaku7MgvRL5hyjiUJ1WkADesx WbJcf824fyVaTLBz6HB2GhtfPbbvLiZN6NxkWcb4GCgdWr5VL99Fpng08uRaw0dzdtAyEA+yYhaL ziFB5zMmG6YQ8Zzq/LTO3lsS1Acl8iJrmx2ViDgxPX20sOxXDofdUcpCiYLw67ojFdso9svpf/He dTW1oULThAGPc3XtUAb9HBVcZzdmbrd1Y11htNBXgcNh6Bw49/CfZ9fOr3c0mqvBHU1KxVAMNFVH ixj2V/lu2U1w7ppGrn97++H9+bFHStRJLydElF049mBRiFi03h97nLn/6c6Mx7YbLVscckIYtW7I zIPZeW1JJ7kaOvNIVghBZbKZZ4NhE6Y31XRqO9sGiJnbuoeUbYxQud/G7mZ+HQrXzQ6aGJcSwZLr VkzoSDJFyQrB/op/qSsX4Dtc7nfwmzXdj5sVH1EmznZMKjXEZmSHwtQyYuEHRoq9zAW8//3biQ6/ NVB0FGug5kKkE90aw2bZ3nXdF7iBPhRJBaf0UN+kNSO5PCq5y3wTYjguuZfwpjPTcFOj6G7qyi9u WttNbnKSlIFCDWVACU4ooywdA4U6xcDPWGICeIcvOLhCg9YourOJwQEWvVJKJtDpDGUCXUXOWCGT MUGJPMVEnOLifDf+AlELSVfOxOAsIBQtAUuXBYjh1MojDDeNBgyXv68ADxPXayR0pvVNFcDhPNEP vqbefCspXYIPpIswTpWKdj8VW+JgdIhLTbpKxbLBNlFQzWi6VSp22AmgmuKYUFftPcxcH/6Hdr3D 2Qtha2vzzaukjBSDzzkKoZk6PkFdSElBT6XJosMJO+7x+P5gzni/bBYxD5KKnxEyuFbklDGu01VJ drjhvSZhd48zVCXS4j5XvkIe1mUjKR0s/783DcRwio6YBFgMbdxyqdN6dcaLoSvPCxzlNbrFg5tn F86RCOJk14j6j2XABKiOHdorgRWZC33leSw5B6aazeNReHlvA/LvPWATn6BE+3PGsZlsbVFeHxA5 2MtKQqSSCSs2YjgnxZh9WKaxQm0V6rlbxBMpfDk7WCFYJTFm8rrJCme9nix90EDv6lIWd27ebs2b /cxf22nYnviz48PXJQHMtgPIczb4qKHAYZOQS05/jwdwhSE7FkBfmro/OyT5n+rxVa/92JnzvGyw kjmlQ/Yq+42AnOMcpYqrknmHCHqy0b7q4o72a9MtbBts970H60PVxDIbTTpFMCkLLeeDO248z2Fo xpLlNecnO+6rX9/HYhYT2qAjc5P4uMWkwlSPTwj1T1PEsxBobMz3yjc9SWu3HtZNeVWodzfa0TSQ QhdXb7T3uxN7D8r0tcf3xQcnqlh8UgpY8aEClpxwrRlLJ2DFTw/VvolQ2mWDdS7OVus5CcwyzF1X hSrtyMSLwcOEIOiSqCzSabhgZ3oT+sVq1j51qb2h8dtu9Im8ONzoI/m33OgT633O52/0cYZmoRA0 2UafoPKcWXhAl9QHZmZD/8G61azLzcT6sqvGdhL9XR+4uF2WUraCi+GWCst/H9BEskUMp1gaLwO8 BdvG+ca14F1j0aZgQa2re0xlePPuAw5Esyo+lNQl5UXywU/8qQLFLnQ6XiQfbDXdNNik5+443g/u zUIIxnS6vSDEcIqIeIyJRu2z7appn0wQnwFdeiz6mEMO5YO135dukXQjVeaD90mkVjgeJtwgQwyn SImHi8hD6LDHrZ5Z7tNle2MxKRt0sH3jmCo0JRn0pHuL+2alq2tb9jW26beO8E371A6bDRl//A8P +mx7CmVuZHN0cmVhbQplbmRvYmoKMTI5IDAgb2JqCjIzMDMKZW5kb2JqCjEyNiAwIG9iago8PCAv VHlwZSAvUGFnZSAvUGFyZW50IDEyMSAwIFIgL1Jlc291cmNlcyAxMjggMCBSIC9Db250ZW50cyAx MjcgMCBSCi9NZWRpYUJveCBbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoxMjggMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA1IDAgUiA+PiAvRXh0R1N0 YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDYgMCBSIC9GMi4wIDcgMCBSID4+ ID4+CmVuZG9iagoxMzEgMCBvYmoKPDwgL0xlbmd0aCAxMzMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp42sVaa2/bOhL97l8xXxbbAo0rPiSS/dJFH7s3d9vetA1wcbHdBWibttVI oivJ8fW/3xnKdmM7TiOXiwUCJLFlD3k4j3OG8w0+wjdQHLQYqkyqxIDMNGQiG3KRcgO1g9+hguf/ aBjMGnj+Gn+PG2DQjOljiifhAxfdJzIhBviJ6UPfKg3ffevm2xL6tm+QdA+nBl9I4GL37wC/iemE CxiX8OoamOgewN8pcJ7JBK5LeP53PkxwYddTePLe1s3cFgW8XY5sddO8gKdw/RXeXg8+opUkEYnC H6bh+iG7cGiXb+ziyyIZapEaObhjn+3svy1y38IL+H3uKrAVXF5/grEvXQPLBeQt7v/b0jVtQ++5 qs0Rj7FfrMFPoZ07ePMK35jQnxWM7XiOn8vbp4OwA4Q26bnsA7gQ0MfCBR1cKmHGcKXusTvoB1dn /xRcCFPT7XoDEMI1sS1uf+Hq3E/yMS5yHQ0IpfsCIZKEG24iAaH0KSDQRUq7hpGDhW+afFQ4aD0s GwcWrvgVVK5d+fqGXmxc8BQbzz+M6gsLF0pxrbM4sBC8D/jH2JJ7tLXLbx3k1dTXpW1zX8G09iU4 DBfw6EM1fHnS/aZPfXkaCx7FskN4mlGdl3/7akcjVw99PTuEJ5MyMYrLn4AHsdBGy87+ITy1K12J tkPusNU4x5QCE7tuntErmFtWtoEG0087z6tZcBZY+WWBflPn4xt0Lr9s4etiBl+EyO4ARWtXJuVS ZedmykEqH1x7gcF9m9sDxDTTmZb6MD8PHp2fw0mJo7xcLosWk0jTvozmDtL0dAfGMibZvbXnDG+Q R8kUc8fI1q5YU76YoD9gHsFqsson7TzarrPeqVNKzBCGmSg5Au2fyhEjN7aUKCkW7maHHEMgn1WE SBvebPyyHjtKtRPvmuqvlHLbFqNo7lew9kuYufBgGQ003TuxpolJtcCvjQKaPplYuzSBEPlbVxd2 gSi2K4d1+N3l5+uL1799+BwIyYe3n95s4bPLdu7rvI1WjnWS9fapJM2kSdIo8KD90/AgNPgzshRR 6EyXV7cS6nw2b6Hyq2gI8LQPAhcEQcJ5KrIkPU4ng75UtlvBKQwwdY+WRMUwpIIDHNSKs6k0T7Md lb7Hfo0s8NO7315/3/dONQxT0g0BBm6M0EnKehYMtlkFw70ntH/JDu0fZnOYYzEt3LTtvGKMxXT4 HQZaDKMTUcr0RGS3lgFHJoVrSY/CVbxgKVy9vwcKAiLp6QIHzqfkI1TUHjdAuZdILGZnc4M919va P3Y9DaP11vOa5aghbVB1XtHc0XU/F3tG7LY/eKQYQHcVQv7gnAePjLyt/e/bp+2y5D8K3l6+wfRT Acd60LE3dDyZJPD+VcAFVSOqJBsrDRk8mb4CkaW4Ax6nTqH9Qyi+PFnl7Rxkd+aB5N9l9PdlBCmV MGj3kVAMjjMCwoGL4fpRGeGrz4lb3JcTfhCkjziawe5opIK+NTIzQohEnE2l945GHuWkfBrIkm2a ZelCP+j96K5XBuJg0TD7CwFTzRyJeZInz7a+HM1xs6x3/ZRKKqa0iVI+cQGH8Pyrzav1v6PtUKd9 Q5MplRit43Ako0/yg2vyfOIFI+rb7NoWRMXRE67+eRnrmAUeWl8QMlSTqAejiA+yfwoEj65tW1+j 1pgHgT23t9SzGaOksCNS2dH6eIKSVk8YDCKRqCyNAwMXp2B442HloHIktmCxxAWVfuIKeAkffLTt y95VKuVccsYjbV/yU9v/BU+7JN3dScwGUI5vJFZ4+WU0DDLWu4NpkLWZJFIkZOwUBkEqTnEhuPuF rdHxpxsIAhje7yEUDRCd9AZES5kwzeIAoh+4CvChdTkKrtC4nXPE8wbTu7EvSGXwVMfZvDnZ2Pf1 ZNOerJahU4kl4dPlp2jnztg5/SiWpSpOIIR23v1bpzPHZFjmfwYmVNp2PIfAZrvudOjJ7nnBAZvt WIrQqVTyfDKL3ByXKY4q18i2KOTVISsyUmO5INI4OEfCApfiyN4g0MUfSenHadtBP/dIRV9tmyFp SrUQMbTtd/vH7vGHa4bwBxLoceALpPncn7ZcFIcu0/Xe8N93edO+9lW82FG9C6nk0jDB4qQNpo4K 6Zu88ltKiT+VbzupUC4RiCAqLqhvu0mnDRIuZBookCtfwa0v8jYn+Fzp63U0lEzvUqtEKjTjcUAy R5UWzd/AL+gRhVtTfXEd2RxR23bZ0EUP3RS2Hib+zuXPraux6uZlXtj6BwI644ylPyGfFa6bJ0eC cYJHWbj6/9BSE/yYsooXqFj/Ny01wR81mDDYj6xMoFCJknX48VxC8JngK+QNN11Ube4IQ/7BcMLQ W9QetVvZlalwJhR0w1ixxM+YQFAJT9I0TrXmxxMIHTDXSFBmrkINV0A+cZZoCl0adbemXTIiEtN1 /umJaJD0n0XArxVKZXEQOT2KcAmTfEK3Y6TkKaMEb9nesl2GulWEByauGdf5KFypYTK2MHUrGk9o bRWR4vP+4wmYybQWMk654sfjCR8DTF0AFflNmNWgy8MxVmlXNcumi7M55eq7ruQrFwKLrpW2rrWy 603OpqeihZxg2Rl3j1wYGUctC3bycu2VQ9LjiCNPFh1Q92FZ0jO7fmL4z1a2WDfR2odCiLR/ideZ jnOnTeYPIfrVzyv4PF5OSD29CDSxsflkm7bRZTqgiCBh3HXDUkgi6+6GJNqoFC6tf8vNyEwiAYqD TSpP9x3Rd+a+6EraDKY23+850L2t64bvkC92Hbrco+8gcUS4dhEYDSvVuy/HDZYkmao4WKnTYoN0 BoLQOQqFFqWcD66ehJFD6tm3NLDYhJb+ylbtM7r0pafWlM3a2hdhPKJ7bp+6GMO10Kk6f1KIFn88 o7AdAaS+ERKThZ0FJ5/4VTWk01+Hd7arC5MdXcmOdaCy/2ACjcOh+o1TnOXxYMJlkX/NSRUG/980 1RbOk2zEYIAw5zRHn++0ZejE4mnfVHh2q3lOI3LTTRsKgavcmCKi2T9QhvIl45L91HlKfsRBaanL xR28fmhg8NDhCNPjRmwQCpvhSaakijH8+93+iRsR/LE7TrnHq99dfr56FqoZ1rscl1tgmQvKNxAF F7L88EGN1lMW3SPSgiySaXqPLNqfNPj4X4XyKGoKZW5kc3RyZWFtCmVuZG9iagoxMzMgMCBvYmoK MjM1MgplbmRvYmoKMTMwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTIxIDAgUiAvUmVz b3VyY2VzIDEzMiAwIFIgL0NvbnRlbnRzIDEzMSAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0g Pj4KZW5kb2JqCjEzMiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj ZSA8PCAvQ3MxIDUgMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwg L0YxLjAgNiAwIFIgL0YyLjAgNyAwIFIgPj4gPj4KZW5kb2JqCjEzNSAwIG9iago8PCAvTGVuZ3Ro IDEzNyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaxVrLdts4Et3zKzCrJOfE Ct4gsupO4vTxnHYe3Z6TTTYQBUu0KUIhSGs8Xz8FSLIk6xHTQmYWiSzxdXFxUXWrwB/oK/qBFEU5 GyjJFdaIyxxJJgeUCapRY9E3VKM3f3iCxh69eQ+fhUcE+SJcpiiOF5wtruAsz+CK6627Cqblxl25 pA93Xd4Nh7v9QHgBQWj4AaOzh68Z3InkUmi4WqJiit5dIcIWJ8GnQHBTOOVqit58pAMM4K6u0ctL 0/iJqSp03g1Nfevfolfo6iY7vwJwcG+MKcZC0pyhq2MPR/seTsNJ2Rl8EoYHOROab4IgDyDOq9K1 6C26QBNzZ1Hr0NihM9ROAiL0j4AInV9lX9dUDEQgIwJkOdWKa9EDYLYESJbsEDikB5GhPH8Mbmhr 72r/240ZDm0zmDnf2mrgmjGA9ejGlbUdAdTSo2Ji2sGrLIJd0aeYhOnG9Bn0kWyFjmIR0QnMH6O7 qQqpb9ykXuF7ArAtQeFnIGPZpqoEZU9T1eLpgRUpVK65gkdnz9EUeqypBYRsk5gPZe2ipMwU1FTW 4yirMshr7tCssd7WrWlLmFpU1ogLNC3rrrV+rf99aqOSSK0xOU1tWi7mk+l+aqvsdfs/mVKR951S ghnnDGJhsjmNGPbN6cey8S0CEv68+PsLGjUGSAE+6rH1EDVgbmCmMd2AF/nI+vGxFTiFUht8ZE+S OFcyZ+QnCz/rwccKww4flyAS5K5BGCBuW0zqsjAVGllfNOUsKBzNSwA6tEHoHyDCvvCoNdXtWj7P Usw2Q1pmPRXDGJGUM77n2dnzFAMZdD9D3xmTG6ONWUPA+ZQ8L61ly4crcuzhQaUbEp2bGGn+aerO NPcQ1LFax5rTZ0AS0XcGciElY0ommwHAcGAGIg9lXVQd6BJNu6otZ5VFd6YpTd36lFKUjPclQssc 51rn6Yhg/AARQ1PcbspgbtGoHNUvWtTVIwuSMfUITdw8ruYP79DUzGYhe81dV43g/ybpsgXb2Zur nEBw4zQdV4Id4Aq4cU05LmuAcx9oQhdBROF/Wxdm5rsqZvCkjCjalxGiwROIhKto1yEvCflml2F9 CNbu6hxdXP2Vdulo0nPwhHBJtCDpBq/JgcGHhWHQyLTmrAVVjG0DJKyWx9QGB1D6aUo6FMF96IgG EUNSYFTuCarZM40QoDgshzlEz+B3djMcB4dNFc9PynBQER3D8e8YpRrXtdFgmyGEdF/+x4K/dvD3 9DUadkvDOnLWhygHR+7KEVS/1rQduPAAfhu4wDkB80RPAh6nj+4E4QDXgo46b/0AfQMTHYJMY2OA WXG5gghjAoA+LDT4dXlZk3TBKd47/iqtBJVYJVtxgOGAvoJXRJf23jbBbdeQlAp3Zrp24pqkJMje IZfynHFI2elIkPSoc1kM//ePUE+Oa/DbZbGn+FrXiYQKCONKn1Qm0lwGZGqnJcHeMoy+XK4p2S7/ spMnRIuHcid72oQIDQFHEJ2s3HnAsFvSf+ExF1x8uZNQ7xmIOPU4BB5XdbHaOQuHeCyYzSoSIfgy t1WVUrcQpvrqVkB2oISmM5qA4QBNf9uia8r2PtYdU5AsRLipu4OcWdYQzkIkLFzdNq5C3hapbVTO +gc2BRWJpul8FGA4bCzNaGSDn4ilSGGgVPsVLAja208JcBAsIQniiJlckPCvD7/QT+eK9K4wKIFi TIh0HKhDnnJmXShDRy5Yk6q8tajt6tpWwc6EBjR4TGTg36Qb2+Cx1LZVkVxQrU7sInCsjiF1c4++ v4Q17KfAGaTiCGNLM4LmmmGVPbNFvzBMmGyiyPagCESYMXiisR097q4de2z2M4lo/ORuY7YYsaJa as3RCSPOthSid7ztYqSmtaPvr46PNuu1IDTWTxjttiPOJYGSgp/WrNoY7gOG/RVmUYawAEkCUugE QUYNyaKEddGgiTUj+Fi45FFX2JB/XdfAHzPXtPHMP3//I9YEcN7WOAgFYJLyk429pjuBvTD1Cu2T pfmEHTPNe+2YxbpLUPBBOUm2YfaAYWeyYmFlKu+gDA71ClRXzvsyVGEwQYVpmnuYnk+fP70/R9eu AVL+AufUlmd+5ty1TWritewd5zmnRAqVzsQDhiMJH6JXa25DZDfozgI1HswPfAsttyIy9unzFZpB wVq5IuTBJhSGxcQMyyr4qAfbtC1qqbFULD9d1GrH8IZex9B4m1TRmvdVtIAbKkrTbQE/YNj19nWs t15HnhchZBFx/GJrOM6Mg2+PI9Ly+PnFh5T1Ocekt40VDLKxVMnq84DhAFvFxBa3yHfTRW5uuyZs +brr630x+wzidAgI70LHHczN0Bam8zacdx8v35Y1CxVdr131vbLmmO5sW/m2m5WjhKLmmMueoiZg sqnGLJWDWEM4VmzUDiLN4YFn/fUpRV8zwYiSVHOWykysMeyp1KFCr5y7DYV45ZYOOxTnRzfZ0zVP OM7JnuaJ+IXNE4513rd5kgvOoehJ1jxZY9iZkk+fVzH0cXKLAWPVTve2uSsLmzSWwpLrWwxjpWlO k+0QBwgHeLl3HRimugaRjuws9HohhF68v/yCunpJVLVJx753QwTE/nx/7d5DtzgPQHdbF/fOT667 m/L/9qIPJ4L2fSuEC660DgkszVshSwzZXjO8zGOFm05dXd1v5MOUIZesSvSnh1yqmFJKkmQhlxxs aJTXCyKAhGhpIcO/juJepvrllsyi4bFWejjyIuli17i3cRJ5DiuepVvt+tDGWdg3Rbehoz+f2Dj6 skEz07TBLsWDYwcczVN2wjjFundLFEMkoCJZuzhgOEDJuLHARFg/wUPHBnvYXw0/rEx3UjJo3v99 IZ4rLdIZa0oPZcnKti888uY+vIMatwhjdcF/DRVc9X5xhwmcS5JuqVB+KDHSRf+zHE/QrIGaGMxC 0sHLnffGWjeyfmyr0g6h/vttPDVlNYB49tgcMEVhgbBnBPQNDvJ8kIf4vICyzUH20ldhH/j7S0J/ 1gM8/sjs8ahz0TeTQtEsNSanNXm3pjwX2YEXLTzoPLRJ/DqpdrPXaBozyKKLFMpNW8U+ecgu4XeI myHjVM6MkJ+Bq1zr5Ot/AVL5Q2UKZW5kc3RyZWFtCmVuZG9iagoxMzcgMCBvYmoKMjMxNwplbmRv YmoKMTM0IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTIxIDAgUiAvUmVzb3VyY2VzIDEz NiAwIFIgL0NvbnRlbnRzIDEzNSAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gPj4KZW5kb2Jq CjEzNiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3Mx IDUgMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgNiAw IFIgL0YyLjAgNyAwIFIgPj4gPj4KZW5kb2JqCjEzOSAwIG9iago8PCAvTGVuZ3RoIDE0MSAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjavVpbj9u2En7Xr5i3JsCuI1EUKeWlTbbb HhfNaS4LBAfICy3TNmNZdEQ6zvbXnyElX2U70Votgnh90WWu33wzoy/wDr4AJ8CzQUajiBGgLAVG w0GYpCmFSsJHKOHF7yaCqYEXd/g3NxCByf1pJPQn3DZnJFmAZ0wuXjXJtldtrhYOEne9W/w55Anj aZTG8JAHX/AXzigP8ZQQ/93uPuLFo4xkyYByvMQCXj9AFNUH4V8SJnhJQuMwgocFvPgtGoQBvp3A s0LpshTjlf7lsxiNZDXIS5gJA5+1KuUY7EwZyGfCDp7Dw2e4f0BVtmI6IcMnCBY3gsXghUKbeaHI Vqg3ojIzURRwvxqJcm5ewu7u3iiUkYTRDO8N5+8dnLo3ae6NP8XhII2TjO7LgIaBWoZfVanhJUiR z2D48B7E+KusrDLSgFosC5UrWzzCeqbwd13itwK9uFqCKkFAofPbyp16O1LWAL58imP2PNhTgvA4 S8MwvqwDnNEhqHVIaHpJB1mM9wz3BGsdeSrOtp6CS54Kdp7iMc2y5Ilaop4tT21k2Gn56Rna39kY lrJyphdWV5+eH2seXBOjSbqnefAjMRoyF6Q04f0F6UaIneqPegW5KH+yMJUWRPkIE2EsWsHOROle 7C7mTqBLRJKYcZ518E7QBpeUOeE4PRYufklDePvmHHAE3UPiyClZ1BU4KEtQUsTe3nySRcdqDycO D0BP0P4SZmo6g2WldKXs4yY4DUw1IsZYr8sbcOLaSkwOEcKDf0hIlFH2NJAINvLSiF6SNweEeCNL C1Z7kTW+VIfZcx3C06gzwieIjoSSuDdHbWXYKa4mMEJdz7uocRCaowREFzSTnjsjrYz0hir0GlNt e6arAnsQD9fGNyVZ8ENwuzNbRFOaYYCfuHfwI3DbNhtpwe07rIpD1F+vpjPrMWZnM1cDK72yYlTI AQx9Cjy6b29AYvl8dIkxL/XauB9UBcYKK3u1GU272oxkNCVpmvZnM5qeIRP/1dane4MNI/0NUaBa lfD697e9WoHxLlbwpSAkiA1Rf0Zg/FTgfJw9Qqltr8qmrHOaIL5klPD+tMUaeNrlHyWsRY2tIwmI 8fyQBWL15GmcXsUCSRJdkkR+U5iOl4lg0MnkSZj8ABEMDig7yhdm7Dq6u2/yrQw7Rf8QlUKT/68m RWBW1Vf1FQHJEXExUoUD6WWl0RgLJPETcOzJI5bMpfqqyikM7970mogJoV1jM4sjmoW0t9BEEc6E ZmMnTEePyc4iG7jGWHXmENNpJafC4vterULjziDN0oiwuL+MRRnOhA9WraXI59LW5Wxc6eUSO2Fd esxuZXCI90ZaGV8X2TFhl0TTunKN5UjatUQy4gJ3rB3trx1n95qu673DSGc85cireZT15x1GzgTt EMQCFmLuwtP5QxizWiyt0nW745h0aZCsDT+8rf3XfIHHD+DBHYE0TiDxqDRe4dCTjCKSsjC7riV3 4vMWCHs5vZh7GpzH5KC727LOmBwzLILIffrD5KyFycPis7Imn/na76w/qQ0gYLEqrJrpBeZWvjIW 31TwM9xvaOJ6pp2r9o5yYykso44vHepBsYml2Ntd7Tfv+yO/lXif946qwc99zlIYSbvMUpp2ME5j wjnrzWFbKdp5VpfHsVwW+tFn2vDhPWaOhbf3IMqxY3Huk/sF00sO/q1BA6LtiUFD8k8OGhjrPGjA 9jWLeNzfhHIrQ8tTddlGpHNo57yCCVI6eJTYVXgnrvWqcOmDXMjljxRj9KDv8h0dsjrXRZ/lnaVh 1wJCsYKQlJLeCgjKcN5ce4H9J9YJaKZoaJmFRhv13IyxrHMbj0pkWFH7q6cow+U898HhYPfu3mPd VPsCq8Guta+lNxuL4UGDg7PcEdvDjwqqG+HQk2S2GzDzqEWJ8LY3XohSuj3FWl9C56Cjz3hMuhZT 5KdhzElv0LwVoeWyP1alcpNuh8J3yuS69kOuy7FyDEMUu2XFQpbWeH8JKFQ53w0ea65/qAP2HSnh V3aj3n60RYDWys7GlVjXrO1Avj5pEDLRrp6jnCQpS6L+XMdaNOhuViljFYLMS/jVj1mNdBNGTJkd rQiuBxue0s4z8RQb8+R7SdqhVG1laEXuQ00jEEpMXqmR9GPAw/58Qyn0qsprZtEnFqdhq/Ms1Dcl NsvPpTZWFgNdTY+sFMU8DtvbuuBH91i1kRgdZDzL0lqSQyMFz/btcOv7zMMWOEQClZLv95nBBRFI zM+LgGx36tujErDn1ZVFoEGXIHvHPL3x3ML3WNherRUGlN85ue3Fhh26ce7KtOsAoiN/6gbQiR14 30WtiaK7uSotkh902xjbdsQUiXAnB9jsudiBV2BFMfci+c+vb+A1Nl+PUEhR1R19I7SeeF1e/WS8 LgN4vbL1OXe1tts5CVrgSD0eYoENE3rVmsbrGLdYnlULrLHu5c6JWlm/rBk39fbV3l7+eqKbJt0X NYQl/LvMvgN6bGU4Bs+qRs+PnuuOdQMeqpzoaiF8Z51jmwiTSi8QU/sEDdaZwDH0JIvj/sbpKMMZ TPX61pbARHDF3y1gXHhsuD3c7jUIC7cklt8URjYespCIOKUyCzPo1WJp5y1M7LblcY8dgN/oHFoM ZZjDf5A2Fch8mlESsqbJysjxwI9DnYW22eVrtH9+w9sYuWblq5fDEow0JMKIFUcTlTDh9cM61/Gn LGyRPzeFwFBvFmeNHCg5kjuz8S+YxzKfVbpUf9cZ0Uy7+/RtRqKuvk3SKOFhj1tJlOFMNrzBAg5L qZfFbu/i1rV+0bsUdmb+rTlFFvP2nCL5Rx+IyJLO5M8t2iP3sEpv+L0V4ijvXjZxuj+xVaYZ2uLX Lr5dR9OQiXp268qzWMhm/NZnFPPOKwis74yH6QlTBV044L6peHyuK0eGpau5G3/mMzf2d8/07O1n ejVF1nnejy1illLe3zYGZThjiT+VWQKi4Vo0D6lgcYMR/h+rsVuAfFk5irYQ8zpaxlKMsc/t00BJ GHVGPCz9jNC4ty2ek+GMgVoPFoYJVqEsza4cRfDo0s2/Id0erabGbaXqbRnUPKxHOppgOe0+d03i NCJ9odlOhHZgusmhexLUzzDqcltJ1zX1Gnu0M/dMeRghXYz7iz3a4p53ww93f/mFDHJyNMJ8zwq9 qs/Srg+yhKh9hoX8xBrviTjtpDg2gO/EMAeweA3vH36Dt5WYrtwEFX69u/3rw0WSEbrOO4pidh3L CNnAm6g9bSmkKZS8VdJOfpG5tpVezgYlpqhzWCEndv+x7uDsY92dXRfsuy7aTBc6RC4jLEb3PeGB w9OOq2UITmTvTC+RIMpmi75ZjZglwplRhcKuoMehZBKRzuPkmCQJCdPenpfZydCyhVn5YY+pSfKw 4WHIx3brx3f/B4aWy/0KZW5kc3RyZWFtCmVuZG9iagoxNDEgMCBvYmoKMjU0OAplbmRvYmoKMTM4 IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTIxIDAgUiAvUmVzb3VyY2VzIDE0MCAwIFIg L0NvbnRlbnRzIDEzOSAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjE0MCAw IG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBS ID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgNiAwIFIgL0Yy LjAgNyAwIFIgPj4gPj4KZW5kb2JqCjE0MyAwIG9iago8PCAvTGVuZ3RoIDE0NSAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjavVrbcttGEn3HV/Rb4qo1NfeLX7yb2E5pK95SbCWp VJwHiBySsEEAxkUK/357SJAiDYHWiOP4QaRJAug53dN9+vR8hl/gM2gGmk+INIYbEMqAEmpiBaUK age/QwEXPzUUFg1c/Iiv0wYoNNPNZYxsLnjeXyFoglfMT92VKL2/a3834u/2GchEK6GJtPgBgef7 /yZ4J2otlxPJLExX8MM1UL79Eb5KYBIfDNcruHjDJgSNu57D92/TulmmeQ6vu5u0+NS8gGdw/TF5 fY3GkQkhkjFqrOJwferZ8NCzmf9R8hxfKScTw6UVhzbQvQ2vsqKEF9B0VVXWLczLGlZd3mZV7uD1 5SuoaveBc/Usuf4Ie8M0IsSYYU8zLPGgMODUnjLsb9dA5WpostZBWsygadM2m8I0nS4drNKqyopF c2DXE4z5wkOKJI/y0D0QhlKuCAbO8NnJYzwEAw8pctpDCEqdlXXWrjeg3LlssWxhWhYDL1FNmDHE nuckIU7ZtuhqdEpZHKAyeFwS6gZtH7FRjuLRaE0FbtpzVnrkhZ0JAy9UXQtNuXJ+o9yl9QxjEMrK Q9BAVkSNRmtCo5FZITjVKl40WjOCw7rscCcWOxggm0O7dJg0swbS3R7Nmgae4+dpCyuXIkKbt1m7 u6rx7wsMoFuXr2Nix6gOxU4ZwYziPBp2aMMJ7FbpGu7SooW2hEWO4OwyGkaRRxINexcVEa5CEREW b65IRES4GkGkXWLYeEhuHHSNm3f5thCVN1mOme4eiH05nkhfkJ/7NMckV1qHpLmkN5P2ZlJA13sD JfvSQP5CSrh6e4/MESHAenGuX9R9skse6RfCJSX0K9kuCfCLGst2WFZah0Fa1eVtNnN1A8v01mHM 5jPc0dvtjMHah3K2iea7sv4EefbJwX/eXUUNYROcEI2Uwoh4+RBNGEHqLmuXm32728Y9ZLPdfj4u zz5wCaGKaUXEk2hUsrMPg+GUfXWD7kunn1w7XqOTYF9wokNrtCKGSWN5tCK9t2HoDLfns40rZr07 bpwv0VidGlelSFsc/PbujY/Y3W9/vnx/BXQiYwYtZ6F5l1KsuoqJaEGLJozg1C+YYPSiOR6i9CZf F+4WaTdm4pmr8nLtZlHxEDJ0E0shCTc6Hh5CjuDxvk3rFrdsV/hU5pq2r8dvsTIx7HqiAqFEOBCE WBMTCSVGkCAMZnU6b4+haHp8EJL/doWLj4nhwSSFcOr9GakUogVfIvJnsyzvmnsgMGNUZV4u1n/F XLogLJyxKoU9eDx+hjZ8ufjLAlxa52v0N/5Z+OJ/nbVpkXWrxqfOV/6Tt26NCcN3o79lxdTBmy7P Xf1PkTZBBzVPvCDkW5I2wWUoadPcECmNihapexsO9i4647tmK5ggn75xywx9gvt5IA0wTjhRZ8lK TJlTttTuDtE4JQuE6mdCilD9TGOyJNY8dZ0e8+QIczmWL3/3THiWeT0GsJuri5hkS2geSra0plZY bqORrb0Ng6V3jS8NmxA7ojHEaMatTs4AHwuMOLQgeTDIGlhkt8jtfFudFqWXISBPfUoq55DOZrVr vInHHknOSwCWhSSAnu0LobT8GgEOSQF2kK8/fOi9MlQDKcdu/kFaGRARWpx6+s4fK0Qc0rrsvEDp G6NfX13B0qW+g4xZNCWloUWTU66YerDwPK1oog2josZGxfFpofiuhWlau6iL58FqtdbYElsWrx9G G0YWf4kLR+LU5TNwxTStwJu17UPjhoCwoShYQaUyNmIIiIF+0lxsF9+/YBFuL6IuW4VrIUTjVZrG W7YaE0NmpQ/4jd+bLved9qE8jD/pRZKoiJhgyZcJK5W08fopaQaKxIfvs4mb/MvrEPdS94dnMVeu SLC0ywizmMHjja0UGdMYtnsevY/lYLGEdCs6+LyYeaq6qrBV8EJi4duJ+29Pdg9EaUOVn9me1T5Q NtngxwaFbLZaKcr/vVilWT6ZlitYpg3yunm7VaqnyPYmx2LeExoauLcoOWxoFH+ooTmlQp/NMJWU oQyTa8GFsTIaw9zbMAihedd2mDp6FeJLZp2cs3X0YU+RPCqNaqaINPEkh70Ng3Vn1a3atNW3wivx 066uMYvEnZQpGyq5UCL9BmTxcocday1W2d9QZRsIqvSQykcEQNNg4YXhP8K5jIYA2jDGIXvlbcOi f/gp6jxF83D2jDWOERNPckIbxrTprKm8GP9tIZDhJz60xrvTiM6XYxw6LdaQFS3SpmajuvpaucIM UMbtorQKpdBMU0OsjZYC9XAA+fLggWfrdXo3Fnu8XictcoyvHXAKWeLo5DBHdtQ18Kko72J6Fel+ cHtImbbCxGsPzeiE7jCsC8zxebmfMkQFIWz61us0Wvvehj3hINMIDKMDuLSFBw7XGYXs6sxzW9SI U8/3U+GygFnaplDlaeFi6pVGyHC90o88TbzhsBkd8uGfqi5n3dQf2vIeqDAQMav2CCRR4m4zWEuC 6oo12lpGo2UcMzrc+9z5neZPrL2MutnCpnfbzcY8qSAy4mYbTvDed3W6gj9f/gXzGnu5/12+v/Yp aL5RjBeYftNdl9pTTMxK2Izit/XmCGxUlGz4oE8gQJ52RMvLlozxzcv58GTfvW6x+W5W/lOTPfvQ ZI9+08meDZ/sccuJkTweVbDDadqPyzrDLYteeQF/oA8KhyG6O7aCWeymRG7cZDN/wmXrwf3ZQozq q8t9YDdQdq2fi3hx+ng+wKTfi+dl4A2EQzW0xod6Ct+mN7mLORO0yoTOBJmQknIebSZoR1XQS5j7 w0b9NLZAN23ELd/N4p7yihI6Bt9l/ljSRzftT5ug07xzjjA7EJt++T8v+n7/CmVuZHN0cmVhbQpl bmRvYmoKMTQ1IDAgb2JqCjIxMjkKZW5kb2JqCjE0MiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy ZW50IDE0NiAwIFIgL1Jlc291cmNlcyAxNDQgMCBSIC9Db250ZW50cyAxNDMgMCBSCi9NZWRpYUJv eCBbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoxNDQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9U ZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA1IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIg MCBSID4+IC9Gb250IDw8IC9GMS4wIDYgMCBSIC9GMi4wIDcgMCBSID4+ID4+CmVuZG9iagoxNDgg MCBvYmoKPDwgL0xlbmd0aCAxNTAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 2r1aW2/bOBZ+16846EtboFFFUrwo+zCXdnYQYLrITAMUi+0+yDJtK7VEl5Saen/9HlK240hpEkfa BWbQRJGlc/3O9x36K/wJX0FSUAxSoUAwCVbDJ6jh7e+OwNLB23f4b+GAgCv8nZIm4daz3b2L3SOi wyNEnGWZFIcH7R6Q+Ad8hSSWIpUJz/BCAme3v+KzacIVjVNJoqKCX6+AsO4m/JcD5ZmScFXB27/T OEF7rhbw6kNu3Spfr+G3dpbXX9w5vIara/jtCq1K4iThCc1oJqOrJ78adq+mu1dTtCKJFeNZ2pkQ BRPIwYR3K1u6psxrOP/FgVlAbW5ga1qotZ4DXjbftMVfGmhsXrvSlU1p6hj+ibcUpl3PYa1zW8PC mgpv3xa5a+AMygZeR8euKCoYpfjO57gSda5gFEWSEOi5UKGJDpqVhirfbMp6CXOtN2h1WTcmXC+M 1fEutBHa8wwr7uRSJFhGV1V0nMt1+b3Mf77OZzNt441xjV7Hxi77KQ0eZLJnQXRaSkUaZzLL1MGS o3hEr5pV6QD/W2EmL3wQtN1YTOAh1S8dRqSqdN2cQw6fX9WmPvvj4uPl59dweQGYYY2futZFg4/B //HDnxkTt/lEQxOiOMeGUeMSKrMfOwKvvr/pBY+lVAiSjIteyB9L+y9zptKwyW3jm8AXja95jKIP TPkfPX+D1T0Hg3+x3W34t9o0MXzsauxrq51vDX/9ZqXDff76/vPdhwrsqFX+TWPc7/ZHJjlD4GHj GyRVA9cqxBhvTj5bH/oA7u+D6LQ+EE/BtDuOSpIywcU4R49A7daGe0ENrlZ6u0MqhxltNxj6WevK WjuHIL/OfdLcqtwAgsXc57J0RxaPhwolohNhH2tcZg+/OHoy6HsD+vF5X9YGQ3MBeeVrGFyL065c BN/hJsTqxtgvYBBFQ3zQ2O2UQSEJPzUoKc8YIqd6Rs3eHxe04aG6uQgdnu/HXmjtShervC5ddRuL Az+IuWcIARopZ0I+lsF7GQPZWUqAYtbQRjqYduk54XD54TY4dxhKEo1ODVOHlo6elpqMECqyRExW sgcbftjSvl59duZISOoCJ1mJmHpTNiuYac8A8D6kJest5HOzwQH4Bq8Xeev0HsG12ax1H4OZUGir Go3BhNO+/TcrE4C/ftkgPdmszRZHwrp0Gz8S8JrVebHyxMuHNvpRaSUpS5XMhBpXWzTUlhgEua72 BAaZC5rrkNwtmg4WsPKb+C4HwDdIhVPrOayORAdrSOatUenj1lwbhO35sT0HTvfc6EA/OlEXHZok p0en35NR15Oj4RJDdCpcIjmjSAXIZHDp03T/GPmEvvvp8bsxS+wpX92+uD3xeRAnEyaJZISk44qZ hAixAZhvjVst2uvyySV9F0ifk7ToTtJ4eqrek2mWSMH85IimEHw7G6LjsPxqPYi+y+1Ge2UA517J baxBalh1mLrWy7zYdjqg8bn9gpowkN1VgNaZaRsv9cKvQQla6AFDotIko0o9S+9Fx0ydDlHqyFik bEsvTb2V+DM6dnH1F8pPtM7/NCVloXvt/PR0UqYkjoLpKAtVA6rbpfM86PEgLDAMd9Va6DSFNPDR Cf3IZKMpfciSpSeRvjS87twP5dIFvNaAYIC1ZYN9G7zJ34gZClrJ9gcx54owKsaLITbcFhSta1Dq WRe0WDd20cDqx7IoOrlW2F7LPl0WCUqpTOV0sogN9fQOr9+bsODZydCDFipyZEcLYydXQIwNptcT lyWcE8aTgSh+/raEsay/LTG19pUwL+c54h1y/RuvlM1Bw/928T5Uykz75QiG5/KXc9h9CPJvptzx kb7KzVhKs3R8BXM2qGBTL3zSlrc7h9kWuivzcrHAfqoRDrWtMN9rs9yew+dX5PNruNFdB+brL7dA fnGJHHlusQK0+xveSPFG37CmRvZ8eEGPKCO2KZWOJ8psqN2P1ic+wJ1pHustWusXGIgtWLZLJPw1 DmqUqPGkxXq6XFcZks6MTke12A8Ve22m9DU9TYV3k50kiici44O3R8/kKOlQhztj7Rbd3Q+3f0zr Nk37bruZLY/ZfS/FhAl0Ox2pb9E/LJW0s6Dv8iy4Wuxp2U+TOpyyU2uakYynRMnJahpt6Lv8r/LA WJr8S5hFpYEZjuQvSOHe+z990Fu/x0fyqb83/540JoKeGhPkTwmjE26g0IaBaNGTjl4UgCd6Saik Uol0OicVuZ+zHiTIlA7zIaQ90tuYVkWx3sd6fNvdfAhoncd+tFmDk/dIc15qW+hN0+ZrsCW+n6Qx R96wezRh3fsFUJbGhEjBgREMrqIkWPH2oiIREjp80l9hl/1Nv8OZjx7rxpaFf2byDHndCyrlcGJQ BfHwIcTIo8ujoFLeP7qcea2hX7rAE4p8rit0OO8OMREuoDJ1swJndjet1+ZGz6c8BeRp2j8FvF66 B8YIJpZJNnJPSmgsmES6sTegt2fc+jrrxkmotp/+X8tqLpLhshpVyP9wWc2l7C+rH6vMVAmpUkEm G+YHG27d/lT63QgONL9DeeMptievnnNjapbG/4BDD3k8XmvDAPR/1+DaWa0bB7opYmTBJUpTFNLr dq4DJe+dqCc042S8wuDZAKDDZsft9UKBreNNRiXk4illMpKqJ+DKXacJozzjYqRMvs3ewYajo4bW egWF8sd7rud3JNKkXyMQNOsDyGPli7yMEconq97OhDv+hxNTn3gs4UVeNLA2Rd4Y6yYVWkgMTmXh CRGemE42qMXwqDzssn2vfcttaVrnv1JyltfzsxubbyDfbKzJi5XuVllzs2tpq+dtEboaPxk0aTiL Knu6mSCBlJKNX2sJcc/5UtktsrrU7cXypO26Z3JPb9c0yyRLJZ+uXYds8qOBP/w6ySdCf8d69Y2L AlIXzcH7aHy9yiQ5ddTglPaHSVO1qhweSfmvpJSLnU52+dbBi9q88ANl5c88sRzqjv0EJjBl+8rh kdSD3CehimaJpGQy8iOHB1IX6LFpl6smLDhv/GLZ6oW2djdxw6FP980n2PU5csZJYU0ydVpcFFcZ I4RPF5fh4XkHDhVSZHC6doFxVHpSt7k8VXcpJnmWEDkZnKMNw4KYG3+63u2623npz4i2lbHTOi/F qc5TxlDRjD6ePXJeivvA4eJl9w0fHEW+2q0x1ZSeqyTpe45zc9FW5c+E7rxHRjvg4EymSF/FuL0+ F7H07nd29Pf6zrzpXNauXYfv8rxYdgfUtl1r9+LIpIdFeHQrwhnhMV5G4FE8phlTPN2JcApBhP/5 XybYtNIKZW5kc3RyZWFtCmVuZG9iagoxNTAgMCBvYmoKMjQ1NwplbmRvYmoKMTQ3IDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTQ2IDAgUiAvUmVzb3VyY2VzIDE0OSAwIFIgL0NvbnRlbnRz IDE0OCAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjE0OSAwIG9iago8PCAv UHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFj ZSA8PCAvQ3MxCjUgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwg L0YxLjAgNiAwIFIgL0YyLjAgNyAwIFIKPj4gL1hPYmplY3QgPDwgL0ltMiAxNTEgMCBSIC9JbTEg OSAwIFIgPj4gPj4KZW5kb2JqCjE1MSAwIG9iago8PCAvTGVuZ3RoIDE1MiAwIFIgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxOCAvSGVpZ2h0CjE4IC9Db2xvclNwYWNlIDEz IDAgUiAvU01hc2sgMTUzIDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlCj4+CnN0cmVhbQp42q2STUwTURDH/wd7ICFcYKO9GWPqJr1wkmCMwsGDRhOiqHFVTsYDqIkH 6ldIlY8WRVPgopwIKrSChRpMpZR+BDCpLS0boIZWpZVehAYSU4S06+64W5egJNyY/PIyM29+h5c3 wC7E28uYMx9MW08L/jrBV5u2npxrOdB3acf5xmOYadQKfCut+mktQtl5BTlZ8Qm8eeaRtuHodqX5 OL62MMSbKNlLizZK/YNcyk3eJA9sE8O3QN4amm9XiLVTfJNYnr99T83UzS3lVTXWu/bSp9sUNlDE QNMG4lX4rjL+RZnSDBnkAXms+6xqBW9AtOlpnKNJLtV3Itx5ZPndKQpwMtbrhdZrhfSRowmO/Jz4 Rh+oVa2F+xCGSiVXxUSDrrNKO1i3/9mZfbMdevJXWq8WWK8UkLeS3JXSSIUwWLpwT7XSj5Fz6IT3 7G8nK42ykoclHyt6Dskn31w83VQsuVjRyeaG2dyQbsmkWssWZO1FG44ScYSRvIzkZ6QJhvLIiVJ6 GGGE+WUvyQ4ULbWp1pcnWLcjY9dkHBpxUkMBDYU1FMkTUkq5+bN/z5pds96PuFm1vHeQGYDgR7ID P3pA06BZ0FyeWUgRpJ4jYUHOg4wNrnrVsnBY7YE0DimMmAWhu/hswffXSL5EtA3BesQ7IE1B9GKl G63nt77MbYToBM2AFpEeQ7Qd4YcKUQvSo6AFEA9hGB8e/LcbF8oRfAryKbf0DZRUdIUEKA6KgNwI tOFc2fZVrC7HWAuynvy7YpvWPCiErAvuJlQd3nHzjRxcZiT6sOFWSPQqpfEidiX+APlWgr8KZW5k c3RyZWFtCmVuZG9iagoxNTIgMCBvYmoKNjA5CmVuZG9iagoxNTMgMCBvYmoKPDwgL0xlbmd0aCAx NTQgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTggL0hlaWdodAox OCAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlCj4+CnN0cmVhbQp42mNgAAJWIWklJRkhNgYoYBbNWHX9y5frq7LEWMACbLYrv/8H g++r7NlBKmz2/IeDPfZAVSIr/yOBVRIMrOnfkUW+Z7EJoCj5/3+1sNR1VJHrsopfUEW+qih+RRNR lbuJKnJTQXwDqsgmSb6SH8gCPyoEODW3I4vs1ONiF408jRA4EyPBwcIrH7fvJ4T/c3+SIh8rExu/ nG3Xwcc/fjw+2GOnKMDGxMjEyiuuZuURGOhprSHOBxQAAJ871LQKZW5kc3RyZWFtCmVuZG9iagox NTQgMCBvYmoKMTg5CmVuZG9iagoxNTYgMCBvYmoKPDwgL0xlbmd0aCAxNTggMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42sVaW3PaSBZ+1684lZfJTAWivkryvkzWye64apNNMlTt w2QfGtGAbKEmamGGf7+nW4C5OhZ0zSZVNha6fOc7t+906zt8ge+QUEhZP5E8iTPgMgXJZJ8yQTOo NfwHKnj7T0tgYuHtLf7OLRCwubssobG/oNdeIRmL8Irxs3eNxfau67vF7m7fIW5PFhkeiKG3/TPC O1FCSdbnCZ4/g78PgLD2JPwtgMoUcQxm8PYftB8juMEYXtthXcx+vVfDoa77pp7cwM8wuI8+DBBc 3I9jLggR+B8Gzz0bTj2bupOiHv4mjPTjNEv5LgayxfCuLOEOrFrCUllQQ/Oob+AVAlPVDVTmlUME HwYRIroAxgEFLMPHR7sU3E/sEQGwJSBJUyqFkM8/OTpLAHgCCO1LllCyRbBHgJr2oZmqxtvfLA2M ivFY17pqIDfVo66tagpTWRjqoppAUTW6LrV61KOfoy3W66kRafSi6HgiR2TS8XPi0dFLggOOgkOk h9x8MksXHFoHNTVJDk19PgoEXiMJT8JFQZIcWuoD/icLrzDk20hwgVAZPFTr7wttGxibGhQMF7ao tLWQKxuWlkwe0qLqYryYFb8Suian0s0hOVzELGZHYRC9tEa05AjZT1wctDj2yYlef3ttTV2vPAM+ /hdzlxL9bz/vYOlAQHSSgIwI6JoCScwymmHqXFYgj3IAMUQHkVHMpgYLhN73PBS2rRrumzvHCfoG JrVZNlOoVaPxrApLBvKV1xovGMGoVjMsJbkqyxUUY9gJHmeKxELH6YW1PmpN8TTSoxK3bNGMtCph WSBAB/qVQ/mLbfDnK6jNommr29jAvDbDUs/egKpGreXFZKLrfVO9/RpmpnY/Kr3anLljV88ZRjOO lYqJSwyLNj7yhnF2aNjd758tzNSD7j/FxbZj94Xr2Q4DoYLJJMkuCBOyDhMsG6l0IMQTu1ELgt9Q AZ8/nkDgnh8gLxJ5mBcfVW2nGEfwYTFU1YM9yAsSZywRVyZF3E+ZyHgL4DAp3mP/g496peugFSAT XS0VJKFpmoazNTsqAP8q7BxuUQEENDWJCe9oaswxhnnMZShbHYaTfr2BW4X9zowxpc3CYhV4uek/ FsJYstnLTH8SwpKRNGMsvVII75jOjmrJ57bqga+IM5R/522OujZ3PIu+wOb9whkTVKsZ+v2qyrln 9QbFkcPvF2uBg5K30X/u2h5dKWySGL/Y2B69MNSxEUqRZNcpvl3LNxiOLC8quPv8KGHdI+28LBoo Ta4aJ/ewAd69D6jycM6Mo455LxhKsozLK4X+DhlZfJ6MRw6F7+6+s+dmhoQgGUGnnQQbVFcWUsEY zSQNxgJiOMPCJ6NLcDLNOioU3Kv8YTFHQka6DMoCTbuyQLOYEpz6wrFA0zMsrMwCpu4jTkKOAUAK nMRD8bc09QOUauU0IcrFRdMGi20W47GLITyt3pmNnlFkF/TRA0WWEM4PLeA3LN5TZI46VDGMiNQ9 MrpYBJJU9L3rdmbldU27N70eclOqYa/XPDz0et8Yk08QfEkXXOK9E35BXdsxWyZHGNaG74xK6DsL 9wYnFqfhMZ9znFb6J5zSVaRuYznai+XNSN0hlhkO9tRd19khZ2LZY4h2CfnDj6tuXv1vSPVGsq6S PJaCY0vPgilVh+GMevs9V39TwwIb2coVcuWnssLahQ4paSgRXSSN44BJ/Mfi5KoZd5eDLYZDDnzE e9v9LP5Lq+o2k23IIk4Z71LE25E4pYSkJ3iILowFBHHIwx+19gsNo7Xpb2GEOfBcTY4Z5Sylkl1X lEnsAIkjiZFPH82k+f9VKJztuuYsywRxq4XBKlSLITqVs95JywLBDP0yyhuwpg3emdPmeNDOEOr+ KkN04EGRJm5muGQRiURPHswc1PQotarZj7233S243nubNIuc91jceV6WCUswzeR1K6M73ttieFoZ XXvPLxHkbpPA15zpalgXoy4NJ/pBlWGUvdj8aN1esShQISVc0XCiPfMpOyMV5ws7hfVaaGPmIbsM 2tCxyxCc9WTGSLAms4VwZPdMzedFNbEw0Q2SUJaYC2saSrN0ewalfsRZYjnVFepmPQo7RTFJOrce gmMUS7gI1noQxLlh0sKnfw8wHd7/Nghqdtp5hJaYDYQJFmxsQgxnrF6vI7iImBgzgg9373vzWvth YE8MYYhijRXXxSmLs+cw/QlqMqn1xO9guj2HdrQf+v0IPIKUuZUO92VlGpe7pjSTVVBvZd1HfZmk kpwcDi/0VnZu1P+o5pv9Pes3QXw3ww+T6TqNJ27DBqaFrlWdT4NSw0nn+Z8zkiU8CxfIiOEMNbdu JbBq4F2eu02vr46c2oKp4fbdVxuUB5Z0TuiEUpQ7JBwPLDnDg3sloFnNtYUefFnoeuX2ydzCYK3n pfsjKBVCdl4elARlargVIS7kOSbcft+m5ZXFo16v9WyZwMqHEbLugEPTNGbW7iLoUwl0agSRTMYk keLKEYT6BRKeHDXuEktdpUYLs1GyeeWFbKnHzV8xhPCMQOeFTyEFd3uAgYaQFkN02sG139muDMxL lWunXPCIcyCWggI/jlSjhuv9b2WtnuE8HVTUCBJ3FjVxSgWnp5ZFL1U1iOJMEqyj+xELwSbEkYq7 wVfri8KHQdjaKGjX9kniOMnicFsn4vh9glbVxj5zvrtu0NbDWwQW1HbeuT9KTjO3zBSsGiKGc4Hg XpVzsTADhYlx+x5pwHo403aKvQLLXvvpr1oGF/LUMvhzLyZcvbEn0s4be1JSyYQIGJ3pufHDZSI0 GrH4CF1Oi3y6lcPaR6yfW70H3d6GwVGljWx0nnNnyFiWceehhbKMEp6F6+yI4dyoNn6q/cr1+I0o bt8B8lND9VOD/T2f6tEbd2BiMMqRtgX2hdIdOJ5wSIqNK+Xpda80xfw5A6qR3eiSN4cvjyZ423bA urxxet8RfrjZ00ZT4+Z6pMzFkXvByywrF0YOj6mLSVHh5ODq4+ZFqu232C6CBhdjnZsEIYyn4eqk ZOcWh3xhdCOx30y0xbB0+vENzJV7x7ZtHfm0KEf45xMpX/4HKT3elQplbmRzdHJlYW0KZW5kb2Jq CjE1OCAwIG9iagoyMjk3CmVuZG9iagoxNTUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAx NDYgMCBSIC9SZXNvdXJjZXMgMTU3IDAgUiAvQ29udGVudHMgMTU2IDAgUgovTWVkaWFCb3ggWzAg MCA2MTIgNzkyXSA+PgplbmRvYmoKMTU3IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBd IC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+ PiAvRm9udCA8PCAvRjEuMCA2IDAgUiAvRjIuMCA3IDAgUiA+PiA+PgplbmRvYmoKMTYwIDAgb2Jq Cjw8IC9MZW5ndGggMTYyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNq9Wtty 2zgSfedX9FuSKpsBCIAE8zI7E2dmPZtkcvFsamozD5QEWYwpQiYoK/r77SYpWhIlx7S4W5WKbfGi 7oPu06cbuIWPcAtRAJHyhQpipkCGGkIp/VBGLIbCwBfI4eVvjsO1g5ev8efYAQc3rh4LWPXAef1E KLWHT0x33irCmG+9NRTtS5uXMXrZLTA/ou9UMX7A4Lz908MXBVwr5UcsgvEcfrkCLuqb8KeCIApV AFdzePlr4DO07WoKz98lhZslWQZvlqMkv3Gv4AVcffPeXKFtzGdM40M8CEO4eui74dB3B3STd44/ uWC+FiqW2zbw1oaL5M7AK1gZmNFvZZGaCczWoyKdwNxOTOa2bHqCIXsgRNx7FAjQgiDjKBahOvDV 3mMwgA4GET+CweU2BKWFuSmuDbx/8+kCknwCr/94/5k+zuzKFJAlpcnH6xdea+vp4MRsHxyH6zD/ x7dkNDKFb4vrfXACfIZzHZ2IDkKhYy1rG/bR+XMOvu9jQtwujSsdTGz+rESUEKuM8Li8+uR8uJqZ 9daHhVlk6zS/Pn/98ycHq1k6nkE5M3l9Ab4+v0sT2AKPFhrTkDMunxbtXu0L4Rgxue8DfjUaZ8zX FzBKxjdkIX2EHhUbKzdGmixz1UX0yx9yeaNA9I19IXUY6jgeLPjRhiPBn+bodOpgnDhzRv4jAeKf OaWBm53BaFnC2i7BlSnau1jif5QUi6WbEZovYVrYeYVbaReQGYyDe/BaFvUV8SiazniApBtFcQ9Y vcY13rjGIdAhOSXifafkK8ngw7t7NHd4HNPs1LVUYUvm3uPWMowVl5IIuHchObKWGxs6a1nlXIIL ODHTZJmVME8WC1O4QaM5Un2jOYwki2MphovmSO0jsB3Gg7obyz7unlfZqwMtme6uuPe48t31N5bH SpeDt5efPwCnBFtOvwoR7pAr8irnEjXOKdwaKP6QKWacmryEn7YW/Qme78KuuXiEaNopI4KJgIeh OMnVbdRbGzqoX1Gk4b9/p/nYPHNwOTFJ6713etBpEeyzzI8EgYyFUuJHtOo9XhC0Ntx7f4xeYGoL GNu8LGwGNscyf35OFWHdSAa8vEoKrBlYgU05KBtp1VtXipAFcSD0YGyENuwj9R+qmg0CrfuEFmoO d7ZRUnT9p78HhSNivck5YITJcGhE7EjW/OkM/PLbB4wQVBCQZKUp8qRM8VqezA04DI9BqVvruHds KHy1jIarVGjDETT+Qk1VLHMUWsU8yTbAfLgcHoeY6b44cI3ddiCH059owxEcSEw2zr+5vIBFYTpF jMUsRHKP9WlVTMuHzPlu3EMFrG/XHwdR364/wjY9jqNgsK6/teHeS7cqq2bHwkWa2+MOe/2jTIZ9 K7aSmB5KqsEqdmvDVpShmxhl/7SuBGfyCbaxSZk0pajx3xsky2hUMff6ZJkKlIojFg7WGdQ2HPI/ LVGmOJJpu+yLXdt6YTN7vX6wacMeXWp8vT6tawuoa4t1p1zm28oGZonDPnJaNoJ+lpT+AeOqfu4p q+ZtrZrG2gd9a0QQCKbIibH3lDTdX7XGBu/Aqr2zdygYcPHAop6wUzDfFyZ3VDLnZm6LdaW8sGYQ gWJOj2cmQUHWXDyruHWerEdmL/G0iiQ2peGpExddTW32uoE7k8MknU5NQeE2MXfpeJtad6PLe+JI AA6NBDw0SLADIwH1wEjgVKbXTPZneqEx90U8FNPf29AJoapVoTUpl2gQ6VHjNlOwiXFlShKMau/V p7NmElbTZD0uw7sa2TqgItEsDHsrM8aVVnIwnUo2HIHsZ8wacjw338umUMDSIWxp+TBJhjEKi1ic xpEsJuN0p/maJbiEWbJPlN9smtPU+n9PlZzx3lQZhdXsZzCqrG3Yocrfrck2ce6MmVfRnc7rYTP3 1dcXCE5CxcRi/7GaWax9mR1T6UO9if1s5iwsUgz25QI2wmCXL7kMFFoRnEyXnHfqc9McEs0Xxi0s svsozdJyPaA201zIvtoskJoyTg+lze5t6CzdFwMZrY2z2AWi+I92gogrwSMVSu+JXFlrf6m3DfH2 a9b3H4L+mCzeA12J3vmi6JUsPsnXHdCV2Pe1mlnBr8ssQ6GAbahxtU7IrV/1pMh0NZvYO1NkyRpp sFzZoto62Uwyqu0THy7zOrWwYLiOxGCCcyFOlxg8jLqbOlWuL5JiI2BrCUsjuW9LFPoJrNBw1EvE A2aOxY/ya4Y3k/gfDTsi1lz3rmYSSTE8vOX1tGqGNnQm4tNq34bWM61mcLDFNVUTVO3L0T000xvb ojDjckhgAtZ7q0DJSMRa88GAQRuOlPkvm51viqaySCYGI2ZaR/TCWAyc5rrNJojiWYXUOMlzi6q2 sFQsHEKJtzXN5JDIBbIvcgGPYpT1wXDIBfIIcn/VQIArC1OiYCSyWJb1VmGLTlr68AdtJ7oaRpek kxbD6pb6gRWGHsXf3raFUJKFp7NHNefddSIZUTO12cYfbuSjA9W7EdDY+qCvfLBGoLVhaxb9kbbv SePXns/sqo75LL0xcPH+8991SXgFH+qop9VIRs5my9Jk60HDOurLlJxRn8SGk/1oAhysiD92n3g7 FDqMeHx6XHaPW5SmKNJq9rkDAGcaqwV/gga8B0AEh78SG4c6JppaT5UhydcYHfiLzasuCAPk/7Sf rwULu8272t3Prxot1IMRljzxhL5iu9NSPi2FCO5xaTbbMsyWPJks7abbGudHmq3jQwXvpEwRm6MN jz9noFSkMFzioaaJ9zZsz+yLYp3BW7NCBKjpak6LJO3EZ2x8+EK6IoFbOlwzT24MXUdtsSyqyVVm 7c0Syb8SJdiKrdyedIykCoSMTyd/ocTB80CtXMxhZMsZ2k7KB9e8Ps5U1BxQtSNpjmlZjUmuUXGi C9gkNKqyrCcnrkkhCoohuVJEQf9TQzxkgg22a0M27AOINtzQuYNy02y3eGGXAAUiUZ2ucjU0r+B1 km8OVWHlyerJCgnyop0s7XcOnGvaoD19+buaeCP/65ZnRSeaql3YRujtnGE49ayQlhvp+fgcpqNw IvjRGYYeOSy78nd3BTfDEQSB4KiBqTXw0s0wdecEDLUN7v5EZFIf/6qOiQ4Z87Ire7P0e9oOvRbW YU0+ePwBWyoVdwRjvzLJQ+nHURzr2pRd4LznVxb+Ze7S/JlrI7w6PkfnQ89oqlR3Vd0JBq4Fk7E6 rYRH8UO2EYsmmcVkGtu8KyJQQ4SoqJ9Qo+8tkA+hA8+vlwWWxizFqKZMyk16PRvZYp/cQ9T1jJ24 lVvFSlfZ09GTs6rTbal6TAO1iSkqqvYHze4tte89UstKJWkPbLDk7or9amaNBfntMr1OB03NrnR/ ZGqGAXaSKgyGS819Ce/R6b+LKgnzNY1RbYZ6tm5RTV4d6aYLzhT0cV3ts63W7+N/ARb+owIKZW5k c3RyZWFtCmVuZG9iagoxNjIgMCBvYmoKMjU2NwplbmRvYmoKMTU5IDAgb2JqCjw8IC9UeXBlIC9Q YWdlIC9QYXJlbnQgMTQ2IDAgUiAvUmVzb3VyY2VzIDE2MSAwIFIgL0NvbnRlbnRzIDE2MCAwIFIK L01lZGlhQm94IFswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjE2MSAwIG9iago8PCAvUHJvY1NldCBb IC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBSID4+IC9FeHRHU3RhdGUKPDwg L0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgNiAwIFIgL0YyLjAgNyAwIFIgPj4gPj4KZW5k b2JqCjE2NCAwIG9iago8PCAvTGVuZ3RoIDE2NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCnjavVpdc9s2Fn3nr8A+NZmxZXySQB52s07b1LPJbLr1TB/sPkASLNGiSIUgo2of+tt7 AeqD+rQpoZ3JjC1FFg8Ozr333At8RT+jryihKIl7hCQxEYjHEsWc9aSkTKHSoF9Rjm4+WoJGFt18 gJ8DiwiyA/9nRPWUklhE7s+ul38nifu7p1PfjWO6/u7ld2L3nV8R7iUxT7BQEYa3rtcv3TdRKjDu MUHRYIpu7xFhyH8IfgpEJVcC3U/RzY+0hwHi/RN6UxaZzoe9YdHvp7l9P5rqNOsNiuk79Da6f0Y/ 3ANI3MOYK4ZJjBW638KAXoGBIhw5DBQRRXuxJGQLC1ljuR/r6juLqrI2qBqbojRVOtBZtrhCeVGh 3AyMtbpMswVKczQr9QD+3/RaQM9At82QIDx6PUOozRBhMcU8iXcwRK9jCO0zBFi2GYrePL65/fAF pcBRgUxu69IRpSt4J/+ucpyhgbbm8W0L2WlKoldQwtiuaGy/TKfvn3W/b8peUY4aKqI1FYIIohQj 54kF5OKpYLBuqSRvY9iIpUxH4+oKpRUamcoi2JBZBmqpzHB78dFleoD/WC0+ah78WZd2DKpEP9R9 nU/srg4EZZwrQs4gvqUDhnuSCcXbGDaL/1SnoxS9QxAxgAA9FSUkCxBmnuYj/8pJIdO2gigx1uSV rtIiR/8IGioJ2Q2Vl6hRmFPKBTvw7Oj1IdKmJiHHqLm7h4RRzYty4jjJdN/ljFuTjdJ6GpQGhbvS wGPFBSXhWFD4GAu20mXlCICEUelsguZpNUbfp3nh3kmnMzMFdaBPd7/MQpIChaIrKQlOEkmScNrw xeowK78apO3EDFFRl9Zk34xFul/Uywxa2KoJqalutFMUk3oGH8mHkF4HY2M3VK1rc0+46nztE4BM JFOqS/aLlishy5UQRIlya6B7RTJvJ1401hY9F2kOa6nGUBcGUA16B+A5cGdta7S1rZyjrlpXQrpy cEYmPrKtHkN0ZFu93oGM5dZV4BFgc2vrXkA6eGQs2Y1FmXClkujMUuXxQeVv44t2tqyYI0i+oDXU L8qhgVwNWjPlFUgNPE0F/1wwQm4ChLvFRMUJGMaL0PmdE3ItpGUd85lAA8SPfRB3luaTzaMPyZoz LhMFBrW7v2nJmsYOTcJflnVmnqq/RdSKdRV1QghYehGHE7XHcFDUfyCCrzDGIGJTWjQD+Qz14uRW ESpYnCTqDNW0dkq6nUpaSXSpG/5OCPTl8wEEXfcjOlg7EpBIx/2IuUqogibrkjBp7wdgiI7Ujr62 6QDKh62nM2+qQKAa3dx+/IJGpc7rDBqUarE2YVM9m0HyCVlcEy66FtcYSyqkCldcAcNuBAMl6QjS XA7OswAj7giALgUKJnLkgBGF7BtfRkQr5VLZgIkOgvl9s/7XPyI6wHXcueIpYJtRJcOJMebHxPgT lJapzhdrdrd3nfCEMZFc1JFSQdpIdjvS3806J6F/nS4gFFpCSJvnNEbtAoIdELnneHd70r+1hiRK dZYJVZxIEs4YNRi2aggVvnJAGIrmt9VOLWv/MK3LXGfe2Wo0N2aSLdBgMchMq5+/OF9JIjvmKwJd Ikug8w+VrgDCsV4ArNiocPbQkZDmg2LqXnijuDUAUzGBABOXDcAYPokJojmvp31X53VpnE0cjWFH XB2xemqWHEVBNoUljVo6uB7JBRauIwk02GgwHNwVJ1TYCLDJq6papeXC1dpvBn7aWToxi5BFVYq4 c1GFBcSchevjpYiP8cFd9Ka5l0LuJl/oCrKij+mbFVHDuvQ9D3zEOcSQ5CSdHUci4DtlOMMBEI5x 4xb86e6XL01zjgpQyNjochiUAcU7y0MJzMGWhqNA7XVNdZ5WTa6YmpHuuxc3yBroK4OuXkG567p6 orikmAZbPWA4JoBm331NY+h/n/77oZnVsFVgVOnUuOkOZA9KE/SfW/T4xgfR41v/QQH+0b8JYfP4 NihxjHYlTnKJoT+OwxHHjo6PP3jibPp/47hZ9pngFoh0vwUlQpDuCmIcMxZQQeLosLipuqh4Wmpp mloLxhZIce03xqsce3Lwt2q7L5v7+bZbxXuVUbyDvWm33c2sMZaCEzdO6ewi27PGpOc3SZLdZn/6 XLQ8dU/XB23160YBnc8rlZPjy6qJdrIu4VzQy84pN6rZYNhXjc84ZDfN2IA2TWGiuto0pZwSJQ1l 05YYjpbewSaJDIu6n7XH4wEIYLKz9aAcx0yJUInDYTheenJU+hkHQZ9v/zoLprBIOidQQTAncUAe RHIyFKC7WcaC9cHgequgHCR7Hl2X6VM9Td8TusxSual2m0lMBCWSXHYuL+Je4k6jGxi7UxDmF94e gJy52qi12v3LGq9YLTRoWDLGLpyFtperxO74CRBe/xO2+9wFHxz8KkLOOF2CnjwRLNSszWHYXezD HeqbLDXfjLtsMIfyx67c2r3FxPjhOAXdCx5hrGvBo9AZccaD1Tuyf9XiwZf6vJg7Q+SC/Lega25d sXjFmpuzKCmc8zlrGBMd3Pf9OxYPLovvD1WxlDHh+MK5nVA7j96a25W2EZo7RPCXfFYew/4W8GaP IqvbEy8FXLRhHlMshKKXXgRrU79/h+NhYezVdpiha2SLslwerCxmBVARsLSQ7rc43DE/pjzYiMNh OGoz6qkfgUEOGqa2KtN+7c+enup84H+5RpkuR+646bnw50/Qyjj9mhw+DOXY3wWq8yrN/Nt/RXWm 3e98SCgxRIWboDW6PEyhXjK0afX2T6R8ZqEspslF6oZO6hQid2TiRja1NcMmxMdFWTnv2NzS2ps9 EyjoSXzwaszrQfGYnQJVzG3I1EKp7JJafDwJaJ7jl8bLL14abImBHrXt42IO9by8AlU8mTnavxbC FMdUqPgiY0FF0gazfy1kGZdOA/XMDV4oB2h1CclvPk6hqXA3PVfhmuaVKb/pDM2X0oHP7xxRcAVe QIqLdOJ3j+9Vw1lW+OtR1g/kZ+OTaom6po6YdLU9JFYUHGq4Pn+NgbQxTEAs//a3bN3Km0DNIA0P 15qJWmbUPUnJiwRMZXwKktOMRrmuIFlkkMGKmSmbbL+l4cjjSdw11FhcdM7OqVqdsx/Gc4VcBitA oNaRA0gsNMXuImpIk0hl50kQoxAKMQ9nVKg8Wp/v0LBwN7AnYJJ77h7aWEOphpJTeEZOHCtyKiQB KJcdK0pxCqUTjb8m7qrOcw0ZR6NBUc8y48ugHkxMFXRoQ1VnK8CVJBDOKpwVUEetgJ/XOGfkA0cv J1ipXafVMZhOIKcq9VPIOysc800s7cMbhLmzAn5Kdu2jIZuC85EqWB/NiDx2Z2XulLgoamSNWRW4 D9//uHKsa9K3AFJ4ItiyC69pturxAYADf+rsdbF5+M9/AqSyLO8KZW5kc3RyZWFtCmVuZG9iagox NjYgMCBvYmoKMjUzOQplbmRvYmoKMTYzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTQ2 IDAgUiAvUmVzb3VyY2VzIDE2NSAwIFIgL0NvbnRlbnRzIDE2NCAwIFIKL01lZGlhQm94IFswIDAg NjEyIDc5Ml0gPj4KZW5kb2JqCjE2NSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAv Q29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4g L0ZvbnQgPDwgL0YxLjAgNiAwIFIgL0YyLjAgNyAwIFIgPj4gPj4KZW5kb2JqCjE2OCAwIG9iago8 PCAvTGVuZ3RoIDE3MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjavVrbjts4 En3XV/BlMQnQ7fAuMVhgFpNkBsEms5mZHuxLXmiLtpWWRUWU4ni/fouU75fels1ZJOibJbHqVLHq nKK+ot/QV5RSlMoRIakkAnGZIcnZKMsoU6gx6N+oQq9+cQTNHHr1Br5PHCLITcJtRI2UyrBI/G33 /X04k/6+6VPPJphvn71+Jh4J/9R7PMKECibTVCUPE3gEHqWSp1gohOHf/e5XeDZlhPMRZRxNFuin B0RIfxF8p2AGVQw+eligVz+TEU4IepiiF+I1FujTx5fo4Qt69wBWbi3w62P0/EWT9aJsvShDwi8p SL8kHWHUL/lRN26uyxK968a6enSv0W518BcTSVOJObnCYbpem4IZeJQxoXhvQ7Jxe23Dh66YFeg1 mtoGMbQoqq41aKInc3OHlPob0hCPzpk8XPB3uOnjT8hOUdvo6WfG5MtkazC6xUrORW9lsofUzsrJ DpjnL5GcCUKKhwYBM8wx5SSNF4UUX4pCOzeAt8dco6lZwu+6PQzBL4fwg6nJ1lSZKkF5Kq+NROIt ZSrdt/QkEugeLaxryxWq5ytXTArXOlR3ZVlUM7AXvro9q64w5ShimUoGRkwSnqU0JWfWTq4LWKaO YZg2doHevPv919s2wKGvHGcDfSU445yDkbFcBRPQ5dxEpbWPXe1QUUGC+qBDLuSmjAoCTYcGPBOU 4SxV8VCg6SUUBMaoNs2mUrYWMXzwp6hYcDkUC8WIEJRGzAguL2GxnJsKLQ207IkpvkHNqpCpJrp2 XalbqFe1njya1l8xgY9mpYGvPosWuq59tQibyP9hDzPIaaIoFmDgVVUs6T0I6MmT6lVUFQRKVzmy ECr4Kc8b45xxeyAerZsMj1qqjptMWXwv9D++6PHYNKMayqcpR7aZvT70HLwGeqO4vMl1IvlIwWOy fVN2ENjKoK+dcW1hYROPAYcQgtDykSv+Y1ABSVVUYKPOfa+ZWPhZV3BZsTD+8m+67IAdLH1vOoqc FFzRCJFT7Njs3lJnF97IRV1CtuW6bnVww4Ht8MFY+y4Jv3dOz8yPMXeiIHRwVVJpBp7Eq0pgw//a ic5AamsE1CA9zCzJYEcxfFtoKGTWE8bYJQKCsi0GvRVHhZpAaFV2E5ViQu5bkZxa4fd3bqsfWjTX wZJ1wbkLn7QeqyO7qFQEiPstZoUsofJYVkBjANq2ACP63gn0Caid75yf/vzwYd0+0TMTNXlGonLx PIa7o42plBATEGK30MaDRN3YcJqoxPfPDYuA+lEVs3nruyj3XbTo+0OuV32oAK7WFohno5Sjf47h ljWIhwl+H3g6YUrApmPXuJFsoyjSp9yA5PIk/DB7Uk6ZhJvCwskt6SP2q3XiF/RwHMqyMwL1VCJf 0cOOJbJIT7wXrwn2Ejm5WSJvczc5yF1Fh6ozoDop73M3iSLOehuSywS4mgFv8D/6dog27XNhQaSV xaMBXXRQ+ZKNNCMsk9eSmt7OhGXZkZ3Hyel51kYX7omENIPEuCIn9vQ5k5eXTl6ErrOhdetdfJSt t09QJBk8QYGCwBkV8SYoYMMl7T4H/HNrnBfBDljTovbCHUrb21//OBDs+0WLkhQKV6Zu64jySQMn 6MfrwnB+hiLZ0BkKJB/wIBUvCOziACWv3La9wN4E0ljlTzufDOKBkqtnOH9AvTIuJAXqdBup33ef q0vtlR5qUZR3TT+WMX2nvetbKrThu6MrP7/QpbMnN3x+GZNFS5kN1rMgYWgWcZgDNlxCT5ft3Haz eXAfmGMDKgLUEJo1Rnu1uAcOUJSowGSDhx4cdoFg8XQ+mHAJF2fv+qIG/0Oja+fQZz68/+NTT9O8 wLddmfspZUDHVzzt9lqCW4GcXMRELMXDRyOKC0EyFg0ysOESZBuF7VBUGZpSMdRrir0KJVk8r+lF dl9M0cp2aBmmBRY1XYUWK+CGTVG3LioOnF8hx5mgPJ4cBxsu4eBBACoW1WPJhnqcCslB9sdzWJ5M Zd4WlQV/3/wLNjwUB99PXNGGAVNTABVazouyLwfrT+fWtZtPo8KTDZ7PEM4UI1TGwyc7oeRv3wd8 3oeDkcf+OGdTINvGhO4CfWaFlkVuQi09p2yBwQrYxvwmZQvOPmWpbmNOITJMhk4h4IEZpjyNNoXY 2rBz8sFWqxAOX6FM7mvUHFgOCLd2d+IWTrAipmZG8eDerkiaySxerQIbLmABYi23vkVDR3//Frjz RLcWdnENmPjG7jXMQj+GJu6HryBkIFPtdOrOjAF2gwgsQZSQVIorVN/eJILQUYCQnTTaEpprpfPO bqbqkwrNgXOUZtquFRhsttFfNqvIhBgqRtOw8fzhdqRZRW9Dcj6qrQWO+oNDnyDbbVMGlpab2g+I bS/QGxBIPq51qSsT5lrAcwG1cQGxXz0Z3gtzpoHRDXOmwO1P5kxPvYqR3Lwjs2wbu+R5sWM0FUIw cUVlvBC7LLuwI9ebrm1WQWzYMEowlQMJEoLUM3FgVvbb+gLdb9eYRUvhwYIEqDWHxIhXtMCGyxBV pq/fY9AepdENdNB2DhTDhqMhSHIoWga5rlcroeuu0GNll5tfAcRlAd5U9ugUC0vMOWOY3HyMpehJ ao/7KaHfla7WE9Nv05inj4rjoRMKSSUTjJFoE4qtDSeR88cgbXiDxU9Q9RiCNWvsEkIH8ci7MC9z ppze50bPQHfPwgHfVmZuot5VuWn8qWR+5ErKJfDy7PYjSCX4aexaPwVYzlebPMttyKao4UvZ0PCl JFOURxwwbW04t/ECXV10k/lW5o3NlkLocuUgkNBg6sbW1unS9fttGcAKx3GFb9Tf8qjVSg1l/xRA w0pFK+fqdBw/13ujx+RWJxkIFjK0a3EgHJxxGsnNPRvOceowAtqlR6hzU1s+ur6JVUA2+g0+tZPO bVgIfDAxddvpErjbt5jvEjH/7t6QvLjvMWOKU346L0muYmnBiAuYbWZqHob3vz/8/DSjZpJnnNxG qIki3qLTV3qcZ/3daKFb17l5sdi+rPKl/j/SajBNDqbV/qUZEPM8Eq3e2HCWVvfzrUDPdBlEUf9e yvpNJ3/SDwjeba+CKjiGJrcKLKMvko1xQFcm86h5ng0ehwmFQRTSWGPBYMPJ9MOX+49mBU0TCkQL jd0snFcj7bwfDEEtmAFs5nvtB0JQB2KCQvDgiZnEjJA02ouEwYYnZhDOv6KSF67uddhfBAMdPBkD TcaYymQ8GCi9MDn8syqNc2G/+Ewoqtb25yum1UXpNkRrUbg9ygdXNzuCERUsTgbPaoQAYX+2Ll8J Fr/cYyE5wHd/LOUR81hBt/WQPBpTe+AW/qUafdJU4VIbFSc5eKZFBKaEMxIPJ4mfMd/zdXpdpBfG hH1Wme/9y4x7bey3/wLy4i0TCmVuZHN0cmVhbQplbmRvYmoKMTcwIDAgb2JqCjI1MzQKZW5kb2Jq CjE2NyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDE0NiAwIFIgL1Jlc291cmNlcyAxNjkg MCBSIC9Db250ZW50cyAxNjggMCBSCi9NZWRpYUJveCBbMCAwIDYxMiA3OTJdID4+CmVuZG9iagox NjkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA1 IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDYgMCBS IC9GMi4wIDcgMCBSID4+ID4+CmVuZG9iagoxNzIgMCBvYmoKPDwgL0xlbmd0aCAxNzQgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42rWWS2/jNhSF9/oVt7sOUCl8P7IKWiRFFwPM AAIGg7YoKJmWZctiIspo8+9L+hXXysOyXXghyzDJ75zLe8gn+ApPIAkwITKMpeDhmwLCaaYUoRw6 C9+ghZtfPYbKw80v4Vl6wODLOEwStB6QbkconIQR0/dmxS+TbidDcbInQJkUTCKuww8I0v1rEiYi VCoVp4JyCT/ngOnmT+HJgSIsNeRLuHkgGQps+RR+/Gw6PzNNA/erwrQLfwufIJ8n93lgQxlChFLE KKWQv7c2vLY2iX9K0vDEFGWKcs0OGfCe4ZuF0q2aCZQz01bBl84toZ9ZeOjqiXkGN4Xf7vMH+Nva xackn8OG7gykIzu0Sk6yA3Z24FA5RBB+ZenkFDdg4IZWx278XtnWdqYBXze2Le2f15RMsBwpGXEU piSEXk1zYDjWnLv2GW7hi3m0nf8JHhtrvL2qbipG61aac0bV9XRT8YbuqrO2BT+ztv9/1HM+Rn0a 5VOlGGdKDBZPTmv8oXzO35CfzyIB/PAieR95GY+htwZiClGMqRjhRrIFwlsgDLF3A4rExygLW9fl rP7Lz+qluZuborBd5roKZsZDY6d9CKTax4TqsxfONRiXSAnFxRllwskeDIsIpgatEbzpV82HSPvQ TtcxxamQMWjHE21DOxCpSBQ+x0T8NpxmXz4f7RcuMJccHcdEcuqa2/KoLG5YOoyIpv6n3rvw6Hxv mxPrI7BiIb/wRfXBWm/I6MCP3k2sr2xT26K33V21NHWTleEI+xhNEqEIP69MyQ6MbMCYHgU2d3Vr J++4FpuNnreHDlxTEU0MOr9zjWkn2cQVRd36UZ5dt5wKX7GcTArNJbvQMxXTkupBB3jTu26VLU3v V/+JqfnjaRUVgihy0WYjIdPDfRAPesB09XS1rO8w2TK1tv84p8LOYIphflFOYR0jnRE91q83axnJ tAwNEK4AV+lNxgYNMHdpGjxqTJGm/WKRpn9QKgZHMBIIC5acac+mZJIdMCSHDCecKYcBz6gOF1Z+ YcDryCIGXefMYoezasM+7vusdR+33GUn3W5Xr086JuUrJx0fnnSCSML14GY0zggs+aYsemDFd7fa ibZrzVA8Q+Oqqm4rcKseXAeFjS+T2peubW3Z28mBMV//BRR4gNsKZW5kc3RyZWFtCmVuZG9iagox NzQgMCBvYmoKODY0CmVuZG9iagoxNzEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxNzUg MCBSIC9SZXNvdXJjZXMgMTczIDAgUiAvQ29udGVudHMgMTcyIDAgUgovTWVkaWFCb3ggWzAgMCA2 MTIgNzkyXSA+PgplbmRvYmoKMTczIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9D b2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAv Rm9udCA8PCAvRjEuMCA2IDAgUiAvRjIuMCA3IDAgUiA+PiA+PgplbmRvYmoKMTEgMCBvYmoKPDwg L1R5cGUgL1BhZ2VzIC9QYXJlbnQgMTc2IDAgUiAvQ291bnQgNiAvS2lkcyBbIDEgMCBSIDIwIDAg UiAyNSAwIFIKMjkgMCBSIDMzIDAgUiAzNyAwIFIgXSA+PgplbmRvYmoKNDUgMCBvYmoKPDwgL1R5 cGUgL1BhZ2VzIC9QYXJlbnQgMTc2IDAgUiAvQ291bnQgNiAvS2lkcyBbIDQxIDAgUiA0NiAwIFIg NTAgMCBSCjU1IDAgUiA1OSAwIFIgNjMgMCBSIF0gPj4KZW5kb2JqCjcxIDAgb2JqCjw8IC9UeXBl IC9QYWdlcyAvUGFyZW50IDE3NiAwIFIgL0NvdW50IDYgL0tpZHMgWyA2NyAwIFIgNzIgMCBSIDc2 IDAgUgo4MCAwIFIgODQgMCBSIDg4IDAgUiBdID4+CmVuZG9iago5NiAwIG9iago8PCAvVHlwZSAv UGFnZXMgL1BhcmVudCAxNzYgMCBSIC9Db3VudCA2IC9LaWRzIFsgOTIgMCBSIDk3IDAgUiAxMDEg MCBSCjEwNSAwIFIgMTA5IDAgUiAxMTMgMCBSIF0gPj4KZW5kb2JqCjEyMSAwIG9iago8PCAvVHlw ZSAvUGFnZXMgL1BhcmVudCAxNzYgMCBSIC9Db3VudCA2IC9LaWRzIFsgMTE3IDAgUiAxMjIgMCBS IDEyNiAwIFIKMTMwIDAgUiAxMzQgMCBSIDEzOCAwIFIgXSA+PgplbmRvYmoKMTQ2IDAgb2JqCjw8 IC9UeXBlIC9QYWdlcyAvUGFyZW50IDE3NiAwIFIgL0NvdW50IDYgL0tpZHMgWyAxNDIgMCBSIDE0 NyAwIFIgMTU1IDAgUgoxNTkgMCBSIDE2MyAwIFIgMTY3IDAgUiBdID4+CmVuZG9iagoxNzUgMCBv YmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMTc3IDAgUiAvQ291bnQgMSAvS2lkcyBbIDE3MSAw IFIgXSA+PgplbmRvYmoKMTc2IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDE3OCAwIFIg L0NvdW50IDM2IC9LaWRzIFsgMTEgMCBSIDQ1IDAgUiA3MSAwIFIKOTYgMCBSIDEyMSAwIFIgMTQ2 IDAgUiBdID4+CmVuZG9iagoxNzcgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMTc4IDAg UiAvQ291bnQgMSAvS2lkcyBbIDE3NSAwIFIgXSA+PgplbmRvYmoKMTc4IDAgb2JqCjw8IC9UeXBl IC9QYWdlcyAvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXSAvQ291bnQgMzcgL0tpZHMgWyAxNzYgMCBS IDE3NyAwIFIKXSA+PgplbmRvYmoKMTc5IDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAx NzggMCBSIC9WZXJzaW9uIC8xLjQgPj4KZW5kb2JqCjE4MCAwIG9iago8PCAvTGVuZ3RoIDE4MSAw IFIgL0xlbmd0aDEgMjE1NTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjavbwJfBRF 2j/+VPU5933lnMkkk0CAhIQQopE0kACTyI2QhATCEUggmHAEORVERMIVRRHvCxDwGhKOACqsIsp6 4Hrsuuqu7m48VsX1VXQXZSa/p3omkLi67/6Pz29mqru6u6ar6nm+z1Pfp6pngACAHtYCB8rshTOb hD8Kx/HMayzNXrbU+0hw110AZBcA/83cpnkLJ3TqDQDibXh8el7DirnjM+5YAaC7FmBoeV3tzDlf /vk3CkBwN35/cB2eMH0lduDxh3icWrdw6fLCXb4RAKV4SFIbGmfP5A7YLgCUpeKJOxfOXN7E3SPn 4DF+B7zXz1xYe8d3fzfi8Xt4HGhqXLJUfEZ6AwCrAzjUtLi2adt7Ta/j8SEAaQ27KbD+sB6JcIrd A6apZyh0vzjgQVBzIkgggwa0oMPy2Cswggm3ZrCAFWyYs4MDnLh3gRs8EAfxkACJkATJ6p19kAJ+ SIU0CEA6ZEAf9a59IRP64b4/pgGxOrMgGwZCDuTCIMiDwZAPQ6AAroKroRCugaFQBAoMg+EwAoqh BEbCKBgtdEKCcBLSWOIVrBe6PsDUyfaRxV2d7Drbc327vhHeBjP9U9fXwltg7fpn19f0K2x/j1fX r7xQLDfCf3zFym3D7LZfLXQbtMIHsA6GkKfgVtgC8/F4CdTBetgEd9Am2AEH4TBpxzssgOtJHkpg F7TArq5bul5Cuf9AfF1NMAG/cSNsh/vhX6iPzZh7D/W0sGsLv7BrF5ZyopSGYZmNeO0wSecuwAqs pRrq4W5s5NVdM7se60IpQCZhestD2U6GhfBbeB9+oHu6jqOuXaivctgKHZF/do3tegL17UKdBKEC GmE7r+l6FrGgVXHgRp1MhtlwE/ZlO97/cWgni8kjNIlezeVwnV0nur7quoQlLYiJIaitSTAL+7MZ Sz+A7xfgNOHJIDKajCe15AA5TF6mNbSOrqZvcXdyhyMfdf226xPEJIfoikO9joGxWNs8WAZ3wMOw Bw7DWegkVpJFRpGZpJ60kdNUTwN0MW2jL9GXOJEr5cZxO3i3aAjf3RXXtbfr466vEI1eFVcjsEdl eMcpUInSXojvRlgKK7F921Bed6LkH8D+tMEJeBZeh7fhHfgbfAafkWTixxqHkOFY6xhseRX2eD25 HVt/lvyWvEk+IJ+S76kJ25FHFTqCLsT23ED30wO0nR6lZ+l5bJeGS+UquCaumWvhPuI+5YG381P4 RfxS/g/CH0S/tPiSEOkfORP5pOumrg+6PkP9XoNoHwvjUC+V+K7G9zx810MDanodtnkrtnoHtvk+ eBAeg73wNLa8Hd+H4CScxvdZ1PDb8FfswyU0fC2JJ17Sh/QjeWQoyn8Kyn8FWUk2kS1kK/ZlN3mC vEzeJp3kf8i35EcSphL2yEx9tJJOp/OwRytpC72T3k3/wqVw6fgezo3kpnO13CJuD7efe4p7gfuW +wn7xfND+Yn4nsQv5NfzIf4NAQSXEBCKhYnCdcImoUV4UDgj+sVrxWniSvFO8Ul8fy0VS49KB2S3 7Jfz5QnyGfkC9u9ORE3v16cUNUcKUDsT4F5yFF4nPxAPGYA6UhCvXxIjuR8xGUKprYAnoRPx927X QNgNN0AE5XYbNMOL0EqTiMynwqGuBNJO5pL7SAqcJAJq+zN0hiPQ25yhn+L381DT9WiRj1MBJXwR JTid6OHvhCNbUMYL0Ptdg170AXgJx4MKRJeF5MDTZCKcAW9XEbcNHicumEDKLu2mCvwFvoJwZA9s Jp2IuJ1kA/wAbWQytjGe7kPNvQBvwr3Qwgf4z1DHCxGl02E/zMU3kNfIdOXqwquvKhiSPyg3Z2B2 1oD+/TL79slID6Sl+lN83uSkxIT4OI/b5XTYbVaL2WQ06HVajSyJAs9RAv1K/CNrvKFATYgP+EeP 7s+O/TPxxMweJ2pCXjw1sneZkLdGLebtXVLBknN/VlKJllQulyRmbyEU9u/nLfF7Q68X+70dpHJC Oea3FvsrvKHzan6MmucD6oEBD3w+/Ia3xF1X7A2RGm9JaOSyupaSmmK830GddoR/RK22fz84qNVh Voe50Eh/00EycihRM3RkyVUHKcgGbFWo1F9cEgr6i1kTQlxaycw5ofETykuK432+iv79QmTEbP+s EPiHh0yZahEYoVYTEkeEJLUabz3rDmz2Hux3qmVLhxlm1WTq5/jnzKwqD3EzK1gdlszQKH9xaNTK Tnf/fh1k7+TykGZEB4HJ5cegtGvtweDa4uIKVpt1RPnGnsXjuZYSd72XHba0bPSGHp5Q3vOqj20r KvCm/fuVTSz3Yav9JVu8rBsTy9Ue4E2JOwsbyc6xbkY7XOsvYWdq5ntDGv9wf13L/BpUVlxLCCau 8LXFlSrHuj6G0hJvy+Ryvy9UFO+vmFmccNAOLRNXtAcVb7D3lf79DpotUUkfNJpiGb2hZ6b28jU1 pxZnOWx1t6gJa5E/iBAJeWd7sSXl/hBNG8I2tUOgZfYQLIavCoISrUf51bSYr2KKENLMfm/L94BA 8J//qveZmbEzYpr5e2BZBpfLkMPr3flQZmaob1+GFGkEqhZbNlQ9zuvfb1mozN9k9obKUGQwvhy/ VHFVForc52Na3tyhwCw8CK2dUB499sKs+DZQsjIrQrSGXTnVfcVxHbuytvvK5a/X+BHOh1SK5QjJ gcsfk9lpK6m7KkSc/+FybfQ6mk+J9yAvpLWMLw/MbNkcH6hp2VKBqhmJptjSMtLvHdlS0zKzo2vt LL/X7G85WFbW0lRS092ljq5Tm+NDypaKOoJCDeVGpRGyjSjn4mlFNEfjOcyVTfKXTagsHxJTWohP w09wjr9kTj1CaO2s+agv/MzcwtDmazGHgj/4WDmaZn7Tf5aEiC0EdnOIFKrNJiGwhQgqPhjiXEPw Yn+grKMCo5cccssxBwW+g7jbQJROEDdSUEL+cJjjQCsKHcR1hONoqUbiWZZAUL7rKXfmWPOFwjHf F441/1A4xvx9IRQVmsOF3xdidmC2z+KzpOGG4Lh5ycuduqQI8BN4+VMqu83mHTSInJDVO0XREOS4 VOIAKxIUPSeij+UoL0gi7SAbFE0yl8VRDmvHo8NiUK64R617zHmsuXrMeYu1oIAlrD9cGMsPzCZ+ LpclmjPPeWekts55J+8g5yIDyTnU7zrMO9T6E45hPwVFS4E7QoP8jEWxW0PR+YHZNvx+ZF70m4yt E11kCl2OzTPAICVeIiDbwGIaNapUni3dBy+RR/nZuqDxrruj9whfOH/h/NiS2uJPoago2qZckVrM Vpc/wHbk94/OWlYx9t7S8joRzoY/j/wt8q+I83gb+SsRiIc6sJ2rI1PI39X6hihGVp8FbKw+3WxU RH9FH6s3aJzxVKzdWGe4d53+wTgE0fRcJ9uRpEdnN2OdZVPrIlPOUjdJJDL54nhbJDHyU+Tz8JdY 59quyeRpYkTZ5LRxhDKVaFBnnID1kg4qHeauiClaFZN91pjzam0uLp2kb3x1NjEqkVv7sghnGPkK 2cpcvF8/xUoozHJySCdpqYD3qVjM7tNp/trCblGGPndtXEX0TjafwzeMBsLv07kr1UjpRFcnOQgf YvSTqThPMeGIOgO26RRHuKWaoH5ed5uqY/0fc756YHZaDg7Coj8lkDdoMBmcO3p0LqYPRw/KDQZz B41m9x3dNYQrVrGgKFYOlXwd5eyUIuKYI+AQc+1QKhCGPQTIDYuvYI+hJAs7v1EYkLlxzemB2Rqk pVxx+IF76Cyh8+Jk8UmG9WFdH/D98f4m5Lw3Ka5Jsv1GvSHxRl7wNMqlKeZGCPo27e190/MMfCNW KEOJVxtwuZ1uKloDxjQxLT6QnEYDDp3nE2IzmD/BmAtzSRzm3Br7J4hF3MRJiZ8gscRNJr7UTfTV N3OdzWwdnJujIoHJhNrsSSQ3Z3D+4LxBNOBPMZJhazq3bv9844Yvtm/9602bK56eOetAv/xZT9XM erKSfoS9G7p7T+RI5IvIl5GOxx8lw0jSxa5b1q174E9/JvHr13epNuLHTt+PcaCAmLVSwvHCC8Bz esJTNPKLXAeV24SgeBzZ+wKIdvvCeWuBar9Fqv0iinwWv8VPVhHfHZ8JJ38cJmShKq7BGD4V5eiC /cqQcnqP5Sx3RsMXcEEa5DiXM905hHIuGbKt9gKi4Ear020xmuxGo0lnMGpNDv0LRj10kEcUmwOF b7IatTpro/Q/hlIPNJLjFMNqqjlsDLovK+OCqg7WOPQoUBTuLDqPMLVE9W1cYz6Nsh2Y7UY9GW12 QbQL1gZiEx0NBMO6zHXrSHV1tc0/GHJzrIhAiSCekefnDUI5i+e3isT1+qs/LX8qcgd9/JKH5jwx 79itW09w375P3JEf29Z8cCLSvI3OOHpw1ur2ZwGiOP2A92L/M+ElxV6dPC11AbcglU9WrI6CVMXs KHDjyKIk6RwFx/znvHR/8n7/sWRugKz13WhKqUmhKSl9HM4Oct/huButBgIdVKfo+qAgtCkpzkCj 3EHtRxMbjaX9URgdVHvU2egI9vuZKHBnKchiorhQyJK1IKv6fIGKVG96RnyCySJI5gCi1JLYQDKE QANJMMU1QLrUp4HEkLhunSoYzFUT/1DEXhJx2CUnY8pGgohEN+VyIiLzBg0g6Xk53fIipp19Pn9w ycsLn5tfXHNL59bnI+mtgVHTtj78wszHnqjdW3ZP84wWfv6R0/VtM59vzJzUfPuav63+4J3tyoRT 66bsvFazcdT1w2q2LIjKcRLK0YH4TISQ4jlkPWWlg6zFVhqQKcdtSUi0JyQkckJCBzUrhrgbBQFd AXkhEXhzB9l1iJkuik572IW2m0yfJyvRk5kgkRohgRoPmxtNwaR3jxE7dMutM9ypSq5TxQ+OTwil rPCnltyNxgGZAmIoCqA4h0fUadGwXQ3EI+LGqbE3gFuKY2BSJaeKjTh8HNovXBZWElVlhSKSbNw/ wheCNWPOEuHWT3a2/+C+2zJhY+ntbz77wM3HbhNObok0JkS+e+v2b9d98PR184d9uOeu4+Po+8w/ taA87IgrKyTBEcU9mJLtDjJItqITJBhYWe0AVtuNtIPWKkYeB2rPjToDJU6rCXFiUdwApoRGkMwS lUq9zkYwmU3UFEz+w2UpVHeP09jzbls6X4T580wGqh3l5MCAqCACriTBqAkY0uK0CQ3ErXc2QJKA uXjZ0wAuI24SRRtDU8yxrVsH1aSauAhza1GxDEDMDM4XUkSHPYqkAP3HisiS8SOfubDsj2tWnFsW nE4S1x4+vBaT0DkuvDc+fOym11c0v7Oi8uUtzYfXsUvrDkfn3kpQNn1QNnGQDoPgbcVzswwG343m jJoMmpGRFX+jXci6UTKkNbqZ/eQ0cqWDkxrNLJ/ZqA3m/bv9sK6H0YiqwwVRw5lFBgmB/gFnmjXg T8sWcxrIADkTbcaRhtZjS2qAPvrMBuo1JjXQlLi0Bm4QyWngBvJZDdBPg5uAK76BJFpw01eX0UD0 ySZfAxgNqR7cxeVSPEXAXJhZmKlufjYgMPkR1QBxMKBMakx23VYpkpgIVSPk2IE6WLAD213rGm8L X7h0y70NDUteXbbkdGN95NkVDz2xOHhzsPXmXW+UP1j3yPNnufTS51ccuPkh4tq36qUxQ/bOqDla P//InDn3k++3z5710Og1RRU7w7e9tH5C69jnb1p1ErE4p+sD7usYFh9XXJMdSx3016FoQCgKV6Bo BJCcjaZSb0KjFExGM7weeg6r/zX8DGmaAAMdMPgRBkQVdCr8VCD2hp+QTqL84rLgpLSYUTL5kU0r yNYo+FavZOCL/HXdYRVlaWNpZRxi77WVy95ZPu3lLctUSGIClSOrfIevQr7jQmaSek4k4mqQTumJ frVV54kRn90azSkTMe12BN3d/Od8NdLwHhyoiNEg0oMG2X6JEnUnvmr0oEGjGT+6tPYKS2LtYbww 2h4TBI+BEXmhWx9rld5osmCLDOc0RLObW2dAmoikERsWNMeoYjWjw9Vjzd18kbUs6/zPGsbIY3eD UpFE9mhMW5ROYjuWkJP8PD4as4xUdIRRU16UuJuQqhYoDvEmSaIixyN3E0o1HIYLsRYUYphiiUUK yFYjl+MGbITDl8cSP++SnrtwSc/Dpk2R0Zs2qeNFHZzlF/H/BBGalCKeUHodx9s5pDVYw3WiYBdF Ad5XxLPES99XuLNeQngBowkRBLNAhVKZA9EsUjEozdgVlUSh+dNqte7cXPBkxY0Jx7nPx3nMbLdR JZIbB7ijfNKmIdguUseNunSM1/z0TzKNrCe37oj0uTmSqcriQFcnz6O99IXB8KmScsh7yHfae9rH X6O/JmmGfkbSHM2apLX6Vu0zPo092+Io6NPR9SZqzVKQIeu86dkOAg6zw+vgNOAgsqOD3NFmnenp IDcq9lOI8NUDdSZIhizgNCYgMpKn+5XU9JkmnvDk1AAyYPegQQmO2c77UmdLpUNMsxN+gNkkmD9v 58+dHrO8aiiqDndOr55eXRSujkRz1daYE0xIC8TFmy2CaIkzTYWAkDqVmOOtUyFNTJ8aZQ4qb0DS ADHaoPp6SZRiTj4/Vx0QmQ3mq2yWjYhiT2yRq2+n518+/fE1q+97sU/fRZWz5+vvkH7z2KOn8mbe +t41hTtW7Zx0FfF2G0HWb788s2PkDTOuGRtIz7+qqrbx8WP7VhUuGJ1f3q/fxKnLZ5dc6tfDOCgM RLAdR04hgRYeVobO0xAtR6ms4QVBlqks0CkE7OiKZUGmwhRRQtBIsgScltdQgYj8dI1GxHBclGW0 pWdJPFDqQio9oQ2ek4ZpyARkzi4Q8byOOqgT3Zr5h/MXIhfOf6q6s8IiHFEuwzkWkMjo2XDvVjOS YC4s3Gg+jYE5qcYohfNxfmLDrZ4+/eBn4Vs/3U2PWsPkn4xsk85IgnAy8goGg+oYeBR5dwb2zYyj YADeVQomyPFWixxvC1gTTIlmC8HT001WosEkW62QON0sx00Hmio7OBdYrPF8gtnVZBKI0EHdisHX pC/NSKg1B9Pnru/pni9UYw9cBRaX6p8ZZhhELveKpQKOdUNFzNU0zZHGpSWnadP8KakpVLRLrmbO Q13NJMnoayZpGl8z5xRtzSC5+bhm4jUkNkOKLtBMNDIbEDNxNCTRoIi5cZsv5rmTqMPO+302S2zY 83PdufSA/yhJeebZhTXVS1aXRMLvRxpaJ9/TOnnrvQeOPLJz2tqmMgTApCfrZz2Sk15/19SD3wtZ kT4Fq8pql4TvCr9WdOvYWXfEW5k/aez6QDSonGKfkreRklcMZ+L+SLhXyKv0VT13ghzXHzdwT9Gn 9PsM3G36++h9em6peannNnqLh8+QjUDQu3oO6VZaNDjqeRQnv9KNAbUBjKUJ2QlEbnIE45d3S7aa zc3kWHLR3SL9DHda2HQ1MzirS9CKabY0wSXPAa0VN5KTn0M0dt0cuEzVWQSDL7Q5KZDqT+Gpwww+ b75L5P1eLmDBgxxeNCytiXz3SCjyzh6yiHhI3ptLr48cfTVy40cnyEvkujfItfzTFWvW7Y/8rS3y XWTXt+Vb7iHkjySXjCDHHlNtpx1tpwXxpQM3rFL8+bJeZwAXdRPDdJDd0wnm9GBtkkrj9LUQ9PRG TXTeB/FyxZlj9/pyTk3AbDFZqCiIPDpfu81ho6JRa51DnBxuLLJhDthE15yod+nbF2PjXIvP68LQ 2E55X1quN3+wFYPi9IDP304GktK7fv8/JyPnIucjxw6Qgcv2Pv9GR0vkxTrhZF5ZZFsX/CkSenhz YDDxvPouGTCkrzpuHELj6VL7Va8MlnhOq9HJoiDxGBKDNJ3ndRwaiTxdJwsag5YDWSc8Th4HLdGW GuRaXVA/95mes1wXOq9Mc0XNo5dpxCyDTZpYYukQVxYeTdvCY2nbpRPCydsjg1rDJ2+PxkAoc+5O bJsGpih9ealXuzSsXRr0WSKekDUiKdXJtZqgtmd7Cq80pmhMr8b8vCH+dvqX8EE6LnzwDrUNt4dZ LN+MNnAX2kAyxrKj99uO2V6Gszb+Ve63BnrEfpb8lnJ77c+R5zhul/EJ8gTHbTLcQ+6h3Fz70qRN lKs0zOfm2jC2BWKymqdbLLx+pSNqDVp+ZSJnsZhkjHDJCsVgarKW+uQmT9C7vLe3yWGBmBqUMTp+ no3G0UDWmSDo2ESLNuBKExLQMHROZh1xzDrc+svW0cM+ehqI3cpjfJbvy/NRNBU0kkHW1Fy0kqGL V0U+2PxU5OUn28hVJ/5GrkqMZNKVNNIYCUXqvj76Frn+sxOklH+lYcWaA5E/Pbo38u4TBF7bFnki 0kicvyee35G6VzdGdXcQ/fFLKq6WK8NkDkcQImlFHU8EjEWnyxoNiIgpoAIvyLwkAqEaXquTascj VSs1aEwGImtrZ+gIg9jT3REa+truyVT0wVaXOqqwAD8asl5RbVS7aCuWXIsft/6Dd9Kv7rwzbEc4 he+m9T8Oo2fCV7F2PoibgdhONu/noIymoVLUWURaywX5WN09phCLitR5P7zvgzt2sJHoMlZ5xA6O rPuUoVUikWWJEozVKZ0iYOAqIHzlKWz6RRBxpJU0opYjPKzF8UbQ8kBFLQqDUJnXaLkOmtjGPy/h TrGIpXqTHgctPZE1tdqgbu4x4uiOF9jI40F5uNUpD5RGTrc4qi8bXW7uxmgEv5HHQZZlONlcKLMR dhH2geSyyUCE/05a9nL4Gvrji+GVO1FE79GMcMOld+nT4YkxO1ytzpVlKS4e1SfIbFYedVcq0Voh KM49fxm1n3bbWzgmJjSv9jtpXjgfZXVumyqrJgDxC7yfnlQrS7LlbB01cfNk9KAugZ6Vz+ioRnta oK+igZ3huePkGD0scAfIfrpH4O6jd/N3CtwG4Tb5PsKtoM1CC+Hq6VxhJeEqUNT1hBss5OsqCZdB CkgBKsCNTFcjEyLv0xHq3Sfzgrej6x5lKHo6ryQKwhRZsqOyeITklChlZqRoik5r1+m0RKfXTwGC ER3hkQLptRqJF0H+RtdBfYdAQAV3UC9qCT2QFrm2iFIxInTEYTqSARJNApkmI96TkRElYXczDkPQ 0G3iYc8Fd1jdqNhCVUU/qMQx54sKzcyXulQtxmZuY4S79y6Tze4RhMKM6hnVV16L0NwX5dpQvbk2 P8cmfJt+56ZT6Hj327e3hv+VFv6f7cLJn4L80R+H8Qk/dfKpP30I3eOBkK/63FVKWb48mhslcxlc ujyE44AzyVSjbmWOwTk6A80EI2mYMFAMEi9wIodARrLO1YqlOg2OhtpuK+oeDXsYbyzW2RibmwYG 6kWLUA6EmS6xHPJyb93uuzQYW3svPxdbW/7TPjW+Qt+8Fn2zHuKhUXGNkO0rRY1hJXDuJq400dKk CSb09qVX5qtzSLwzLS5gStMFHIJ7DrFJljkQTzBn1GPOxdvngFXGjYca5hCz1jCn9xz1OuIFRitw i37TFWMcOalsJE7lmshY8kKkKPJc5Fhk6Otk1ruPRT7cTRYQeIL4H3ss8p7QGRkeOY6Xh5JTZOg7 ZP7rrQciHx+M/Bi5ey/xhp4h8QdY/9rQnwRRD0bwwCal3yDZrDfoLHqzh5hAP91sNppw/DPKYDLr eYPR0SSWxhtqjcG4nxMPJuaiXxr72DwCdcuSBuNQWxqqDYdSV8CqdTQTN8WNXbI0g1PwNHfP7fXN 7MsYqCtKQUWf3+K3WVwq7RxA/G0k7VL5jQ/fv2lO5Ov6HTsu3r1l/Pj1dwknncm/uWPHSZ87PFnI jui5/FXXlq4ahP1r7toi3oz6s4AfflJGZtpSU1L9BdZiEERO9lEPafRusu60fAY/esUhMlj9CGFf Ck1B0yR+DFL8Xp/VxifzHFgwxvXTlBR3MobWzYozeaWgca/Uczarz8vbzRZAwzSldFDXIb8/wU6Z WzWR39mbTKVpCU1yMPVnQy6TEwrLlYsfFTOM0rD1k+gpZossVDEWFkpGVZBsRibDkSQanYG4NG0g SUxADBnsc4hHh7lEKXkOOIwIrngNbiCz18i8qDrN5k8X/VEo5eLOTqXBFsRRN5HNySe5wob3D+88 9FcGqDfI7HfIKPKbVX86hVjavYdhaz6BZ26PdLQ/HPnq+cYoqBa8FhkWOX4g8ql8glgZpPZHPlIh dh15ODZvg/iqU+OleHhDGWPSmgzx2nhDpjbTcLX2aoOcLVuNJoPRoDegB4w6Q71JZ7ZpDZzRGk8s YJyOUZTOLFsQh1qDDkMoI2/CEEr8nZ6JWKcrTTRh/JQw99/E62KrE0y0hVdgecXRoXApDlExlDLh ptA4OeCIQdQTsGswfIpjMZRTwsjJLcT3gCgaZ3U3SDH0RsfXG6YnSNr3U9fvXvTWMWo5Ev5m8o4d 4R1bx42/+W7hpD3ppdblR6pJeDJ9EtGaFdHTIYjWFYNUvxjf9QG3nM1hkFRlKTvD992v3+sXTA6T 0+RaoW3RbNWKWq1WX6Ct1JcbQsmhFKnYv6DPa325Am2B/0U/96rrNfdLydyJvqfJ63ruKDnuOuHm HqH7XPv7ciV0J92ZglxxpeaAgWoMuqDuHh3VpcxNId4UztnkIq4OmqLo4lbaOHiGnCRU5ZEp3MoM jYuA83dS00dp/0ijaaX9svoV9aOJTV5TtkkxcSbGL3VIIVHlwcz962NMCsPY6iiTYsEWWyqpzlE3 qIRqSy5+cqujRDOQHp9gtvKiJSCkxVsxPOXTpWaSYMZoVQxwzdB7xSRGNKurbfmxKdn0AHtHpx2d LglVoM43upxRP+JPCcSvueWp0puLc0qOdvQfW/X4rLrDtcsnNZdULMrIS3zk5Lbvnr71fWIt+65k 6bDSUbNaNg+tW1Hz4LR5LdOuH9kwLrsyL+GGrR82PvzVdtSRD3nKaHV+Y5Ti5SUceAEDMxH5pToy a3Bk5j4WasWPISjvv0KkLoQvdLO7y8FCQUGUQuap0YHFx6VHOnYK2du3//imkM3wUAMgjVU5TK4y RsdpdBp9POfRefRDxCFSvjxEP1IO6qfK5fp58kb5Nv3d/N3yLv3j/D7NPv1RvkPToT9DzooJoLVT s7aSVgrXaY8K0lokEchO5rcLGpntlWuoXucVr1BHjcDzU7Qau1ar4bQ6XWwE1lNCpoAeWYoeozc9 4XgRey+gqwu0y3pZ20HTFIvEwiUW4On0KkeRVI4ikgewYCpoMVHME5JxVEGSojuEcVTZxPIQxFWM NV+K+9/YCuPf/yVZYUshKjHBD/Ej/6y5m2SSvUnkETJwZ6QyIXJtZEQCDvcfMlLCp+KQX/HT46oN lqDPuk+NKV5RxpcJ4+RX4FXhnCwEhVEaOoqM5kZLnA4kLSeDpMFRQdRguIhEWxKZfCSUj4SBiGaK lkMBcox/Mx4eZd9I5Fxt/O+QdbuUuCJxnDhD5ExispglchoT0nkMSpoMhLBS8DsN7g5rg/rbOtyZ yMAvqAxc5eLqhKE7uobC2E0MU72FYsIXm+JCS4kJgomB1D5JasjsA5FS8vaTkZsja58k7yIVf4EO DeeHtbQe45YfohytCOWwBuUgw0qlryBTDoPiKbxg53mBxRzYVxn7KqsdlLF7MkVSJmnZjB1HXcCT UW1iLZuxG4UhhwvvGA8a6qD+2IxdWJ2xi/Izyy/N08GAAYzaM/2hbRQdIMvJ4gORAbdjax+l08MQ HkZPsjX2lMhiuhh9pgSjFS8L3FkAz80CMz9LsrIZRQ54SfMDER/lb0LBp7fL23axJoQvFPaeR+gx B+5z+C25Dh9JIeNPn46EhM5tF/dsQplURxaTp9S6yhSPgPhn9WE9ZqzPKvHAxg6CehMPw03coyLp IKnt8g1fseoKL4R/vbo8ZKF5PvJUJPTii2R8ZPE2cdomNn4u6Ork3+OrcPxMhueVgUmKR4xX9JY+ sikRwwcgZku5XiJas+gpF3VgxrMCrSKlPke9JuitWdZzTIzOJRZF6+WQVKw5HRv5EqxuSecK2NLc kqMSrDrcOGVPJdi1lkpyxfVCcPIKxZyUbDAmGS11QrIhsY4YTcRcmAndV61xCbwQn5bAe+r4OAGv 81z0OqMh2EM2MQ15g4A56TwhxUiiy2jqnCL/Xkv5Bzd/FjlGSj+/9Y8TI5XNZ5qXvbx4yRuNF3nl p1MnFjSQcd98ScYuXvzKgiVvLl3yVvPSM6ufi0R5xp6uTsGKemFyOq5kxSsWfZIieqJyQtlIBFBS OtAicBNNghlQQKU+cxUEvas2/BKVxc+/y8iWhtQVxUOYoAgTjyqon8uohxQEJgXoIYXeQuSZEOGK ENHVWdgQBg47sDVtR1o3o1Bl5dyzufz9mz8joyJHPt/w3iSyRxXRoiXnGi8KneFHGhZEDv7jq0hb TEJL32pujkqIQD3i6FnEURxsU9ynPUSnmJwFlG0yZCAGDQ4wMhKqDEWrLTfrNCYMZAk7tHHlLpSd HgylCWK9LRhf00NalydT0R3hsI7bnNjEUYLFyWscATnAO8VK0FhwI9i5SiJZtZU9plTZgw9SACER hUF0MhXxwaaJkgj/bGPrxZcjF1e8vf6bXY1jIxf3RSKRJx8izicbzm7hppec7IKjN7y19GSweR0Z /eWDxLRr+HyGhYXY1/djWDii9O9tM8xOqJZZDfu1yP9mL7+Cg//rtmIhP7OV93/VVoTOHxN62Apt CP9PL2uhUIfy+S1iwQVejImm9oW+PI3j40SXxMnUg+EoN9LwhfNf9F8cf8T4d/ol9w+ef4++x/2J 59iPGM46uHbumOMV4O517jE+6eQ2ebbE7zRyyz23GW4zclkyAbPbCx10jjLE0trlJRqTl8heb4IC 49lvecyQDRi2A5Ht5YIugWnCayFt7npzaYqlXg76anoZZJQ5ortUxzyLuhKyKKyyqNgkZWKy1Sbq kjAosolokYk6byUke62SHXeahEo2q60ucmT2II8Y/C8iLiNV4ZY/mE12u3xR8doGULZeJvHZy67a 9fzyyA+Rd256hBiJc+8yemkA/8WTkx64XklYEJr58JLJmaR+6OItQVL94blH33j7ro+e/+6qGtLa dOvEeWU71TF0HAq8SmS/QtqhjPHIFrPGajCatFaDzqSV9LJZIyGPAqdWY2o1i1y5yUmcxKA1WqyS rBP1Bs0aE2Sh0Eo9+irDi2aVbI838aag++FjpLH7kZJL0VnxzpjvqkZhMelYcqMMAGVk5h1Cmj3A O6S1INq4tST6GA1xqM+5JZJcHO7wnZcbZdC0akx+n8HGv3Vu2b49c16wWOjc5PNlVu9YfmkI98ry A81zrmE4mhOZwr+FOEpBhZ4/BoauU0q8wV4Qr/R1JSnJ/tFySn87iP7yZKlvuUuL3qWvEm8ql0zU Zu+fIgCaXY6+XrcmvT4+OPCy6V24YnzsGTN8c8Yr1jcotY87yWzlRJ4TOCpa0jxpaWmJAbNoqyR9 3OmVkJqEGytnqoSMuL6VEEjwV/YMhjP7sggian4Dsr2+rMAAn79OyPb2ryO+lJ856cx+Dmc/R986 PtOJlx32butF4eVa7BL6qpQBJD03ipprCLPX1EDUeTldaVGHHXt6iy/ZmpEf+ebklo+2XL1r6Onb t780eVzn2p2Rf7XuJJodK9+eFZl9w2tLvzn5my8bzvDKpQc+mb/z0XEb1jbULXj00JA5C+66dPfd RNhVu3TikleXtX/x+XOrftMU5Wj3I0ebgL7ODU8pRVdzJEURLEkydbp0Lq0bcMwTJK1bi3xdixzM ybvcuqqT2nPaj7SctjTOVRVyn3K/6ebcQc+qZb2fT+rm2YydnS/qpgzRCR27aJbSjAaTgYpmUV9J DLLq+wh7qFIVndPq4Hi7w+agooND92flnXXICaMCRBUAmxSOPSGCuBuUrsZrkogH92+57rUbVj5X ucUUt6nxprNe+xYc2e5palz9u4/Cb1Lp2aKGhftWj38vsig67leiEIahfbHnMFoPCmIHGaz0NQER cFATTVpD7FmMU9ybHLLTNmPVKdObJiqY2jRB88MxP3NhRLmCdkXAxKJZ7mPTNyZK0EFUVIejl9gj ul4um+M+5r7hYpei4Uk0jisaUd72ECOHFSg4zM8QWR65a48ldw4J3uvZxcXZWcXFrq1bRVBzWdnF EeQ2al+6TkWmkBFqX+LgTcXgke02i150lltM0X75Yv3SG+MSevXpnOYjDRU0bXEdZLtiAJvZ5rWh h7UR2XacDoB42u8gdtX8PfOglzpZl8ZpiEmTpSnScP/QdGn+H/X2F/vKIBJbTTW7PCazO81ljltL PCbnWog+sfAzWbBseh6aR/7gvDezR4zIxuTYNnvKqIoh/QsSLL3Ek7BpTcqNiVlJM7Da+xDvZsS7 Fk4p5e9JRINhBgbdI5bRW+nddC/9oyCwkKxGFMjgK2sj0y6vjUz7t7URtjCCQhe12h4rI1ltfBuG ClmKUSzVe/VEU6UN6lYd67GQ3GsxpMhakPXfrIUwBUwH3BBMPdZF7ttK/vlG+Am6/Ez4z1uFzkt7 yZHwxfDL5O8RF/Z5I2Lcpj6TzfiYlpl9dOWoigvym5f9+8pRdN1o45YtjAtE/QTKTfwBfXUfeEsZ LcqiaYFvqbxUs9R0i3yL5haTxqeIfvQb6RkZSYk23trHXW4w+JE2g2jto7XYrbZkbQKXmIQSSucz +mRi7dYqWwfNbkusSsLd0YyqPsG+q5b9/Ln77jn4bk9SNOZ8oVmV2xVvYvXE6/RxaR59QiXotPE6 dyUH0RE75ojtqQFOSEvjAwEOfXWqkH7Fl0SnN225jsH5g5k3cfVwKjHS3Ct73+bgmPnN47ZV+ka+ tWLRU5O356yYPHf/2M0DV06euX/CZl55ti5bGTqvZu2Gxa+9Fn6aTnxm/fjlr3wRmUL7v7T1uuYz r0Vye/hdlKcbjnTQZmV4nPZd0xXnaxLR/aLfZe4XRI1eq/t/7X2j85cFZMj/f96XVJNgMcrs1xzw 5NeWowPebPa0RB0wr7yI/vetP1/xvxP+0O1/GZd8F+Vg6F4fMZaD5CiXdJ56vjTRUq8NJvSmc73W R1xptgBN0wecIgZRduwHxBPMmQyYcwuMX2twE8cZK4lZZ6z8+fpIDntSGlSWnD/YlUKvEGRKH/pp z87Iixd/jLy4c8+lp39c/MLSpS8s/omvOrL3b52RJ8h1nX/de3RTJHJ02WuNja8tO0potD8PRhYL uli8fUwZkKS4dfGo1T4ytRtNIDKFust1OrMRiJ1NRCfUy6U+U5X5V8NIxl96hg+eZFEbl5YU8GiR mSaLuInXuJG0Sr8QPlhtHG+LatB+RYPd/MXh0hucAYfBXce79HjdYLzMX2LK7Y4iLX7S/cBqNJp8 cPOk9zZ8Tkojxz67+f3yzTT7yMXGc0sWvbysGdnHK4sXR9q+/CZysGFB+KgwO/Lc6jNLm99asvTN JSif+ZHF/B9i8vm32IrJRy+pEZbxv4qtfi6c/1uxleU/zkP84T/MQ/yYQ4O/PhFBYB6CaCvKxwIN SgD9gZaazLIk4PCCyLFoZQkdgYk3W6RSm7nKErTWvNVzSRuNPledF2ajacxDRk1aZ+R4g1FvpKKR 09YhRE29TDqmcBcLptGMPcQ/b7uybcxVw4P9kkbenBK3nVceml6dtsy2ZEV15JNIq9rWwV2d9BS2 NQD/UqbvlncbDmkO6U9rTuvFTO8gfZH3Fv1m70NJ9/l2a1+lGg3nIWV/t5Mnve/ZPwPORdwOeoye cf4hgbsv+X7vAcqtSFzhvYdyGXISck27Q6PVcS4TSSZZhCMddKCi5crTJPaIJXWwQ7+r3KJDucOa uHpjaUZXBsaJGUQW60+lkJQ2ezD9wW56Vq2Gfj2CwXBnNUuquNg7OuXgT3Uj8+AFPlVcC25GPwQ/ xziIay1ceWyShX5QzcZhEn1URV0ocLGVghhBSc+PsvbuJQUcWOjJyqYFxTMzMtbePyT/2a3TnxhS vmD55GXp6Zt25OXtX7eTO1u9sLIwL3vg8All18649fjE0XNWNAQLswaMvLa0dMbq3dExYypiY53w DvK7WiXnlyaQdZTjBVnEEV7TqhUlrcyGDUEUJfbLLh7JXZtYJR0n20FDlrfrH36dzSrGVhW+jjkc Bh1XQWzmF0XTHdcR59Y//3nryZPCO5GGaBQXbVML+u/hvILx6TIlJVc2ECNI5TadEUQcYfQEqEtf ZSr10CpX0L152c8fNrscIFx+2CzAOS0BrU6jo7EQzZEmW3GQEu0UR3ezVAmcU+qeAmIPmiFTsbu6 f3eFyuz+1ULLVnvS/ubmx5Id2+vffuihd+t5JcIfHzln6aKqotfIpfAXf+lct+6zz1kf8nAszsM+ iHCrkt0hviy8IqLnYbPV03rMVk8D0Y4kCCkfD6KoRbnKbKHmOOmDFDLYJnwrHidBIKQPW5iQLA++ 3nthQn3CtJsGo6AL1RnrMf82Zc0m3KNz1v68u0gDqd8ZMXowpPucc0d5PgENNuMBbC9b05mQpi2g BUKxdop2Ob2NvkJfETSD5QJ9he4Gebn+Vv42zSa9vJPfpdml3yd36M7IZzVn9XI6zeDShXS5j17w aD265SKn0WqJvDi6rrMltq6z+cq6zrQr6zrTrqzrTLuyrjPtF9d18tplvVaLe7auI/7buk4fEGku FhwEWkwU8yg+9uzJA+d+6dmTr/8/rOao1Lm6x1JGdE1H00rGkGoPqSKT7ohkxEf2Rh6LQ2F/wTlZ +ukUp7v0PZN510UA7iOUuQ5CSulRHblBt1HXIXAmQ7Ihy/CrqznTrqzmTPv5ag5iiEUKg6ORwuCj YilSMiIQdgraNLhjSzcPHLtMiUeUH3rYcMqAEVVF9eUfwPzvize91m68+4gXN5Et5LEDkfZIx+Pk frSLhWRH+KfwS+RsJJ9eHcVYOo7TA7G/ErQro26gOP7xvJ2z86lcKl9HJUrZ8+JoDZIk0sv9FLlu i2HdpGjCIAqiUaLRNc0O0qedPe7eQfPbMUKmJ2k++8k0gwEZxFTfBkH5OB1Hmi7/4uu8OVwdru5h N9EHxyzdxsNsh/VXxn6zIOk06zJ0G5At/U6yjCy4K3zDnW+hVo9zI3/MIR932xA3S+3fOiVHoA6K 9kxYoKfinFeXYSSgrYJWakVVoRvl15BSjdQmBOVudKo/RutkA0iv5ZjLP2DFaDjhZaq6k6NCh/gK 4ZZjHH6UcsvJDfQGlBEDZAV7EED9OaNvBJcc3kUnXzpB68KsvYWruZcg+g9GFfdO/WoHmWEq/B7i ZfWvQl54c3tG955F/tJYkR3qYv+BpH5P1keuwbFga2RPZLdmyOUr3a+giKeYDugKyCZ3wTp6gejo BViN59bSfTAM9ye4m2A03wjD+Ebix/01mNjxJEwtmEowzWHl2Hf4P8ISTHX8cTggfAkD+V1wVFwH jcIFaOdL4RD3F2gXf4Rm4QY4SM7Bg1iunWuDdnToTVj+kHgBv/8stIn/gmb+A6z7EsRzdeCTnoYa /iOs61kooudICj0H1XiPBUIz7BH6Q72wChYKuVBH18M4YRbM4f8C95N7oZI83HUKvfV9mN8orYP7 2HnhGqjD7z2IaT6tg3lcPAymR2Aq/ye1P3niXtBwf+i6iO1N5+YynEAhvlfDLniTaEkOmUJuJm20 L51Cf8+t5CnfKowW3hCdYqV4h/ixtFu2ysc1wzVPay5pC7Xv6wboJupO6T7XHzFoDSsNXxgPmIab 7eZSC2+5zfKh1Wottf7Zdr2t077U0dexy1npfN+luN5yX+u+3uP03BtH4+6IT4lfnpCdsDLhw8RB iV8nzU36fXI/VZNBmIIRfQGgoSGb9sNQ1OM/pTWg/tAakzWmbxHQNCdPGD5+dHnmiNrrlzYvXjGq cWld/ewr/4zVdTXc8Iv/7hRUf7MgxP4ly3T537Gi/43F/her+1+xov+I1fP/sKL/hTXgF/7/Kvrf V0NBufKPV1hTKZTBteo/Io2D8TABJsIkmAzXYS+nQjlUQCVMgyqo7qCL25rykzvoovbq/OQ/DdPQ eVhlMq2P7evovLZAcn4HbTx0+JXk/HHDXHQBzMDUiOkmTNsxPYTpGUwSXRD72nzcF+J+Xvt0Z7Iy LI/OhPGYajA1YeJRVjPBjMmLKVs98yZuP8b0DSbuF66fwm3PMjyE6FTMTWVix62CqYlOVSZzZrfZ 43V7PYobwyENkyuVmYwRKQ5ew3JULoIigrg/R7qgi/AzYAbSuO2E94KXjINx6G5R59/AN4Rf9JQ2 edFTwzRdR1BtTjKVLMPWJbP9IZFz3rWtg2S3p1zeb17VQXLblV/eK3rFCSNH4q2tDll5jnyL0F+P ofoHZH2bATQdZFtbU3byMA3ZgB25Fyu5BWrV/U3tjT9c5cQa2prSkjtIVltTevIwLTr6i7r3sYCT ZEC9WtDf3vjCACyYomhZ5lLTgOQ/VnXQe48kv9RUkXykvkMYpOiTDze+nePcite2NOKJo8k3s7I3 sYttySsaO8j77Y3O2Rfxa0eTqxsP9nVOazwm7CJj2pxTLh5jFbY5r2s8oRuk1tzSNr0/Num2tumj cLexbXoN7jLbpj+e/BxJh5X8HqLDUj5FW/7tNc4fp09O/ld5B/lcsa50/rP8jUHO96fPS/59+f5M 5wsrj0nPkmePOk+VH+zvfGLlMd392GznndNPJreWd9AH2h933rjymPAaGXPUOZ/da9bKDu7D9j87 Z+LVexVD8kgYSUcK19k1dk3r8/QGHIla6TK2JXuVSVLrJ1LrHql1rdTaLLU2SK0LpNY5Umul1DpV SpVTZK+cJCfIcbJbdsp2dDlm2cieoJFlWZR5GdEjgyk5K7kouTH5ZPI/kr9Jlk4dI9/iGBuycWW0 bNJwUhY6NRvKZnlDP0zydxDthMqQ4B9OQtYyKJs8PDQks6xDhomh/MyykDx+WvlBQrZVhOht6p// dBAPO94Qz/73h/3jR9qGrfFs37Vha0UFWQpLnJn//nL3+q0sKRu/4lkEwHjscTLJaZeS6yQ8XTYJ z7aqZ1vZ2Vb1rDsxtLNsUnnoQGJFKIdluhIrykKPT/JWlR8jF8i3JcXHyHdsV1F+jH5ALpRMZOfp B8UVFWUdRKeWg1ryHZaDJrbDcvwbUMvKQS3/hlqO3hstV4Xfx3L1bIfldNVQpZar0lX3KHewsaqk +GBVVXeZRrVMY6yMMEgtc7EWy9TWqmVcf4WLapmLrr9iGSgLVahlysuxzPRytQyZDeVqmXIym90n VHOlyMpYkZsuF7mpZ3PUMuXRMtoV3WW0K7AMaUIhfDepvG2kb2TJ5mL8DvcZO5qpHrU11Y4sqfOX 1BT/52L1Vf9VscaLsWLwCxD42c+le75qh2dmts99evl69h9PNf6SWkw1oc3L6tyhtbO83oPLn479 +VOgZtbsOrafWRt62l9bHFruL/YenLv+Fy6vZ5fn+osPwvqSyeUH1yu1xW1zlbkl/pnFFe2rltVs 6FXXpst11Sz7hZstYzerYXWt2vALlzewy6tYXRtYXRtYXauUVWpdpKSeGdz48oMyDK8YURXdt1Od Fu2nJt5XMdxpbhqqGtPVPveN8cd5IPtAl1kR0vuHhwyY2KX+w/oPY5fQ07NLRvbXXrFL7huv9sUf J/til8x42oLG3EPasGTp0qXN05dE3/jCI/ZQZGZzt1JIJoS4kroOOr2kLqRsrgl5/cUhiZ2YETuR 4i/GkeD/AMUNIsQKZW5kc3RyZWFtCmVuZG9iagoxODEgMCBvYmoKMTQ3MjUKZW5kb2JqCjE4MiAw IG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCAxMDA2IC9DYXBIZWlnaHQgNzI3 IC9EZXNjZW50IC0yMjAKL0ZsYWdzIDMyIC9Gb250QkJveCBbIC0xNzAgLTIyMSAxMTUzIDk3MiBd IC9Gb250TmFtZSAvVFFCUEhYK0NlbnR1cnlHb3RoaWMKL0l0YWxpY0FuZ2xlIDAgL1N0ZW1WIDAg L01heFdpZHRoIDExOTQgL1hIZWlnaHQgNTM4IC9Gb250RmlsZTIgMTgwIDAgUgo+PgplbmRvYmoK MTgzIDAgb2JqClsgMjc3IDc1MCAzMDkgNzUwIDc1MCA3NTAgNzUwIDE5OCAzNjkgMzY5IDc1MCA3 NTAgMjc3IDMzMiAyNzcgNDM3IDU1NAo1NTQgNTU0IDU1NCA3NTAgNTU0IDU1NCA3NTAgNTU0IDU1 NCAyNzcgMjc3IDc1MCA2MDYgNjA2IDU5MSA3NTAgNzQwCjU3NCA4MTMgNzQ0IDUzNiA0ODUgODcy IDY4MyAyMjYgNzUwIDU5MSA0NjIgOTE5IDc0MCA4NjkgNTkyIDg3MSA2MDcKNDk4IDQyNiA3NTAg NzUwIDk2MCA2MDkgNTkyIDc1MCAzNTEgNzUwIDM1MSA3NTAgNzUwIDc1MCA2ODMgNjgyIDY0Nwo2 ODUgNjUwIDMxNCA2NzMgNjEwIDIwMCAyMDMgNTAyIDIwMCA5MzggNjEwIDY1NSA2ODIgNjgyIDMw MSAzODggMzM5CjYwOCA1NTQgODMxIDQ4MCA1MzYgNDI1IF0KZW5kb2JqCjggMCBvYmoKPDwgL1R5 cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvVFFCUEhYK0NlbnR1cnlHb3Ro aWMgL0ZvbnREZXNjcmlwdG9yCjE4MiAwIFIgL1dpZHRocyAxODMgMCBSIC9GaXJzdENoYXIgMzIg L0xhc3RDaGFyIDEyMiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjE4NCAw IG9iago8PCAvTGVuZ3RoIDE4NSAwIFIgL0xlbmd0aDEgOTU5MiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeNrFWXl8FFW2Pvfe6lp6rd47SSfdSZOwNBAkbIEARUgCIRP2YEcJJhAgRJAt oOATeSBCmsUwos7gMsjI7lIJih2QRwYZRh0VRsXluY6TcWbUKM6gM6Oh652qJAg6b37vv1e3q+52 6t5zvnvOued2AQEAK6wHBsq8JTXLYC8Zjy0v4/3SvNUNYds7F5YCkJ8BmM4sWLZwyclnPPMBhNkA 3J8XLl6z4OkjmogDFAE46+rm19T+Jf9XCkD64/j+ML1BniTdi/V2rPeqW9JwW8kt9BGADHwHJi5e Oq+mb0v2QaxPxXrOkprblrFiIYz127AevqVmyfw1lf/ZhnWcHwYsW7qygZxaVIL1F7BesmzF/GXn pqW8CRCSAfiF2EZAl0eXiIf/0seAG7pb/j8viuhyYEKeBKyJIIEZc0s3pzZ82sEB8hV6J6LdDkHT KcjWb06BIID2Lt7tep5cobXr/XrO+mkXTa+DTN/XvjC9Bi7t79oX9GtwXT299r9cyNjif894N91W LG79X4m2wCa4F9bBfrIW512AlPWwjNhgBJYasbcR5XGTAbAT7tNehh3wLJRCHOrgEgxCmm3wNlwi TvqGtgPckAoDYSWshTjN1hoQkWL4GSInIUoxeBfpvOyS9k/EMQy9oC/Sjqf7kn/X/mRgmgppkAOj ceTl7HFtpPYf2i/xXRvy5MYZF8LD0EyOUTd9k5OSl7TrtWptEdI0ax9ql3AtUnHMcTAXauF25PEe 5PZ9kk+W0FF0A5ed/LNWrP1We1/7BiqgEpbBCpRgBzTBo/ArTN+RIXQ2PUFfYxvYSfY6u8xHkueS r2mvaB9pfwcf8tUbJV2AaTXidBdshwcwPQwH4BS8SFwkRHLJZFJNbiUt5CQ5Q3NpBW2hv2Y8m8Aa 2X3sb+wS0zgXF+BquS3CissPJM9qstZPW6it036uPagdQSneRow8KEMYMqEQJmIqhTKYjKkCrkdM 6uBmWAxLYA3a+gbkYQtK8DNMu5GPX8AeeAYScAJewfQOfITpE+hEY8pCzgaRPDKcFJKZZD3ZSO4l 95FnycfkWwo0hQZpbzqO1tEldA19hB6irzOJuVg26+CyucHcdK6OW86tMM3pNF0+k8xMrkg+lTyW fCX5uTZVe1b7jfaJ9jXahgnXzoIIDYaRuHoKrsI0mIl2OxuqocbgWud7BSK3AXn+KeyC++BBeAge gb2wD54EFVrgOKaz8AK8BL+FV+F1uABvohwfwsdwEbWGEisJkgEoyzCikIkoyWxSQ5aSdSjPJnI3 2UHuITvJz8gjZC/ZR46QpzA9Tc6SV8jr5H3yCfmMXMTUSS5TByY3TaXpNEL74ToNosNoKZ1BZ9Eq OocuNJBooOvpA4jGL+hh+gRVaTN9mb5C36Ef0c8o2iazsBSWzjJZFuvNxrIiNpvNYf/JmtghdoS1 sdfYn9hFDjgvojeDW4VJ5Y5xr3Cvcue4C9xnJjBxpqAp1zTdVGG6xRQ3NZneNr1vusjLfIQfyU/i l/AH+Mf5x4WZwl5hrxgQI+Jg8WbxbsmNdngvrvq11yV6A5mM2nCCWKAPPAafkT/ACyQFNmjvJTeT OlKIVl0JvyO94RZohi9gEcxCbZ+D67CZDMEVeA+e0MajXfUnN7LpqFvPIfbXcTcTD9mHFurhyrml +DZHbiP5VET/8Bn8g+Zz0+GM1owj3wrniJM0aKPgv8ls1J5Z2lewkfTC1EQUtOlHaBM8o1XiOlfj mj8K09FnXIKD8Fe6SMggoc5V8ClJh33J1YikDGHyIn0QGskcYoW/EMaN4yLMCbfCSTIKtekVmAG5 kCRpMJ8MJSVabzKF+MkI8j7chzJv7JoB3zgL36A+LYEXUfM2op+WhQxogPvRhuaiN8qG58mD8JmW hI/IBfTqHWhXT8JpOI92FOdyuD9BM5sg3gCPox+pVUaPGV0wamT+iOFD8gZfNyh34ID+0X59+/TO ye4VycoMhzLSg2mpKQG/z+txu5yyw26zWsySKPAmjlEC/YsjJdVhNada5XIiEycO0OuRGmyouaqh Wg1jU8m1NGq42iALX0upIOWCH1AqXZTKFUoihwugYED/cHEkrL5SFAknyA3TYljeXhSpDKsdRrnc KHM5RsWGlcxMfCNcHKgrCqukOlyslqyuixdXF+F4zRbz+Mj4+eYB/aHZbMGiBUtqSWRZMykZQ4wC LSke2UxBtCFX6qRIUbFaGinSWVBZdnFNrTp1Wqy4KC0zs3JAf5WMnxeZq0KkUHVEDRIYb0yj8uNV wZgmvEgXB7aGm/u3xbclZJhbHbXWRmprZsdUVlOpz+GMqhMiReqEte2BAf0TZP/MmCqNTxCYGWuF Sdr65tL1RUWV+myu8bHNV5OnsXhxYFFYr8bjm8Pqnmmxq3sz9WdlJQ46oH/Z9Fgmch0p3hbWxZge MyTAQUkgF5nU23QxuwSeHynWW6rrw6oUKYzUxeurcbFS4ypMX5PZkjpJadU+gknF4fjMWCRTHZsW qawpCjZ7ID59zdFSJVx6bc+A/s2yswvpZruju2C1XV2Yf6XPKBnkegm57oGa6BxFSlFF1PC8MHIS i6g0e4T+mD8C4vNGIBlelQQRXYT4VcflkfpCmLLlSDj+NaAiRDo+v7alpruFz5a/Br2oq8sVlcP+ nrIajar9+umaIozHpUXOxhj1oQP6r1bLIsvksFqGkMHUGL5UOTIXIc/M1Fd5a0KBuVhR10+LddXD MDetBZTcaKVKq/Wetp4eb4Xes76n58rr1RFU56eNwNGrijlXfg7Z5y6uG6kS37/pnt/Vj+ZTHG7m TNnxqbGcmvjWtJzq+LZKXJoSNMV4vCQSLolXx2sS2vq5kbAciTeXlcWXFVf3iJTQ2ramqcq2yjqC oKp5XWio7vExlkYru0o0jWGpbEakbNoNsRHdi6Zy2fgrrY0U1y5CFVo/tx7XC38123Rty4zLauk3 mTodzZbPR14kKnGr4JFVUmCwTVRwqwQXvlRl/hHYiVOZoxFcFdWP9qb2icZxLc9HVDlaEJadKrgw sqM6FLgzAXpEAaY0m7gECbYAL5wgQdzgCbU+wxiYeVOCpLUwgTuBXhhfIUILpSxBCo9Kbz4ViMrf FMiXC74ukL8ugLFXitcNynRmOrPxQTCa6wyztk7FBN9BmGvDoQu0du6v3GyMnoPEqjwwiV8tNljv dR9OeSzttFXIELNptmsoHepa4jsA+5j4rutdH33J9YaVvmB6SXreylqdx12tPvaY7aDruMTuCx42 HZZY3Pew9JCTxaSl0hqJ5buGByeamN/ax9U7yGweZJnY7YRUgMMDOLGD2Hl/zCwQsxzjLFYbo9Rj YxjO2+0S6QCQHA5cTCXs8uSHHMQxKUNKrQ0JucI9AmsSzglUKE0Hf81vAtHoZPlS1fLyjujayfJf q6LoJqIFJLf8sv6MygXEn+/Mc+bB2I6x+HPl5282DYzeIZ/ZLBbYz5y5bhCp+v6CqszIcD6SBUNl yBvs8w/PI4PHkKFDcrDJ6/FxNdu9Jy99kPyYrPxuyyulKTsvV2z+YMObR15MfvzmY20k4/e4Y69a seZcZ687v9h26I3kB68/8UbXOWYU4v0Vnj0Qb/hcubFWrJVWiXu9TwSeCp5iLd4z3GnvbwMWl+iV ssRsKRocAQXBIlMRXyHVmtZa73YdD9gla9S9it5ha7SZEEqPDaG02ysc4HE4gOA5CLG0yDGaoC8r Izk8LznMjFptiDvTe+XUWiUsKEK1sEzghEkZTiLZOxSQmhx7HKqDOUrTvQ5/zaOIJnoyFVIrJ8ud VYhgqoFjGbrr9XpbsioVgUZQna4eWBHVjrEdzquARVhF1D+oQmhJHhuWNxi8MkSycnoLEZJlJ4gk NiGqhNtRfvJvH5L05I7vtryKeNIjd3+44a3DL5KMC6b2y62nkh//PtmZ3LpyzXn2ngEpydIhJYb+ Pon6mwrrlYFzfat8m3y7pF22I/xeSeBMIV8vaYhU5rnBc6P/KatIFbsv3xa2e/N1pBJ0+9OWmMtC EnSpkspiAcFOHBthUlCoVfZ4VS/1lqZ5dSSuAgKFnix/U96ObI+93I4/px6YkGgUNYYIqB26UBkk b/Cw4X47iYR1/ckc7OOeXLnmn01f3F37zO3r/qisXHz5QDKZ/JDcTtz7OlnF+DPr2zesPDa3dsq0 1UtIyqeoPMu3oq6MwVNq/25dOadsWgiLxZt9a9E+N1rj7rh3l3W3uylo6UV7uXoFhwSnmG6UDsBj bH/KnuDz1OIRPdIe6/NW7kcGh1KCbm9oYWhvYL7K4lCTOhwSKqqjCQN1w9KUHhvzdRvZtWhEdVXQ 7asc/c21ZmbYmfMHdtajDteal/sH5jXvGvOatvNy+r8yL7ry2/U/tK+RqA/3oT74IQOeVPLQIbn2 ZzBhkNWXP4yV2Yo9N9oWpa9ybnLuYj83P8YOmY+nv5Ru85g9zoTEIEAypAQ99MwU8SaRign6uuLO WEeI2xSzWtJibgH8vgyC7W8c/VIiUoJsVYKB2ibfHh/1TQqTWofi9efrhkQdpaGa5oDhkKKGylSV d1yq6tCBMRxQhys/t+ObqnYdHh2RKhKtIpm833eV5gxx9dINxtN7IIlk8QK3o3MYq6t7YuUZpW6K tkuDpPYEyTr0O+LazJ+9/5f/HEK500uXzqmomL+GjD67l/Q/kPzju33G7j6VeBTtZDqCs5sHPEuf VioxVBadVptdclrNdom3CA6Rt/AWS4XV6bFanYSB12a2MKtdkEUHizm8xIteYp3o4K0YXqMCgWDm LbLNaXVa5cCECZNgo+QQiSgepyuAp8tbLB3OBF1+zG4t9Vv9L7eS1dDlnQvK2y+3d86pmnNpcvH8 ok+6/Ed+vnHndWtNQfnlgrFVHV3tXbqkK5AdNciBFwxEe9MtjXeQPCHCIu7I8LzhY2jeYLrbXVbY r8Dp/Mjx0ZbGxkZH3BYYVq/MNJ26a+L0Oxpu7xzFfn179aEVxfq/XH0BuBy0LT/hlGkN/F08BXae 0YFsoDvbM4aNcU9mk91z2Bx3g+ku0wGvVZTMZhG9qEV3uV6fj9gQLrPowVbi81X4weP347AWn9ns Nxu+t68zpntfSRCtdt3CvMQnmsEvWyy2Dn00WVwmrhebRA71qaUlRUI3tPKoD10x5orFXxrwmv1+ /84XELmrbK68PfVyexTVyjC2bpPrgVHXLkPBdE9cYLT02N7AgIGgYJcLCsQCPdNvA8yq5VDlNrwz nqMEBHSYYYh2guV/bJl68O19v/MVxYu821bUn1yYPm4LOuRnf/Xqvht3J63k0gOVy+IrTr+e7Iu2 Z0dgN/D6/3IOuFcxO1ExLFMZYSxBzz+tosGgbZ1TfKh4uF1ZcbtCYKwOs5W/iSd8goxVJIf+/6PV IdvQtI7itmTVTUxylMq4J+34Q+BfAIGRTlVH1dirtnOyVr4YyK1a+0989JCjsn2BkuoCotfJGTpk GMtjEeIaWFg4MHfcuLGbdsZ5MIq5AwuTyndtui/RRiVnkUZDnlQ40goO7SPFKlnzgz1ynaDnQQIJ ZXIaMqVaPampVpu1RxxXlzi8L+Z0pKb1saaiXGgc9g7rSboc3HQlKJBKXzuW5kn1p6aZE3R1sy6j XNAjppxM/bzdkDIqtxlxC8rqzN9sHxg1XZH08g+ljP5ATvQmWb2Ho2cZPmw4STFELixUGn+RsaRi aJEzO6uvP9NxjfRr39oevNUXHrQY2dfXtB7thMHNSvgAJYTSCgYejEYxZmX6v7BMBhMxISY2Q4Np twZLrJTzMv+Oj3+0apeu5ne5sYRdy1durJ+ukaiOkd83vhY3tX8b7PLrI9CvP4x+3Q7p8JAyJ9VW QktYqVRqnsUqzQucDfxa21183GY9FDzrfCHA7vPuDv7Sy/KD8+W6APPyadZhXiaJlIg+X0y0OGIg 4NbGNXF7OMZNCrlxm7PssVBLaYZX99s/2vHRfRtuG5krmxE7Abz2LQha8qid2vgReFWiT9PjRlJF BmdgCEA5fXNDD+7vCXP07W0goQe3/nnD/uSfm99N/nE/ydy/4Y+3v3Fw44V1cx7nZm/quP9I8t09 JPTBkyTnwKYNf2h8/K07Pt+8/KkalJ9PruC+6orT4WVFuUNca9suxm0YL8tSWBrNRgXLWaFpplRP F4jV0lrrVqutOzjsCvyuBIgc2B1dDsor6w5KD70tDrsjvY8RGwp6qG11+PL1GJFifGgsqr17UW1N GICnOPyOdPOOR69R1cm5VYZF6lhFjcjQUFkjBtB9Of567NOPClxgBIakSvc8wlVxIbs2Lnx5h/f7 sHDilJ30oythIaf88vuo8PJeU/1VYSEQ7StUmr2Ilwy/VpSJENP/vmX11s3kBDtu/S17yWqmNruD EIejQsbTmwyiWTA5iAzmmEmQzcCLgt2GwGFQJBuYuHEvEia5HK6QK9fFJIeLiET3Ug4dGvRSbodM 7pHJTfJS+U6ZyaXOItl/nN5O1sK1MRMeUHScdH2ZLH8S/T6E1gPo8o4eP94NlmAvKCjosghhDIaV fqHHM2/a6hrxyIxRSuGQSOk9lSFlC6c0Tr4+uN674PkPk3n6lxztfa2dHkMMcuA3SmyX/Ji838vM DlNWqsOb1cvay9MvNMQ60j0yNDSnWCrKmSXNzJmf05BzV2CX9LDjp1mPSU849mYFMiTc6IIZnmAw IyOYkmmR7DxBVBXZkw+QErMb+oIVu70PH8vM9LiPaxfBjY2pNk++2xLMkIJSL48v5nZaCItBLyG3 Dy772LzLg/W7W1rcxUbk5eVifJQb7cjTKz1hge7rNtvvONMVNnZt/F6P36cnw8kZng13rN45ekKP h9sYPfaT2esmLghl3PzQ4OtO/fyleMWaHdNuG5B+Z2M0emzr9E3s7PKNc/L79+lTPL/sJ/Manz46 794VZaNH9Jo1Z8zo8jWHC9HvLUD9ud/0Fvr+vygzLBjvMBEEiTMRXuIo4c2M8HyFAB4BLYgIYKEm kTMLZk5apzAz7hkcM0sUqS34GgjyVFu1jdrQScrASLWxdyzHvYPQlS18h2FaWcJGpVoigyRFmoqR qKSbNcPdhYhSqTVF8H9qbH89x6/OLn+TWt7Zjv60q7WzanmXnqWpSrd3rfphhKXHV6l6gOX0518V muuBFWpZHrsSUZGbG4e9Lb9917aNJ5zHTW8lF63tHMnOrjW+EOaiLyrhFBRsuzKcUiLwCAKjBM2l AgQ8YgiMM5kqeObhsVkwMZ6h2+HteFOB8RLCwJ2kG1F+E90AjG5ULBLfikf9UnFnuxE0Y7AcbSeX o5eIESfqnMJYZBpztBVjp9h8hxHUiLqRiHKB7k7ceRLJIxGS20RSyWsPdu59mAzhlM73WeTbwdQN Bu+4rJW7J+U+WHuTo+BrSBONP/FPn7+nT0+u7/qm/ry+51iufPnEXLQmR2M0tz25OvmSVEM7oPaa 7wAuHonocADTrVBgWgWjTAMwvx3GmPJgJMo6nfs99CW7wU72aKP03DQaRiAdT+u0r1ia9j49Bgu4 SZCLYxVgukQeomb6GBvEEtxc7iXTT0xNvMwfFPoJL4izxKe7ZXHB9fp/OMDhEx0oxhNA3+EX4m5N DApXtwQ8pAHMnDFt5oQp0fHzb2nAw9OEpQ11i+YNKG2oWbxoXtceC9o/FizURsGt//Irpf5FlEER FEMJTOj+OvYTKIcpeLaYARUwC3mZDdAKb9A3W3JCF07QN9HzhOiHLRU5oZP0LXrBqL5JLxzNCQ2f Ms5P34Gb8F6K951434P3L/B+Cm+BvtNN/jbmBZhfOFrlD50fJ9O7USQVn214U9iDz/O0FUtt+PyS Pqs4aVv8fJy2rT6/mrYtP7+cto2z0UYkajTIG/HlRoN8C7ZtUaZQOSCnhAPhFCWgpPASBCCFiuDB DckjezlJL1FxLIwl9BycIxpohLsJbiL3wD2EC0OYTIEpqNwI9kW4SLjtCVLfwoW2jzOTeu09XBcf +YLk4HwhPVf8jPpOL7GETi/Jt/g+3ekLfbozzed774MEXXfU25UrIe/3PRg+EnQBFEQoKdHXwCkq JyieXbDx3pb6maEE2dlSvwuzppb6U6FxbrId6gNDTUNw3jyoJ8/hvNdBLd2NeX+oxXNYJfZEj9ae H+xLkH6KufaFQb6/1k8KddS2mjaS8hbf+doE3a3YQudqtdG+V2s/HeE7tThhGqJYQ4frB4UO1h7u 67tTJ2kJzV3cKjxJnlNsvpt0stm1+/v4ZtWeEG7EWX1kV0tVb2RrR0vV3aHnSBxipBx5GNxStTB0 nPTFqufZCb6LVUtDn8USdIdiO+D7S+ydEb62qg9C/1WVwGGdoediLw7xnYi1DvIdqpoUWhdrNaXp HDZUIT8toflLW32LseCb11OYE0vgYc4+3lcilKCOVkh4NSVIhTJTaPpWaPpSaNolNK0Xmm4Tmm4V mlYJTXVCU7XQdIPQVCn0ErPEsJghBsVUMSD6RI/oEmXRLlpFsyiKPB7SUClEcGTkZozNOJXRlmEi qpuV0bIZhaRMbZsHZXPD6jczIglinnaDaooUEtVVBmUzC9UR0bKECNPV4dEyVZx6Y6yZkB2VKt1i fCxJkBS9vilN/07SioudvWl7mp5rm7ZXVgZgpS/64ytwdYWUTV1zHJFtAyFaNgOLTUYxkK7ej4Gq eji9Uh2sF7T0yjJ16YzwbJymnvYtLmqlffWsMtZK3oL64ul6O3mrqBLJ1hpkNNpF1q+bjPI0qpNh O6+TJYila7jFtF8XXT+DjjsLi43hFnNnDTq6u4uuAt8vakVtjBp0FjNUGHQVFvM1dNcb48Gi7vEs X8L1Bt31li+RDsrUhTpdcyxWXNRcFesS4acQM2hi5KeGCEu/J1naTdJ8haT5qum6aGJdNOaRPTTm kUhDlqGQf5sRaynJLCneWoTvsD/ptRqj1rLo+pLiukhxddG/J6ut+D+R1S/uJoMfrziJ/strfiEp XqQr4NRYswiFleNnd+VHqcWM+lSdlllZ6JOXjTGUS9w1dnHacWhkfwdLtFI1RwpVS6QQ44GAHiPk 8laVxyYBb516VGZgXdpxDshBg9qKzbburgHjBozTu9Dp6V12/UNid1dg3ajMtOPkYHeXjM1ONIVr 2IeVDQ0Nq+as7ErfX7rYq7opQWXFdQl6trhOVbZWq+FIkSroDb/pbsiKFMH/AJTgwaMKZW5kc3Ry ZWFtCmVuZG9iagoxODUgMCBvYmoKNjg3OAplbmRvYmoKMTg2IDAgb2JqCjw8IC9UeXBlIC9Gb250 RGVzY3JpcHRvciAvQXNjZW50IDEwMDYgL0NhcEhlaWdodCA3MjcgL0Rlc2NlbnQgLTIyMAovRmxh Z3MgOTYgL0ZvbnRCQm94IFsgLTE5MyAtMjIxIDExNzMgOTcyIF0gL0ZvbnROYW1lIC9UU1FUR08r Q2VudHVyeUdvdGhpYy1JdGFsaWMKL0l0YWxpY0FuZ2xlIC03LjU5OTk5MDggL1N0ZW1WIDAgL01h eFdpZHRoIDExOTQgL1hIZWlnaHQgNTM4IC9Gb250RmlsZTIKMTg0IDAgUiA+PgplbmRvYmoKMTg3 IDAgb2JqClsgMjc3IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAg NzUwIDc1MCA3NTAgNzUwIDc1MAo3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3 NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwCjc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1 MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAKNzUwIDc1MCA3NTAgNzUw IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA2ODMgNjgyIDY0Nwo2ODUg NjUwIDMxNCA3NTAgNjEwIDIwMCAyMDMgNzUwIDIwMCA3NTAgNzUwIDY1NSA2ODIgNzUwIDMwMSAz ODggMzM5Cjc1MCA3NTAgNzUwIDc1MCA1MzYgXQplbmRvYmoKMjQgMCBvYmoKPDwgL1R5cGUgL0Zv bnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvVFNRVEdPK0NlbnR1cnlHb3RoaWMtSXRh bGljCi9Gb250RGVzY3JpcHRvciAxODYgMCBSIC9XaWR0aHMgMTg3IDAgUiAvRmlyc3RDaGFyIDMy IC9MYXN0Q2hhciAxMjEKL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nID4+CmVuZG9iagoxODgg MCBvYmoKPDwgL0xlbmd0aCAxODkgMCBSIC9MZW5ndGgxIDIzMzQ4IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp42r18d3xVRdr/zJx6e+89N7ckIb2TQC4hjSpFIEGC9KZIka6wUekiFqQs YMECCCoBogQRl8VgQFFBQRTL6oou625W1x+yCtyT3zPnJhBc3/fdP97Pm5uZM2fOuXNmnnnK93lm zkUYIaRGDYhBsfHTx84cg+/rATUnEcLG8fPm+B/6a885UP4SIWbapJmTp+8+8F0bQlx/hMRdk+9c OGnSsbkvI6T5GaHKM1Mmjp3wtx8m34XQUPg+KpgCFbpZ3BcI3crCefKU6XMWrNIHVHAehTbvvHPG +LE/PkTCCA17HK43Tx+7YKbYrIDycGgf+e8aO33iqDuWwPOH3wnnSTNn3D1HoVCG4PwROP945uyJ M9kHXDxCI6ZA/96BOozoeOiIEObR//iHCYMQizheEBVKlVqj1ekNRpPZYrXZHU6X2+P1+QNJweRQ OBJNSU3rlp6RmZWdk5uXX1CIioq7l5SiHj3LYr3Ke1dUVlXX9Onbr/+AgbcMGjxk6K3DhkPrI9D/ 2l/tb1XWjfyfv8gdQXruMIpyDcjJZiIfQu2fQDpPj9Kw9m+5VqSXprf/kymBmw/SRKSyUnQEPYS2 oD2IRzuhHEWj0SZ0Ak9DB/Eo1IQ+wl6UATzDombUH53E7e2n0ST0HNw/Bx1F69FeoH8UTUcWuLoW h9oXwXkMyuPQ0vZnUDIqQsvRYVQMra5Fbe0vtO+Hq0PQMLQL7Ybvv4ODZC9ran+5/QIS0WBocylc Od3ev30PMqJuqBwNgtql6A0cYs63T0F2VAK924qeQtvQH9Hf8f24qX1K+7z2U+1fIQJX3WgofBbj JvwVs4dd3r61/bt2CSgRRanw1DFoHXoW2t8DnyPAPpX4DjwHr8PrSYzcT5rYZZxNigMdUlA1fGrQ DLQSKHAQtaAf0S/4e2Jn9Mwc5lh7fvv/QyrUD0ZJRzIRzYPPCvishTEdwjzOwr3xILwYP47X4w9J KhlGasl8soB8ywxkRjELmQ/Zu9l93BpuE6+Sfmo/1N7afhbZkAfdhmajJTC6o+gUuoSuYAbacuMQ LsHleDR8GvAWchBvwwfJIHwEnyK78J/w1/h7fJVwRE0sJI3MIevIbnKUvMdMZdYzv2f+xPzE9uQI t437hg8Jn0rjpFXSe+0l7V+1/wxaQEQBmJlyNBDdjsbCaGeiPPQ7GMVL8NkDs9aCjqET8udr7EZt 6GegAugK7MQ5eAB8BuJb8CQ8FT+JX4PPG3JfLhOYCKIgBmIjbjKUjCPTSQM5SxoYF5PK9GVGMnvg c5z5iLnKXGU51sRa2Gq2D1rDTmc3w2c7u5Pdx77PFXM9uYHccK6BW8WtYcZzp7mP+CX8Wn4f/z3/ gxAV+gszhDUwOyeAZ/94kxiwOBl6n4PuQuNxBR6HNsBsbMNj0Wrgrgl4JfRxJoq21zNLmGqSBdzw BroHuHUzWoxWMaPQtvaPmV3oHHAK1UMNaAdbjjzcRpid+1EWcFHig2IpqSnRSDiUHEwK+H1ej9vl dNhtVovZZDToNWqVUiEKPMcyBKNulcGqMf7G8JhGNhysqUmn58GxUDG2S8WYRj9UVd18T6N/jHyb /+Y7Y3DnpF/dGUvcGbt+J9b7S1Fpejd/ZdDf+G5F0N+MRw6uhfJDFcE6f2ObXB4glx+RyxooBwLw BX+lfUqFvxGP8Vc2Vs2bsrpyTAU0dzAG5FCmd6OKI4ZUtOFG1Hvs4il2ONA7KhudwYrKRkewQr7G hCrHTmgcNLi2ssIVCNRBHVQNqYVnpHebSvuJHlRPCE54sDmGxo2hpbGjahuZsXWNZAxty5DWaAtW NNoWfWO/cdpZqlzT5WIjCVWNnbi6CkjwYE3idAw9G7sGzvoN9UOzZFldbSNe1tEJ2sdpFYnuTgxW 0qox0/yNimB5cMrqaWOAuGhI7T5nzFkZHFtR14gG1e5zxBzySXq3g/YlJQEY/cH0Xum96LEkYF+S OP7lgUT9B0dU8n0tX8Kx35DrBMD0ScE+0M9G/3j5IUHobBHNJhah1eOL4Db4q8MwzKnQn96NBHiG CTVyoT5jGxuGdnZjSkWic2OmVexTOJx0DGPK6+D+Mav13eExcL8+6F/9E4IpDLb9/eaasR01fEj/ E6JFOtHXeQWud5bnyYShj7MHp9D5nVfZcR60V3apgHNKGtrnRnNjTr9BtYFGfx1UNKO0bv2akWJQ 7V6M19Y14/ZlzajCcxApEHP7aLjcjbLa1Ap4Ppykd4OK1ACUMrr5q6DhKsor/tX+1X0mrPZX+acA M7Eh+QgXJq6uywQKDq0FOqFb4YmxOtf14sS6uu7QTiZth5XbWV0HLUzraGGa3AI0EIebsrr1g2GG B9UOrm1sqHA1xirqYBaAfY8Mqm08AhNXVwd3ZV/vKRwXT7V39DkH+pydCoXcRCtDoQ1oom716sRZ MNB4ZPVq12oqY4nzZox+XRHrqGhGcgNA0WbcMEi+1BAMuGSaB4IB6FYdpWkesHQnRzWj/P+ewgVd KVwIvS2QKVz0v0Th4v+Ewt3/IwqX/DaFS6HPJZTCPf7vKNzzJgqX/fcUjnWlcC/obUymcPn/EoV7 /ycUrviPKFz52xSugj5XUgpX/99RuOYmCvf57ynctyuF+0Fv+8oU7v+/ROEB/wmFB/5HFL7ltyk8 CPp8C6Xw4P87Cg/pQmEw2wTQMuIywTdgkIB6xgIcnwnAhBUyGaTk2EyGIU4FL2Ri5BAVKwPj77Gn pQ28VDogXjpQf7l0gD5eispK46U0ZWflGgKGCKRt7Nrma3/mDl/p3cwOuLofyc8BfxE3w3M4mL+8 mAvA2C1CKrhbNptTYBkc4pFDqZoQWHCv/IQBLfHi4paBlRMrvkUDyuLflmVnmXINTJAx5FqCbe9k T8prbeUOS574UnLvtcunoP0hzCwyumMcoZiZ8E+w4NWlMGyKAF2XAodqEg23fRRHie5iaI5+yGjv Qt82z0IfdzjeRPrTBL0sbz/Pn+IeAzSvQy4UQbnoh9gQXh1Sk0JtrXqyeoN6h/ot9Tn1ZbU4RdRo tVVGnU6t1Rntak1qlis58KMlWRNJT1b9mJvMKXXafBhnajL5MStZ/M6Y7P3RnpzsyCsbYk8bqIc+ XWu7DCkx3MzSAWVt1+KZLW2X2rDBWFxM04qMtMX6luwse++FsSEoJ0OZ5QIfKNWFnUl2F9L7jS5s DUPJ7IZSDg9XoyxczVSku3AahswRdLmQwQeZLWRxYZMHsmwh1wUUggyldfzhzsJ9uH4WAtDKB5PC +XkFuUwuDhoL8vPCwSTeYrbmGrtcQ13qefbkyUcePXny0UdnXPvTjJyFC4cPW7hwGK14BC6waXAy HCpJ88lHaMUjJ8n5KzXMlIXDhi1cALeStHcT9e9eDdA6mmQXHW1lZuEh8vyGYybyBIM4oCj03sFy f7w+ufEECcsGtCWmFw8JzAkkppW2sVYaTcZyZ5EZOF1hNihMVmhDcQhvBX/HjLfGtDHUwPbXOyzW fwXuHGJvFnKWJXjG+bmz7UzH/JQBL2Ii8Aa9zWoKZuBIOBLO1xcWmMjoJzKrB+esW/hYVUqRVVVf cog7K73/yKfSV9IXPzwufXdhyZ2P7xxxC47+ZR0OyWOqgP7YoD8mVBBTiwZkskB/2P46E+0SQgro kkJ0mC3/CpTd08G9Z9o+79IPk7GwwKCPhJlcL7Z5sUUv8Ez1UxlVtBebe4WzUkaXvCaNxgVrz+EA DvzwOLZevnvi4kuzpI8vrpe+kPswEOSmBeiqRftjk1bwG1kygp3PtoqMRq0uNKpUSrVKAIdFLDQq FEpRIfCCyBcaOY7lOYIJgwuNLMuowalhNSpwawjIMnVywL0RtOwAQYsEXg+jYjZirWajyqErq0nw fLz0887ZKnMM0P/dYCsGbrcV08SuyLCniYv1x8TfLrBQgEmoR/XYUmgTbEJEiBRGCm35+Oj56PkV 4x9YOmnVZ9GPucN/6j+j+vXqN9+EbMbAr+TxjgLNM4O1gFwXxtzMIo74RdUipVIDfeQXsQo/o1yE HOpOybwEmuJSJ1PJJ0D0/IABVJ0lYAgaRuGm3bhJ6r8bv7oTH5D67JT64lfl5+ySTuEGdB7omh6z oqBWOUFUUkIIecoJSHToxk9MPKE03nadac8A29oKCqk4RYL5uSBhwq5Ktw6T6R+NmXdaPSw9VVAJ 59+e32RJyMQw/AXpRzaCTPhjSpTJYCeHQB6acfn+wGuySFzQg0Kh0mCC/g7DlyUl2XhQ/u4eyGj/ ZHnCqYySyhOeQL8/IUA792t5KgTNu+f06fPnE8+mSn2aLI9pMZuAbXgjZjAhbiPDIMIoMahkxpFp PwPKtqyUS+gvXI9BjeAPNkkZm6h5oHYh1v4J6+Y2gZZ1o1kx2woOV4mWfB3nzhc0xiJmhr1I5a32 6Oe12M+0xdtQWVsZ9AW0YB5yacI45AwrQlzYqrVHQaqNUewSoaTnoWRTW6LYRCBzKN1RZGAhu0nF pd2H6pHNatALJOCPhA15hcaAscCQR4JJxGC2WXOZ2L1jRiyR/ixJS6aWzcP5q7cveOmpdZk1L3Ob vtkrnZQ++4P0jy8P4ZJLe3DVlW9+xkMu4RLprPT5p8veSdCoBQZ4FmyIiIJ7RdyMc2NqlhXUrLCB Q8pqBR1Uy9l4MUjApXcpX/XEhbnAVC1vbg6vPcJcXm2q237lLuay3BY42ayXewIloe2xgQVsFTuC u8Nzl3eRdyleQcRUcaTjDse9jnvdrzg4lIR1rFvrCAhuB4sR59PpkkzKfBPn980NJKkDvxOKrDOS tBHdfb6ipOTqYIK4l9r0P7VdSJjzNrA5mUZZIoupBYIM1ctkd7MOdcgQVhm1UaQwC0BcVqNXRrFo gQzoq9fjDtIWGMtwgpeDSaA1glAO5BgtZoHXYR4qgCH7LvvjkfvyhmxYfLA6zB5gyufi6OWvF1a9 smpc0QQno72WchAbZ87olz/0jsXr1vRbdmjeKenysy8uqp7YvyB7xLRdMl2ygX+c3GaUjVpivj7q oekTU8anz02Zm85vCON+YprSnmbWML9km/M1/mYcjJkN+frfaTTZrvxkTsjP1tg3RCoMzbhvTKcs yphBfCn++5gIya3O6UIVyGXGA6Jcin+rb9NT+lDayCQpyMxyhJGCC3tCSWEeMVHEMmIWkMMd9EWR M2SPYhYLQK5MyLwBF9As7JKJlWBGfalMsfuAZrieJfm5VuC9nA6bKuR7cW5OFzLmUTJaKRkFUPhm FMTWb15XR6sOrH3xlW3GkMkdtk7sNXvTxKbKMLcvdhe2fPpDdbeqWb+Tfvw5gm3HHyybtWnB4/Mw fooh/qJH7pizoHzR0zOPv3lw6ZBcj29vw7uSlMBrecBvmdxWKGnQqFiSgihFDcj3G0aeFwiPOUFk YBqVZK6K+55RA4RrxrZX8AaN+KKyGdfu53TVWpmCP4HWvEA5HPjKUCxTrQPQUC2uAzVuUGBDIB/n UmhnIM9L+fi9+BryyKYPP8RXyar4fInDoxuZtdduf0J6JiFX5e2fgc5oQH50KJZWY1zpI8XqKtMI 02QT211UawSkBsSlnWs0mYxand9oEpDJprTlQ8eSYk7N77Raj7G7jmXz/a0ejUEocs5ARf6k6kBi xn9qa4HJbiuLw2xfuNQ508WdIOwY6qhIgLGo3YcVJMx4URQ65vNzbpAJhR0y7GOjiHdBJjoSskFn W19Kp5vOdb3ppnmOUA3NgJDk5rAWMwkkJUfixsWxW5/efKChflnm1unkYvypHjnpg6Yew8arUtse 6f/p8fTNJd6T9254riamYJiXpdlhU0B68x3p7WMn5Tkc0P4pG+SelPHrC7Hi+U5sE0NixFHrWI5W 4JUKoVpUBiKBfK3WzLQK+S4ukg+ykkLu8xYZZtiUpFSZnG1LqY7KhIkX39tvyIJFmXYQiA55oALR 1ikGeaGw26+zIp4L+3XeKA5bkqPIbYISlQnMMj59IIpD1kgUeYyQUZmQdQVOCACVgPuoTQfYGQRM BVr4BjmCScigl/XzDajJVB/epw/2Wrpxn7Ln6OHTmrBa+tsJ6bNei3H/+x5asn3Onqce4p78Zemw rJHSX6Vrt6VHv73wpvQhzsZTseo1POHK53+4/67WzVtWJuxhP5nfG8AODY0VcCoHKVJ1Vxdr+mqG keHsOHJAUN6radIc0zBEgTXa7kjHKtREIyI0QysWKV7UGqr1MplAYXxD2QNYHjge2AaD4gScwgNk pPJrNBUUBvLZzMpvakekezJaKy6u2njtItfwRG+p6cihzeM/w5vxhn+89AoCy1refg5021bAKjaU g96JVQ/HIxQjdXWmCXii4g7dVNP8kKKP/h7HvODs0N2Re7PvzVnpWOFfEVmZsTJ7k0NTLeaIIS0J 5ajyDYZuXL6Xs+V305AicA2XH9AWpczIFItcUH7FXJSZV53bReHd0HdtxR1GQJ7j/NQMt99oZTTW dHMUqdO0Uaw0isDmHshYH4liS4YtijSpkAluLooZP9dF03WZ466uRJcyisgeRYeCs9KwOcx9MtQV kueWNzxw/5wNk1Y+v2vZfc+u3yq9knrLxbPvfVcRHlSXe7t08bT0p3sXMbFlowYtXz5y4ux4yYrl Dz6y7v6Zz5Kn0wY1PP3tJ48uH5qZnpI/4enD0i9ff/y7g9lURvq0f8wawH5QGdkdy3BwaVzUWsPX clO4VY6Vzk1ORZUoBCKRfKXSHsjXc2y+q9WuEUip4M02N+NhMZUGpbjuSy7SdAqKTMJ48eKEtMi6 5GZB8YUdTpUJM8YQCSfpQEr8BpASxgEqJKyC06AWBMVnggw7QX2E1JGbkEuChjihPUxaDIKSn2fM 9ZusFgplwCfrSl2sF+8orLzv1XDp3knv//MfF3Hx/PJbHpBaPzhPcvY+dc/SLSvX45Hri73ncJ/b B2Dyzps4Kn275a/SL+9IL3+2HYcfanxyy97H1zxPafU1CEoTG5B97JyYk0sVmFQERkAB0JHDE1ga JLjhwgP7dwL8AWAyqQcPCh7S16fhjw2cj687n7A1XwNWboZ2deAJFcc8KKgDtGxK1fOi0iJDZqNy gh7UqJk2LYNmaLuta+P/hpyBe+RHVbm0GE8/68u7/+zZ05pBqTmcoD7/9h0182zc4PNU7t3tbexL VFOjabHYCGYyswIArB9QLCF+I0aYhzLLsH5weXiGZwHVchzGPKdkEGYJB5hb5JFDEFcGbn8lERzR X7aVwlyjHmVl1JnJZAfYV+jT9CvSIId/6riYsEWBLdjNPnqtgnn96gwyGr/dJG2UNjThd4Aeo9AX 7AymQKZzJGbBfvSu4OdZ5FQIBEg8KkDdk8SjSim8j8ehUQvYUEjsjKttrOlqG1Owc6c0dPfum8d4 Z6y8FtUyU5iVDEtHSRg6Poal4wOHDkaMUccoMQwY01HyyClilmNI11Ha6LNhlD3Q9VGu0NtvHqUC 58M/Zl+6OoM5dK2SfRS/KhU24Wl4apNUQOcdnFzWxp2i/gvaGquOGmtMtaaJmrkabqp6oZqERZ1e Y9GpFHaLUaNi/foR1E/xv+1K5rFRl6334QkMo/DbixTOJF+23xFI+jAwvjPMM1B/eYAMY9suUYRN Dfq3hhuI1iiLotPhZUVPyM35eiGnYO+FvayrF3aIkKGEvCVQWQhYCRlltcQLWmwJ5hXcDG5xW2ur tOfS2WNtI5aOKd5XcfegZGt07oodsWRu36lT7AksfLVn2tKG+vuWPLxn1i1JoV5V4x65t/J+oMFX 7WeFEu4b0PF90duxuoKCvJqqwLCaKYrJkWk9J5cv6HHc8ValypHmKI72KGKKtIUBXiy2KCPlVapq Qy0axtQGJlmPa45rz5nPWc710qqUDmVYOVzJSkqsTM/I7OYHX1zMF5vxI/udwb4EjvvSU0rg8IqJ qe5b1RtKMUNfhZJLz/BkFOVw+eGcsK7oMH4YjE4Z5DohZ1lm2+egwoCWmcbizzM+B+Yui58xFpe1 nWlp058pjbdQFljB6Y/g+llg7QDcIGq/qf7JMeYjJgzGuyDgB2cLAKscNCqkegsKCIhqK8xlgKjm BBpCAb/AU/8rkJNcaOPZIPvV0D6zdwzvtWJjfOOfX/nsEt6CJ5z8g/T9C+NHs0z+M8Pv+T3mNkxa xuasW6bTFgZnvyK9Lv1DWnrixeeO4PHbsXd++Uhp8znm0Hjp/y0bNxmX/O5aLeZOYyOuuiA17ZL+ eUE6fHtvlV1z9+371rTirHlDwYnP7WlPT/nHkYtY8cVh6c9Xdp2YWjdy0Bpqk70IcT3A7yVICXN2 PjaoBtfiKRgEaiO7SfmCslnRrOSj4P8KPI+JqFBApkQCh9dg0CJmpTJkhDozx4UASWOVimMUSpbn sIpgcJy9AkxUXUzBMoRXKBkOznbGjBoaneCexE8qHWrNtsCa0cDjjoGX7APicYesBasqwM7YwNEe EJdhdlknZDUUZ8qotd/g2kb2iKuRbamjAZREBQMVTEtdWie81ZeWCpCo6NLQigqbwFtnAkwQM2v/ 1LbsK2I5vz5+6KmT5BEykgJzZvyV3rhZqpGjABuBLiyUlMgCduz+WNFIzUjDNDJNM82wiMwPCH00 NQbiEX061mcCGkZEr42ovBGRzXZN1WUHnakKSyhqdaSkNuPb9wfmTeoaaB4gA5K4bEbjNxwvo93J iY4QHxbsbBrmnGIaSG1CaGEEWPaaAEcGDF2KDOXCG+BC4FMwaVlSddfc8vulJ/BLBwZmP9x/sTT3 TTIfk+mxW1IGzCoaX7dM+iK+jhkULHz4kRy3VBwfOa337U9398WvcqbNt81/sC4zklYw5oW1d78I XDGy/Tw3C+TZA5yyN1bi4jbiDRzjA2/gfryCW2XihorMco/BYOG7exh1d4vCS7xeB5NNSvTZBqdf ke1w+PzbAtMmddVjl+jIQdMmkIQ+EQHpjty2kCmsDbnCKqsiB2nM+hxsNOj0ghvOOMTkYExYRmlX 5yCdETLRyeeAKwpZB+ymwDuRy7gCFJ2IbcEMLKNtI3U7C3MBtMrRESrAQdaL8wxHA8f2fSL99M/v P7u7h/eo87E90rl29PI3L76Gq6PcN9L5Q2u3S+9LxyRJ+sMLdY9efOLwlnfxi7jy1J9lWw9AghsP fKJBdjQ55lth2GAkOaLKqyPIaxPFbJPTqQlpHQ7nR4F5qzqjUJQGlAHi8sDD2GoIWcK8wAmswAhE 4HilXoTRWiFTGFU5WDADXpYVeCodV4iOhKprPelkAYNZIDD1pyb2mtO3xKn75J/SU8fJUJy5Y33t Fml5fM8uS2RG3YNDq7EBZ1zdxJnOHZVOf3dY2iePYQ/YrTYYgwqp0cBYsuBlWRXjxYgoRK9SJaqJ Wk0QP5WUKJxaRgwhh0bbjFX7A+s7ByQz9aULhsSsygsoMm8n4nSGjoT3sJnX1jFp184y9149Snzc 4SapfJek3QOP7ozhsbvgRAGoyU57oejoBX8HdqrkJytVzXgEPPmzrk+m/vi/PTC4h7l67SQ5Hc9s lR+0Jz6BjnV8+yd0jxBKQkF0OtbTxS/HywjjwT5uOV7lftXPxUQda7Ey+unWJVaisxo07PIkvcFr MhotQvckxiJqujsVQRIMMl5jM+4X0zNsNlOiD5mcIWW215EcasaT9wemzbyJ3+NyiCXB8jLPA43k quL6DtUmc0I3VwCp3SF/GIfULiVweAAyHrE5mDAcq/JocpDCJ+RgjkCGbjB9AkYDv6NEDD/B8GBw TIF8oEQEmD7YyfQR5tuNn2YfS/7ziyelv36L2VbMMVIeWdaQNXHgA29LV19/9/gbOCPAfT3obunL beuk96TT0hXpwF8wef7aPw7PSOv7whk8G886f4rIc9a53qZCZbGAqPACzmQxUQoiK4R4zqnBypAK OdRqzdOBeZQm+i7LbfJqW1mpTA15QYwGooOQB7edINdOnIizJ7jD8W3k9iu9yZ74YPl5JyB7TNbQ tmagwGty6DYjDTUjlNmMSGZWNrQTPHHihByQxSjY/gkzHe43ofJYkoJ38JNVi/iNhFvAYoWCNRLN Y6zCEEJOizIkOMyWZjx4f2DNTZNHXUeYMdntBQULDkkPnCtbd5BAQy4zvXCS9Ofnvzt0x6ynsr3H 8KuvTX59/zdTpy5YOL33a8yH8loP0GigTKPXYot4LsRFxBqhVpjPrWQ2Mc3MceYvgmo7sx3gNxcV UxQ7Fb8QDpSByCmYM4TiVlEUFIREGSZkBKHgqbGFKo5V0IwBT1whcoRVsgylPC/ewd/DXwR0f536 GlA+o69bIMdA/bf1YGBLgfalclTUViyuGJCRxi3WH5PXI/TU1zumF0tFmBc0e1Y9nlUPZMUBBQ5g wRDcepScxKb4E2SOFI9LfzsKs5RHTsYbr60jX30loY4xs/3k9dHsmAkRhnhZTmScAiYhDjl4oRkP 3d+1U9AnJNv7xNIoSPDWVnLx2mCYxh/3QHtgj3mbPI/vxOoqcD8AFFjBWLGDOYc5E3YzZpVLPQLX Mmfwp8wZ1adqJdBDU0mWE3Yw2UhIijKqKVIWaarJCDKPCKEJGiVhjEAwldrI8KK8UkWXGrbENEof o+LjakziGh+I+JZXTchhpswLrhr08ILjUnEx/Nsv0F4nnDaKVYCS/YYs3KtRN+NdTQRmAlTVrn2E MCu4ARmL4uzilhVc4gg0rZ89C8+un2WiFAWWzyvIx0EKGS2G4Ebswdvxs9h5mJXqj0kjuTe4w1fD 7PkrvZnx6afmX01hz6UXfJ537QnU4XNwqbLOVKJ5MXMhLuIJXb6I4GpcC2yECaGDsslxThrkJCK4 oYxSiXkRZgWuvcKxTjXFaVtiSgVyqNQdknqToFIllVDuMNBiuqKVtmLxMToQ8P5yMZVbDP9b/0a+ PfynuO4N0h06PZLdfqU3+/zV22QFz6BB7We5i6B76Qq0G62OdVvBtaJW/CY5Lp5Q8r1FS3cd4+ou KNzE7VYZsxmn156tcni8H/8KPlwHD7LSzEFOunLSsW6SQ9dNcsCLhZKeh5JNbcmh6yY52KF05SAD 68q5ed3kV8smNCyHjPl6RJWo2Rhg2C2HHtvRIq2XXjr60uNv4DnY9Tfpn3+7IH35L2zRct9ceVM6 JR04346+/Bj3xalnsP7KM3jhT5jBpVKr9P4laS83usPG/izjSTMaG8ufqp5qXKheZGRrzLXmKeZF ZlYQvQa9Xom1OmrzlCLhjWpWYTZns06rTgGmz2L9DaMbp55KwubqE2ZFjs+Z5Jg6D+ggiGScGABX ZA9Z3/LDR19IOa1Mw4Lyu6U5eM3yHdzhz4+/2B5fxx7s7pOY2Y9QnhrU/qA8TxYUQRdid0xlplkW MstMG1ytLr6vu8410j3BMteywH3AcdwpFol2F3E5HNjidDmdToQdGDm8Rig5nA6ny24hfDLCBq8F EU5DK9hAJNBdw0S6Y07hBYyYkpytcERTfj3JqCy3jS7c2OT4ekfQmiqqDHnhFINTXppWCnlLWmlH 7NoX5vWqsC4khJLUyTnIr/Xm4DAPpaAykIN9eshCYiQHoa7BJxq+CwkR8N86Zz8Bp3iBLaCLsAWd vKBHAe6zCV8P+cMsadfR3TInLDv0WDB/iTTizui2CUdu6wVs8Q/pO3A0CLvwpfSCL8/jmgRDAIus feD4EqfBseSe9VMwmSdzx2kAlf+S3krEjJpAjhfIchxBj8eMgqYPruHqcC03lZtgXsCJ1kM4CzuQ C7tj5cGAPzzGOMs418wYvT6z28IEvFYzGzYmh7xIoXAJXhUJu12iP2TxhaxMtm6qy5kihkMRJdD5 o8D6m52RS21n4CObg3iChYo7AgvUi6qHoxz9wDk3fI4cmxw58GIfDdvZLAA5MnFYvhhkqtc8O7vH JMnZSnbunP7+9HHDR3ACozJmXFKqWbUwoXiRVNLKuGc+9kSxV1KSbdmj40t35gZnNxy7NaXKHDCV Dv/pkWxXfDXQZEz7WfYy8GEmykJSbHSKLhIMhwu0+YHq8LjwIu38ZMUdol1rC5E67RTtriRGqe2e lJykZFi3fbk5MzPN3d3MsN3TFFlEqRUNyUm+aFaWwR6y9RFDUWeOL2Tog0KZjuycpwPTOoQKPJMb DorRABQwyKHvTkeFsmNGPJdGBYDhBkQzDD4kkjAJp4f4kDPMdENpKD1DPnCp4L95TL405LLY07DD jtPZNKSIqNJwSIUzoCykQOY1uuGi1Z2WCCvr9dcXEG4AOxqzkcOjCbdPJnV+XjJdSkisLPAWs80q z4XFzFI+LsTYK+SNvzJz1L5+/Z9pfXPwGmy8+hfc+5Au+7bzjZtHlpx6b/3gNdITf5P+sWULQwbg 84sHPubv+fSC3JxQerf8UQfekv7007yyux8fd2eOPyszqWRyy6UP1jz4D1ZFbXsAdBngKySgvJgT 814kEFakQVN0lTAhjr3KO0Tq1P96x4Fs3+XQHkV5+ewJyfC2ZOAO77nyI6fdk5CDXYDPKZ60ICsq jQVtXIQr0jNKUB7d9QorY7WaFSG1045DZofN/nRg/czfMgyl9XQdzmzrxGgJ5c6EHQBf5pTWfRi/ LfvtPsulNdKaZX1Ib+7wtTlPT3v6pdFPMWuutUr/fEy6jJWPYR1TDGPNA7ksgP7w6OFYxSP4aUxi +FZMrBgv4L7FZDI7hVvJMo4oCdG4I6JREA7wOcMz0GVWFCmuIMyTHMJP8g5hLVAF4BcNdRQXw38i 3EGxGEAIYzGmKIwiMAASMQAgGDEsRpjw3ArQeS1yltgoMmvWbAWhmw+wHsDCtj/FL34Y/yuYXA/7 9ZXenf5UCCFhFpyo8fDYelGBFwgLFQtUK/BylqvG/UgFU8MOEMuVq8QVyuOklWkVjqvUtarJwhTV KrKcWS6sUv2ebGDWC5tVL5DtzPPCLpUOYKdSVDlEq3KEwKtEVkl6RiujXAjQBQqp1SoFixkVOCu8 mkNEVKoYQdTSkDfHL4+JDHtJSRSXGlQIL1c7NDcRw5kgiLMrUWwyVWwyWdpWZLQBVZoUSoWobMab YzojDQdwDMsLClGhFGmdkm7egWqkVq1YrBcpmOVka7FC1N846Td44X4MNha+8So0B7CPkRtUKMRE e5Tk0IKoPyInPbcobhdb7HJhsUhnYHZ9/SzAcCYFzlXQPSAKmIk4tuD+H+P+2HJeWnJaeknafVpq gCkZxu6mCZDQ0as9YTYwfauCy5P9gddjM6O4gAAoZUawk5nJ7DyyQFwJE6SKqApJIVckTuGAmQiW kT8nCqJCABYDj0ABxZBRqVLKu5ZCRoRUhBNVMHyBpy9jKJQMEpU8i2gtzL2gcGoYDK5AM1bvD6zt CLkNsLfoBzouwyGBIyiOLS01dNA8DUZPt7rIB32XQwL3BYKJ4dPBY+cPRCuZfsHz8Zw2yUS4f0lz yD/BJ3iP5MTz4joyCmSbjrsaxi2ClXs4lrqSxeYoG6JRe5AbmDZOJKKAGRZEB0bHgH+G6H5Khm3G KKbgCeH4EBbBdUCvIIeyk31AxRTbwWj1yNQDMpd5B2yWnWoCWaiKM0q5LnJ1gAN5FGGGWWCRFjmT lzDkiQS9ZEq9CBK1/a/xs62TwK/pSY5eWxdvJIOY6bJMNUjTCQLYKqD8mJtxIz3rFoyJBaNahvUL dM3oh8CduddN7KXOVaMBcrzHFJAXjQINuOGjj4A/Wtf9cnIdwu2HQPkl/NpYLLAJJpzuPQIupVoE wQlWYidHdweeCnx6QJ68C/rLVHEMKCvFXbdU0tWYIB5BSrbGj1EfWFYGGGVK0/Eeud89Y34EbgHj 5lg96ug87ye4FjFy30vv7eg7qO4bXafI0kB3CVD3Oh8AZebZs7hBamhHfN66n7fLz1hARjMfyLry jljWFGYB8xADOpEhrFtebeoYEWVPxHGYcinLneYRokoSN+Mhr3AOoTT3ulK4oRwHtHXsppMHybZ0 ijL1pGYpEuJHZuGxz0qXpX89h28Hjb6NbIhPY25P7O1qR+zd7ROBtrpXcBVQFJXqS1EmuA+G/IAF LqGJE6l/MqT9M/kNLR0qQaXo81hRahZW6sGvdEdya/RTFdP0QrFoVCsYV46QrPDo1Z6SNJKRUnKg hJTkpIaMeoET3ZEkm7sZrwbT5fEJEU+GinjyVaVCaanbLKSk7kx29nSluPvqIkWOHj1fxxvBmB7E G9BN8ONCvOW6iyPvSqBDp0Asoy1D3kML+EwGINGCQksSIO4QLtAFkN3rCiCr3xzAgSRUSALI6bEF wNhChm7sS+jYmJMs28YeWIvl7UuWm5Z/euJcCvEM8hJGoYWubUTCkY4ljoJCE9bOHnh73YbAlJzp 47KH4qaeFvUDix4qCSh3cv969vC8ubaQ2mtI7RauT7UqCt+7d/3h1zaufn9ktz7bH7W4ea3GnTkZ 3yl2s6ePGto/dehbW2pqNsU3upMYZpmaLw/Gaqa9snL9cyZ8geKBee1fsCHuKDIgL5oZy9gu7HCf czNJos4L04hsHk4wKL0elcocEZ1+Z4Y+A6cgg8PnXxE4XN8pgxcuXA/kwL+h2JCgnt1o5ZVW3hzG RiVkFsEWxiaFN5yItFIyAa9TUhgNdNUeKGAJJl9figZwMW9PyXNjjv9y+fyiW3OKt5NJjz760D0H w9VHuaPxvw0YLLVJlySpsSQ4YNXii2+88MWrpzeO3itjnJL2r5hT7EDkBD94RyxzhwNvsu8Ud9mZ vqJhi5lhzLzHKWg8ZpVLcLls+ogRMxFicHqUEZvD7WnGwv7A7MU3cA+IR3Hxb0XU80AZhdQWZRhp TfpwIpbugDMOMQE5lq6yasJIZ4RMYefDNJYe+I1YuswvyJqIpAt8YmGrMDexUq9HuQL56GvbHv3s JS/2zVr52MwHHHu8Pxz64Ao2nnGzAxvPjX9g5/Snt322av7ZYzj3W+zE3QEaoKL280wbzKsKedD8 WE6htlo7QruDfcHFhUQz0Xn0SPR4BJOSeGwqLsOUoU8xGJ0+VcTp8PpWBGaXdx0+TPCv59ZpdyuU CGO7Csbmhgw5SBgpXWIYd8wujMp4Y7+SBYEfQ6MY+XRYiG5AuPzYtsXbti9a+QJePTSrx0vPlL04 Y7905fsv8O0Xz514581Tb5PCPG8/4rnSc/34Wpx+5Ts8AnRITft51gk6xI2SUQirYws3ir937vAx nJboOLNFa9RZzDF1zCymOHE/1atMK36LaXV9LH6i+Mj3cfCi7WJQ1WpoNZJRIhdI1m22epKLeUGw BjxuQemxqkLCRvcO9wGQATZk1YXcnEOpFgzaiM4T4ZyR5Awh4nCEI2cC2+s7ogQJ1j8TL+7YeU8j mdf5pDMKLZOsCgUB/nAE4CvL+8AVNupNerOe5dWhJFdyGPmRJ4y9HoVNCCOVRRvGGm3QGYAqDjLR Dnyl0UOGru+BkpknNS31PjyrHs2qpyxEPZRAYgcgZSC6hSjhWufihCMDhqnpo6ICo/7a99wjGx+6 Ncu8V7gle8jCXkOOg2dt/zP2qaJ9X7p3J4eDbPUdwwbf2feZZ4/VF1SXPJoxyK0HM8ADai6XwnOr 7t+/Gn+WwMFuEDob9wGyoQGxNMHDKz0M1pmLrRreqHSA7dFqDCk2o2DUaX1aor1mdtgd1wKTl3RQ sL64RSZUVyemTN6hYaTbucD9pXLBW+huEPjk5+a/EixrMiTb3A7VEP++pn3r13PleaMIeY7gYS+v vTaB2bp2pxwP6yGVMBeBV3woHWWgA7EBBeY+Yh9FrVinWKl+wbXT80Jke9pBlwqQszUpRduiTAKT wvIpHofS6FHqMoSMDM7NZFgz0lM4Z5ZaG9H0DEfcjsysLgJyqa1YjhNd+Mlww6aUJbZ8diw6BKNO r8qQHNKHg95wGEWdkBlU2gDSadWakCcpjCOuFNATamMA3bzoIEsRlZz8XEMiNB7J7XBUZWuRTGcW ha9rDTAxmNw7Ojd/e+lM6cRLf9ce0ER6PPB+LMwUbFr8snQVC6/hiud+90ZVaN29R2/pJp1my3sG e6+4lnNy3vktz9dESh8b/vmQQf/CHqzBGdK2I/tu3/zK4T3jl5J0eZ6XAlGpTrGiobFuIDWiTbCJ ETZimivMFUWThpgsCBk8vGBRKzUpSvAiLSnICn5kM+b3B8aV37xGS50yqlGKMRUQ2RjI+/eoYQwa 8hJ+tyG4tCmWO+L+vw5NP+jNXjHz1SZQ/p8NDhQ/W/dkfDB5dl5h7eaP4scTvi30D5d0vNNTEHML 37DQaZ6R9xsB36YIDEWPu270pCVe2nKd7eRd6xR90Y1ASw/AH5t69SPusLw3sv28NAgXyW0bUPeY l/VotfgbgkTeRP1yhTKFxYLoMJq6tt61+QHAFxjQI/Av7ompz2ymshmO4KKmJumZhdlN4bJGjcfH tp36JY8NjmJfvVo4t/s4gO6AiYHuP8v+zI7YhDqCu4vYQUC4bfwIbjK3kF8grOAOMieY84yyYzGD IUvJ4yAQDCk2AszneFA5040wY/KCBpdYzwCvH7EMrxR4Je/UKIgyBanAgdkXGHcQW9H1yZLXMzqW M+S9O5gCxQFymPCP8qsX9dxi/ZGO1QxMVdFsupgh+y2CIdjwEn7vW2kS3vuttG/jSwAdd+NWaUZ8 HHGvlu6S+WoVZD1k2qbEgIM63i0gKYji8V03Mc6NV1lgolY1NSVeC0jwJh9iq1EYLYuVCKKg5XU2 0aa16SJiBNR3jWO4arJKHQwpnZ6gQ0lYWyjgsXk04FbzLneIMSmj8ExDirkZ433OFAABOAb2LSME gumIRJuxpisDX9BfarvUCd7Bp6MIWo5dde59pNxs6eBmWyfaA6bu4Oku3L0vllc3q2Fgt+TSZyZ+ PDD10B0Dpv3+gDNl5qQdTWzmpluSe5QlVw0fuvXWtfFCcvGOQWu3xx8lh6bn9Hvyfcr1JCGToOMc gHZGx7IP8K08YXkzHzHP4+cInFlNzHY9oDjE21VKp+B0InWKwunGGfYUB3K43L8SzQtd4jwwrrYb 4kldOEuXoUQSWFaL4Qwv3d1/15QLg7od8GQtiaX0LUp3NeEd0P/RQ54a8QyV03GlEzTW8vxZU+Pv Q2dhpkvaP2EDgNHUyA59fySWu0ncoP+99Xl2p7hd/4K1WTwunmO/0f7VrO4u8h67oPYYVQ7B4bCQ iM7pUkQsDqerGSsAqdX/10sX3ZCNDatMCrCaBhLGgg1KnAZKSrM6jLAeMtEKwIzR8mHcZdcpqk82 5nfMEd1xChaUAOZPgLEvl2X1f+35DRue/Qh7r0n/+ly6ho1/4edg3fYNox+/tm/3Bea89HeApnHp ZZx2DRyAGMVj86RhbAiGrkVJaE6s2wviDhuJin63Qct7LIKO13rcqiQtididyUpA2YGUJJ0jmPyb KFs2MIbONW231YU4Z5gNIxcMjLNChh3aMGJsfAcWS2Dt5ER4WTYVYEJwB38aDXqqhwB8G4LkrR2h qtcOVYYglzL2FMRuu+dV6cCczQuHZJU0Lfzwg4ZRew9N2HzviO3M3rV9oqXSX2GMz2y4Pd/bJ/45 5cVSaRjwYjWM0Y8WxXKL7DX2WvtOvIPb6eajotHGqDx+wcQzHqfKqhUAdFpTLGZnkjbicQSSfhN0 dgy1Y6Qun1qDCA4TF4xP7YMMuRmARV5V50gTsPNGKLcTeeZTta7t3Kjyc6Ry3+vVkbQ+zXN34Idv y8nY/Ur6U/N3Sz/GT+Alo3c0jt34YP1T75whPXsnV62/EibhmmFYjcG3xn079RV5DMZpQLfEwhEm rClkqllWK+qJVmFQqCMiFTeDUnSaMMXVCMxCM64EMVvSRcxko1DWQvfCFXfsUUKdInYd84CO2215 7g7O7tG79CsfA5VwsGALYd5gyJ7Z8U2U5uXt55hX2X6AbzJxRuzhIsUmboPx9+ZNlk2pfDQ5FCkI VAWqk6sjw5NHRCYlTw4vVC/ULNTOC85JnhOaE97u3dnNxADc5NLZDBNyWlw2t92Sbs6I6lRTxXCo IERCSRolm2ayv+X2mATWk7E5TZUpKLR6IqDMQKbTZ7faI7ae0bAQiTqztb6IvieKZDiysvddx8h0 R6WMkYr1UEqsdFInOxH5px44VZ2JkH9/nE7ClpAzHND6AkgRFgKY6QY+PJcKJY8R6lxmewD7dUkB FEjSasSIMoDDIYUSp7MBxKdA5jW4AzTiH+iI+FMwJWc3vclF9VnnCxXXQ/6yvhb+PeafMNTfi6GK nRM29Yjc/fCqXnM+PfjjHb3JLi7c8/eTplZGB84/Wj71ky++bxXwATxoZNaIEbdVJoN3kZTa575N r68dOaVHTvXAWFWqw+TJ7Fb5+MOnPnma/AK8ZGv/nii4kaAFh7yiyVAe0eJmXBYLsdZiG8NrlQYn DdBhPgVZtBYd42MIc83qcDgBPy/+TfycmQDQbfr4BdlIUtQsB+o74gzhfAqhd766e3fYkq3xmn29 I0tGPvooN1I6uy5eWWRSYbJWId43mRxbJ2OqhvavmS9Ab9mgh6Nj3ZvNx81EYRLNDpPDHOXnM+cA VCBOq0S8RsmBjrYLdju4vRnKFLXK6cQptLMfdBqY66J9Y7NOabGh077ctKIQLOQTeinfEMJFzqwH Xq8INe0iwbzJ674Zmk63OsWLh+SN2TnyCaK9evrJHqm3/n7IKvKxk8qnCgzMd2wmAswXyyjHxzBB k9EUMoWZzK9gV3I70E4iVqMaUsn25Zazq7hW9jgn9oneHaWr9GBSZNek35CFze0zm8BZ87PN+IED DDPdSDDhoBzz8oCm4EkcT8PhidUIgFhKGmhj9pDXMEWiS/fjPbwjse/yyy/jv16KkJGCADBKP/DC ACFxSOs3eGEsRFLkpY6ULksdnY0DaNvDoRvt/tYiByfo0wR5R/UsupBhkgPo+DPsxWnHpDuPSHPZ zGubmClXTwOFMIJhcNugpMb+2JJqdpcCph9XCX1UK5jV4jLl26SFeUs4Ib6lPKFSTRKmiROVU1Xz hIXiPOVC1TJhtUpJ7yXVzHy0gGNGRK1REDO2BJewD+OHWb7rcgUvL1coO5YrtogM26IkihYVwlvU Dg2ledeVm18NrXOpop5SSM0BbQQeKKRWq7jEBvIuaxcPxkw02i3wLEdvvL5+8WBMS9cvVGoYtvzV xHKQfnGLnet8X1gu0Jj19RoKaWfNmgWo1kVyXZSWKiDnufdOv/3Bp03SiUPnPzwkvQMkbWL6XzvI VF89zfS49iYQtIMPv4IiHE3wVVtHJNX718u/fCptxAu/lS5L0gW8kM2UVuCFXPxq/FP8mHQXCaGE P2OR+sj+K0VIb8fuWm1Zad9hZyjuLzLWGGuNk4X5zHxhjXkT2shtsmy0brTtRDut+hrUz1JtO2Fh K7i3OLKC2462Uxts45KjnN1is4JPZFGrdB5RSwGV1UWD68BTNot9j/phK+CqMwkJoOsXF+w3TURC bGGKchyZdrqUQW0XXUwzWizIap1utNnsHMZUOOwrgKeBtPQgwlHe6j1Lfgk7l2eIQGSlKr+uWFDY ExcCZRkm0Bp+YFz51oat4RRvZqo+J1PP9dRKc05iH2YzJ0uPSn9/WZrUxIvPafiAXXw8mR0IrHx/ x/uHTBPQiu7TuTNWXsjXoBGoFo/gQfLxZH4+pwBp5VOo1NK9ORzDYVIM3g8S+GJgD6XA9RScaqYv 3aCz7zqovHB9+2O8tFjOcMJ+de7PwfWFOJAfsGC6/zKP3BNvYnrGV5HV1xrw+2sZtG1dHKSrD5Uz HGObyVlAf/1iGtG30kvMBp5hVS7xEF6GdMiGl8W0SaqtOrdK7Ux2uQH8NeNx+wO3P5joybvQkXdR Zkv8TFwfl2P1sq/VYaKuBwypKUuEEWmUGeiaiyf5i/O/yA3kR/tMMs5xrFuf3jO5+mR4sPPWLLdn riGakzq2F2niRMsIs1J3961rvzOqXAN1+l7h24bO7ZuTRbF6G0KCEX0m+9UqVBoLcCzBrDKV4UUG ya/CKycofmYm4J/5CaxDveCZjp+puNx2+YaTNKDNlpOdFcjPtdC3I+iR2Xj62rJTp7hhpz6T/+SY jRuyBXIsyYV8aGyswPWNA92IKXmsGt5nUAbgmS5vit33b6Elf+CDwOTyX5nGj268W0QX4DoCTLJD /l/FmELQQQHM0L/FmoipCf7+PeLkO3my9epHstzSMcyBMdDR1MayCTJ49FaPBrv5YoeCR5zSK/8W BXY63CkK3sDrnD4ncV4THB7vb3U+fqPrnT2HjgeCBtBFcl/zbgxB4D2A7IPMnKam+PfQ23X32CMO 6Hx/hy7hLENX35h/N8NuI7ibo3jZ2o538xH6dszRP9yuK/0JGUT5/Oiph6Odx/ZDUolAd6kjkC/c +TOY4HGnSCkITIc062qt8sz1K51/t3GtaBspBpIUozZyDk0RPKgcr0ATyS60FlIF40ED2RdRf7i+ C86HwXEPvZ+9G8UgtXQcsyHlQSqHNABSv45yH7j3a5qgDS1tRz7ejbaKPvQVNxx5IW2EPoyE9DyU 97Bfoz18MRrf0a8TLEJBqN9Kv8Pvku/dCtcH0XvlYytqgvIY+F4AyrugnCc8hEJwTKUJ2mggxe2H 4JjJ/BHlQju070MgzYO2S+BYBKkGrrvh2APSUtxKU/t5uN4A5VXw3KW0HlKJ/L27USnQYhVcL4fv 2eC8AcoqeL6RHiFZIOXBWAnMVBuU3TQBvfPgMwGtwbfiefgNgsgC8iL5glxj3EyMeZk5w47h1NxI 7h/8Uv49oUG0iuVig/i2+KOip+KIcpMqWbVTXaTerP5Co9c0a37Qitq+2hbt33ULdO/p++ufMYwy fGvcZ/zSFDUtNw8xv2fJsoyyrLG8YVVavdaLtiG2M/aYQ+kY7pCcA533Ol9zpbr6u467k91bPVrP /Z7j3p3en31DfBf9G/yvBvoHtgauJGUlPZb0ncw1t6E7EIfuRCJIjx4+Q0HjXBR3IVa+SlFKgrd4 uIaGVIyoGNInrWbinfMmzpk6fqwsc/Jf+0Q08Td/0PQ2Wbew8AxRfg9HjTTgpeqgNQO0bUJmeT+M Tba0Tnn3JH0fwwd+bEDeyZ6MQiiMIiiKUlAqSkPd5Igy3TeVjXJQLtA9HxWgQlSEilF3eXWzJypD MdQLlaMKVImq5F8B7YP6yr/1OQANRLfIv0c6BEZ6KxqGhlNjherQSOjpKFSPxqLd9Ncom1GftGZU Bik/je7G7mUHntmOHoH0NCQGTcUPooWQVkH6PST2eukFSAfxg/tYMfYaXoicuG9MxfpuNTt8dqXK 90Ez5pue9H1i//oQdgAtvsKOfRqk6KXET+OngId8+HkUwougz1G8eX/Knb4xcOkFNBNSAyRGzjF+ YZ83x/cG7oZCLIbvhJGXxa/6/pKd7vsmu5ngfb6jkWYWDn/0wllM5zviedL3B89k3xuQdicu7Upp pt95wXOnb523GW/e53uMBt/2+R5NHOZ64Kuv+qanbPBNyJav99/QTHbv8xXD9eExla+gKODL91zw ZUaaRQzn6Z7+vtTsd33JHvk2PzQaihl8bs86X3e45PVURrpDOoR34S0oFW/ZF+rrew2KMNz9fVKK NjTje/bXRLNDzXhRrKAmuiGlJhJK6e8LpVRFIlAeflxYKtwm9BJyhDQhKoCDKrgEs2gU9aJWVItK UaQbKF7cV+bjD+HdwAQ+vHu/yIvgN7wMlewh/JJc+dIBkRVBgEVzc/uXTZTHzc14d5OelqDwKi+X +Gb80v5E1UsxH0tLrHxBT2ieeEUAESwSYK1G/FAzj5ZZ55XZy4w9DcVVFf9VNuamPO2//rNjT+OG fkNrG3d56hpzaKHdU3f9Ytr/9DdnLmQTy2Vnav+8mdMmyT8xGaycCGlM44PzptgbG8b5/Xunzez4 /czwmHHjp9Dj2ImNM4MTKxqnBSv8e+dN+o3Lk+jlecGKvWhS5a21eyfFJlbsmxebJ/+65v5x5bPr b3rWquvPml3+G42V08Zm02eNq/+Ny/X08jj6rHr6rHr6rHGxcfKz6Dgrpw4tv3sOcKe/cmo/f2N0 aGOfwSNrG/1j6yqa8Xb6W25z0f8Hwf3SjQplbmRzdHJlYW0KZW5kb2JqCjE4OSAwIG9iagoxNjQ4 NAplbmRvYmoKMTkwIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50IDc3MCAv Q2FwSGVpZ2h0IDcyNyAvRGVzY2VudCAtMjMwIC9GbGFncwozMiAvRm9udEJCb3ggWyAtMTk1IC00 NDQgMTQ0NiAxMjA3IF0gL0ZvbnROYW1lIC9SRFdEUkkrSGVsdmV0aWNhIC9JdGFsaWNBbmdsZQow IC9TdGVtViAwIC9NYXhXaWR0aCAxNTAwIC9YSGVpZ2h0IDUzMSAvRm9udEZpbGUyIDE4OCAwIFIg Pj4KZW5kb2JqCjE5MSAwIG9iagpbIDI3OCAyNzggMzU1IDcyMiA3MjIgODg5IDcyMiAxOTEgMzMz IDMzMyAzODkgNTg0IDI3OCAzMzMgMjc4IDI3OCA1NTYKNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYg NTU2IDU1NiA1NTYgMjc4IDI3OCA1ODQgNTg0IDU4NCA1NTYgMTAxNSA2NjcKNjY3IDcyMiA3MjIg NjY3IDYxMSA3NzggNzIyIDI3OCA1MDAgNjY3IDU1NiA4MzMgNzIyIDc3OCA2NjcgNzc4IDcyMgo2 NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgNzIyIDI3OCAyNzggMjc4IDQ2OSA1NTYgNzIyIDU1 NiA1NTYgNTAwCjU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgzMyA1NTYgNTU2 IDU1NiA1NTYgMzMzIDUwMCAyNzgKNTU2IDUwMCA3MjIgNTAwIDUwMCA1MDAgNzIyIDcyMiA3MjIg NTg0IDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMgo3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3 MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyCjcyMiA3MjIgNzIyIDcy MiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIKNzIy IDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIg NzIyIDcyMgo3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3 MjIgNzIyIDcyMiA3MjIgMTAwMAo3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3 MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyCjcyMiA3MjIgNzIyIDUwMCA1MDAgXQplbmRv YmoKNiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9S RFdEUkkrSGVsdmV0aWNhIC9Gb250RGVzY3JpcHRvcgoxOTAgMCBSIC9XaWR0aHMgMTkxIDAgUiAv Rmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAyMjMgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCj4+ CmVuZG9iagoxOTIgMCBvYmoKPDwgL0xlbmd0aCAxOTMgMCBSIC9MZW5ndGgxIDE1NjIwIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42r17C0CUVdrwec5533fmnes7wwzMMODMMILoaCCI ilKOCoqShdfAmsQEQ01FU7/KSpIlXLTSctTadrPLdu/3Bcqg2pVKye1qbVltrZllWRvfWtvFUl7+ 57wzoJXt3/d/3/8PnPOc+3nu5zkHhgAhxELqCSORBUvn18GX9FZseZmnBWtWBTZd2rqOENhBiDhy Yd3lS+3aoR5CpAOEmF+//IqrF37hVY8S4ryPEP9VtTXzq7/I/12QkLw0nD+yFhtse266GuuzsD6w dumqq54/7HoA61dh/b4rli+Yv/XWO88nJJ+Pn7V0/lV14njLHqzXYT2wbP7SmiGm7CFY34z1IXXL r1zFPhcDWH8G66vqVtbUiZEHyggZkUuI8U1sA8Lp4RRJpJOvQS5OtJztQ5FqQgQi4miD3mIkMuYm Yj5jlKW/ZP3RbBux/6iu/OI+DuIkScRF3CSZpBAP8ZJU4iNpJJ0MIH7EkZAgySAhMhBLmSSLDCLZ UhhHEXE/tp7lI0zlvYT0/l3PP9Xz9wjRVvceQ+mMwtLL5L/5MSaS8N9d6HEyB7E7v/dhLHeQKJYn 9977y8NhMvkKRoAFCsgbMJZ8A9nYlkX2o2g5zah9BKUPZvJSYkIH+Yw8QPb/eyTg/h/VxuOqHaSL LCff/WzoY4l0+nPDr6JzJ6lLlO6OAzaMOlkz2UPaSIwc+snoDtx5K9lCngKZfAmZNEw2wjOQRD4m r5O1ZCN9kt1IHtLH/fxzCH824OzT9Awm30E9GU/eJheS4aQNfFBDXgYb7vEPpPR98g+ynuyBtH6e nSFjXZ+I8Fhco/6ffdYir/eRBb9+AmQDA88v9aJlZGLOfkpHAia4zW2izz700tj+1ZehDozCPdIg GXXNCIycIF8g999Greggm8lvyFVcnvq4c3BcAHmqgACUfI9cPU7+TO7oGwXjccGwruVv9T4MmWi/ BGn9VR9xIed7nz0bCeLx+mk6xLcSdh638K/7Zmlf6mA3/vxADpN/kldBIbthE2K2jzyH+rYJpb4J MVxLLiP/AtAIew7pKseff4dLmjj+LHLbitRza1mOuByCV+Dsfm4r/vxEx6VyeOsnlkTIs2jHO7lN n/F59GzrsavI12Tqj9o+Rmxep0+SjWg368kyvW25sFPowF2G6D8kEpkxpbRo7JjC0aNGFozIzxue m3POsKHhIYOzB2VlDgxlBAP+AelpvlSvJyXZ7UpyOhS7zWoxm2SjQRIFRoEMBY/qmVhRslj1TqxS LaHikBJQLRccn5ajEqcvGHIE8nMqhyVGqWJYJUllqqu8ooVERleqUvinQy5QWabyVRAnT/MFSlQh E39DU+dXq9kzKoIh5aCvv78S56ipEyuCQZ9KM/F3Cnbh79T5gWpVKcf2oC/eMkUl5RU8tfceGY2N ZHSwEvMZFeqAvmpl5dmQRG/S2/kTNC+AZqXF4p1YrBJXC7EcUYmbDzs+mqikSM0OIyIKlvTVSI4K rq9USFLBPQ1R/vEWfNrh0WfhQUn14lBJ9SLkaHXVaZ4ej3M0GGgONM+ocORjUUe6TN0/vaLFbJoY mlhjwgaiN5AWkxlbzLwBl6hrAct5oBeopWRMCyVGK7LPydEt4WmxGtlYhYVQMfINe5JO97T3dm46 s4vgtL5SUrwUR0KVJqqGOBKBRWpkvko2BlqGdjZvalfIZVVhS3Woev4lFSqbjwNaCMssqZ2lppWV z8Um3ApTVW2Ai7tYz7jwAiW1gWas87FVmIeKudB/1F5dW1PF1QSqQsXYJ0+saAp2+lQnwhLVEVat OMx6zcc+1lziWRTg1ebmpoC6E9E9ozfIc1QCD6LeXBLC3XCxksUTuEhy+sWma+OUal04kY3zA2r9 ZYvjujd/U5/+B5sV1fJtEKWD8sGZ+sQEK6urFnOUF8/nZJYsDjRvrNFJ3aSThvoaKFlczBOfiNpP ZuPsuRUltaGS0xsi4VhgmT+dGwyq3jCf2NxcwlGcX43Yx1HGjtP4c5vwhQHxmahGZumAzNJlgDtG 5hdXJpoSA+byabynqriyMhiXOw5VDZlN4jmhQDNf0ZCpusJKcC/2dQ4bWjajoqTYp1Ov0okV53Z7 fN1YLivvbwYPjmnO6fbFeVQ2M1Q2Pa4FtX1Z1ay4AdN+yePQxHh91Vc8vlewPCk0qaq5eVIoMKm5 qnl+e2/9ZaGAEmpusVia60qqArrlA7Y/tdGnTtpUqSpVtTAGhcz1bdKMMjVp+sVcPJMCtfPjzmJc KDjaF3RU9o0p/6XuhJ2hxqPecztrVr5A3CzokXyBSdy9tKNX8KnKaG6miMnsCrSDBbrO6hnax0xc 3McthVVmliyamWAQamNCYbjfm55oxUWCQW5DG9sj5DKsqPXTK+L1ALnM10oiOWGUXRXv6ezrcc/m PfV9Pf3Tq0IoK0/ZzP+DTp+pz82OkDNQmKPzX3e31WrnLKTxxGjVODoh7qSJFcxHEyXqY7xkCqP7 KlJTwvpEzhP0ks1KKHAgpCphVZxY0ekrqgwoDnRv0K8MiRW5mioHQn8B7kSJS1GhSIVk3k7Qqeq+ naWMxs7+iYGS5qqEmp1JX+IkqK49O5E4Rgkhnb74eIczxEl9WfdtCZedOYkblS8YHzG1UrVxx6za vtAzJM43sSKAbgjNdrpeCJQEarnU1UBVse4PKn1nNrf3Hq4q5v4PUeZDfAn9xrzyp2wom9VfmlFx ne+aymHtZObQsnYi40kKcHNlO/Q2tpPi9A68kbF5l2L3rKGBQMmiYtwQK7OHYsOQIJbmDEXd5Kpf EarkJ8mU6uYA1+5qpEmH2FHTXJkT4MqJ/pKgHaqRSl9/saaycgyucxFfR9DXaa7EFRYnVlisr4AL 9OCgiqFl6KmyyivQ2dajQ48UcxKR3E60qk5OMSeksh9ThNct8iRwnos4Vw7BwsXxVVCW9bhEZXNz vBZCNW9u9jUjHYl6O5CfNkQSDe1EXwDNrh3qy/Wu+pAeH5SEgiHO+cpi3OoS5Hufl2on0X/P4UvP 5PA8xPZSncNV/0Mcnv9rOHzZr+LwgrNzuBpxXsA5XHN2Dqs069/w+EyWRuIsjZyFpQt/xNLL/z1L a89k6SJEr1Zn6eL/IZYu+TUsveJXsXTp2Vm6DHFeylm6/P+f0tadwWH9nYY/4Yj4QxgxEOT3zHA7 MeYg3zEZlXZCDmDidSyz97GMUEDIEIrvk6f0C9UcnCQoTxFKJL1MldzhQUfQkYkZ4IhTEVZ/ql4k J0lEqCdA9lG/MIe+g3u6IyaIRYggAq0eEyaenNRp3cNzkwqC7n1sC/V3dOgvT1HM/oB3QUbSIjbY RZx0F0Rwzq683DCkepRp3WQcTsvHLaN4qRyv7Ym/QS3sfU/4UOwmZpJE8iP+fBPkUygyQpEAlhjx KjFJsDUcl0F2OxuYSznYrRyK8qX4YlH8iBnEoZBggOeZAYcSxER/f0rbB0WAnINztee1U2DQerSe TDx1KiEKj2qztfu132tzOmg5Le9p6dlFAAJ477wd8ZDJRU9IijejlLX3HouYnZ5SA8SIU4iJGDdH Mv0ZpWLE7SkVJcFoAEEwNFbRzbSTMmQoVelhepyKNCe6orur6xXlFTLu7+Fw97iezuG54XCwIOgQ CzIdQTdep7O1d+h0yH5MKJ7auvWHzsd0Ht6GOKxBHLzkT5Ebb3RBWRK8lwSyCO+KsFCECQLkCeuF rwRWwGazo+wbJrhpJi2gbJI4R6TnJk9Lpsm5yd7SEgmekN6S6CIJCqVF0u0SE5PdyTcLoksQxKkC JAuiW0jZ5nVaYn4zmOWYTYg3NYChwRHxlHuox2dGpkCqcjDahenNbqU7JY+M6zkYRc6n5EG0SVDC TdftHZ4L0RXRFeEVUYLCWMF/V0TzC0aNHAekYEQww1AwMj9PcLskO0iGoPs25T+uuxrC2ol73z7y 1y8grfl/Vb8+iN78efJdS5eA8YVjy96d9cHTN7y5qfzBzZ/rDxXkRdSPzeJ/Ej9pj9ywyAsLPVDp gbK0i9NoqmGIYYyB5VpBco90U9liS7MNtTFLcnJW8shkxtLAkn5F+rXpm9IFO7Ml2ajC5Jgp4hpg iuXlkhiw2ACvM5brAIc95hKsDSlSQ53vuI/6grJ3uWmdiZocAciFKmAE6qAeGASQFSsOdkXz8rDQ /WZ3giE9B7vDRNdxZMe8S6OXIisujRIO+GdUQXJ+3sgCJRgqGBVwjAj1MUURBYdLCGa8+P4tjXdr My+eBreeuLfj+XeOAtM6YI32pqa9Zz40e8MKyET/avjLzBcnPnO/9sMVc7SuF45x27kcefMX5I2b BMktkepUC0x1z3XTSTAH6KTUOal0hAmukZtlOtUz10OnBuYG6GArGBjc7gLR5XZluhjxxuwUKLX5 Y0Y0tnHIjCRUhwsd8xzLHcyR3HhcBDHiTSsVQ2mkwZyhHOzZpxwMR7v3Rvu0wVmYs6I7jytC/EP0 HJBE4naRkG6ZwbwUd1Yog8IIzCW3izMEfrfx3S4QtDe/0L7QXoT5MG7boRd3tu6lUuPKpbFb1yxr YI4HtZMvfKa9Db+FS+EGeGTkO7O1wz0PbFd3rvndn+/W9eNrtJlj4n70H1siyxfK4JYz5RJ5tlwj i3bmZzmMeRhIwkhhksCmmCpN1CCnyINkdo0MT8l/k2kBW83oZxQKKMimq02/NTHiNIrbJCagbzUe NzKjlYi5YkQsF+tEUTRft46AQgLkOHq6nGi0uyuqoD4gLzrH9bFgRR8TgudBEqDZu43ghnz32rfh klMa+1r7u7b7gVMwBk4eP65t6Vl6kMtyPcryCNo+l+VDbQ8YAP3N4cgSq6O0Ek2YVqYCcyY5Jzpn Oq90NjilEs9sT42HTU2FiYGZgQUBttreaKdj7PB2OpgFnxAWmOSNGY0uG4ldiIbMYi6vHwWbJjVE HEAcxx3UEYpAOdduSG4k6AbQvz3uSS/lMtbly3W9Zx93tVzODhTzT6Ucjqu2s0AKZaC1k/y4rDOS dPkW6LI+8Kf7dr1002vPa9/CsM/BCaO0W7U//xYaV16xdcuaZevNB6dB6ORDYOv6FAZr12gPafVa mZB7R+s9a37fuRP5sgiFvEWYqp99wyIeYZdo56eLtEuU0NPiGWOUzzhjOpVOpe904EcNYFrEnS1/ xdPeYRk818+d8VpUUsW/kKGkgBxvEwbDYM7vTValdN4gMA/aOIiODcEYsVmkXnGwSKuHrBpChSxY O3DjQGpyj3HT2bYaGy0x1ZjoVCN4jYONi4xXG4VUYYjQLLCpTih0TnFWOlmBMz+w3Z4fs7vScran 1qWCK9WVGs60yQxsJGxjac70YwUFGcOPpaRk55BxiBnJsNVZ6i3Uwg8cu8laahllk7Kz66R6iUo5 0VemFOsCys+JOlAkXCz7uCkizY7CwpycqNK9T+lEf+3IzwcU02mR9ZlmOCq6pYRd8pyGMrIGoQiz ChSSn5fiSHHl52Ffn+WyrFDAgU2jhEMPNmurtCCVYB1qzh2vPj5v2eA7791yPww4OvUtuuxRbW+v 9pZ2ETTDmIa83KHaqZvmrdrfMgS+xcjgHjpSK9A2aJ9rz85d8dIrj4MFLnD29ESfg9shB67WhmpP aq3apcLkJG3pF3vivh8jC6FRt+2SSJZxixgBIm7x5spb8DzeAkyU15GIxIgpYKIyM1ktZAkNg0c5 iC74YFeqMq2nU1eFft+MGuEOJlIH+33PdvhBk+gOcf9L2oIubfQbfXtuwD1F1DYvw52AMdyGCAGh TmB2JhikxDZduE2qHtf0aRuuCiPo78T9J019a0nNuJYFSGTnUOP5RjrUfL6Z+hm4KYjUTUvobFQq upt+S1mynCVT2eQ10VrTfhNNFcCE2jRXYLLgFQYL7wqfCaIgG+X1THAxJpgoozeYTS6z2SQzu8mP LDBJGHUJEgMmGNfZJb9Ex0nzpFukPdI/JVGSTbkMCAPzBwzsDBRGiVkx15s3m3eaxUzGzb9txLhS DiNm2V5qvp5ErDqpOvfCYSQ3z/vmpdEV+JuX92Z0hacb/V5K/rjOvdiT1yTqAUGT53RcsFIPCFaS 6IoVyB4ZeLwJIXB0wA6ohuWwUPtY235C+wMy7J+C44fRQvSUJMgnt3LeJWPMuxx5ZyCDI8lo77CF MfEjA/3IgNIwymRdv81/onyScL+4fgGXLs3u+U+xsuc/hZ6XXjrJ4nHmjN5PUYALSDrJIndFSp5y vuikiwxXG35rYKIz00mZR7aU+rdH5HKZVmG4KVOHN+ZJjvkGkMwdNNkey7GNs1GbJeZQTOkT/B5/ k8vGWRUw20ptJANkltEgRrJdtdQu+hHzPaLgYYPEhcg/ZFwCVSztDSvdXcrRzr7TMy/vANou964Y NGKYiCdnNFM3xhEDg/kFiWgh4AVugSnYkQMFoYB+gtK/bn1o8+PIUPuFzz/W8pd9sGum3WO4tHT3 COsk7cOZ59auuUXdtHtf9SOXvXw+OtbUG4T7026564PHz52J/OhAfnwphYmNeMhtkdTOFLg9BbZK cJm8Ul4vM6uSrgxTooqgh8El6IWs1nTrMCvLcsOtwj1Cq8AyDcDsTr9znpNZRZvbbnXEzMkelrxN VKjLZmV2q6vBaG0kkVTjIuolNTSc4ILSrRzodORzu8nL01M8bJqne6iwHj1EuT1hCOF0oyPKGGRI iodQyI0OyF75TddHveRg+/pRo664Zun6dxuulsI95ce0Q5rWrT25YTn4r/qrCtMf4no0p/dT9hHK 3U0OR2SXc6CTfuwEJ/f1zf5Qqdc22PaQjb3r+sxFmwTYLjwg0FSpWXpYYpLHmVxqti+xr7WzsfYy +8Vo+45ZjmoHG+EoxgJb7YD7GUxlMMpwuaHJwO5zwkDnCOcs55tO4UbbNtv9NpZlG2mbYztoE8gO dxJqkWmH2brDqJiIgrrC/2auksNEkAlXJFuqv9ROwMJISrKuNnEPE447GWVv3MdjSoTc/EMSsTfP oysypR8FW/EwaxT7qP332vfaaxhvuG/ctXtp4z27bm28yTMcCsAEVsgNHxz78kOPHRiDOhFFnYgl dOK6yPQ5CjTa4eYkqHRDkxsqBDBTHw3TMiqYUrJRJQSzyzzQzDBiUpzUKhK3B5K3sWS72RGTFQsx e0ijzdUgRVJttdQrLTytAD0HOn8mfTKP0xqPHaNBHlLQAsXJzyN0Gjo5CqfmChT+kd63H70Jw4W3 l6D03/nNVa8dgwwNXFC6gZZ//xYLX/VGi7brobjdo/yFUSh/BTVge2SgwwrjrdOtr1s/tH5pFRsF iAl/5CIHXdyThYsEihp/PJLqTClF0V5jAst2uwP2OF7DgMlhc5Edim719qRSxYYSdcWMimJ3ovk7 G8wWB4rVfFp8/Ajap3Cr74yHUeHTho4yDKOy67KLCw7jpzynI+gM5o2CIGq6MOqvf0J9fg5C//zy UM9FA2Bs7OmemdD8RHvmeTAabL0YSx3AU7OrBO7k/xwAZDwhbK1UjDfptZFiiTu0JyQgbv3S4yk1 WWIGDMDsSLI91xQxlZuYKeDY6VAxzk/aiZcAYksSk9BeuWJuJkxmul7Kaf5Sl5s0cn/Lz4D+OKuL R4hdeA3gNZ04lGQUwvmOUEE+3nbiWpgO3CO/s307xBo2Xl99OyRrn7MtHRfCI1n7Cz6d23FqeVxO US0qxFBOqWQg2RCZOzutMY1WZkBTBlSYwOgx2UotA9MGDh14/sBLBooFjhLHbAcb6Z/kp2RHgMe3 O7xpPkNom+xOcwyI2RWnXXI6fI0utCiM6IMNlkgWuuZMy2kl3Iu0KD2deWdqInfJXDQkGndDSaO4 2zkX4srIg6NRQYdLMkjBDHD06eSznifvv+/WK77f+wnQgw/e4gfTuRVbtX/tgZeXrK77zWu3aI+8 PWvT77d1Q+YPYIBzNyw/9dTJQxfUsyKIXf3yo9qfT8c6W9H2FDK/gxh634mYUHzU7rRTZm/vPRAx u1JKKXMymnDJ6Vi3Mys6WyAmYmqUqYKic8q11HHa1fbwaDinUyeQyy48j4eD4YRvTXYj5AcMHsjZ W47e9rD2zrU3rddd6VN3nzpB9zz9Qs80LhvEDT4Uf+iLwcFO3MI2UTA0CgYmsEb9PG78eQw+LhGD F/C4SI/Bhaknd4vsu+8I7Z2mXQJf4ppW4iBzI6NMZpgqwA/oYiLe9FL9cm5JM9glt22bXXA02hyy zQ7zMGZAtQS5UYo4k6TTW3JHeXrbhJNEj0iiLH73dnCxhTL4o1XbDZfMmQLZr3xY/TkitbFr7JJ1 iNaLn7whPfDdd6dlcQRlYSE9kZY00yUm+oEANUKjQCsFWGvYaKAmOVWmY+S5Mp0tPiHuE4+KQqkI s6Ua6Qlpn3RUEsskKDUcM1DJAIMMUCeBaJAMG/gLjMEoiLLBaGgyyS6TSRYMZpOwnH3A6GBWyH7L 8GOhyE+nhBcdIhsVMSotlahVGiZRWRpnnGdcblxn3GV8zfiB0cCvqDSJGW0GwcTMjTxgq6F9ou/i rxTImGgXD9hG8/MWY7VO3QNFU/L74jUjD9jE6/YCqoZ+deU32PhjDpdePuRj4AYhriNJ0PStth3+ pu3QrkmSwqfQ+LQhPZtoZs97fXyDD5Fv+hsgcWO0iSgJ4hm6QfqUAleTwt+/1c9vQzLavo88GjEl y8CkJCTWzNW+Gq3gmPmEmY4VyoT3hH8Iwir5N/JWmfGM2tzEbXRsMzEPtwO7kbhsjVbm4z7MCrrp u4nLWjPW1eiOrHOD3T3OvcfNdrpBReTc2J2W7taRQzbxaDUe6fJatM98kF3cQeQf6M4fd6BT99vI HTyp9BDFzc0oRY/PEqbUb1Fp649fu9N5x99gmPbx+sbrtY8bGq4Xpr527Jplx7THT31Gdz/f2TOZ 7t77bM/kfvvXz6n/sv3b/y/s3/2L9s9xPNP8E2foPsTNjFH5JZExNiPYBPit9XYrBTegXdqSwGQF ZraA2QwEwCY6YpJiiZFkW4PsamARj7yIprAzAoC+O7rOagz84hfTqBg44zE3z9H3WERv1Hq112E4 SOhAh2uvaid6m9asbrrRC6OwwQQjtJe1E9pX2qsd0NR24MATbW/Ez5QObbXwJeLN45nmiOfHAW62 yV7KI1yqs3M8hjNmu89Ofym+9f0ovrUzO0Y2RtsvRbe/GNvyYyUpzv5EaOuFn4e2bz+2KRHYaqvF t17TI9svtPYNeFt9uC+0jesMW4P0WcmNT1ZZ6izHLUx/NAigblSZ68x0AbuS3cvamHCHAKIAR4Vv BFojgIAUt/kzSjmMZKOeEbdBNJp0XWI8Yud+pc642SiY7EbwMqPdpvuVeESqB6T8aj2up0vZN44/ bXPj4UdmQrFS+Nmoa9WV/0jzjRvZspwrlaSdSGlDZQdyJ8bkJxFvP97EhotWkNPBZMArF1Cv/pvi TMlIYbmeTg81pHhTNssGlywb5BSvQRhgA05hgcVRyt9vk5XYLfEnS0XvNosNPnej2RGxOEsdPjNR fPX8PZdHNJQEFP2xTtmr8EuY0u1MKex7wO0KO7DW1Hd1XUH0ADvxdFswIgfOgYIRnDIe0rhdfhgA bpcQyrjz/Tt3b6u+d9N/Hryxo3V1+4Y5z27Xel/tCr17ybXlRdkTdtTd+digA+etLBsRnLJtze+e RdrP7/2U/lPMxBjtwkieyUhiSY4YTbaJZjFmtFvtkmC2G4Uke2OV0ClQIij6u8NmYaegCocFo4DB I3JdD7+Urv7Qq1t5ZXgujyK9wGOvTHe+O6Q/2dB/Lj5XW7d2LWT/4x9/zCqQ/FBLJ3R0ZLzX0XP0 RRvXocfQtjcIU5FBt0Yuf9AKYQtYAmgaNwt/EOgCeiWlRfR8uok+Sp+hYpIQEp4XmMUC9oUiiNmy rbTUgpeIdKCQi0pnsaZZqYK2hWUrmPEuQNw2A2pPo6Kf2Qp6J+kMU+FadIZ3iureKRq/BRCs6teA LP30RmIQsKrNn9z2MGRft2k9ZHM/xYw9459+gbad3I20TCVEuhtpscDiti68w/NAPiM1vXSRDCZ+ gMPz2GMBUYQmEUwm2GCCizDube89ETmIGJcaKgy1BmYwYvlFXM6DkYgRXQc9KsFb7CijTDEHzFQw g0E2yhskg0uSDCZREpvi7zCCxWzZEH+dIZTRJiAuwDPQYpJkkb/MiAajCHbZ9LQEG6XfSY9IL0nv SeJJvHtEhuWWShGfv1SSjGYLKWNPM/oSew93ZGAIG5cY6RIjGI+IQti8xLzWzJaYwXyE+iAM1AUD YQRUw5sgzkLwOOwFYTPsBEphnA2iOfP0g9z7NX+z+Rgz/lq/Mj+fRwG63ebnEw9/xDkdEHjOAobn Eu6m8dALr9Cd2IrET3hFEII+/psPQTPAWrxoJr3zCZDXPntVe0r7eP9hYeqpXganTjLx5G76ZQ+e yqQYz7prUU5mcjBy3UIzLBJhG4U1MkgsmVFZ9spUIMgtZjRJeKCIVKYmg2SWBCwTmRlZE5VdlMqi WTJvIKKLEBEEk8GAQhYks2xkxM1EiVE7b+E9gpGIjEpGSmRzvXGnkRoVAnWICX/0crpLSQ6yIiea l8+typGfx51BDn5InDOOeO3HDFKa9iaSca+Rl4x7+59aecjk0wMnMxTD1RgzTf/iyHHtQVih7fr2 FB1EQ9p9cEnP0Z7XYYkW0325H88q/s5tIC9G7HYDrBTWC7fiMfScIKKb3tBqn8JBZJVlykUSyBLs wuiGwBSxUlwksskMJhkwxAT+nnW7gWHIKQMshDWwDXaD0B97CiJgwN5EAbmHjKEG4kswin8LIFeK SFXSTkmUwC/sEagQYBfSWyilOdH8VO/fo3mvRPP25sXVBfWo8Ocvfmd8CGpX1AcQlFEz/vS9tgjO AwUmftgzV1sNG4WpPRn00A/hePy3FvWhDGmXydLIpKslWGUAweAyjDDMQo9OffRitCYwSBhMN3GF pwYwxmS3xPAia6QBaTPirEqHEW+zYCC4CwUTXk3zuvRMfxvsOfBskxhWCObXKQlUSTS/QP/rDN5Q 19KFPbvZgz130JX76MsdHT0j9unfnID8/Julh++eZy/6Bnzx/7N+7sAt2X2Q32IMyXjjxki9/5sW CA3PaOX8KxLf76rvtc742XcwBkvYRO/l/3NM9sEPJCpOJgvFyRBAeBumFzFdjulrTOuxf5F0iIwX XiUdwgOkwzCRdIiNJFl4nMwQp2HbBDIHYVRQyRw2nYzHOVFxPOmgd2B6uHeaqMTLhudwHrbjnnx8 B7sX595I7mTnkfOx/THpUzJVeIoUCw8TP0KUCRmDPzPIMtJKvobrqYXeTL9i17OH0XZ3C++L14j3 SEOkP6CY/mB0GVcav5Ij8mK53TTLVGf6yhwx32mxWGotn1jPsW611dq+stfZn9E5MZgsxcP4QtR0 wFMnl6xA6TebX8dbg85x4kzwS0LXS+YWT79g0oXh81cvWFQ9f/LK+cuqa4ZNWH5FtR7fxf+rfTSp Puv/ZA/mX0LAHRz93z7h3zzh3zsJkWySgzuPQk9UQiaRyaSUTMHTo4ycT6aRCxC3cjIdKZ9JZpM5 5CJSQeaSi8klJNpOLg+3YxjH/wdjfAa5kCYhrvMwX45pHaZbMN2FSUT0nETBFMCUi0nFJFIn9iUT nw69vZ3wfmS1bC784HByStqbb2G29tpk39prva+/geU1/4HZ0jrMrliO2ZJlyb55y5YvW7eMkSWw ZNm6lamrVrvcaZcvxmzhIsxqal2+5bXram+pZaRGqQnUqDWHa8TOGqipbVyR6r0y+ZqJ3uDVmCjt oNto7Imxfq2XhtuBtiGItAPZbTIVHo8ZwuNtdCwdQ8YSPw1QP0oiTLOgB7kZ7u2k6a0OR+GfaDpN SzSktebkFnboBW9qomBXcEha/5zU1qQkvSe11WrDHi/28FWToadVCpvG58JBvDe8BW+gVMN4lsXh XxPw9QQ8kICvwAs6fDkBX0rAFxHifvCXBNyfgF3wQiseneNl4FZtxlYfn9F7APa2jixEvA5iwR9M FFwp8UKbbCu0PwM3ED8mCuHWbQx5Nbh1CweD2rYYOcsy22RTIcJQm9miw1ast4OvNRb0t0OwdYsf gScOhN3I2l/gOA9qx37iTCpcf5sxvCEmhLfcBmFyM9wcM4W3xFj4thgN74jl+e/aDge2Hd52fBvb FoNwJOb1FUZiyOx2uqz1BjHcTq9o3SOGOacva8Ol65+mpQSw5mvLGoT4IUxO1mGrxaoLxN0ayEgU UjyFHeht3a0MUaMprckevcPVKluwwwWnWnWcT7Uhmhy2oup2wCHY3jogiPVDrS5v4XgTPAd7dGk8 m4CdsAcnkvFD4O9EwYSBOOa5eqke/oxyfxra9ZFPJWBHAj6ZgLsT8IkEbI3D3sPQ3mqxIQ5t0IJb mJ+GFiT2AKh9UlX7pKr2SVVtRan+CRpgPfoFP1rger7CM1ALi0geSjqldZ2E8hnS2shBdusGAUFW 6284GNh2A9LxFGQgyhltOACJ9rZ6B3AuYcHjSRRsDtQAf0RpCPp7TiEvTyJjT9YzLuO2E253oQ4x AOMyt5ywWgu//YaFv6k36gP+lZevD/jXwIH6APO/klMLc1siLeUtTJ/Q4vAURj4ellOofMyvQm2t qQP0gSNbFUehuksM72rEk+6j8o82f8Q2NaKSHvF6CwNHxh2568iuI3uOHD4iXbcOW6+32wuvT+xZ P2asvmd9Yu/6IUPj0DcgDkNxXFz1Lk9hfSMNb24UwjfgKusa9QUivqYJ5YVNjaZwA9+wMTOzMNLo 92OGxjD+ajy9BSpiVP4dnIDvEX4N38C3xILehft8P3xHxmEqx4ShCHxDHcSKIZ9AzQglOEGNCO2k iMqYJEyMFOHYIvga010Y696Na94GWyGGcDNsgVsRPoLwMWKFP2L/Awjvwf77ED6Cc/6I6R4+F9Nt mDZjGg1j8cD2w1gognNxfg7kwnCEQ2EYnINwMsIpOH889k9EeB7281emyTh3PKbzMI3FlINpaOS2 It8ot2ek213gdo5w2/Pdljy3PNwt5bpZjpuc484aZMseZB8Stg0N2zNCtoEh+wC/LeC32xWHRTaZ LZLBaGGCaCFALYQ5/X52IdvDepngt4+zl9uZD9KtHkOq1a2kWJ2Cyzq0aEhRdlFW0cCijKJA0YAi X5GnyF3kLLIXyUVSESsiReX5oDrLSNmsCWoSIJw5Qc0Pl7WzwAw1L1ymyuUXx/+JE1tVugE90yxV 2NBOETgnzr24AjWddzf6OlD5iVpW1XhTZQslE1TYoIZmVnAQmV6hBja0K2RWRQuFCZWVleqosvIK PqoynK5W8//erk+vVPN4YXN6JSlTx0xXfaEJ4bN9rrzyzFpLdlaJOqRkvjq0pKo4/F/66AvB2Tr0 Xz1bdZa+s1WuvPKsI0k/vqvOus1Pqbny56NgYoWvkqdwWPWoERQPLpaYdcbkdnibf5+kHd6Jg3fj 4G9x8F4cvM9BHNsWmQv3vBkTylTjDEzlF6upIazsx8pIrFhCE/43KXA8zwplbmRzdHJlYW0KZW5k b2JqCjE5MyAwIG9iagoxMDEwNgplbmRvYmoKMTk0IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3Jp cHRvciAvQXNjZW50IDk2NyAvQ2FwSGVpZ2h0IDczMiAvRGVzY2VudCAtMjExIC9GbGFncwozMiAv Rm9udEJCb3ggWyAtNzkwIC01MTYgMTY2NiAxMTY5IF0gL0ZvbnROYW1lIC9aRFFORk8rTHVjaWRh R3JhbmRlLUJvbGQKL0l0YWxpY0FuZ2xlIDAgL1N0ZW1WIDAgL01heFdpZHRoIDE3NTAgL1hIZWln aHQgNTQyIC9Gb250RmlsZTIgMTkyIDAgUgo+PgplbmRvYmoKMTk1IDAgb2JqClsgMzMwIDc1MCA3 NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDYzOSAyNDcgNzUwIDY2 MAo2NjAgNjYwIDY2MCA3NTAgNzUwIDY2MCA2NjAgNzUwIDY2MCAyNDcgNzUwIDc1MCA3NTAgNzUw IDc1MCA4NTggNzUwCjc1MCA3NTAgNzUwIDYwMSA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA1ODIg OTA4IDc1MCA3NTAgNzUwIDc1MCA3NTAKNzUwIDY5MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3 NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA1ODggNjYzIDUzMgo2NjMgNTg2IDQxNSA2NjAgNjU3IDMy NSAzMzMgNjMzIDMyNSA5NzAgNjU3IDYzOSA2NjMgNzUwIDQ1NSA1NjUgNDA1CjY1NyA3NTAgODYz IDU5MSA1ODMgNTkxIF0KZW5kb2JqCjcgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1Ry dWVUeXBlIC9CYXNlRm9udCAvWkRRTkZPK0x1Y2lkYUdyYW5kZS1Cb2xkCi9Gb250RGVzY3JpcHRv ciAxOTQgMCBSIC9XaWR0aHMgMTk1IDAgUiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMjIKL0Vu Y29kaW5nIC9NYWNSb21hbkVuY29kaW5nID4+CmVuZG9iagoxOTYgMCBvYmoKPDwgL0F1dGhvciAo TWFyc2hhbGwgRXViYW5rcykgL0NyZWF0b3IgKGlDaGF0KSAvQ3JlYXRpb25EYXRlIChEOjIwMDcw NzI4MDIxNDAwLTA0JzAwJykKL01vZERhdGUgKEQ6MjAwNzA3MjgwMjE0MDAtMDQnMDAnKSAvUHJv ZHVjZXIgKE1hYyBPUyBYIDEwLjQuMTAgUXVhcnR6IFBERkNvbnRleHQpCi9UaXRsZSAoVW50aXRs ZWQpID4+CmVuZG9iagp4cmVmCjAgMTk3CjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMjU1NSAw MDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDI2NjAgMDAwMDAgbiAKMDAwMDAwMjUz NSAwMDAwMCBuIAowMDAwMDA1NzA4IDAwMDAwIG4gCjAwMDAxNDc5MTggMDAwMDAgbiAKMDAwMDE1 ODkzOCAwMDAwMCBuIAowMDAwMTIyMzA4IDAwMDAwIG4gCjAwMDAwMDI4NjEgMDAwMDAgbiAKMDAw MDAwMzYzMiAwMDAwMCBuIAowMDAwMTA1NzIzIDAwMDAwIG4gCjAwMDAwMDQwMzMgMDAwMDAgbiAK MDAwMDAwNDkxNiAwMDAwMCBuIAowMDAwMDAzNjUyIDAwMDAwIG4gCjAwMDAwMDQwMTMgMDAwMDAg biAKMDAwMDAwNDA4NyAwMDAwMCBuIAowMDAwMDA0ODk2IDAwMDAwIG4gCjAwMDAwMDQ5NTMgMDAw MDAgbiAKMDAwMDAwNTY4OCAwMDAwMCBuIAowMDAwMDA4MzIyIDAwMDAwIG4gCjAwMDAwMDU3NDQg MDAwMDAgbiAKMDAwMDAwODQzMCAwMDAwMCBuIAowMDAwMDA4MzAxIDAwMDAwIG4gCjAwMDAxMzAx MTAgMDAwMDAgbiAKMDAwMDAxMTA2OSAwMDAwMCBuIAowMDAwMDA4NjU3IDAwMDAwIG4gCjAwMDAw MTExNzcgMDAwMDAgbiAKMDAwMDAxMTA0OCAwMDAwMCBuIAowMDAwMDEzODg1IDAwMDAwIG4gCjAw MDAwMTEzNzkgMDAwMDAgbiAKMDAwMDAxMzk5MyAwMDAwMCBuIAowMDAwMDEzODY0IDAwMDAwIG4g CjAwMDAwMTY2NjUgMDAwMDAgbiAKMDAwMDAxNDE0NSAwMDAwMCBuIAowMDAwMDE2NzczIDAwMDAw IG4gCjAwMDAwMTY2NDQgMDAwMDAgbiAKMDAwMDAxOTczNCAwMDAwMCBuIAowMDAwMDE2OTc1IDAw MDAwIG4gCjAwMDAwMTk4NDIgMDAwMDAgbiAKMDAwMDAxOTcxMyAwMDAwMCBuIAowMDAwMDIyNzU5 IDAwMDAwIG4gCjAwMDAwMTk5OTQgMDAwMDAgbiAKMDAwMDAyMjg2NyAwMDAwMCBuIAowMDAwMDIy NzM4IDAwMDAwIG4gCjAwMDAxMDU4MzQgMDAwMDAgbiAKMDAwMDAyNTU3MSAwMDAwMCBuIAowMDAw MDIzMDY5IDAwMDAwIG4gCjAwMDAwMjU2NzkgMDAwMDAgbiAKMDAwMDAyNTU1MCAwMDAwMCBuIAow MDAwMDI4NDkxIDAwMDAwIG4gCjAwMDAwMjU4MTkgMDAwMDAgbiAKMDAwMDAyODU5OSAwMDAwMCBu IAowMDAwMDI4NDcwIDAwMDAwIG4gCjAwMDAwMjg3NTEgMDAwMDAgbiAKMDAwMDAzMTM4MSAwMDAw MCBuIAowMDAwMDI4ODA0IDAwMDAwIG4gCjAwMDAwMzE0ODkgMDAwMDAgbiAKMDAwMDAzMTM2MCAw MDAwMCBuIAowMDAwMDM0Mzk5IDAwMDAwIG4gCjAwMDAwMzE2MjkgMDAwMDAgbiAKMDAwMDAzNDUw NyAwMDAwMCBuIAowMDAwMDM0Mzc4IDAwMDAwIG4gCjAwMDAwMzcwMjMgMDAwMDAgbiAKMDAwMDAz NDY5NyAwMDAwMCBuIAowMDAwMDM3MTMxIDAwMDAwIG4gCjAwMDAwMzcwMDIgMDAwMDAgbiAKMDAw MDAzOTc3NCAwMDAwMCBuIAowMDAwMDM3MzMzIDAwMDAwIG4gCjAwMDAwMzk4ODIgMDAwMDAgbiAK MDAwMDAzOTc1MyAwMDAwMCBuIAowMDAwMTA1OTQ2IDAwMDAwIG4gCjAwMDAwNDI1NzggMDAwMDAg biAKMDAwMDA0MDA4NCAwMDAwMCBuIAowMDAwMDQyNjg2IDAwMDAwIG4gCjAwMDAwNDI1NTcgMDAw MDAgbiAKMDAwMDA0NTUzNiAwMDAwMCBuIAowMDAwMDQyODg4IDAwMDAwIG4gCjAwMDAwNDU2NDQg MDAwMDAgbiAKMDAwMDA0NTUxNSAwMDAwMCBuIAowMDAwMDQ4MTA5IDAwMDAwIG4gCjAwMDAwNDU4 NDYgMDAwMDAgbiAKMDAwMDA0ODIxNyAwMDAwMCBuIAowMDAwMDQ4MDg4IDAwMDAwIG4gCjAwMDAw NTA5OTggMDAwMDAgbiAKMDAwMDA0ODQxOSAwMDAwMCBuIAowMDAwMDUxMTA2IDAwMDAwIG4gCjAw MDAwNTA5NzcgMDAwMDAgbiAKMDAwMDA1MzkzOCAwMDAwMCBuIAowMDAwMDUxMzA4IDAwMDAwIG4g CjAwMDAwNTQwNDYgMDAwMDAgbiAKMDAwMDA1MzkxNyAwMDAwMCBuIAowMDAwMDU2NzI4IDAwMDAw IG4gCjAwMDAwNTQxOTggMDAwMDAgbiAKMDAwMDA1NjgzNiAwMDAwMCBuIAowMDAwMDU2NzA3IDAw MDAwIG4gCjAwMDAxMDYwNTggMDAwMDAgbiAKMDAwMDA1ODk0OCAwMDAwMCBuIAowMDAwMDU2OTg4 IDAwMDAwIG4gCjAwMDAwNTkwNTYgMDAwMDAgbiAKMDAwMDA1ODkyNiAwMDAwMCBuIAowMDAwMDYx Nzc2IDAwMDAwIG4gCjAwMDAwNTkyMDggMDAwMDAgbiAKMDAwMDA2MTg4NyAwMDAwMCBuIAowMDAw MDYxNzU0IDAwMDAwIG4gCjAwMDAwNjQ1ODIgMDAwMDAgbiAKMDAwMDA2MjA0MCAwMDAwMCBuIAow MDAwMDY0NjkzIDAwMDAwIG4gCjAwMDAwNjQ1NjAgMDAwMDAgbiAKMDAwMDA2NzI4OSAwMDAwMCBu IAowMDAwMDY0ODU4IDAwMDAwIG4gCjAwMDAwNjc0MDAgMDAwMDAgbiAKMDAwMDA2NzI2NyAwMDAw MCBuIAowMDAwMDcwMjQ0IDAwMDAwIG4gCjAwMDAwNjc2MDMgMDAwMDAgbiAKMDAwMDA3MDM1NSAw MDAwMCBuIAowMDAwMDcwMjIyIDAwMDAwIG4gCjAwMDAwNzI2MTYgMDAwMDAgbiAKMDAwMDA3MDQ5 NiAwMDAwMCBuIAowMDAwMDcyNzI4IDAwMDAwIG4gCjAwMDAwNzI1OTQgMDAwMDAgbiAKMDAwMDEw NjE3NCAwMDAwMCBuIAowMDAwMDc1NDIwIDAwMDAwIG4gCjAwMDAwNzI4NjkgMDAwMDAgbiAKMDAw MDA3NTUzMiAwMDAwMCBuIAowMDAwMDc1Mzk4IDAwMDAwIG4gCjAwMDAwNzgwNzYgMDAwMDAgbiAK MDAwMDA3NTY3MyAwMDAwMCBuIAowMDAwMDc4MTg4IDAwMDAwIG4gCjAwMDAwNzgwNTQgMDAwMDAg biAKMDAwMDA4MDc4MSAwMDAwMCBuIAowMDAwMDc4MzI5IDAwMDAwIG4gCjAwMDAwODA4OTMgMDAw MDAgbiAKMDAwMDA4MDc1OSAwMDAwMCBuIAowMDAwMDgzNDUxIDAwMDAwIG4gCjAwMDAwODEwMzQg MDAwMDAgbiAKMDAwMDA4MzU2MyAwMDAwMCBuIAowMDAwMDgzNDI5IDAwMDAwIG4gCjAwMDAwODYz NTIgMDAwMDAgbiAKMDAwMDA4MzcwNCAwMDAwMCBuIAowMDAwMDg2NDY0IDAwMDAwIG4gCjAwMDAw ODYzMzAgMDAwMDAgbiAKMDAwMDA4ODgzNCAwMDAwMCBuIAowMDAwMDg2NjA1IDAwMDAwIG4gCjAw MDAwODg5NDYgMDAwMDAgbiAKMDAwMDA4ODgxMiAwMDAwMCBuIAowMDAwMTA2MjkzIDAwMDAwIG4g CjAwMDAwOTE2NDQgMDAwMDAgbiAKMDAwMDA4OTA4NyAwMDAwMCBuIAowMDAwMDkxNzU2IDAwMDAw IG4gCjAwMDAwOTE2MjIgMDAwMDAgbiAKMDAwMDA5MTk2MCAwMDAwMCBuIAowMDAwMDkyNzUzIDAw MDAwIG4gCjAwMDAwOTI3NzQgMDAwMDAgbiAKMDAwMDA5MzEzNyAwMDAwMCBuIAowMDAwMDk1NTU1 IDAwMDAwIG4gCjAwMDAwOTMxNTggMDAwMDAgbiAKMDAwMDA5NTY2NyAwMDAwMCBuIAowMDAwMDk1 NTMzIDAwMDAwIG4gCjAwMDAwOTg0NzUgMDAwMDAgbiAKMDAwMDA5NTgwOCAwMDAwMCBuIAowMDAw MDk4NTg3IDAwMDAwIG4gCjAwMDAwOTg0NTMgMDAwMDAgbiAKMDAwMDEwMTM2NyAwMDAwMCBuIAow MDAwMDk4NzI4IDAwMDAwIG4gCjAwMDAxMDE0NzkgMDAwMDAgbiAKMDAwMDEwMTM0NSAwMDAwMCBu IAowMDAwMTA0MjU0IDAwMDAwIG4gCjAwMDAxMDE2MjAgMDAwMDAgbiAKMDAwMDEwNDM2NiAwMDAw MCBuIAowMDAwMTA0MjMyIDAwMDAwIG4gCjAwMDAxMDU0NzAgMDAwMDAgbiAKMDAwMDEwNDUwNyAw MDAwMCBuIAowMDAwMTA1NTgyIDAwMDAwIG4gCjAwMDAxMDU0NDkgMDAwMDAgbiAKMDAwMDEwNjQx MiAwMDAwMCBuIAowMDAwMTA2NDkxIDAwMDAwIG4gCjAwMDAxMDY2MDcgMDAwMDAgbiAKMDAwMDEw NjY4NiAwMDAwMCBuIAowMDAwMTA2NzgyIDAwMDAwIG4gCjAwMDAxMDY4NDkgMDAwMDAgbiAKMDAw MDEyMTY2NyAwMDAwMCBuIAowMDAwMTIxNjkwIDAwMDAwIG4gCjAwMDAxMjE5MjMgMDAwMDAgbiAK MDAwMDEyMjQ4OCAwMDAwMCBuIAowMDAwMTI5NDU4IDAwMDAwIG4gCjAwMDAxMjk0ODAgMDAwMDAg biAKMDAwMDEyOTcyOSAwMDAwMCBuIAowMDAwMTMwMjk4IDAwMDAwIG4gCjAwMDAxNDY4NzUgMDAw MDAgbiAKMDAwMDE0Njg5OCAwMDAwMCBuIAowMDAwMTQ3MTI3IDAwMDAwIG4gCjAwMDAxNDgwOTQg MDAwMDAgbiAKMDAwMDE1ODI5MyAwMDAwMCBuIAowMDAwMTU4MzE2IDAwMDAwIG4gCjAwMDAxNTg1 NTMgMDAwMDAgbiAKMDAwMDE1OTEyMiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDE5NyAvUm9v dCAxNzkgMCBSIC9JbmZvIDE5NiAwIFIgL0lEIFsgPGE0YmMzYTRiNTllZWNkNzdjNmU0NjZhZWE1 MGU2MTRjPgo8YTRiYzNhNGI1OWVlY2Q3N2M2ZTQ2NmFlYTUwZTYxNGM+IF0gPj4Kc3RhcnR4cmVm CjE1OTMyOQolJUVPRgo= --Apple-Mail-7--1009703681 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --Apple-Mail-7--1009703681-- From ram-bounces@iab.org Sat Jul 28 09:43:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEmYt-0000n1-D3; Sat, 28 Jul 2007 09:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEmYs-0000mw-OA for ram@iab.org; Sat, 28 Jul 2007 09:42:26 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEmYm-0007sl-5L for ram@iab.org; Sat, 28 Jul 2007 09:42:26 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id A15D659DEB; Sat, 28 Jul 2007 23:42:15 +1000 (EST) Message-ID: <46AB47AB.9060304@firstpr.com.au> Date: Sat, 28 Jul 2007 23:42:03 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] First cut at routing & addressing problem statement References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> In-Reply-To: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Thomas, I think the Problem Statement is well written. The only typo I found is that the final sentence in the definition of RIB should be deleted. I suggest this be added to Section 6: 6. Ensures continued reachability from hosts in non-upgraded networks to those hosts which directly use the new architecture - such as by having an addresses which uses a tunnel-based mapping system to enable portability, multihoming and traffic engineering without further burdening the BGP routing system. I have one big suggestion and a few smaller ones. The Statement mentions the looming shortage of IPv4 address space, but doesn't consider it to be part of the Problem to be solved. I think this is the biggest technical problem facing the Net itself - not counting regulatory problems, botnets, spam and general security problems with the computers and how they are used. The Statement recognises that a future solution to the Problem as currently defined could have great benefits for Mobile IP. I think it would be good to also recognise that a future solution to the Problem as currently defined (Section 6) might be able to help with the IPv4 address shortage, by enabling a much finer allocation system to end-users, giving them as few addresses as they actually need, rather than with the current minimum assignment size of 256 IPv4 addresses. Another approach would be to define the IPv4 address shortage as part of the current Problem. I think this is the best idea, for two reasons: 1 - The reason for the shortage is the poor utilisation of IPv4 address space - which is a direct result of the limitations of the BGP system in not being able to globally route millions or hundreds of millions of prefixes. Currently, it can only handle a limited number of divisions, each of 256 IPv4 addresses or more - and ideally these chunks should be advertised in a manner which aids route aggregation. 2 - I think the "IP-level" solutions - LISP, eFIT-APT and Ivip - to the other parts of the routing and addressing Problem as currently defined will also enable a substantial solution of the IPv4 address shortage by enabling space to be more finely divided between many more end-users. We are running out of space with 3.7 billion addresses available, but less than 10% of those addresses are used, as far as I can tell. (I could only find just over 100 million with ping, which I know has its limits.) The Statement's current wording could be interpreted as indicating that IPv4 address space is being efficiently used: In IPv4 there has been a heavy emphasis on conserving address space and obtaining efficient utilization. but this is just relative to IPv6, not to the ideal of approaching 100% utilisation. Even allowing for a wide margin of underestimating actual utilisation with ping, my survey: http://www.firstpr.com.au/ip/host-density-per-prefix/ shows that some prefixes have quite high rates of utilisation, such as more than 30% while most have much lower levels. 30% is pretty low, I think - but if this could be achieved in general for the whole 3.7 billion IPv4 addresses, this would provide for probably 4 to 10 times the number of active IP addresses than there are today. This doesn't mean IPv4 can go forever, but it would be a great improvement on continuing to use the clunky tool of BGP to distributed finite address space to a growing number of end-users. There are two broad areas of solution to the Problem as currently defined, not counting general improvements in routers themselves. The first area is improvements to the BGP routing system, in terms of the details of the protocol, how BGP is implemented in routers, how the routers are configured and run etc. The second area is an IP-address based system which has nothing directly to do with BGP, other than either not advertising prefixes which otherwise would be advertised. In this second area, four current proposals exist which aim to work with both IPv4 and IPv6 by altering the behavior of routers - and so which not require any changes to hosts, host operating systems or applications. (However, they all involve tunneling, so I think there is going to have to be some effect on hosts, hopefully won't require user configuration changes, in the form of a marginally reduced MTU.) LISP-NERD LISP-CONS eFIT-APT Ivip (my proposal) I think the proponents of the first three proposals have the primary goal of providing multihoming, portability and TE for end-user networks. In addition to these goals, my understanding of these proposals has always been that they can lead to much better utilisation of IPv4 address space than is possible with the current BGP arrangements. The fact that the proponents don't state this and may not even support or believe this doesn't alter my view that this increase in utilisation efficiency may be the most important and immediate benefit these proposals can offer - perhaps more important than saving existing DFZ routers from early obsolescence in the rising tide of the global routing table. BGP slices and dices IPv4 space with 256 address granularity, with clunky temporal resolution (minutes?) and with unacceptably high cost burdens on all BPG users, for every new advertised prefix and every change to how and where the prefix is advertised or not. The main problem is that the cost of each extra slice falls on every DFZ router, and that beyond a few hundred thousand slices, the system becomes expensive and has stability problems and slower convergence times. All these new proposals enable the division of IPv4 address space into prefixes of any length, including to /32 single IP addresses. (Ivip is more flexible, because it isn't stuck on prefix boundaries - it can group one or any number of contiguous IP addresses together in terms of them all being mapped to the one ETR address.) The temporal resolution of these systems varies widely, but even if they were all really slow, the fact that any of these systems can be used to make single IP addresses, or 2 or 4 or 8 ... 64 addresses etc. be portable to any ISP in the world which has an ETR, and to be used for multihoming, is a tremendous step forward compared to BGP. I think that any of these schemes, once successfully introduced, would enable end users - including some who would otherwise get an ASN and PI space and many who wouldn't - to run their networks with just as many IP addresses as they need. I think that in many cases, end-users would be happy with significantly less than 256 addresses. So with any of these proposed systems, many more end-users would be able to have their own portable, multihomable networks in a given range of IPv4 address than would be possible with BPG now. Exactly which space gets sliced up finely like this is an important administrative and business question, which I think will find natural and generally agreeable solutions when one of these proposed systems is widely implemented. I suggest something like this be added to Section 6: 7. Provide for more efficient utilisation of IPv4 address space, such as by enabling end-users to connect their networks with portability, multihoming and traffic engineering capabilities without burdening the BGP system and in a way which uses only the number of IP addresses each network actually needs. Regarding Mobile IP, I think it is good that the Statement recognises that the solution for the main routing and addressing problem could provide tremendous benefits for Mobile IP. I understand that current Mobile IP systems are not a burden on the BGP routing system or on the addressing system. However, I think that the potential benefits of Mobile IP, including for IPv4 (which as far as I know is not really attempted much at present) are so important that the mobility support of potential solutions should be an important factor if is necessary to decide between two otherwise roughly equivalent proposals. Ivip is intended to go a step further than the others by providing very fine temporally resolution to mapping - a few seconds, ideally - with the user setting up their own systems to control mapping to achieve multihoming service restoration, mobility etc. without these being built into Ivip itself. I think it would be good to state some approximate, but reasonably concrete figures for BGP router numbers in the Statement. Is it possible to get reliable figures for the number of BGP routers, and how many of them are multihomed border routers or transit routers? I asked about this on the RAM list a few months ago, and got no solid figures. Recently I found this: http://iplane.cs.washington.edu/data.html Lists of alias clusters: Each line in this file contains a space-separated list of interfaces that correspond to a single router. 58,834 lines (62,699 on 2007-07-12 for reasons unknown.) Can anyone confirm that this is a good estimate of the number of BGP routers? Perhaps there is a way of analysing this data, probably with other data from the iPlane site, to determine which are single-homed and which are in the DFZ. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jul 29 07:25:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF6tZ-0002Ku-17; Sun, 29 Jul 2007 07:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF6tX-0002Kp-Mu for ram@iab.org; Sun, 29 Jul 2007 07:25:07 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IF6tQ-0006UF-OL for ram@iab.org; Sun, 29 Jul 2007 07:25:07 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 3F3C559DDD; Sun, 29 Jul 2007 21:24:56 +1000 (EST) Message-ID: <46AC78FC.4050701@firstpr.com.au> Date: Sun, 29 Jul 2007 21:24:44 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] First cut at routing & addressing problem statement References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> <46AB47AB.9060304@firstpr.com.au> In-Reply-To: <46AB47AB.9060304@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here is a rewrite of the Problem Statement, focusing on "end-users" rather than "sites" and extending the goals in a number of ways which I think are achievable and highly desirable. I think the current version of the Statement is compatible with these two statements being true - but I think they are not true: 1 - That a new architecture could make renumbering robust and sufficiently painless and free of costs and risks that all end-users would, or should, be happy to get new addresses whenever they choose a new provider. 2 - That a new architecture cannot, or should not, enable a much finer method of allocating IPv4 address space, to accommodate more end-users with multihoming, portability etc. - and that this cannot or should not be used to enable a much greater number of end-users of all types, (including those who don't need portability/MH/TE) to use IPv4. I am also keen to see the new architecture either directly support Mobile IP, or at least be compatible with future extensions which do so. I mean an expansive view of Mobile IPv4 and IPv6, with correspondent hosts not requiring new software, and with close to optimal path lengths. For instance, the new architecture's ITR system could be used to create generally optimal paths to ETRs which are close to the mobile node. This would enable correspondent hosts without any special mobile IP software to communicate efficiently with mobile nodes, including small devices (cell-phones and laptops) as well as nodes which connect mobile networks - for instance in passenger jets and trains. I think the term "site" tends to imply a physical installation, largish network, etc. These are the only types of end-users who have the resources to gain ASNs, PI space etc. today. However I think the new approach to routing and addressing can and should provide multihoming, portability and TE (for those with multihomed links) for a much larger number of end-users, including those who lack the resources to get an ASN, PI space etc. In principle, I think the goals should be extended to apply to single hosts which are physically mobile, such as cell-phones, laptops etc. I think the term "site" does not adequately capture that sort of end-user or the device, node, network etc. whose address space must support multihoming, portability and ideally mobility. I am wary of the current state of point 4: 4. Allows end sites to switch providers while minimizing configuration changes to internal end site devices. End-users today need "portable" address space, because there is currently no mechanism for reliably and painlessly renumbering every aspect of their network. The current wording of point 4 only makes sense if a new routing and addressing architecture might be able to automate address settings so that end-users with all sizes of networks - including really large ones - could reliably, quickly and with little cost adopt a new address range when they change to another provider. I think this is an unrealistic hope and will remain so within the foreseeable future - most likely forever. IPv6 has been designed to support painless renumbering, including smoothly switching over from one address range to another without loss of connectivity. I am not sure how well this is regarded by the operators of big networks - and I imagine it has rarely, if ever, been put to the test in a real, busy, substantial commercial end-user network. These IPv6 provisions can't cope automatically and reliably with every little detail programmed into routers, switches, etc. such as ACLs, VPN configuration, source address spoofing filters etc. Nor can these IPv6 provisions work fast enough and without human intervention to support multihoming - because existing communications sessions do not persist into the new addresses, unless perhaps both ends of the session are using SHIM6. It is completely impossible for any new routing and addressing architecture to enable reliable, cost-free renumbering of IPv4 networks. So to respect the genuine needs of end-users, I think this should be rewritten simply to provide "portability" of their address space between providers. I am a little wary that the current version of the Problem Statement's goals could be used to justify a new architecture which pressures end-users to adopt IPv6, and/or to make any other such major change their host operating system and application software. I think some people see IPv4 as a dead-end and so can only foresee long-term solutions which involve everyone moving to IPv6. While I recognise there are fundamental problems with IPv4 (NAT and limited address space are the most obvious) I think it would be dangerous in the five to ten year timeframe in which this Problem Statement is relevant to think that the way forward may be to discourage people from using IPv4. I think that any such attempt by the IETF etc. is bound to fail. I think people should move to IPv6 (or maybe some new and better system in the long term future) if and when the benefits they receive exceed their costs. At the same time, we should be doing our best to preserve and improve the usability of IPv4. I think there is a danger of seeing the Problem being just the biggest obvious problem: the RIB-BGP load caused by an increasing number of multihoming end-users who are big enough to get an ASN and PI space today. We certainly need to solve this problem in a way which doesn't add to the number of BGP advertised prefixes. However, I think it is important to frame the goals for a new architecture in a way which encompasses the longer-term challenges posed by ubiquitous Internet adoption, with millions - or hundreds of millions - of end-users wanting and needing portability (or at least painless choice of providers), multihoming, and TE for incoming traffic over multihomed links. It seems that these things can all be achieved with an ITR - ETR scheme as proposed in LISP, eFIT-APT and Ivip. Furthermore, if the ITR tunneling (EID-RLOC mapping) can be controlled by the end-user fast enough (not just codified in the form of instructions to ITRs regarding multihoming service restoration), then the new system will support Mobility too. Although lack of Mobility is not regarded as a crucial problem, this is a little like thinking lack of cell-phones wasn't a problem in 1977. The value of genuine mobility, with sessions continuing as the mobile node switches between separate provider networks, will be immense. This is probably the biggest single thing which could be done to boost the usefulness of Internet communications - even more than significant increases in speed or decreases in cost. I think this real-time control of mapping - such as with 2 to 4 seconds latency globally - can be achieved, but the proponents of LISP and eFIT-APT do not base their systems on any such high-speed mapping information distribution system. There are two goals not mentioned in the current Problem Statement which I think are achievable and essential for coping with long-term growth and ubiquitous adoption: More efficient utilization of IPv4 space and Mobility, including Mobile IPv4. The currently low percentage of advertised IPv4 addresses which are actually used is a result primarily of the address management policies of assigning large chunks of space to all applicants. This long-standing practice is based on the intention that end-user won't need to ask for more space for a few years. Another, more crucial, intention of the current address management system is driven by the desire for route aggregation. The idea is that by giving providers and end-users largish slabs of space, each provider or end-user will be able to satisfy their needs for a long time with this space, which will either be a single BGP advertisement or at least be advertised in a few smaller pieces in roughly the same geographic and topological area. This goal of route-aggregation would not be so well served in the current BGP-dependent architecture if the providers and end-users were only given small pieces of space, on a more frequent basis, with those smaller pieces making up non-contiguous blocks of addresses, each requiring a separate advertisement in BGP. BGP imposes some clunky restrictions on the use of address space. The granularity (in IPv4) is 256 addresses at a time, and all users are urged to minimise the number of prefixes they advertise. The likely new architectural approaches all enable the address space to be used much more flexibly. The granularity of control can be prefixes of any length, including single IP addresses. The number of separately mapped prefixes in the new system places no burden on BGP, and only burdens the new system - which will be designed to scale to millions or perhaps a billion such separately mapped prefixes. So to the extent that address space is split between end-users with the new architecture, that new address space can be assigned in much finer and more flexible ways than has been possible with BGP. This is exactly what is needed for the space to be highly utilised so that more users and or more nodes can be accommodated. This is not just for end-users - providers can use space which is sliced and diced in this way as well, though not for running ITRs or ETRs. Ivip is the only proposal which has as one of its explicit goals a great improvement in how many IPv4 addresses can actually be used. However, I believe that LISP-NERD, LISP-CONS and probably eFIT-APT will be just as suitable as Ivip for this fine-grained address assignment. Ivip is currently the only proposal which aims for mapping changes to be transmitted rapidly (a few seconds ideally) to all ITRs. While I haven't devised precisely how to do this, no-one can say yet that it can't be done. We can get packets across the world in a fraction of second - so maybe all we need is a multicast system to distribute mapping changes, with some authentication arrangements and provision for coping gracefully with lost packets. I hope there will be other people working on Ivip or on their own proposals with similar high-speed mapping distribution. Even if the best efforts to devise a system such as this fail in the next year or two, it cannot be assumed that such a system will not be practical and attractive in the future. So while Ivip is a lone, young, proposal at present, I think that the Problem Statement should not be limited by the assumption that high-speed, essentially real-time, user control of ITRs (or however the new architecture works) will never be feasible. Here is a chart of the current proposals which are intended to provide benefits directly to both IPv4 and IPv6, without requiring changes to hosts. (So this leaves out SHIM6, Six/One and IPvLX.) "BGP improvements" encompasses the proposals which are intended to make the BGP routing system work better, such as being able to handle more prefixes, increase stability, reduce unnecessary control plane traffic, lower costs, ease router management difficulties, improve security etc. I assume that these improvements will not drastically increase the BGP system's ability to handle more prefixes or to propagate advertisement changes more rapidly. Proposal >> BGP impro- LISP eFIT-APT Ivip vements New goal: Better utilization of NA Yes* Yes* Yes IPv4 space, via finer allocations to more end-users who have portability, MH and TE without burdening BGP. Support major improve- NA No No Yes ments to Mobile IPv4 and IPv6 - with optimal or usually close to optimal path lengths and reachability from non-upgraded hosts and networks. NA Not applicable - meaning the proposal does not prevent this goal, but does not directly support it either. No The proposal does not allow this goal to be achieved. Yes The proposal allows this goal to be achieved. Yes* I think the proposal allows the goal to be achieved, but this is not necessarily the view or the intention of the proponents of this proposal. This rewrite also attempts to consider other problems the routing system faces apart from the number of advertised prefixes and their rate of change - including the cost and processing difficulties of the FIB. Having to process 48 bits of IPv6 address for the new PI end-user assignments of ARIN and AfriNIC seems really inefficient. Consider the vast number of streams of little VoIP packets - such as 30 to 50 packets a second with 20 to 30 bytes of voice data, plus RTP header (12 bytes) and UDP header (8 bytes). This is 40 to 50 bytes. Users want this to be a low-cost service, and they will expect it to be pretty much for free. Yet with IPv6, the small amount of data per packet gets a lumbering 40 byte IPv6 header in front of it, and every multihomed and transit router the packet traverses has to labour its way through 48 bits of destination address just to figure out which interface to forward it to. I think it would be highly desirable to have some policy which limits the IPv6 classification tasks of DFZ routers to something like /32 or /35 at the most. Then, the routers can be optimised for handling the bulk of their traffic within these limits (which are still really demanding). This is not a goal below, but maybe the new architecture needs to include administrative and other arrangements which put reasonable limits on the FIB functionality of routers, since they are so costly, use so much power, and are going to be handling so many VoIP packets. Here is a rewrite: There is a need for a new architecture for routing and addressing that: 1. Reduces the growth rate of the DFZ routing load, where the routing load is dependent on: A. The number of individual prefixes in the DFZ. B. The update rate associated with those prefixes. C. The length of those prefixes. D. The complexity and size of the RIB and the complexity and volume of inter-router communications. E. The complexity, cost and power consumption of the FIB functions which handle ordinary routing tasks and any requirements of a new architecture, such as encapsulation, decapsulation, authentication and support for Path MTU Discovery when packets are tunneled. (Actually, I think the new architecture needs a whole new system by which hosts can do a much better job of PMTUD than is currently possible. The new tunneling architectures will make PMTUD much harder, while the problems with MTU and fragmentation are going to be made worse. So there is a lot more which probably should be added to the goals about this.) F. The costs and difficulties of administering routers and the routing system as a whole so routers operate efficiently and do not place unreasonable burdens on other routers. 2. Allows the following benefits for end-users, with the needs of larger organisational end-users being most important, but in principle extending to individual end-users's networks and single devices. These benefits should support communications initiated by hosts in networks which have not adopted the new architecture - perhaps not with the same efficiency as to non-upgraded networks, or with as high an efficiency as between two hosts in upgraded networks. Hosts in non-upgraded networks should suffer no loss of reliability in their communications with hosts in networks using the new architecture. A. Portability of the address space when choosing another provider. B. Multihoming with two or more providers, with robust session continuity. C. Incoming Traffic Engineering where there are two or more links to providers. This TE should be technically capable of being controlled by the end-user and/or the provider. 4. Provides meaningful benefits to the parties who bear the costs of deploying and maintaining the existing and new elements of the routing system. 5. Requires no change to host operating systems or application software. Configuration changes to hosts in upgraded or non-upgraded networks should be minimised and would only be required to improve, or perhaps maintain current levels of efficiency. No changes to any hosts will be required to maintain current levels of reachability and reliability of communications. (I am thinking of MTU settings, tunneling and fragmentation. Hosts in both upgraded and non-upgraded networks might have less efficient communications with hosts in upgraded networks, due to fragmentation, but they shouldn't suffer significantly less reliable communications. This may not quite be possible with packet loss rates having more impact with fragmentation.) 6. Requires no changes to networks which do not adopt the new architecture in order to maintain current levels of reachability and reliability of communications. Any changes of configuration, such as to routers, will be necessary only to improve efficiency. (It may be best for all networks, upgraded or not, to have their DHCP servers send out lower MTU settings, to avoid packets being fragmented due to the tunneling overhead.) 7. Ensures sites which adopt the new approach remain fully reachable from sites which do not. (May be redundant since point 2 may make this clear.) 8. Supports the greater utilization of IPv4 address space by enabling greater flexibility in address assignment than is currently possible - which will enable a greater number of end-users to be assigned address space in smaller increments which more closely match their immediate needs. 9. Supports administrative and commercial frameworks which are intended to improve flexibility, choice and competition - including the ability of large numbers of smaller sites and individual end-users to gain address space, with or without the benefits of portability, multihoming and TE. 10. Either directly supports or at least does not preclude the use of the new architecture to be used for supporting Mobile IP in terms of greater flexibility, more optimal path lengths and communications with non-upgraded correspondent hosts. I also wrote about the RRG Design Goals at: http://psg.com/lists/rrg/2007/msg00199.html but that doesn't include all the stuff I am proposing now. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 31 14:35:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFwYu-0003v9-BZ; Tue, 31 Jul 2007 14:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFwYt-0003pL-6Q for ram@iab.org; Tue, 31 Jul 2007 14:35:15 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFwYr-0001gS-Oy for ram@iab.org; Tue, 31 Jul 2007 14:35:15 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 0897B53E0F8; Tue, 31 Jul 2007 14:35:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id mOkp1g3K-FNI; Tue, 31 Jul 2007 14:35:04 -0400 (EDT) Received: from [172.16.13.200] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 0526753E0EA; Tue, 31 Jul 2007 14:35:03 -0400 (EDT) In-Reply-To: <901157.22509.qm@web58708.mail.re1.yahoo.com> References: <901157.22509.qm@web58708.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [RAM] First cut at routing & addressing problem statement Date: Tue, 31 Jul 2007 14:35:00 -0400 To: Peter Sherbin X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Peter, Thanks for your comments. With regard to statement 1, we discussed whether targeted numbers might be worth including but decided in the end not to do so for several reasons. For one thing, it's an invitation for contentious argument about exactly what the numbers should be -- which would seem to be a rathole. For another, the supportable values are certainly a moving target, based on the state of the art at any given time. With regard to statement 4, I personally think it's OK as written. Surely a proposal which can allow switching with no configuration changes also optimally fulfills "minimizing configuration changes". Seems like flat-out forbidding any slightest configuration change would be going too far, though I think it's clear that forced site config changes are undesirable. With regard to statement 5, with what other statements do you think it's redundant? Note that statement 5 focuses on the alignment of cost and benefit. Regards, --John On Jul 27, 2007, at 1:50 PM, Peter Sherbin wrote: > Enjoined reading the statement. Re the "flatter" Internet in 5.1. > since around 2000 > seemingly there is a trend in changing upstream transit contracts > to peering > arrangements. By Q1 2007 in the observed example over 80% of > traffic is routed via > peers. > > Statement 1. Would it be beneficial to define the targeted number > of individual > prefixes in DFZ, specify the update rate and then architecture > towards those > numbers? E.g. assume 1 AS per each 10,000 sq km of Earth's surface > and 9 routes per > AS. It gives about 450K as the maximum number of DFZ entries > providing an idea of > the router required processing power. > > Statement 4. Make it more rigid "Allows end sites to switch > providers without > configuration changes to internal end site devices". > > Statement 5. seems redundant > > Thanks, > > Peter > > > > --- Thomas Narten wrote: > >> The Routing & Addressing directorate has been working on a strawman >> problem statement since Prague. I just submitted our first cut as an >> Internet Draft and it's available at: >> >> http://www.cs.duke.edu/~narten/ietf/draft-narten-radir-problem- >> statement-00.txt >> >> We would welcome comments on the document. In particular: >> >> - Do folk agree with the problem statement as written, or are we >> missing something fairly fundamental? >> >> - Are there other pressures on the routing system that we have not >> listed or described completely? >> >> - We intentionally did not include improving mobility as a core >> "problem", as explained in the document. (That doesn't mean we >> don't recognize that some of the solutions under discussion may >> also be applicable to mobility scenarios. Rather, we tend to see >> improved mobility as a possible benefit of certain classes of >> solutions.) >> >> - Are there other views of what folk perceive the core routing and >> addressing problem to be? >> >> Thomas >> >> _______________________________________________ >> RAM mailing list >> RAM@iab.org >> https://www1.ietf.org/mailman/listinfo/ram >> > > > > > ______________________________________________________________________ > ______________ > Get the free Yahoo! toolbar and rest assured with the added > security of spyware protection. > http://new.toolbar.yahoo.com/toolbar/features/norton/index.php > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 31 16:24:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFyGe-0000r7-RS; Tue, 31 Jul 2007 16:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFyGe-0000r2-0r for ram@iab.org; Tue, 31 Jul 2007 16:24:32 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFyGc-0004YU-Ix for ram@iab.org; Tue, 31 Jul 2007 16:24:31 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6VKOPde022994 for ; Tue, 31 Jul 2007 16:24:25 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6VKOP9a078092 for ; Tue, 31 Jul 2007 14:24:25 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6VKOO4g023539 for ; Tue, 31 Jul 2007 14:24:25 -0600 X-Authentication-Warning: d03av03.boulder.ibm.com: Processed from queue /var/spool/mqueue/active* X-Authentication-Warning: d03av03.boulder.ibm.com: Processed by postman with -C /relay/etc/sendmail.cf-deliver Received: from cichlid.raleigh.ibm.com (wecm-9-67-185-171.wecm.ibm.com [9.67.185.171]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6VKONWQ023410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2007 14:24:24 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l6VKOBfb029716; Tue, 31 Jul 2007 16:24:21 -0400 Message-Id: <200707312024.l6VKOBfb029716@cichlid.raleigh.ibm.com> To: Robin Whittle Subject: Re: [RAM] First cut at routing & addressing problem statement In-reply-to: <46AC78FC.4050701@firstpr.com.au> References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> <46AB47AB.9060304@firstpr.com.au> <46AC78FC.4050701@firstpr.com.au> Comments: In-reply-to Robin Whittle message dated "Sun, 29 Jul 2007 21:24:44 +1000." Date: Tue, 31 Jul 2007 16:24:11 -0400 From: Thomas Narten X-Spam-Score: -4.0 (----) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin Whittle writes: > Here is a rewrite of the Problem Statement, focusing on > "end-users" rather than "sites" and extending the goals in a > number of ways which I think are achievable and highly desirable. We intended the term "site" to be a fairly general term, one that includes pretty much any topologically distinct thing that connects to the internet. This includes home users. It is also NOT restricted to just larger enterprises or ASes. We'll add a clarifying definition to the document. > I think the current version of the Statement is compatible with > these two statements being true - but I think they are not true: > 1 - That a new architecture could make renumbering robust > and sufficiently painless and free of costs and risks > that all end-users would, or should, be happy to get > new addresses whenever they choose a new provider. If we could do this, then I think we have solved a core problem. Whether or not the above is actually achievable is an open question (and I recognize that many are skeptical). But an important goal of the problem statement is to define the problem and not rule in (or out) any particular solution approach up front. If a proposed solution actually does addresses the problem (and is deployable in practice), we should be happy. :-) > 2 - That a new architecture cannot, or should not, enable > a much finer method of allocating IPv4 address space, to > accommodate more end-users with multihoming, portability > etc. - and that this cannot or should not be used to > enable a much greater number of end-users of all types, > (including those who don't need portability/MH/TE) to > use IPv4. I'm not sure I'd go as far as the above. I think you may be making some assumptions above that are not immediately obvious to me. But I do agree that giving out smaller and smaller address blocks to sites/users and expecting them to be routed in the DFZ makes the problem worse rather than better. > I am also keen to see the new architecture either directly support > Mobile IP, or at least be compatible with future extensions which > do so. I mean an expansive view of Mobile IPv4 and IPv6, with > correspondent hosts not requiring new software, and with close to > optimal path lengths. I think the document is clear on this point: The problem statement in this document has purposefully been scoped to focus on the growth of the routing update function of the DFZ. Other problems that may seem related, but do not directly impact the route scaling problem are not considered to be "in scope" at this time. For example, Mobile IP [[RFC2002], RFC3775] and NEMO [[RFC3963]] place no pressures on the routing system. They are layered on top of existing IP, using tunneling to forward packets via a care-of addresses. Hence, "improving" these technologies (e.g., by having them leverage a solution to the multihoming problem), while a laudable goal, is not considered a part of this problem statement. > For instance, the new architecture's ITR system could be used to > create generally optimal paths to ETRs which are close to the > mobile node. This would enable correspondent hosts without any > special mobile IP software to communicate efficiently with mobile > nodes, including small devices (cell-phones and laptops) as well > as nodes which connect mobile networks - for instance in passenger > jets and trains. I think you are now going into solution space, something the problem statement document is trying very hard to avoid. Again, quoting from the document: This document attempts to define the "problem", with the aim of describing the essential aspects so that the community has a way of evaluating whether proposed solutions actually address or impact the underlying problem or "pain points" in a significant manner. Our view is that improved mobility is a "nice to have", rather than critical requirement. > I think the term "site" tends to imply a physical installation, > largish network, etc. Not our intention, per above. > These are the only types of end-users who have the resources to gain > ASNs, PI space etc. today. However I think the new approach to > routing and addressing can and should provide multihoming, > portability and TE (for those with multihomed links) for a much > larger number of end-users, including those who lack the resources > to get an ASN, PI space etc. In principle, I think the goals should > be extended to apply to single hosts which are physically mobile, > such as cell-phones, laptops etc. I think the term "site" does not > adequately capture that sort of end-user or the device, node, > network etc. whose address space must support multihoming, > portability and ideally mobility. Again, you are now into desiring a better mobility approach. > I am wary of the current state of point 4: > 4. Allows end sites to switch providers while minimizing > configuration changes to internal end site devices. > End-users today need "portable" address space, because there is > currently no mechanism for reliably and painlessly renumbering > every aspect of their network. > The current wording of point 4 only makes sense if a new routing > and addressing architecture might be able to automate address > settings so that end-users with all sizes of networks - including > really large ones - could reliably, quickly and with little cost > adopt a new address range when they change to another provider. > I think this is an unrealistic hope and will remain so within the > foreseeable future - most likely forever. The point of the problem statement is to layout the requirements. It is in the solution space that we can have discussions about what is and is not realistic. > IPv6 has been designed to support painless renumbering, including > smoothly switching over from one address range to another without > loss of connectivity. This is going too far, and is one of the myths of IPv6 (sigh). Renumbering is easier in IPv6 than in IPv4. But it is not "painless". There have been endless discussions/threads about this. > I am a little wary that the current version of the Problem > Statement's goals could be used to justify a new architecture > which pressures end-users to adopt IPv6, and/or to make any other > such major change their host operating system and application > software. If IPv6 solved the route scaling problem, I don't think we'd have much trouble convincing people to adopt IPv6. But since it doesn't, we do not find ourselves in that situation. > I think some people see IPv4 as a dead-end and so can only foresee > long-term solutions which involve everyone moving to IPv6. Not sure what this has to do with the problem statement. > While I recognise there are fundamental problems with IPv4 (NAT > and limited address space are the most obvious) I think it would > be dangerous in the five to ten year timeframe in which this > Problem Statement is relevant to think that the way forward may be > to discourage people from using IPv4. I think that any such > attempt by the IETF etc. is bound to fail. Can you point to specific text that leads you to feel that the problem statement is discouraging continued use of IPv4? > It seems that these things can all be achieved with an ITR - ETR > scheme as proposed in LISP, eFIT-APT and Ivip. The problem statement document takes no position on any particular solution space. > There are two goals not mentioned in the current Problem Statement > which I think are achievable and essential for coping with > long-term growth and ubiquitous adoption: More efficient > utilization of IPv4 space and Mobility, including Mobile IPv4. Please justify each of these two positions. The document talks to the second point. I don't immediately see how a more efficient utilization of the IPv4 space helps. Indeed, it probably hurts. From the document: 4.8. IPv4 Address Exhaustion The IANA and RIR free pool of IPv4 addresses will be exhausted within a few years. As the free pool shrinks, the size of the remaining unused blocks will also shrink and unused blocks previously held in reserve for expansion of existing allocations or otherwise not used due to their smaller size will be allocated for use. Consequently, as the community looks to use use every piece of available address space (no matter how small) there will be an increasing pressure to advertise additional prefixes in the DFZ. It is pretty much an axiom that achieving higher utilization in the use of address space leads to increased fragmentation, and hence, more routes. > The currently low percentage of advertised IPv4 addresses which > are actually used is a result primarily of the address management > policies of assigning large chunks of space to all applicants. > This long-standing practice is based on the intention that > end-user won't need to ask for more space for a few years. Um, it is RIR policy that an end site can obtain IPv4 space, even if it it never will be advertised on the public Internet. Thus, you cannot conclude that because only some fraction of the current address space is routed on the public internet, the remaining space is "unused". Also, RIR policies use an 80% utilization metric. You cannot obtain more space until you have shown that you are actually using 80% of the space you already have. Many (myself included) would argue that we have already got a rather high utilization out of IPv4. While we might be able to squeeze a few more drops of blood out of the IPv4 turnip, how much time does that actually buy us in the overall scheme of things? I suspect not much. > I think it would be highly desirable to have some policy which > limits the IPv6 classification tasks of DFZ routers to something > like /32 or /35 at the most. Then, the routers can be optimised > for handling the bulk of their traffic within these limits (which > are still really demanding). This is not a goal below, but maybe > the new architecture needs to include administrative and other > arrangements which put reasonable limits on the FIB functionality > of routers, since they are so costly, use so much power, and are > going to be handling so many VoIP packets. One small observation: There is no place to define such a policy that would actually be implemented by (or enforcable on) the DFZ routers. Remember, the DFZ routers are operated by ISPs, and what routes they carry, etc. is completely unregulated. Nobody can tell them what they will and will not route. > Here is a rewrite: > There is a need for a new architecture for routing and > addressing that: > 1. Reduces the growth rate of the DFZ routing load, where the > routing load is dependent on: > A. The number of individual prefixes in the DFZ. > B. The update rate associated with those prefixes. > C. The length of those prefixes. We have not considered the prefix length to be a significant problem. Can you you please expand on this point, and why it is significant enough to include? > D. The complexity and size of the RIB and the > complexity and volume of inter-router communications. The difficulty here is that this gets into router architecture, something way out of scope for the IETF "on the wire" focus. And the discussions that followed the RAWs report (to me anyway) make it clear that there is not really concensus that this component of "routing" is where the core problem really is. Or that is not a symptom of the core problem as outlined in the document. > E. The complexity, cost and power consumption of the FIB > functions which handle ordinary routing tasks and any > requirements of a new architecture, such as > encapsulation, decapsulation, authentication and > support for Path MTU Discovery when packets are > tunneled. > (Actually, I think the new architecture needs a > whole new system by which hosts can do a much > better job of PMTUD than is currently possible. > The new tunneling architectures will make PMTUD > much harder, while the problems with MTU and > fragmentation are going to be made worse. So there > is a lot more which probably should be added to the > goals about this.) I would argue that the above is covered by by section 3.1 and 3.2 > F. The costs and difficulties of administering routers > and the routing system as a whole so routers operate > efficiently and do not place unreasonable burdens on > other routers. > 2. Allows the following benefits for end-users, with the > needs of larger organisational end-users being most > important, but in principle extending to individual > end-users's networks and single devices. These benefits > should support communications initiated by hosts in > networks which have not adopted the new architecture - > perhaps not with the same efficiency as to non-upgraded > networks, or with as high an efficiency as between two > hosts in upgraded networks. Hosts in non-upgraded > networks should suffer no loss of reliability in their > communications with hosts in networks using the new > architecture. I think all of this is really getting more into desirable properties of a solution, rather than the problem. Thomas _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 31 21:03:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2cj-0002BM-EV; Tue, 31 Jul 2007 21:03:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2ci-0002BB-G7 for ram@iab.org; Tue, 31 Jul 2007 21:03:36 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG2ci-0002LT-0a for ram@iab.org; Tue, 31 Jul 2007 21:03:36 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 980F01A2F0; Wed, 1 Aug 2007 03:03:35 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 4FE331831E; Wed, 1 Aug 2007 03:03:35 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Aug 2007 02:52:41 +0200 To: Thomas Narten ,Robin Whittle From: JFC Morfin Subject: Re: [RAM] First cut at routing & addressing problem statement In-Reply-To: <200707312024.l6VKOBfb029716@cichlid.raleigh.ibm.com> References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> <46AB47AB.9060304@firstpr.com.au> <46AC78FC.4050701@firstpr.com.au> <200707312024.l6VKOBfb029716@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070801010335.4FE331831E@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 22:24 31/07/2007, Thomas Narten wrote: >We intended the term "site" to be a fairly general term, one that >includes pretty much any topologically distinct thing that connects to >the internet. This includes home users. It is also NOT restricted to >just larger enterprises or ASes. We'll add a clarifying definition to >the document. Dear Thomas, I am sorry but "5. Provides meaningful benefits to the parties who bear the costs of deploying and maintaining the technology." is an error. What we want is to provide meaningful benefits to the users. The users are those who have the money but no incentive today. Their satisfaction is the benefit for the parties who beat the costs, because they will pay. Not the IETF. The incentives for them the users are: - to get presentation layer warranties. Each network application tries to build its own virtual presentation layer features. IDNs and 200 languages. ccTLD with 193 countries. RFC4646 and 7,500 languages. Addressing does not, while there is an unlimited need. - as a result SNHN (small networks/home networks) have not been considered and their addressing area has not been protected and supported by the addressing format which is for them no better than a NAT. - privacy, security, national policies require that the "sites" can decide of their routing. Addressing is to point fixed, mobile, virtual targets on "the semantic distributed networks of the decentralized logical network of the centralized ISP/Corp/SNHN bandwidth networks" in order to flow a traffic of fractal natue. To match the resulting diversity and routing constraints (path, access, and content) presentation layer equivalence is of the essence (whatever you name it: presentations, externets, groups/classes, views, closed user groups, etc.) I looked for "presentation layer" in the list's archive. I did not find it a single occurence. Such a layer could be implemented in part through the addressing structure. Multi-level addressing also can help it. May be there are other possibilities. This should also be investigated through a "smart NIMROD"? It could be involved in getting some control on routing? Whatever the solution retained, it should provide the best addressing and operational environment to "plug-and-play" standardized sub-addresses. jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 31 21:03:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2ck-0002Bo-Lf; Tue, 31 Jul 2007 21:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2cj-0002BH-7X for ram@iab.org; Tue, 31 Jul 2007 21:03:37 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG2ch-0002LS-Rs for ram@iab.org; Tue, 31 Jul 2007 21:03:37 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 341731A0F5; Wed, 1 Aug 2007 03:03:35 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id D19BA1831E; Wed, 1 Aug 2007 03:03:31 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Aug 2007 03:03:34 +0200 To: Robin Whittle ,ram@iab.org From: JFC Morfin Subject: Re: [RAM] First cut at routing & addressing problem statement In-Reply-To: <46AC78FC.4050701@firstpr.com.au> References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> <46AB47AB.9060304@firstpr.com.au> <46AC78FC.4050701@firstpr.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070801010331.D19BA1831E@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dear Robin, in your rewite the point 3 is missing. Is that a typo or a real miss. thank you. jfc At 13:24 29/07/2007, Robin Whittle wrote: > 2. Allows the following benefits for end-users, with the > needs of larger organisational end-users being most > important, but in principle extending to individual > end-users's networks and single devices. These benefits > should support communications initiated by hosts in > networks which have not adopted the new architecture - > perhaps not with the same efficiency as to non-upgraded > networks, or with as high an efficiency as between two > hosts in upgraded networks. Hosts in non-upgraded > networks should suffer no loss of reliability in their > communications with hosts in networks using the new > architecture. > > A. Portability of the address space when choosing > another provider. > > B. Multihoming with two or more providers, with > robust session continuity. > > C. Incoming Traffic Engineering where there are two > or more links to providers. This TE should be > technically capable of being controlled by the > end-user and/or the provider. > > > 4. Provides meaningful benefits to the parties who bear the > costs of deploying and maintaining the existing and new > elements of the routing system. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 31 21:03:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2cj-0002BM-EV; Tue, 31 Jul 2007 21:03:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2ci-0002BB-G7 for ram@iab.org; Tue, 31 Jul 2007 21:03:36 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG2ci-0002LT-0a for ram@iab.org; Tue, 31 Jul 2007 21:03:36 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 980F01A2F0; Wed, 1 Aug 2007 03:03:35 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 4FE331831E; Wed, 1 Aug 2007 03:03:35 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Aug 2007 02:52:41 +0200 To: Thomas Narten ,Robin Whittle From: JFC Morfin Subject: Re: [RAM] First cut at routing & addressing problem statement In-Reply-To: <200707312024.l6VKOBfb029716@cichlid.raleigh.ibm.com> References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> <46AB47AB.9060304@firstpr.com.au> <46AC78FC.4050701@firstpr.com.au> <200707312024.l6VKOBfb029716@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070801010335.4FE331831E@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 22:24 31/07/2007, Thomas Narten wrote: >We intended the term "site" to be a fairly general term, one that >includes pretty much any topologically distinct thing that connects to >the internet. This includes home users. It is also NOT restricted to >just larger enterprises or ASes. We'll add a clarifying definition to >the document. Dear Thomas, I am sorry but "5. Provides meaningful benefits to the parties who bear the costs of deploying and maintaining the technology." is an error. What we want is to provide meaningful benefits to the users. The users are those who have the money but no incentive today. Their satisfaction is the benefit for the parties who beat the costs, because they will pay. Not the IETF. The incentives for them the users are: - to get presentation layer warranties. Each network application tries to build its own virtual presentation layer features. IDNs and 200 languages. ccTLD with 193 countries. RFC4646 and 7,500 languages. Addressing does not, while there is an unlimited need. - as a result SNHN (small networks/home networks) have not been considered and their addressing area has not been protected and supported by the addressing format which is for them no better than a NAT. - privacy, security, national policies require that the "sites" can decide of their routing. Addressing is to point fixed, mobile, virtual targets on "the semantic distributed networks of the decentralized logical network of the centralized ISP/Corp/SNHN bandwidth networks" in order to flow a traffic of fractal natue. To match the resulting diversity and routing constraints (path, access, and content) presentation layer equivalence is of the essence (whatever you name it: presentations, externets, groups/classes, views, closed user groups, etc.) I looked for "presentation layer" in the list's archive. I did not find it a single occurence. Such a layer could be implemented in part through the addressing structure. Multi-level addressing also can help it. May be there are other possibilities. This should also be investigated through a "smart NIMROD"? It could be involved in getting some control on routing? Whatever the solution retained, it should provide the best addressing and operational environment to "plug-and-play" standardized sub-addresses. jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 31 21:03:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2ck-0002Bo-Lf; Tue, 31 Jul 2007 21:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2cj-0002BH-7X for ram@iab.org; Tue, 31 Jul 2007 21:03:37 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG2ch-0002LS-Rs for ram@iab.org; Tue, 31 Jul 2007 21:03:37 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 341731A0F5; Wed, 1 Aug 2007 03:03:35 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id D19BA1831E; Wed, 1 Aug 2007 03:03:31 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Aug 2007 03:03:34 +0200 To: Robin Whittle ,ram@iab.org From: JFC Morfin Subject: Re: [RAM] First cut at routing & addressing problem statement In-Reply-To: <46AC78FC.4050701@firstpr.com.au> References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> <46AB47AB.9060304@firstpr.com.au> <46AC78FC.4050701@firstpr.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070801010331.D19BA1831E@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dear Robin, in your rewite the point 3 is missing. Is that a typo or a real miss. thank you. jfc At 13:24 29/07/2007, Robin Whittle wrote: > 2. Allows the following benefits for end-users, with the > needs of larger organisational end-users being most > important, but in principle extending to individual > end-users's networks and single devices. These benefits > should support communications initiated by hosts in > networks which have not adopted the new architecture - > perhaps not with the same efficiency as to non-upgraded > networks, or with as high an efficiency as between two > hosts in upgraded networks. Hosts in non-upgraded > networks should suffer no loss of reliability in their > communications with hosts in networks using the new > architecture. > > A. Portability of the address space when choosing > another provider. > > B. Multihoming with two or more providers, with > robust session continuity. > > C. Incoming Traffic Engineering where there are two > or more links to providers. This TE should be > technically capable of being controlled by the > end-user and/or the provider. > > > 4. Provides meaningful benefits to the parties who bear the > costs of deploying and maintaining the existing and new > elements of the routing system. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 31 21:10:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2iw-0005tK-B7; Tue, 31 Jul 2007 21:10:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2iu-0005pa-S8 for ram@iab.org; Tue, 31 Jul 2007 21:10:00 -0400 Received: from web58704.mail.re1.yahoo.com ([66.196.100.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IG2iu-0002Qd-2I for ram@iab.org; Tue, 31 Jul 2007 21:10:00 -0400 Received: (qmail 63483 invoked by uid 60001); 1 Aug 2007 01:09:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=lIJ/YqRjpYoiBPd7NDAAJW4OPJ5XngZ9AN4hpdBDrvpO7KoXhslbNHvEZ1IWLy4DRR6HNlTnaHYD101QUzGjMOmFC+al4txpsZ7n5Za9rpU6D8tqeO8zG82FMIcshdtSstenfhWq4F7ZGhuIfPX3CY8iy04WMyf1oGCR6KBwB4Q=; X-YMail-OSG: SiZMXlEVM1lKL2wX0n5pfRRzi1gRhd13W7vJWcO3ylvgxpXdE851_Qz_NCx8kv5FoUZ27ofajphJ9XPOl0qqlKt87AUKqeZRHfmcSiSG_tFpsM2kUfinvndZqUWemg-- Received: from [99.244.193.46] by web58704.mail.re1.yahoo.com via HTTP; Tue, 31 Jul 2007 18:09:55 PDT Date: Tue, 31 Jul 2007 18:09:55 -0700 (PDT) From: Peter Sherbin Subject: Re: [RAM] First cut at routing & addressing problem statement To: "John G. Scudder" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <16360.63228.qm@web58704.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > invitation for contentious argument about exactly what the numbers > should be -- which would seem to be a rathole. There were at least two reasons for suggesting a quantitative benchmark. 1. The Earth has a finite surface or more precisely a limited band of interest which includes the surface plus 20-40km above and 10-20km underneath. Thus it will sustain only a finite number of routers. 2. The draft says that there are 229,789 routes, that "there will be an increasing pressure to advertise additional prefixes in the DFZ" and that "the amount of work needed to maintain paths for a given set of prefixes appears to be increasing". Such conclusions lead to questions like what is the optimal number of prefixes in DFZ? what is the relationship between the number of prefixes and the number of paths? What is the optimal number of entries in RIB/FIB for a particular processor speed? Having numbers here provide a reference point for the discussion. There is also a few other questions such as what is the general theory/model of the Internet? what is the countable unit of the Internet: a node, an interface, an end point, a bit, all of the above? what are the quantitative relationship between the Internet units? does the exercise of producing the Internet model belong to IETF? > Seems like flat-out forbidding any slightest configuration change > would be going too far The strict requirement here protects the site. Ideally there should be no effort at all for the site to change providers. Please keep in mind that the wire-line Internet is only an individual case of the more general mobile Internet with end points moving freely between (relatively) static access points. Which access point belong to what provider should remain transparent to an end point. > With regard to statement 5, with what other statements do you think > it's redundant? This one is redundant in a sense that it does not specify the quantity of benefits and that it seems to be a default assumption in any engineering effort whether IETF or else. Thanks, Peter --- "John G. Scudder" wrote: > Peter, > > Thanks for your comments. With regard to statement 1, we discussed > whether targeted numbers might be worth including but decided in the > end not to do so for several reasons. For one thing, it's an > invitation for contentious argument about exactly what the numbers > should be -- which would seem to be a rathole. For another, the > supportable values are certainly a moving target, based on the state > of the art at any given time. > > With regard to statement 4, I personally think it's OK as written. > Surely a proposal which can allow switching with no configuration > changes also optimally fulfills "minimizing configuration changes". > Seems like flat-out forbidding any slightest configuration change > would be going too far, though I think it's clear that forced site > config changes are undesirable. > > With regard to statement 5, with what other statements do you think > it's redundant? Note that statement 5 focuses on the alignment of > cost and benefit. > > Regards, > > --John > > On Jul 27, 2007, at 1:50 PM, Peter Sherbin wrote: > > Enjoined reading the statement. Re the "flatter" Internet in 5.1. > > since around 2000 > > seemingly there is a trend in changing upstream transit contracts > > to peering > > arrangements. By Q1 2007 in the observed example over 80% of > > traffic is routed via > > peers. > > > > Statement 1. Would it be beneficial to define the targeted number > > of individual > > prefixes in DFZ, specify the update rate and then architecture > > towards those > > numbers? E.g. assume 1 AS per each 10,000 sq km of Earth's surface > > and 9 routes per > > AS. It gives about 450K as the maximum number of DFZ entries > > providing an idea of > > the router required processing power. > > > > Statement 4. Make it more rigid "Allows end sites to switch > > providers without > > configuration changes to internal end site devices". > > > > Statement 5. seems redundant > > > > Thanks, > > > > Peter > > > > > > > > --- Thomas Narten wrote: > > > >> The Routing & Addressing directorate has been working on a strawman > >> problem statement since Prague. I just submitted our first cut as an > >> Internet Draft and it's available at: > >> > >> http://www.cs.duke.edu/~narten/ietf/draft-narten-radir-problem- > >> statement-00.txt > >> > >> We would welcome comments on the document. In particular: > >> > >> - Do folk agree with the problem statement as written, or are we > >> missing something fairly fundamental? > >> > >> - Are there other pressures on the routing system that we have not > >> listed or described completely? > >> > >> - We intentionally did not include improving mobility as a core > >> "problem", as explained in the document. (That doesn't mean we > >> don't recognize that some of the solutions under discussion may > >> also be applicable to mobility scenarios. Rather, we tend to see > >> improved mobility as a possible benefit of certain classes of > >> solutions.) > >> > >> - Are there other views of what folk perceive the core routing and > >> addressing problem to be? > >> > >> Thomas > >> > >> _______________________________________________ > >> RAM mailing list > >> RAM@iab.org > >> https://www1.ietf.org/mailman/listinfo/ram > >> > > > > > > > > > > ______________________________________________________________________ > > ______________ > > Get the free Yahoo! toolbar and rest assured with the added > > security of spyware protection. > > http://new.toolbar.yahoo.com/toolbar/features/norton/index.php > > > > _______________________________________________ > > RAM mailing list > > RAM@iab.org > > https://www1.ietf.org/mailman/listinfo/ram > > > > ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jul 31 23:55:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG5IZ-0003kq-23; Tue, 31 Jul 2007 23:54:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG5IX-0003fn-BK for ram@iab.org; Tue, 31 Jul 2007 23:54:57 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG5IT-0006Ut-KU for ram@iab.org; Tue, 31 Jul 2007 23:54:57 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id B114359E41; Wed, 1 Aug 2007 13:54:42 +1000 (EST) Message-ID: <46B003F5.5040300@firstpr.com.au> Date: Wed, 01 Aug 2007 13:54:29 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] First cut at routing & addressing problem statement References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> <46AB47AB.9060304@firstpr.com.au> <46AC78FC.4050701@firstpr.com.au> <200707312024.l6VKOBfb029716@cichlid.raleigh.ibm.com> In-Reply-To: <200707312024.l6VKOBfb029716@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ac00a67115ef9face560ffa0586506ca Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi JFC Morphin, The missing point 3 is just a typo. The other points you mention seem to involve long-term new architectural goals involving host changes. I have approached the RADIR Problem Statement assuming it concerns a problem which requires a solution which is incrementally deployable and automatically enables existing hosts, without changes, to remain connected, but achieves important benefits such as multihoming, portability, TE etc. for many more end-users without adding to the growth in the global routing table. In fact, there is no timeframe or requirement for unchanged hosts, or incremental deployability, in the current Problem Statement. Below, I discuss it as if this was the goal. Perhaps there needs to be two problem statements. One is to get us out of a fix in the next five to ten years, without requiring host changes. The other is to create a new set of protocols or whatever to achieve some of the more ambitious goals you discuss. As far as I know, your goals can't be done without changes to host operating systems and probably applications too. The rest of this message responds to Thomas Narten's reply to my message 1773. Thanks Thomas for your response. Some of my message discussed what I think can and can't be expected from potential solutions. I wasn't suggesting that that material be included in the Problem Statement. I think it is important not to write the Problem Statement as if something is possible when it is not. I mentioned the capabilities and limitations of various solutions to explain why I think it is important to include criteria which identify solutions which might preclude the realisation of an important goal which is not part of solving the current Problem. Thanks for clarifying "site". I agree with much of what you wrote. Here are some points where where I disagree, don't understand etc. >> I think the current version of the Statement is compatible with >> these two statements being true - but I think they are not true: > >> 1 - That a new architecture could make renumbering robust >> and sufficiently painless and free of costs and risks >> that all end-users would, or should, be happy to get >> new addresses whenever they choose a new provider. > > If we could do this, then I think we have solved a core > problem. Whether or not the above is actually achievable is an open > question (and I recognize that many are skeptical). > But an important goal of the problem statement is to define the > problem and not rule in (or out) any particular solution approach up > front. If a proposed solution actually does addresses the problem (and > is deployable in practice), we should be happy. :-) I think that it is distracting and of little or no use to frame a statement as if some solution could exist for a problem when it can be reliably proven that no such solution is possible. Ignoring IPv6 for a moment, consider the large number of IPv4 end-user networks. There is no way these can be renumbered reliably, automatically, or manually, because there are many IP addresses in obscure places, as the RRG "Design Goals" note, such as: In addition to being configured into hosts and routers, where automated renumbering tools can help, IP addresses are also often used for other purposes such as access control lists. They are also sometimes hard-coded into applications used in environments where failure of the DNS could be catastrophic (e.g. certain remote monitoring applications). Although renumbering may be considered a mild inconvenience for some sites, and guidelines have been developed for renumbering a network without a flag day [RFC4192], for others, the necessary changes are sufficiently difficult so as to make renumbering effectively impossible. These obscure locations of IP addresses cannot be known to any newly introduced architecture, software tools etc. - so there is no external solution which can enable these networks to reliably renumber in some clean, automated, manner. (Even if the IP addresses were known to some system, how could such a system reliably know they should be changed - and how could such a system re-initialise various daemons, in the right order, at the right time?) I regard the above as complete proof that any new architecture will be incapable of providing reliable renumbering of most substantial IPv4 networks in use today, or in the timeframe I assume is of interest: the next ten years. Can anyone think of a counter argument? In the long term, it might be possible to define some new architecture to which all new routers, operating systems etc. would fully comply, with systematic linkages for updating configurations and reloading those config files etc. Even then, I doubt any network administrator would be confident about letting some intricate automated web of processes suddenly try to steer their network on another course, all at once. If some new architecture is developed for reliable fully automated renumbering, then it would be a decade or more before it could be assumed that many networks would be fully compliant with that scheme. So an architecture which supports reliable automated renumbering is a solution which might have some value around 2022 or so. As you note, even with a decade or so of efforts, it is not close to being achieved with IPv6. Assuming the Problem Statement is referring to a solution which will have reliable, practical, benefits in the 2010 to 2012 timeframe, I believe that reliable automated renumbering of networks can be completely ruled out as a possibility. In that case, I stand by my argument that it would be best to frame the Problem Statement without the assumption or implication that something which is provably impossible may in fact be possible in the timeframe of interest. >> 2 - That a new architecture cannot, or should not, enable >> a much finer method of allocating IPv4 address space, to >> accommodate more end-users with multihoming, portability >> etc. - and that this cannot or should not be used to >> enable a much greater number of end-users of all types, >> (including those who don't need portability/MH/TE) to >> use IPv4. > > I'm not sure I'd go as far as the above. I think you may be making > some assumptions above that are not immediately obvious to me. But I > do agree that giving out smaller and smaller address blocks to > sites/users and expecting them to be routed in the DFZ makes the > problem worse rather than better. I should have added this to the above paragraph: ... enable a much greater number of end-users of all types, (including those who don't need portability/MH/TE) to use IPv4 without adding to growth in the global routing table. ---------------------------------------------------- I think that something very clear to me is either not understood or not agreed to by some people: If you have a largish subnet assigned to the LISP/eFIT-APT/Ivip system, say 20.0.0.0/14, with 262,144 IP addresses, then this will require either no BGP advertised prefixes or for Ivip, one advertised prefix. The ITR-ETR-database tunneling and mapping system (LISP/eFIT-APT/Ivip) is capable of dividing these 262,144 addresses between a large number of end-users. In principle, each IP address could go to a separate end-user, with portability, multihoming and TE. A more likely outcome is some mix of prefix sizes going to end-users. It is easy to imagine some mix of prefix sizes between /20 and /32 - with thousands of end-users getting what they need, which may be only one or a few IP addresses, or may in some cases be a few thousand. This address space can be divided up much more finely than with IPv4's current (and likely future) BGP arrangements which, in practice, though not technically, restrict the advertised prefix length to 24 or less. Changing that limit wouldn't help, because the real problem is the number of advertised prefixes. Any of these schemes (LISP/eFIT-APT/Ivip) could take this /14 and with either 0 or 1 extra prefixes in the global routing table, serve the needs of hundreds or more likely thousands of end-users. I think that the LISP and eFIT-APT proponents see their schemes as being beneficial primarily by providing multihoming and TE to single prefixes - so the overall benefit is mainly that a prefix can be taken out of the BGP system and then still be used for MH, TE etc. with LISP or eFIT-APT. I have always seen the primary benefit of these schemes being that a single block of address space can be used for many more end-users than with BGP, because it becomes finely divisible without concern about route aggregation or the effective 256 address granularity of BGP. >> I am also keen to see the new architecture either directly support >> Mobile IP, or at least be compatible with future extensions which >> do so. I mean an expansive view of Mobile IPv4 and IPv6, with >> correspondent hosts not requiring new software, and with close to >> optimal path lengths. > > I think the document is clear on this point: > > The problem statement in this document has purposefully been scoped > to focus on the growth of the routing update function of the DFZ. > Other problems that may seem related, but do not directly impact the > route scaling problem are not considered to be "in scope" at this > time. For example, Mobile IP [[RFC2002], RFC3775] and NEMO > [[RFC3963]] place no pressures on the routing system. They are > layered on top of existing IP, using tunneling to forward packets via > a care-of addresses. Hence, "improving" these technologies (e.g., by > having them leverage a solution to the multihoming problem), while a > laudable goal, is not considered a part of this problem statement. I agree with this, but I am suggesting that since some solutions to the "multihoming, portability, TE vs. routing table growth" problem (one so far - Ivip) would enable great benefits for Mobile IP and that others would not be extendable to provide these benefits, that the Problem Statement should support a decision framework which gives preference to a solution which either provides the Mobile IP benefits, or does not create barriers to such benefits being added in the future. In principle, it might be possible to add an Ivip-style "real-time" database distribution system to LISP-NERD/CONS or to eFIT-APT, but this would be a major change to those architectures, and made more difficult by the more complex and lengthier nature of the mapping data than is used with Ivip. >> For instance, the new architecture's ITR system could be used to >> create generally optimal paths to ETRs which are close to the >> mobile node. This would enable correspondent hosts without any >> special mobile IP software to communicate efficiently with mobile >> nodes, including small devices (cell-phones and laptops) as well >> as nodes which connect mobile networks - for instance in passenger >> jets and trains. > > I think you are now going into solution space, something the problem > statement document is trying very hard to avoid. Again, quoting from > the document: > > This document attempts to define the "problem", with the aim of > describing the essential aspects so that the community has a way of > evaluating whether proposed solutions actually address or impact the > underlying problem or "pain points" in a significant manner. > > Our view is that improved mobility is a "nice to have", rather than > critical requirement. I am discussing solutions to show that there are important differences between the current solutions regarding mobility. I am not suggesting that this discussion appear in section 6 of the Problem Statement. >> I am a little wary that the current version of the Problem >> Statement's goals could be used to justify a new architecture >> which pressures end-users to adopt IPv6, and/or to make any other >> such major change their host operating system and application >> software. > > If IPv6 solved the route scaling problem, I don't think we'd have much > trouble convincing people to adopt IPv6. But since it doesn't, we > do not find ourselves in that situation. > >> I think some people see IPv4 as a dead-end and so can only foresee >> long-term solutions which involve everyone moving to IPv6. > > Not sure what this has to do with the problem statement. > >> While I recognise there are fundamental problems with IPv4 (NAT >> and limited address space are the most obvious) I think it would >> be dangerous in the five to ten year timeframe in which this >> Problem Statement is relevant to think that the way forward may be >> to discourage people from using IPv4. I think that any such >> attempt by the IETF etc. is bound to fail. > > Can you point to specific text that leads you to feel that the problem > statement is discouraging continued use of IPv4? I see nothing in the Problem Statement which discourages continued use of IPv4. Nor did I want to imply that this was a motivation of those who wrote it. The current text does not mention the timeframe the new architecture is to be developed and deployed in. Nor does it mention that in order to be acceptable, the new architecture must not require changes to host operating systems, software (and perhaps configuration). In this whole debate, these requirements are widely assumed - or perhaps this RADIR statement is for a longer timeframe, so it is another debate. If words to the effect of these were added: The new approach must be developed and deployed so that its benefits start to accrue by 2011, with full benefits being achieved by 2015. The new approach must not compromise the reliability of communications between hosts in networks which have not yet adopted the new approach and hosts in networks which have adopted it. In order that the new approach be reliably and incrementally deployable, it must not rely on changes to any hosts, including those in networks adopting the new approach, in order that those hosts maintain reliable connectivity with all other hosts. (This does not rule out an architecture which marginally degrades performance for all hosts, with some of that performance perhaps being restored via host configuration changes. For instance MTU settings.) then I would not be concerned that the Statement could support someone arguing that end-users should be required to adopt IPv6. >> It seems that these things can all be achieved with an ITR - ETR >> scheme as proposed in LISP, eFIT-APT and Ivip. > > The problem statement document takes no position on any particular > solution space. I agree that it shouldn't. >> There are two goals not mentioned in the current Problem Statement >> which I think are achievable and essential for coping with >> long-term growth and ubiquitous adoption: More efficient >> utilization of IPv4 space and Mobility, including Mobile IPv4. > > Please justify each of these two positions. The document talks to the > second point. I don't immediately see how a more efficient utilization > of the IPv4 space helps. Indeed, it probably hurts. From the document: > > 4.8. IPv4 Address Exhaustion > > The IANA and RIR free pool of IPv4 addresses will be exhausted within > a few years. As the free pool shrinks, the size of the remaining > unused blocks will also shrink and unused blocks previously held in > reserve for expansion of existing allocations or otherwise not used > due to their smaller size will be allocated for use. Consequently, > as the community looks to use use every piece of available address > space (no matter how small) there will be an increasing pressure to > advertise additional prefixes in the DFZ. > > It is pretty much an axiom that achieving higher utilization in the > use of address space leads to increased fragmentation, and hence, more > routes. This is what I mentioned above - the LISP/eFIT/Ivip approaches all enable a drastically more efficient utilisation of IPv4 address space without adding prefixes to the BGP routing table. (Ivip adds one for each block of space which is assigned to it, but supports many more than one end-users in that space.) >> The currently low percentage of advertised IPv4 addresses which >> are actually used is a result primarily of the address management >> policies of assigning large chunks of space to all applicants. >> This long-standing practice is based on the intention that >> end-user won't need to ask for more space for a few years. > > Um, it is RIR policy that an end site can obtain IPv4 space, even if > it it never will be advertised on the public Internet. Thus, you > cannot conclude that because only some fraction of the current > address space is routed on the public internet, the remaining space is > "unused". Figure 5 "Current IPv4 Status" at: http://www.potaroo.net/tools/ipv4/ shows quite a lot of space, in orange, which has been assigned but not advertised. Figure 12 graphs the unadvertised space, which is growing more slowly than the advertised space. It is currently about 0.46 of the advertised space. So about 31% of assigned space is not advertised. I wonder why an end-site would want address space it was not going to advertise, and why in an era of permanent shortage, RIRs would allow space to be used in this way. Couldn't those end-users be expected to use private address space and let another end-user have the publicly routable space, to advertise? > Also, RIR policies use an 80% utilization metric. You cannot obtain > more space until you have shown that you are actually using 80% of the > space you already have. > > Many (myself included) would argue that we have already got a rather > high utilization out of IPv4. While we might be able to squeeze a few > more drops of blood out of the IPv4 turnip, how much time does that > actually buy us in the overall scheme of things? I suspect not much. Perhaps this is where I misunderstand actual utilisation of IPv4 address space. Does "80% utilisation" mean that 80% of the IP addresses actually have a host, an ADSL modem/router etc. using them, at least some of the time? I wonder what fraction of the space actually has that rate of utilisation. Only a fraction of it would have, since much assigned space would be either old (and often very large) assignments or an assignment to an end-user or ISP which did prove the 80% utilisation, but this new assignment generally won't be that highly utilised yet. In March this year there were about 1.695 billion IPv4 addresses advertised. I know some of this space is /8s with very low utilisation rates. I wonder how much of the advertised prefixes really come close to the 80% utilisation rate. It is my impression that a lot of this space is sparsely used. There is no pressure about reclaiming sparsely used address space this now - such as telling the assignee to keep a quarter of it, move their hosts to that quarter, and use the rest for other end-users - but I am sure there will be in two or three years time. A recent JPNIC statement: http://www.apnic.net/news/2007/0626.html may be foreshadowing this: To maintain the existing IPv4 based Internet, and to create smooth transition to IPv6, it is also important to recover and recycle unused IPv4 addresses. >> I think it would be highly desirable to have some policy which >> limits the IPv6 classification tasks of DFZ routers to something >> like /32 or /35 at the most. Then, the routers can be optimised >> for handling the bulk of their traffic within these limits (which >> are still really demanding). This is not a goal below, but maybe >> the new architecture needs to include administrative and other >> arrangements which put reasonable limits on the FIB functionality >> of routers, since they are so costly, use so much power, and are >> going to be handling so many VoIP packets. > > One small observation: There is no place to define such a policy that > would actually be implemented by (or enforcable on) the DFZ > routers. Remember, the DFZ routers are operated by ISPs, and what > routes they carry, etc. is completely unregulated. Nobody can tell > them what they will and will not route. Maybe not a policy then, but sufficient ISPs deciding that they don't want to be paying forever for overly complex routers because a small amount of address space involves what they consider to be unreasonably long prefixes. >> Here is a rewrite: > >> There is a need for a new architecture for routing and >> addressing that: > >> 1. Reduces the growth rate of the DFZ routing load, where the >> routing load is dependent on: > >> A. The number of individual prefixes in the DFZ. > >> B. The update rate associated with those prefixes. > >> C. The length of those prefixes. > > We have not considered the prefix length to be a significant > problem. Can you you please expand on this point, and why it is > significant enough to include? I am not concerned about IPv4 traffic often requiring up to 24 bits of the address to be analysed. I accept that IPv6 will generally involve looking at 32 to 36 bits, but I think the recent development of /48 end-user assignments by ARIN, AfriNIC and yesterday RIPE means that IPv6 routers have to do a huge amount of work in their FIB to classify each of these packets which match a /48. If the router uses a TCAM wide enough to handle these bits in a single cycle, then I agree it doesn't really matter. TCAMs were 36 bits wide and are now available 72 bits wide. However the latest high-end routers don't use TCAM in their FIBs - they use ASIC CPUs and RAM lookups. The more bits which need to be analysed, the more processing time and RAM lookups are required. The shared Dynamic RAM is the bottleneck of Cisco's 188 CPU system. The initial brochure for Cisco's CRS-1 mentioned that its MSC card could handle 40Gbps, but only for IPv4. I discuss this Tree-bitmap based CRS-1 MSC at: http://www.firstpr.com.au/ip/sram-ip-forwarding/router-fib/ You can see the "IPv4" proviso on page 20 of: http://www.dfn.de/content/fileadmin/3Beratung/Betriebstagungen/bt45/forum-winip-irgens.pdf Silicon Packet Processor 40G of line rate Forwarding capability (IP4) This is with one or two gigabytes of DRAM, and an ASIC with 188 independent 32 bit CPUs. IPv6's longer prefixes are hard work, and I think that any new architecture should only increase the workload of FIBs with very strong justification. There was a lot said about FIB burdens in the RAWS report and presentations. >> D. The complexity and size of the RIB and the >> complexity and volume of inter-router communications. > > The difficulty here is that this gets into router architecture, > something way out of scope for the IETF "on the wire" focus. And the > discussions that followed the RAWs report (to me anyway) make it clear > that there is not really concensus that this component of "routing" is > where the core problem really is. Or that is not a symptom of the core > problem as outlined in the document. It is my understanding that the primary reason a new architecture is required is that the growth in the global BGP routing table must be constrained in order to ensure that unsustainable burdens are not placed on individual DFZ routers, particularly in terms of the amount of state they hold in their RIB, their processing load and their communications load. The internal RIB functions of routers are defined, in large part, by the protocols they must handle, which is under the control of the IETF. It would be easy to invent a more detailed form of BGP message, to enable routers to make better decisions, but either no-one would implement it, due to the typically 4Gbyte restriction on RAM, or they would do so and all compliant routers would cost much more than current routers, with older routers needing to be completely replaced. I think "complexity and volume of inter-router communications" is important, since this is the real problem along with the amount of RIB state - and since the current text: A. The number of individual prefixes in the DFZ B. The update rate associated with those prefixes. doesn't cover how long the messages are for each update of each prefix, or the amount of data they contain which needs to be stored in the RIB. >> E. The complexity, cost and power consumption of the FIB >> functions which handle ordinary routing tasks and any >> requirements of a new architecture, such as >> encapsulation, decapsulation, authentication and >> support for Path MTU Discovery when packets are >> tunneled. > >> (Actually, I think the new architecture needs a >> whole new system by which hosts can do a much >> better job of PMTUD than is currently possible. >> The new tunneling architectures will make PMTUD >> much harder, while the problems with MTU and >> fragmentation are going to be made worse. So there >> is a lot more which probably should be added to the >> goals about this.) > > I would argue that the above is covered by by section 3.1 and 3.2 I think this needs to be part of the formal Problem Statement, because otherwise an architecture could be chosen which involves excessively complex processing to achieve important things like authentication of ICMP messages and filtering encapsulated packets to drop those with spoofed local source addresses. I have written about both these problems on this list recently. Just the encapsulation of some proposals involves extra headers, nonces, etc. I think there needs to be a good justification for all this extra work and extra bits in packets. >> F. The costs and difficulties of administering routers >> and the routing system as a whole so routers operate >> efficiently and do not place unreasonable burdens on >> other routers. > > >> 2. Allows the following benefits for end-users, with the >> needs of larger organisational end-users being most >> important, but in principle extending to individual >> end-users's networks and single devices. These benefits >> should support communications initiated by hosts in >> networks which have not adopted the new architecture - >> perhaps not with the same efficiency as to non-upgraded >> networks, or with as high an efficiency as between two >> hosts in upgraded networks. Hosts in non-upgraded >> networks should suffer no loss of reliability in their >> communications with hosts in networks using the new >> architecture. > > I think all of this is really getting more into desirable properties > of a solution, rather than the problem. I agree this concerns required or desirable properties of the solution. I think this is in keeping with the current form of Section 6: The problem is that we need a solution which will have the following properties: 1. ..... 2. etc. My understanding is that most people in this field believe that a new routing and addressing architecture needs to be developed in the next two or three years and that it must be backwards compatible by supporting connectivity to and from hosts in non-upgraded networks. I also think there is a consensus about not requiring changes to hosts. Ideally, that connectivity should be undiminished by the new architecture, but I think that when any host sends packets to another host whose address is mapped with LISP/eFIT-APT/Ivip, that there are likely to be problems with MTU and fragmentation. That is why I wanted to make it acceptable for a new architecture to diminish efficiency somewhat - because I think all the solutions (other than moderate improvements to BGP, which is not a full solution) involve tunneling and so will have these MTU and fragmentation problems. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram