On 01/21/13 19:06, Damien Saucez wrote: > comments inline > > On 21 Jan 2013, at 10:42, Lori Jakab <[email protected]> wrote: > >> Hi Damien, >> >> Many thanks for the review. See responses inline: >> >> On 01/15/13 00:15, Damien Saucez wrote: >>> Hello, >>> >>> Comments inline >> [...] >> >>>> LISP site: A single host or a set of network elements in an edge >>>> network under the administrative control of a single organization, >>>> delimited from other networks by LISP Tunnel Router(s). >>>> >>>> Since LISP is a protocol which can be used for different purposes, it >>>> is important to identify possible deployment scenarios and the >>>> additional requirements they may impose on the protocol specification >>>> and other protocols. Additionally, this document is intended as a >>>> guide for the operational community for LISP deployments in their >>>> networks. It is expected to evolve as LISP deployment progresses, >>>> and the described scenarios are better understood or new scenarios >>>> are discovered. >>>> >>> maybe describe rapidly what an network element is. >> Not sure it is really necessary, but how about something like: >> >> Network element: active or passive device that is used for >> transporting packet switched data. > ok >> >>>> Each subsection considers an element type, discussing the impact of >>>> deployment scenarios on the protocol specification. For definition >>>> of terms, please refer to the appropriate documents (as cited in the >>>> respective sections). >>>> 2. Tunnel Routers >>>> >>>> LISP is a map-and-encap protocol, with the main goal of improving >>>> global routing scalability. To achieve its goal, it introduces >>>> several new network elements, each performing specific functions >>>> necessary to separate the edge from the core. >>> wouldn't this clearer in Sec. 1? It is important for the general >>> understanding. >> Agree, will move. >> >> [...] >> >>>> From the LISP site perspective the main advantage of this type of >>>> deployment (compared to the one described in the next section) is >>>> having direct control over its ingress traffic engineering. This >>>> makes it is >>> remove is? >> Thanks for catching this. >> >> [...] >> >>>> Another thing to consider when placing tunnel routers are MTU issues. >>>> Since encapsulating packets increases overhead, the MTU of the end- >>>> to-end path may decrease, when encapsulated packets need to travel >>>> over segments having close to minimum MTU. Some transit networks are >>>> known to provide larger MTU than the typical value of 1500 bytes of >>>> popular access technologies used at end hosts (e.g., IEEE 802.3 and >>>> 802.11). However, placing the LISP router connecting to such a >>>> network at the customer edge could possibly bring up MTU issues, >>>> depending on the link type to the provider as opposed to the >>>> following scenario. >>> counter measures for that (e.g., any special setup that can be done >>> to minimise the risk >>> a client is not working properly because of MTU) >> That could be a lenghty discussion. LISP sites should check with their >> providers and make sure they offer links with the required MTU. They >> should also be able to check for themselves. > is there any IETF document that could be pointed out for that?
RFC4459 could be a good candidate. >>>> 2.2. Provider Edge >>>> >>>> The other location at the core-edge boundary for deploying LISP >>>> routers is at the Internet service provider edge. The main incentive >>>> for this case is that the customer does not have to upgrade the CE >>>> router(s), or change the configuration of any equipment. >>>> Encapsulation/decapsulation happens in the provider's network, which >>>> may be able to serve several customers with a single device. For >>>> large ISPs with many residential/business customers asking for LISP >>>> this can lead to important savings, since there is no need to upgrade >>>> the software (or hardware, if it's the case) at each client's >>>> location. Instead, they can upgrade the software (or hardware) on a >>>> few PE routers serving the customers. This scenario is depicted in >>>> Figure 2. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 5] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> +----------+ +------------------+ >>>> | ISP1 | | ISP2 | >>>> | | | | >>>> | +----+ | | +----+ +----+ | >>>> +--|xTR1|--+ +--|xTR2|--|xTR3|--+ >>>> +----+ +----+ +----+ >>>> | | | >>>> | | | >>>> +--<[LISP site]>---+-------+ >>>> >>>> Figure 2: xTR at the PE >>>> >>>> While this approach can make transition easy for customers and may be >>>> cheaper for providers, the LISP site looses one of the main benefits >>>> of LISP: ingress traffic engineering. Since the provider controls >>>> the ETRs, additional complexity would be needed to allow customers to >>>> modify their mapping entries. >>> or the client can have some form of access to the configuration (a bit >>> like tagging route with >>> special communities in BGP to tell the ISP to which of its operator >>> not advertise the route) >> Yes, that's what the "additional complexity" above refers to: you need >> more stuff to make it work. >> >>>> The problem is aggravated when the LISP site is multihomed. Consider >>>> the scenario in Figure 2: whenever a change to TE policies is >>>> required, the customer contacts both ISP1 and ISP2 to make the >>>> necessary changes on the routers (if they provide this possibility). >>> ok, cf supra >>>> It is however unlikely, that both ISPs will apply changes >>>> simultaneously, which may lead to inconsistent state for the mappings >>>> of the LISP site. Since the different upstream ISPs are usually >>>> competing business entities, the ETRs may even be configured to >>>> compete, either to attract all the traffic or to get no traffic. The >>>> former will happen if the customer pays per volume, the latter if the >>>> connectivity has a fixed price. A solution could be to have the >>>> mappings in the Map-Server(s), and have their operator give control >>>> over the entries to customer, much like in the Domain Name System at >>>> the time of this writing. >>>> >>>> Additionally, since xTR1, xTR2, and xTR3 are in different >>>> administrative domains, locator reachability information is unlikely >>>> to be exchanged among them, making it difficult to set Loc-Status- >>>> Bits correctly on encapsulated packets. >>>> >>> IMHO this document should suggest not to use LSB in the Internet case >>> deployment >> Only for the above reason, or due to security concerns? > For me, the main reason not to use LSB in Internet is the problem > of definition of reachability, what does mean a LSB full of 1? It is not > because the one that set the LSB can reach all the RLOCs that it will > be the case for ITR sending the packet based on what it sees from the > LSB. I see your point. Still, I would like more opinions on this before making recommendations. Will start a new thread. > >>>> Compared to the customer edge scenario, deploying LISP at the >>>> provider edge might have the advantage of diminishing potential MTU >>>> issues, because the tunnel router is closer to the core, where links >>>> typically have higher MTUs than edge network links. >>>> >>>> 2.3. Split ITR/ETR >>>> >>>> In a simple LISP deployment, xTRs are located at the border of the >>>> LISP site (see Section 2.1). In this scenario packets are routed >>>> inside the domain according to the EID. However, more complex >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 6] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> networks may want to route packets according to the destination RLOC. >>>> This would enable them to choose the best egress point. >>>> >>>> The LISP specification separates the ITR and ETR functionality and >>>> considers that both entities can be deployed in separated network >>>> equipment. ITRs can be deployed closer to the host (i.e., access >>>> routers). This way packets are encapsulated as soon as possible, and >>>> packets exit the network through the best egress point in terms of >>>> BGP policy. In turn, ETRs can be deployed at the border routers of >>>> the network, and packets are decapsulated as soon as possible. Once >>>> decapsulated, packets are routed based on destination EID, according >>>> to internal routing policy. >>>> >>>> In the following figure we can see an example. The Source (S) >>>> transmits packets using its EID and in this particular case packets >>>> are encapsulated at ITR_1. The encapsulated packets are routed >>>> inside the domain according to the destination RLOC, and can egress >>>> the network through the best point (i.e., closer to the RLOC's AS). >>>> On the other hand, inbound packets are received by ETR_1 which >>>> decapsulates them. Then packets are routed towards S according to >>>> the EID, again following the best path. >>>> >>>> +---------------------------------------+ >>>> | | >>>> | +-------+ +-------+ +-------+ >>>> | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | >>>> | +-------+ | +-------+ +-------+ >>>> | +-+ | | | >>>> | |S| | IGP | | >>>> | +-+ | | | >>>> | +-------+ | +-------+ +-------+ >>>> | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | >>>> | +-------+ +-------+ +-------+ >>>> | | >>>> +---------------------------------------+ >>>> >>>> Figure 3: Split ITR/ETR Scenario >>>> >>>> This scenario has a set of implications: >>>> >>>> o The site must carry at least partial BGP routes in order to choose >>>> the best egress point, increasing the complexity of the network. >>>> However, this is usually already the case for LISP sites that >>>> would benefit from this scenario. >>>> >>>> o If the site is multihomed to different ISPs and any of the >>>> upstream ISPs is doing uRPF filtering, this scenario may become >>>> impractical. ITRs need to determine the exit ETR, for setting the >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 7] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> correct source RLOC in the encapsulation header. This adds >>>> complexity and reliability concerns. >>>> >>>> o In LISP, ITRs set the reachability bits when encapsulating data >>>> packets. Hence, ITRs need a mechanism to be aware of the liveness >>>> of all ETRs serving their site. >>>> >>>> o MTU within the site network must be large enough to accommodate >>>> encapsulated packets. >>>> >>>> o In this scenario, each ITR is serving fewer hosts than in the case >>>> when it is deployed at the border of the network. It has been >>>> shown that cache hit ratio grows logarithmically with the amount >>>> of users [cache]. Taking this into account, when ITRs are >>>> deployed closer to the host the effectiveness of the mapping cache >>>> may be lower (i.e., the miss ratio is higher). Another >>>> consequence of this is that the site may transmit a higher amount >>>> of Map-Requests, increasing the load on the distributed mapping >>>> database. >>>> >>> one possible solution is to aggregate Map-Requests with a hierarchy >>> (à-la DDT). >> You mean having site-local caching Map-Resolvers? > yes, or regional ok. >>>> 2.4. Inter-Service Provider Traffic Engineering >>>> >>>> With LISP, two LISP sites can route packets among them and control >>>> their ingress TE policies. Typically, LISP is seen as applicable to >>>> stub networks, however the LISP protocol can also be applied to >>>> transit networks recursively. >>>> >>>> Consider the scenario depicted in Figure 4. Packets originating from >>>> the LISP site Stub1, client of ISP_A, with destination Stub4, client >>>> of ISP_B, are LISP encapsulated at their entry point into the ISP_A's >>>> network. The external IP header now has as the source RLOC an IP >>>> from ISP_A's address space and destination RLOC from ISP_B's address >>>> space. One or more ASes separate ISP_A from ISP_B. With a single >>>> level of LISP encapsulation, Stub4 has control over its ingress >>>> traffic. However, at the time of this writing, ISP_B has only BGP >>>> tools (such as prefix deaggregation) to control on which of his own >>>> upstream or peering links should packets enter. This is either not >>>> feasible (if fine-grained per-customer control is required, the very >>>> specific prefixes may not be propagated) or increases DFZ table size. >>>> >>>> _.--. >>>> Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3 >>>> \ | R_A1|----,' `. ---|R_B1 | / >>>> --| R_A2|---( Transit ) | |-- >>>> Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4 >>>> +-------+ `--. _.-' +-------+ >>>> ... ISP_A `--'' ISP_B ... >>>> >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 8] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> Figure 4: Inter-Service provider TE scenario >>>> >>>> A solution for this is to apply LISP recursively. ISP_A and ISP_B >>>> may reach a bilateral agreement to deploy their own private mapping >>>> system. ISP_A then encapsulates packets destined for the prefixes of >>>> ISP_B, which are listed in the shared mapping system. Note that in >>>> this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3 >>>> as source and R_B1 or R_B2 as destination in the example above). >>>> ISP_B's ETR removes the outer, second layer of LISP encapsulation >>>> from the incoming packet, and routes it towards the original RLOC, >>>> the ETR of Stub4, which does the final decapsulation. >>>> >>> if there is bilateral agreement, could we imagine single encapsulation >>> and use instance-id >>> to differentiate with the "source" able to install mappings at the >>> second tier? >> I think this would remove the elegance of the LISP solution by going >> back to MPLS style LSPs. But it may be a solution preferred by some, >> choice is good, so I'll mention it ;) >> > If LISP can be used to implement MPLS, it is a strength of LISP :-D > >>>> If ISP_A and ISP_B agree to share a private distributed mapping >>>> database, both can control their ingress TE without the need of >>>> deaggregating prefixes. In this scenario the private database >>>> contains RLOC-to-RLOC bindings. The convergence time on the TE >>>> policies updates is expected to be fast, since ISPs only have to >>>> update/query a mapping to/from the database. >>> but convergence is O(TTL) or then specify to use SMR or Versioning >> Maybe we should spell that out it the document, but we expected the >> usual LISP mechanism for keeping mappings up to date (SMR/Versioning) >> will be used. > right, but it is good to keep in mind that it might not be possible to get > sub-second or sub-50ms resiliency with LISP. At least with the current > specifications. However, we are currently working on it and I am > convinced that we will be able to react as fast just with good deployment > and configuration. > >>>> This deployment scenario includes two important caveats. First, it >>>> is intended to be deployed between only two ISPs (ISP_A and ISP_B in >>>> Figure 4). If more than two ISPs use this approach, then the xTRs >>>> deployed at the participating ISPs must either query multiple mapping >>>> systems, or the ISPs must agree on a common shared mapping system. >>>> Second, the scenario is only recommended for ISPs providing >>>> connectivity to LISP sites, such that source RLOCs of packets to be >>>> reencapsulated belong to said ISP. Otherwise the participating ISPs >>>> must register prefixes they do not own in the above mentioned private >>>> mapping system. Failure to follow these recommendations may lead to >>>> operational and security issues when deploying this scenario. >>>> >>>> Besides these recommendations, the main disadvantages of this >>>> deployment case are: >>>> >>>> o Extra LISP header is needed. This increases the packet size and >>>> requires that the MTU between both ISPs accommodates double- >>>> encapsulated packets. >>>> >>>> o The ISP ITR must encapsulate packets and therefore must know the >>>> RLOC-to-RLOC binding. These bindings are stored in a mapping >>>> database and may be cached in the ITR's mapping cache. Cache >>>> misses lead to an additional lookup latency, unless a push based >>>> mapping system is used for the private mapping system. >>>> >>>> o The operational overhead of maintaining the shared mapping >>>> database. >>>> >>>> >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 9] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> o If an IPv6 address block is reserved for EID use, as specified in >>>> [I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first >>>> level) can avoid LISP processing altogether for non-LISP >>>> destinations. The ISP tunnel routers however will not be able to >>>> take advantage of this optimization, all RLOC-to-RLOC mappings >>>> need a lookup in the private database (or map-cache, once results >>>> are cached). >>>> >>>> 2.5. Tunnel Routers Behind NAT >>>> >>>> NAT in this section refers to IPv4 network address and port >>>> translation. >>>> >>>> 2.5.1. ITR >>>> >>>> Packets encapsulated by an ITR are just UDP packets from a NAT >>>> device's point of view, and they are handled like any UDP packet, >>>> there are no additional requirements for LISP data packets. >>>> >>>> Map-Requests sent by an ITR, which create the state in the NAT table, >>>> have a different 5-tuple in the IP header than the Map-Reply >>>> generated by the authoritative ETR. Since the source address of this >>>> packet is different from the destination address of the request >>>> packet, no state will be matched in the NAT table and the packet will >>>> be dropped. To avoid this, the NAT device has to do the following: >>>> >>>> o Send all UDP packets with source port 4342, regardless of the >>>> destination port, to the RLOC of the ITR. The most simple way to >>>> achieve this is configuring 1:1 NAT mode from the external RLOC of >>>> the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer >>>> broadband routers). >>>> >>>> o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in >>>> the payload. >>>> >>>> This setup supports a single ITR behind the NAT device. >>>> >>>> 2.5.2. ETR >>>> >>>> An ETR placed behind NAT is reachable from the outside by the >>>> Internet-facing locator of the NAT device. It needs to know this >>>> locator (and configure a loopback interface with it), so that it can >>>> use it in Map-Reply and Map-Register messages. Thus support for >>>> dynamic locators for the mapping database is needed in LISP >>>> equipment. >>>> >>>> Again, only one ETR behind the NAT device is supported. >>>> >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 10] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> An implication of the issues described above is that LISP sites with >>>> xTRs can not be behind carrier based NATs, since two different sites >>>> would collide on the port forwarding. >>>> >>>> 2.6. Summary and Feature Matrix >>>> >>>> Feature CE PE Split Rec. >>>> -------------------------------------------------------- >>>> Control of ingress TE x - x x >>>> No modifications to existing >>>> int. network infrastructure x x - - >>>> Loc-Status-Bits sync x - x x >>>> MTU/PMTUD issues minimized - x - x >>>> >>> Does Rec. mean recursive? if so, make it explicit >> Yes, will do. >> >>>> 3. Map-Resolvers and Map-Servers >>>> >>>> 3.1. Map-Servers >>>> >>> s/Map-Server/Map Server/ga >> Thanks, will do. >> >>>> The Map-Server learns EID-to-RLOC mapping entries from an >>>> authoritative source and publishes them in the distributed mapping >>>> database. These entries are learned through authenticated Map- >>>> Register messages sent by authoritative ETRs. Also, upon reception >>>> of a Map-Request, the Map-Server verifies that the destination EID >>>> matches an EID-prefix for which it is authoritative for, and then re- >>>> encapsulates and forwards it to a matching ETR. Map-Server >>>> functionality is described in detail in [I-D.ietf-lisp-ms]. >>>> >>>> The Map-Server is provided by a Mapping Service Provider (MSP). A >>>> MSP can be any of the following: >>>> >>>> o EID registrar. Since the IPv4 address space is nearing >>>> exhaustion, IPv4 EIDs will come from already allocated Provider >>>> Independent (PI) space. The registrars in this case remain the >>>> current five Regional Internet Registries (RIRs). In the case of >>>> IPv6, the possibility of reserving a /16 block as EID space is >>>> currently under consideration [I-D.ietf-lisp-eid-block]. If >>>> granted by IANA, the community will have to determine the body >>>> responsible for allocations from this block, and the associated >>>> policies. Existing allocation policies apply to EIDs outside this >>>> block. >>>> >>>> o Third parties. Participating in the LISP mapping system is >>>> similar to participating in global routing or DNS: as long as >>>> there is at least another already participating entity willing to >>>> forward the newcomer's traffic, there is no barrier to entry. >>>> Still, just like routing and DNS, LISP mappings have the issue of >>>> trust, with efforts underway to make the published information >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 11] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> verifiable. When these mechanisms will be deployed in the LISP >>>> mapping system, the burden of providing and verifying trust should >>>> be kept away from MSPs, which will simply host the secured >>>> mappings. This will keep the low barrier of entry to become an >>>> MSP for third parties. >>>> >>>> In all cases, the MSP configures its Map-Server(s) to publish the >>>> prefixes of its clients in the distributed mapping database and start >>>> encapsulating and forwarding Map-Requests to the ETRs of the AS. >>>> These ETRs register their prefix(es) with the Map-Server(s) through >>>> periodic authenticated Map-Register messages. In this context, for >>>> some LISP end sites, there is a need for mechanisms to: >>>> >>> how periodic (suggestion of good timers)? >> The Map Server interface draft has some authoritative text on this, we I >> didn't discuss it here: >> >> Map-Register messages are sent periodically from an ETR to a Map >> Server with a suggested interval between messages of one minute. A >> Map Server should time-out and remove an ETR's registration if it has >> not received a valid Map-Register message within the past three >> minutes. When first contacting a Map Server after restart or changes >> to its EID-to-RLOC database mappings, an ETR may initially send Map- >> Register messages at an increased frequency, up to one every 20 >> seconds. This "quick registration" period is limited to five minutes >> in duration. >> >> Maybe add a pointer to the MS draft? > yes with a sentence like. "More details can be fond in []..." ok. > >> >> >>>> o Automatically distribute EID prefix(es) shared keys between the >>>> ETRs and the EID-registrar Map-Server. >>>> >>>> o Dynamically obtain the address of the Map-Server in the ETR of the >>>> AS. >>>> >>>> The Map-Server plays a key role in the reachability of the EID- >>>> prefixes it is serving. On the one hand it is publishing these >>>> prefixes into the distributed mapping database and on the other hand >>>> it is encapsulating and forwarding Map-Requests to the authoritative >>>> ETRs of these prefixes. ITRs encapsulating towards EIDs under the >>>> responsibility of a failed Map-Server will be unable to look up any >>>> of their covering prefixes. The only exception are the ITRs that >>>> already contain the mappings in their local cache. In this case ITRs >>>> can reach ETRs until the entry expires (typically 24 hours). >>> where does the "typically 24h" come from? >> Initial popular Beta network configurations. Should we remove the >> parenthesis? >> > the question was more general: why 24h has been chosen. I will let those that chose this TTL to chime in :P Would it be better to just remove the parentheses as it may not be true in the future? > > >>>> For >>>> this reason, redundant Map-Server deployments are desirable. A set >>>> of Map-Servers providing high-availability service to the same set of >>>> prefixes is called a redundancy group. ETRs are configured to send >>>> Map-Register messages to all Map-Servers in the redundancy group. To >>>> achieve fail-over (or load-balancing, if desired), >>>> known mapping >>>> system specific best practices should be used. >>>> >>> what is meant by this very sentence? >> If we were to use ALT, use BGP best practices, if we were to use DDT, >> which has a similar design to DDT > DNS :-D >> , use applicable DNS best practices. >> > ok > >>>> Additionally, if a Map-Server has no reachability for any ETR serving >>>> a given EID block, it should not originate that block into the >>>> mapping system. >>> why? >> It doesn't receive Map-Registers, so it doesn't have up to date >> information, and the registration will time out (based on an >> implementation specific timer). Returning forward-native may be the best >> choice here, because packets to the ETRs may still find their way >> through PITRs if it's only the MS that lost reachability and there is >> another MS in the redundancy group. > ok >>>> 3.2. Map-Resolvers >>>> >>> s/Map-Resolver/Map Resolver/ga >> Thanks, will do. >> >>>> A Map-Resolver a is a network infrastructure component which accepts >>>> LISP encapsulated Map-Requests, typically from an ITR, and finds the >>>> appropriate EID-to-RLOC mapping by either consulting its local cache >>>> or by consulting the distributed mapping database. Map-Resolver >>>> functionality is described in detail in [I-D.ietf-lisp-ms]. >>>> >>>> Anyone with access to the distributed mapping database can set up a >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 12] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> Map-Resolver and provide EID-to-RLOC mapping lookup service. >>>> Database access setup is mapping system specific. >>>> >>>> For performance reasons, it is recommended that LISP sites use Map- >>>> Resolvers that are topologically close to their ITRs. ISPs >>>> supporting LISP will provide this service to their customers, >>>> possibly restricting access to their user base. LISP sites not in >>>> this position can use open access Map-Resolvers, if available. >>>> However, regardless of the availability of open access resolvers, the >>>> MSP providing the Map-Server(s) for a LISP site should also make >>>> available Map-Resolver(s) for the use of that site. >>>> >>>> In medium to large-size ASes, ITRs must be configured with the RLOC >>>> of a Map-Resolver, operation which can be done manually. However, in >>>> Small Office Home Office (SOHO) scenarios a mechanism for >>>> autoconfiguration should be provided. >>>> >>>> One solution to avoid manual configuration in LISP sites of any size >>>> is the use of anycast RLOCs for Map-Resolvers similar to the DNS root >>>> server infrastructure. Since LISP uses UDP encapsulation, the use of >>>> anycast would not affect reliability. >>> maybe change the term reliability because anycast actually improves >>> reliability, isnt'it? >> You are right. Reliability here was used as a comparison to TCP over >> anycast, which can be unstable. How about "Since LISP control traffic >> is UDP based, using anycast would improve reliability." ? > ok >>>> LISP routers are then shipped >>>> with a preconfigured list of well know Map-Resolver RLOCs, which can >>>> be edited by the network administrator, if needed. >>>> >>>> The use of anycast also helps improving mapping lookup performance. >>>> Large MSPs can increase the number and geographical diversity of >>>> their Map-Resolver infrastructure, using a single anycasted RLOC. >>>> Once LISP deployment is advanced enough, very large content providers >>>> may also be interested running this kind of setup, to ensure minimal >>>> connection setup latency for those connecting to their network from >>>> LISP sites. >>>> >>>> While Map-Servers and Map-Resolvers implement different >>>> functionalities within the LISP mapping system, they can coexist on >>>> the same device. For example, MSPs offering both services, can >>>> deploy a single Map-Resolver/Map-Server in each PoP where they have a >>>> presence. >>>> >>>> >>>> 4. Proxy Tunnel Routers >>>> >>>> 4.1. P-ITR >>>> >>>> Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP >>>> transition mechanism, allowing non-LISP sites to reach LISP sites. >>>> They announce via BGP certain EID prefixes (aggregated, whenever >>>> possible) to attract traffic from non-LISP sites towards EIDs in the >>>> covered range. They do the mapping system lookup, and encapsulate >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 13] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> received packets towards the appropriate ETR. Note that for the >>>> reverse path LISP sites can reach non-LISP sites simply by not >>>> encapsulating traffic. See [I-D.ietf-lisp-interworking] for a >>>> detailed description of P-ITR functionality. >>>> >>>> The success of new protocols depends greatly on their ability to >>>> maintain backwards compatibility and inter-operate with the >>>> protocol(s) they intend to enhance or replace, and on the incentives >>>> to deploy the necessary new software or equipment. A LISP site needs >>>> an interworking mechanism to be reachable from non-LISP sites. A >>>> P-ITR can fulfill this role, enabling early adopters to see the >>>> benefits of LISP, similar to tunnel brokers helping the transition >>>> from IPv4 to IPv6. A site benefits from new LISP functionality >>>> (proportionally with existing global LISP deployment) when going >>>> LISP, so it has the incentives to deploy the necessary tunnel >>>> routers. In order to be reachable from non-LISP sites it has two >>>> options: keep announcing its prefix(es) with BGP, or have a P-ITR >>>> announce prefix(es) covering them. >>>> >>>> If the goal of reducing the DFZ routing table size is to be reached, >>>> the second option is preferred. Moreover, the second option allows >>>> LISP-based ingress traffic engineering from all sites. However, the >>>> placement of P-ITRs significantly influences performance and >>>> deployment incentives. Section 5 is dedicated to the migration to a >>>> LISP-enabled Internet, and includes deployment scenarios for P-ITRs. >>>> >>>> 4.2. P-ETR >>>> >>>> In contrast to P-ITRs, P-ETRs are not required for the correct >>>> functioning of all LISP sites. There are two cases, where they can >>>> be of great help: >>>> >>>> o LISP sites with unicast reverse path forwarding (uRPF) >>>> restrictions, and >>>> >>>> o Communication between sites using different address family RLOCs. >>>> >>>> In the first case, uRPF filtering is applied at their upstream PE >>>> router. When forwarding traffic to non-LISP sites, an ITR does not >>>> encapsulate packets, leaving the original IP headers intact. As a >>>> result, packets will have EIDs in their source address. Since we are >>>> discussing the transition period, we can assume that a prefix >>>> covering the EIDs belonging to the LISP site is advertised to the >>>> global routing tables by a P-ITR, and the PE router has a route >>>> towards it. However, the next hop will not be on the interface >>>> towards the CE router, so non-encapsulated packets will fail uRPF >>>> checks. >>>> >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 14] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> To avoid this filtering, the affected ITR encapsulates packets >>>> towards the locator of the P-ETR for non-LISP destinations. Now the >>>> source address of the packets, as seen by the PE router is the ITR's >>>> locator, which will not fail the uRPF check. The P-ETR then >>>> decapsulates and forwards the packets. >>>> >>>> The second use case is IPv4-to-IPv6 transition. Service providers >>>> using older access network hardware, which only supports IPv4 can >>>> still offer IPv6 to their clients, by providing a CPE device running >>>> LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP >>>> sites, with IPv6-only locators. Packets originating from the client >>>> LISP site for these destinations would be encapsulated towards the >>>> P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, >>>> decapsulating and forwarding packets. For non-LISP destination, the >>>> packet travels natively from the P-ETR. For LISP destinations with >>>> IPv6-only locators, the packet will go through a P-ITR, in order to >>>> reach its destination. >>>> >>>> For more details on P-ETRs see the [I-D.ietf-lisp-interworking] >>>> draft. >>>> >>>> P-ETRs can be deployed by ISPs wishing to offer value-added services >>>> to their customers. As is the case with P-ITRs, P-ETRs too may >>>> introduce path stretch. Because of this the ISP needs to consider >>>> the tradeoff of using several devices, close to the customers, to >>>> minimize it, or few devices, farther away from the customers, >>>> minimizing cost instead. >>>> >>>> Since the deployment incentives for P-ITRs and P-ETRs are different, >>>> it is likely they will be deployed in separate devices, except for >>>> the CDN case, which may deploy both in a single device. >>>> >>>> In all cases, the existence of a P-ETR involves another step in the >>>> configuration of a LISP router. CPE routers, which are typically >>>> configured by DHCP, stand to benefit most from P-ETRs. >>>> Autoconfiguration of the P-ETR locator could be achieved by a DHCP >>>> option, or adding a P-ETR field to either Map-Notifys or Map-Replies. >>>> >>>> As a security measure, access to P-ETRs should be limited to >>>> legitimate users by enforcing ACLs. >>>> >>>> >>>> 5. Migration to LISP >>>> >>>> This section discusses a deployment architecture to support the >>>> migration to a LISP-enabled Internet. The loosely defined terms of >>>> "early transition phase", "late transition phase", and "LISP Internet >>>> phase" refer to time periods when LISP sites are a minority, a >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 15] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> majority, or represent all edge networks respectively. >>>> >>>> 5.1. LISP+BGP >>>> >>>> For sites wishing to go LISP with their PI prefix the least >>>> disruptive way is to upgrade their border routers to support LISP, >>>> register the prefix into the LISP mapping system, but keep announcing >>>> it with BGP as well. This way LISP sites will reach them over LISP, >>>> while legacy sites will be unaffected by the change. The main >>>> disadvantage of this approach is that no decrease in the DFZ routing >>>> table size is achieved. Still, just increasing the number of LISP >>>> sites is an important gain, as an increasing LISP/non-LISP site ratio >>>> will slowly decrease the need for BGP-based traffic engineering that >>>> leads to prefix deaggregation. That, in turn, may lead to a decrease >>>> in the DFZ size in the late transition phase. >>> and potentially the churn (except maybe because of PITR) >> Thanks, will mention that. Even with PITRs, churn should be reduced, >> sice they are supposed to announce the aggregates. >> >>>> This scenario is not limited to sites that already have their >>>> prefixes announced with BGP. Newly allocated EID blocks could follow >>>> this strategy as well during the early LISP deployment phase, >>>> depending on the cost/benefit analysis of the individual networks. >>>> Since this leads to an increase in the DFZ size, the following >>>> architecture should be preferred for new allocations. >>>> >>>> 5.2. Mapping Service Provider (MSP) P-ITR Service >>>> >>>> In addition to publishing their clients' registered prefixes in the >>>> mapping system, MSPs with enough transit capacity can offer them >>>> P-ITR service as a separate service. This service is especially >>>> useful for new PI allocations, to sites without existing BGP >>>> infrastructure, that wish to avoid BGP altogether. The MSP announces >>>> the prefix into the DFZ, and the client benefits from ingress traffic >>>> engineering without prefix deaggregation. The downside of this >>>> scenario is adding path stretch. >>>> >>>> Routing all non-LISP ingress traffic through a third party which is >>>> not one of its ISPs is only feasible for sites with modest amounts of >>>> traffic (like those using the IPv6 tunnel broker services today), >>>> especially in the first stage of the transition to LISP, with a >>>> significant number of legacy sites. When the LISP/non-LISP site >>>> ratio becomes high enough, this approach can prove increasingly >>>> attractive. >>>> >>>> Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix >>>> deaggregation for traffic engineering purposes, resulting in slower >>>> routing table increase in the case of new allocations and potential >>>> decrease for existing ones. Moreover, MSPs serving different clients >>>> with adjacent aggregable prefixes may lead to additional decrease, >>>> but quantifying this decrease is subject to future research study. >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 16] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> 5.3. Proxy-ITR Route Distribution (PITR-RD) >>>> >>>> Instead of a LISP site, or the MSP, announcing their EIDs with BGP to >>>> the DFZ, this function can be outsourced to a third party, a P-ITR >>>> Service Provider (PSP). This will result in a decrease of the >>>> operational complexity both at the site and at the MSP. >>>> >>>> The PSP manages a set of distributed P-ITR(s) that will advertise the >>>> corresponding EID prefixes through BGP to the DFZ. These P-ITR(s) >>>> will then encapsulate the traffic they receive for those EIDs towards >>>> the RLOCs of the LISP site, ensuring their reachability from non-LISP >>>> sites. >>>> >>>> While it is possible for a PSP to manually configure each client's >>>> EID routes to be announced, this approach offers little flexibility >>>> and is not scalable. This section presents a scalable architecture >>>> that offers automatic distribution of EID routes to LISP sites and >>>> service providers. >>>> >>>> The architecture requires no modification to existing LISP network >>>> elements, but it introduces a new (conceptual) network element, the >>>> EID Route Server, defined as a router that either propagates routes >>>> learned from other EID Route Servers, or it originates EID Routes. >>>> The EID-Routes that it originates are those that it is authoritative >>>> for. It propagates these routes to Proxy-ITRs within the AS of the >>>> EID Route Server. It is worth to note that a BGP capable router can >>>> be also considered as an EID Route Server. >>>> >>>> Further, an EID-Route is defined as a prefix originated via the Route >>>> Server of the mapping service provider, which should be aggregated if >>>> the MSP has multiple customers inside a single netblock. >>> define netblock >> s/netblock/prefix/ >> > ok > >>>> This prefix >>>> is propagated to other P-ITRs both within the MSP and to other P-ITR >>>> operators it peers with. EID Route Servers are operated either by >>>> the LISP site, MSPs or PSPs, and they may be collocated with a Map- >>>> Server or P-ITR, but are a functionally discrete entity. They >>>> distribute EID-Routes, using BGP, to other domains, according to >>>> policies set by participants. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 17] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> MSP (AS64500) >>>> RS ---> P-ITR >>>> | / >>>> | _.--./ >>>> ,-'' /`--. >>>> LISP site ---,' | v `. >>>> ( | DFZ )----- Mapping system >>>> non-LISP site ----. | ^ ,' >>>> `--. / _.-' >>>> | `--'' >>>> v / >>>> P-ITR >>>> PSP (AS64501) >>>> >>>> Figure 5: The P-ITR Route Distribution architecture >>>> >>>> The architecture described above decouples EID origination from route >>>> propagation, with the following benefits: >>>> >>>> o Can accurately represent business relationships between P-ITR >>>> operators >>>> >>>> o More mapping system agnostic >>>> >>>> o Minor changes to P-ITR implementation, no changes to other >>>> components >>>> >>>> In the example in the figure we have a MSP providing services to the >>>> LISP site. The LISP site does not run BGP, and gets an EID >>>> allocation directly from a RIR, or from the MSP, who may be a LIR. >>>> Existing PI allocations can be migrated as well. The MSP ensures the >>>> presence of the prefix in the mapping system, and runs an EID Route >>>> Server to distribute it to P-ITR service providers. Since the LISP >>>> site does not run BGP, the prefix will be originated with the AS >>>> number of the MSP. >>>> >>>> In the simple case depicted in Figure 5 the EID-Route of LISP Site >>>> will be originated by the Route Server, and announced to the DFZ by >>>> the PSP's P-ITRs with AS path 64501 64500. From that point on, the >>>> usual BGP dynamics apply. This way, routes announced by P-ITR are >>>> still originated by the authoritative Route Server. Note that the >>>> peering relationships between MSP/PSPs and those in the underlying >>>> forwarding plane may not be congruent, making the AS path to a P-ITR >>>> shorter than it is in reality. >>>> >>>> The non-LISP site will select the best path towards the EID-prefix, >>>> according to its local BGP policies. Since AS-path length is usually >>>> an important metric for selecting paths, a careful placement of P-ITR >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 18] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> could significantly reduce path-stretch between LISP and non-LISP >>>> sites. >>>> >>>> The architecture allows for flexible policies between MSP/PSPs. >>>> Consider the EID Route Server networks as control plane overlays, >>>> facilitating the implementation of policies necessary to reflect the >>>> business relationships between participants. The results are then >>>> injected to the common underlying forwarding plane. For example, >>>> some MSP/PSPs may agree to exchange EID-Prefixes and only announce >>>> them to each of their forwarding plane customers. Global >>>> reachability of an EID-prefix depends on the MSP the LISP site buys >>>> service from, and is also subject to agreement between the mentioned >>>> parties. >>>> >>>> In terms of impact on the DFZ, this architecture results in a slower >>>> routing table increase for new allocations, since traffic engineering >>>> will be done at the LISP level. For existing allocations migrating >>>> to LISP, the DFZ may decrease since MSPs may be able to aggregate the >>>> prefixes announced. >>>> >>>> Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix >>>> deaggregation for traffic engineering purposes, resulting in slower >>>> routing table increase in the case of new allocations and potential >>>> decrease for existing ones. Moreover, MSPs serving different clients >>>> with adjacent aggregable prefixes may lead to additional decrease, >>>> but quantifying this decrease is subject to future research study. >>>> >>>> The flexibility and scalability of this architecture does not come >>>> without a cost however: A PSP operator has to establish either >>>> transit or peering relationships to improve their connectivity. >>> What's happening when sites have to change their EID? for example >>> after a network merge. >>> >>>> 5.4. Migration Summary >>>> >>>> The following table presents the expected effects of the different >>>> transition scenarios during a certain phase on the DFZ routing table >>>> size: >>>> >>>> Phase | LISP+BGP | MSP P-ITR | PITR-RD >>>> -----------------+--------------+-----------------+---------------- >>>> Early transition | no change | slower increase | slower increase >>>> Late transition | may decrease | slower increase | slower increase >>>> LISP Internet | considerable decrease >>>> >>> The "considerable decrease" depends on where LISP is deployed, if it >>> is very close to the >>> hosts, maybe it would not be so considerable. >> We assumed deployment on leaf AS border routers. > maybe make it explicit here It was stated in Section 2.1, you think we should repeat it here? > >>>> It is expected that PITR-RD will co-exist with LISP+BGP during the >>>> migration, with the latter being more popular in the early transition >>>> phase. As the transition progresses and the MSP P-ITR and PITR-RD >>>> ecosystem gets more ubiquitous, LISP+BGP should become less >>>> attractive, slowing down the increase of the number of routes in the >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 19] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> DFZ. >>>> >>>> >>>> 6. Step-by-Step Example BGP to LISP Migration Procedure >>>> >>>> 6.1. Customer Pre-Install and Pre-Turn-up Checklist >>>> >>>> 1. Determine how many current physical service provider connections >>>> the customer has and their existing bandwidth and traffic >>>> engineering requirements. >>>> >>>> This information will determine the number of routing locators, >>>> and the priorities and weights that should be configured on the >>>> xTRs. >>>> >>>> 2. Make sure customer router has LISP capabilities. >>>> >>>> * Obtain output of 'show version' from the CE router. >>>> >>> too Cisco ;-) >>> uname -a is another way :-D >> Agreed :) >> >>>> This information can be used to determine if the platform is >>>> appropriate to support LISP, in order to determine if a >>>> software and/or hardware upgrade is required. >>>> >>>> * Have customer upgrade (if necessary, software and/or hardware) >>>> to be LISP capable. >>>> >>>> 3. Obtain current running configuration of CE router. A suggested >>>> LISP router configuration example can be customized to the >>>> customer's existing environment. >>>> >>>> 4. Verify MTU Handling >>>> >>>> * Request increase in MTU to (1556) >>> why parenthesis? >> Typo, will fix. >> >>>> on service provider >>>> connections. Prior to MTU change verify that 1500 byte packet >>>> from P-xTR to RLOC with do not fragment (DF-bit) bit set. >>>> >>>> * Ensure they are not filtering ICMP unreachable or time- >>>> exceeded on their firewall or router. >>>> >>>> LISP, like any tunneling protocol, will increase the size of >>>> packets when the LISP header is appended. If increasing the MTU >>>> of the access links is not possible, care must be taken that ICMP >>>> is not being filtered in order to allow for Path MTU Discovery to >>>> take place. >>>> >>>> 5. Validate member prefix allocation. >>>> >>>> This step is to check if the prefix used by the customer is a >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 20] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> direct (Provider Independent), or if it is a prefix assigned by a >>>> physical service provider (Provider Allocated). >>> I always thought PA meant "Provider Aggregatable". >> Will change, since according to a quick Google search "Provider >> Aggregatable" address space is more common, but we've seen "Provider >> Allocated" used quite often as well. >> >>>> If the prefixes >>>> are assigned by other service provivers then a Letter of >>>> Agreement is required to announce prefixes through the Proxy >>>> Service Provider. >>>> >>>> 6. Verify the member RLOCs and their reachability. >>>> >>>> This step ensures that the RLOCs configured on the CE router are >>>> in fact reachable and working. >>>> >>>> 7. Prepare for cut-over. >>>> >>>> * If possible, have a host outside of all security and filtering >>>> policies connected to the console port of the edge router or >>>> switch. >>>> >>>> * Make sure customer has access to the router in order to >>>> configure it. >>>> >>>> 6.2. Customer Activating LISP Service >>>> >>>> 1. Customer configures LISP on CE router(s) from service provider >>>> recommended configuration. >>>> >>>> The LISP configuration consists of the EID prefix, the locators, >>>> and the weights and priorities of the mapping between the two >>>> values. In addition, the xTR must be configured with Map- >>>> Resolver(s), Map-Server(s) and the shared key for registering to >>>> Map-Server(s). If required, Proxy-ETR(s) may be configured as >>>> well. >>>> >>>> In addition to the LISP configuration, the following: >>>> >>>> * Ensure default route(s) to next-hop external neighbors are >>>> included and RLOCs are present in configuration. >>>> >>>> * If two or more routers are used, ensure all RLOCs are included >>>> in the LISP configuration on all routers. >>>> >>>> * It will be necessary to redistribute default route via IGP >>>> between the external routers. >>>> >>>> 2. When transition is ready perform a soft shutdown on existing eBGP >>>> peer session(s) >>>> >>>> * From CE router, use LIG to ensure registration is successful. >>>> >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 21] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>>> >>>> * To verify LISP connectivity, ping LISP connected sites. See >>>> http://www.lisp4.net/ and/or http://www.lisp6.net/ for >>>> potential candidates. >>>> >>>> * To verify connectivity to non-LISP sites, try accessing >>> a landmark (e.g., a >>>> major >>>> Internet sites via a web browser. >>> ). >> I had some input on this from Paul Vinciguerra as well, will have to >> expand a bit on this. >> >>>> 6.3. Cut-Over Provider Preparation and Changes >>>> >>>> 1. Verify site configuration and then active registration on Map- >>>> Server(s) >>>> >>>> * Authentication key >>>> >>>> * EID prefix >>>> >>>> 2. Add EID space to map-cache on proxies >>>> >>>> 3. Add networks to BGP advertisement on proxies >>>> >>>> * Modify route-maps/policies on P-xTRs >>>> >>>> * Modify route policies on core routers (if non-connected >>>> member) >>>> >>>> * Modify ingress policers on core routers >>>> >>>> * Ensure route announcement in looking glass servers, RouteViews >>>> >>>> 4. Perform traffic verification test >>>> >>>> * Ensure MTU handling is as expected (PMTUD working) >>>> >>>> * Ensure proxy-ITR map-cache population >>>> >>>> * Ensure access from traceroute/ping servers around Internet >>>> >>>> * Use a looking glass, to check for external visibility of >>>> registration via several Map-Resolvers (e.g., >>>> http://lispmon.net/). >>>> >>>> >>>> 7. Security Considerations >>>> >>>> Security implications of LISP deployments are to be discussed in >>>> separate documents. [I-D.saucez-lisp-security] >>> draft-ietf-lisp-threats-03 >> Thanks, will fix. >> >>>> gives an overview of >>>> LISP threat models, while securing mapping lookups is discussed in >>>> [I-D.ietf-lisp-sec]. >>>> >>>> >>>> >>>> Jakab, et al. Expires April 23, 2013 [Page 22] >>>> >>>> Internet-Draft LISP Deployment October 2012 >>>> >>> [snip] >>> >>> Damien Saucez >> Thanks again for the great review Damien! >> >> -Lori > Cheers, > > Damien Saucez -Lori > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
