Hi Dino Thanks for your comments, please find below our answers:
On Fri, Sep 26, 2014 at 9:01 PM, Dino Farinacci <[email protected]> wrote: >> We´ll gather more feedback and produce a new version before cut-off, >> please review and comment ASAP. > > Thanks Albert and Damien for pulling a multitude of comments together to get > this draft out. Here are my comments on -05. Your text comes first and is > indented and my comments follow. > > There are places in the spec where the text is just blantantly wrong. I have > commented on those and offered the truth and contributed text. ;-) > >> An Architectural Introduction to the LISP Location-Identity Separation >> System >> draft-ietf-lisp-introduction-05.txt > > To not have too many variations of titling LISP, could this title simply be: > > An Architectural Introduction to the Locator/ID Separation Protocol > (LISP) > >> Ok >> Abstract >> >> This document describes the Locator/ID Separation Protocol (LISP) >> architecture, its main operational mechanisms as well as its design >> rationale. > > I would add "This document is used for introduction purposes. More detail is > available in the protocol specifications which are references in this > introduciton document". > > What do you think? > Since other people have similar issues with the abstract I´ll send –in a separate email- a new version to see if we can agree. >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4 >> 2.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4 >> 2.2. Overview of the Architecture . . . . . . . . . . . . . . 4 >> 2.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 7 >> 2.3.1. LISP encapsulation . . . . . . . . . . . . . . . . . 7 > > Capitalize Encapsulation. > >> 2.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 8 >> 2.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 9 >> 2.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 9 >> 2.4.2. Mapping System Interface . . . . . . . . . . . . . . 9 >> 2.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 10 >> 2.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 13 >> 3. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 13 >> 3.1. Cache Management . . . . . . . . . . . . . . . . . . . . 14 >> 3.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 14 >> 3.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 15 >> 3.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 16 >> 4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 16 >> 5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 17 >> 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 17 >> 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 18 >> 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 18 >> 7.2. LISP for IPv6 Transition . . . . . . . . . . . . . . . . 19 > > Could you title it "IPv6 Co-Existence"? > Ok. >> 7.3. LISP for Network Virtualization . . . . . . . . . . . . . 19 >> 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 20 > > These two look two similar. Should 7.3 just say LISP for Virtual Private > Networks? > Ok. >> 1. Introduction >> >> There is a rough consensus that the Internet routing and addressing >> system is facing severe scalability issues [RFC4984]. Specifically, >> the growth in the size of the routing tables of the Default-Free Zone >> (DFZ) is accelerating and showing a supra-linear slope [DFZ]. The > > Change "supra" to "super". But saying super-linear is like saying "that was a > long minute". ;-) I think you should say exponential slope. > I think that the correct mathematical term is supralinear: http://en.wiktionary.org/wiki/supralinear >> main driving force behind this growth is the de-aggregation of BGP >> prefixes, which results from the existing BGP multihoming and traffic >> engineering mechanisms that are used -at the time of this writing- on >> the Internet, as well as non-aggregatable address allocations. >> >> This issue has two profound implications, on the one hand Internet >> core routers are exposed to the network dynamics of the edge. For >> instance this typically leads to an increased amount of BGP UPDATE >> messages (churn), which results in additional processing requirements >> of Internet core routers in order to timely compute the DFZ RIB. >> Secondly, the supra-linear growth imposes strong requirements on the >> size of the memory storing the DFZ FIB. Both aspects lead to an >> increase on the development and production cost of high-end routers, >> and it is unclear if the semiconductor and router manufacturer >> industries will be able to cope, in the long-term, with such >> stringent requirements in a cost-effective way[RFC4984]. > > I think this is way too detail to be the first text in the Introduction > section. > See my comment below. >> >> Although this important scalability issue is relatively new, the >> architectural reasons behind it are well-known many years ago. >> Indeed, and as pointed out by [Chiappa], IP addresses have overloaded >> semantics. Currently, IP addresses both identify the topological >> location of a network attachment point as well as the node's >> identity. However, nodes and routing have fundamentally different >> requirements, routing systems require that addresses are aggregatable >> and have topological meaning, while nodes require to be identified >> independently of their current location. >> >> The Locator/ID Separation Protocol (LISP), specified in [RFC6830], is >> built on top of this basic idea: decoupling the IP address overloaded >> semantics. LISP creates two separate namespaces, EIDs (End-host > > I think you should start the intro describing the decoupling and how the > decoupling helps keep routes out of the core and allows for various types of > mobility and address portability applications. > Since other people have similar issues with this section I´ll send –in a separate email- a new version to see if we can agree. >> o Locator/Identifier split: By decoupling the overloaded semantics >> of the current IP addresses the Internet core can be assigned with >> topological meaningful address and hence, can use aggregation to >> scale. Devices are assigned with identity meaningful address that >> are independent of its topological location. > > Change to "... are assigned with identity meaninful addresses ..." or "... > are assigned with an identity meaningful address ...". > ok >> endhosts and are assigned and configured by the same mechanisms that > > Change to "end-hosts". ok > >> >> With LISP, LISP sites (edge) and the core of the Internet are inter- >> connected by means of LISP-capable routers (e.g., border routers). >> When they provide egress (from the core perspective) to a LISP site >> they are called Egress Tunnel Routers (ETR), Ingress Tunnel Routers >> (ITR) when they provide ingress, and xTR when they provide both. > > I think this is making the defintion of ITRs and ETRs more confusing then it > needs to be. Just indicate that when a packet leaves a LISP site and is sent > in the direction of the core, it is done by ITRs and when a packet arrives at > a LISP site from the direction of the core, it is done by ETRs. > > It is much easier to understand the terms by "ingressing into the tunnel" and > "egressing from the tunnel". And this would be a good time to introduce the > term "encapsulation" and "decapsulation" so it is presented early that ITRs > encapsulate and ETRs decapsulate. > >> ITRs and ETRs exchange packets by encapsulating them, hence LISP >> operates as an overlay to the current Internet core. > > Well this is technically not true. ITRs encapsulate and ETRs decapsulate. > I´ve rephrased this paragraph, let´s see if this one is better: With LISP, LISP sites (edge) and the core of the Internet are interconnected by means of LISP-capable routers (e.g., border routers) using tunnels. When they ingress packets from the LISP site into the tunnel they are called Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR) when they egress packets from the core to the LISP site and xTR when they can perform both operations. In this context ITRs encapsulate packets while ETRs decapsulate them, hence LISP operates as an overlay to the current Internet core. >> >> 3. ITR_A upon receiving the packet queries the Mapping System to >> retrieve the locator of ETR_B that is servicing hostB. In order > > Change to "... hostB's EID_B ...". Ok. > >> to do so it uses a LISP control message called Map-Request, the >> message contains EID_A as the lookup key, in turn it receives > > EID_B is the lookup key not EID_A. Ok. > >> >> 2.3. Data-Plane >> >> This section describes the LISP data-plane, which is specified in > > How about changing to: "This section provides a high-level descritpion of the > LISP data-plane, which is specified in detail in [RFC6830]. Ok. > >> >> 2.3.1. LISP encapsulation > > Capitalize "Encapsulation". Ok. > >> >> 3. LISP header that may contain reachability information and an >> Instance ID field. This header is originated by ITRs and >> stripped by ETRs. > > I would say "various forwarding-plane features" so you don't limit yourself > and exclude what could be added in the future. > Ok. >> >> 4. Inner IP header containing EIDs as source and destination >> addresses. This header is created by the source end-host and >> remains unchanged. >> >> Finally and in some scenarios Recursive and/or Re-encapsulating >> tunnels can be used for Traffic Engineering and re-routing. Re- >> encapsulating tunnels are consecutive LISP tunnels and occur when an >> ETR removes a LISP header and then acts as an ITR to prepend another >> one. On the other hand, Recursive tunnels are nested tunnels and are >> implemented by using multiple LISP encapsulations on a packet. > > This is a great place to say RTRs perform this ETR and then ITR function. > I´ve rephrased the paragraph to: Finally and in some scenarios Recursive and/or Re-encapsulating tunnels can be used for Traffic Engineering and re-routing. Re-encapsulating tunnels are consecutive LISP tunnels and occur when an ETR removes a LISP header and then acts as an ITR to prepend another one. On the other hand, Recursive tunnels are nested tunnels and are implemented by using multiple LISP encapsulations on a packet. Typically such functions are implemented by Reencapsulating Tunnel Routers (RTRs). >> >> 2.3.2. LISP Forwarding State >> >> ITRs retrieve from the LISP Mapping System mappings between EID >> prefixes and RLOCs that are used to encapsulate packets. Such >> mappings are stored in a local cache -called the Map-Cache- to >> increase the forwarding speed of subsequent packets addressed to the >> same EID prefix. Mappings include a (Time-to-Live) TTL (set by the >> ETR) and are expired according to this value, more details about the >> Map-Cache management can be found in Section 3.1. >> >> >> >> Cabellos & Saucez (Ed.) Expires March 26, 2015 [Page 8] >> Internet-Draft LISP Introduction September 2014 >> >> >> 2.4. Control-Plane >> >> The LISP control-plane, specified in [RFC6833], provides a standard >> interface to register, query, and retrieve mappings. The LISP >> Mapping System, is a publicly accessible database that stores such >> mappings. In what follows we first describe the mappings, then the >> standard interface, and finally the Mapping System architecture. >> >> 2.4.1. LISP Mappings >> >> Each mapping includes the bindings between EID prefix(es) and set of >> RLOCs as well as traffic engineering policies, in the form of >> priorities and weights for the RLOCs. Priorities allow the ETR to >> configure active/backup policies while weights are used to load- >> balance traffic among the RLOCs (on a per-flow basis). >> >> Typical mappings in LISP bind EIDs in the form of IP prefixes with a >> set of RLOCs, also in the form of IPs. Such addresses are encoded > > Change to "such EID and RLOC addresses are encoded ...". > Ok. >> >> 2.4.3.1. LISP+ALT >> >> The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first >> Mapping System proposed, developed and deployed on the LISP pilot >> network. It is based on a distributed BGP overlay. All the >> participating nodes connect to their peers through static tunnels. >> Every ETR involved in the ALT topology advertises its EID prefixes >> making the EID routable on the overlay. > > This is not true. The Map-Server advertises registered EID-prefixes by the > ETR. The Map-Server advertises such EID-prefixes to ALT routers via BGP. Then > Map-Requests can be routed on the ALT topology so an ITR's Map-Request can > get from Map-Resolver, to ALT-router, to ALT-router, then finally the > Map-Server which then can proxy-reply or forward the Map-Request to the ETR > to reply. > > Please fix this paragraph. See my updated paragraph below: The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first Mapping System proposed, developed and deployed on the LISP pilot network. It is based on a distributed BGP overlay participated by Map-Servers and Map-Resolvers. The nodes connect to their peers through static tunnels. Each Map-Server involved in the ALT topology advertises the EID-prefixes registered by the serviced ETRs, making the EID routable on the ALT topology. > >> When an ITR needs a mapping, it sends a Map-Request to a nearby ALT > > Not true. It sends it to a Map-Resolver. > >> router. The ALT routers then forward the Map-Request on the overlay > > Don't use the term overlay here or it will get confused with the LISP > data-plane overlay. Call it the "ALT topology". > >> by inspecting their ALT routing tables. When the Map-Request reaches >> the ETR responsible for the mapping, a Map-Reply is generated and >> directly sent to the ITR's RLOC, without using the ALT overlay. > > That is not true either since the ITR's RLOC is not routed on the ALT > topology. The Map-Reply is sent back directly from ETR to ITR using the > native core Internet network. See my updated paragraph below: When an ITR needs a mapping it sends a Map-Request to a Map-Resolver that, using the ALT topology, forwards the Map-Request towards the Map-Server responsible of the mapping. Upon reception the Map-Server forwards the request to the ETR that in turn, replies directly to the ITR using the native Internet core. > >> >> 2.4.3.2. LISP-DDT >> >> LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a >> hierarchical directory whose internal structure mirrors the >> hierarchical nature of the EID address space. The DDT hierarchy is >> composed of DDT nodes forming a tree structure, the leafs of the tree >> are Map-Servers. On top of the structure there is the DDT root node >> [DDT-ROOT], which is a particular instance of a DDT node and that >> matches the entire address space. As in the case of DNS, DDT >> supports multiple redundant DDT nodes and/or DDT roots. The >> following figure presents a schematic representation of the DDT >> hierarchy. > > Since you brought up Map-Servers here at this point, you should say that > Map-Resolvers have access to the DDT-ROOT and other DDT-nodes for sending > queries to the mapping system. > See my updated paragraph below: LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a hierarchical directory whose internal structure mirrors the hierarchical nature of the EID address space. The DDT hierarchy is composed of DDT nodes forming a tree structure, the leafs of the tree are Map-Servers. On top of the structure there is the DDT root node [DDT-ROOT], which is a particular instance of a DDT node and that matches the entire address space. As in the case of DNS, DDT supports multiple redundant DDT nodes and/or DDT roots. Finally, Map-Resolvers are the clients of the DDT hierarchy and can query either the DDT root and/or other DDT nodes. The following figure presents a schematic representation of the DDT hierarchy. >> >> In order to resolve a query LISP-DDT operates iteratively and in a >> similar way to the DNS. DDT clients (usually Map-Resolvers) generate > > It may worth saying that DDT does not do recursive lookups like DNS but does > do iterative lookups like DNS. > Why stating what DDT is not? I think that this way is shorter and clearer. >> The DDT Mapping System relies on manual configuration. That is Map- >> Resolvers are manually configured with the set of available DDT root >> nodes while DDT nodes are manually configured with the appropriate >> XEID delegations. Configuration changes in the DDT nodes are only >> required when the tree structure changes itself, but it doesn't >> depend on EID dynamics (RLOC allocation or traffic engineering policy >> changes). > > You need to describe a very important concept of the Map-Resolver stores a > referral cache. That is an important piece of DDT that is missing here. This is already stated here: "It is important to note that DDT clients can also cache the information contained in Map-Referrals, that is, they cache the DDT structure. This is used to reduce the mapping retrieving latency [Jakab]." Please let me know if you agree with it. > >> >> 2.5. Internetworking Mechanisms >> >> EIDs are typically identical to either IPv4 or IPv6 addresses and >> they are announced at the LISP Mapping System, however they are >> usually not announced in the Internet global routing system. As a >> result LISP requires an internetworking mechanism to allow LISP sites >> to speak with non-LISP sites and viceversa. LISP internetworking > > Change to "vice-versa". Ok. > >> RLOC-probing: This is an active probing algorithm where ITRs send >> probes to specific locators, this effectively probes both the locator >> and the path. In particular this is done by sending a Map-Request >> (with certain flags activated) on the data-plane and waiting in > > This is misleading. An RLOC-probe is a Map-Request. A Map-Request is a > control-plane packet. Can you please further clarify this comment? Are you suggesting removing “(with certain flags activated)”? > >> return a Map-Reply, also sent on the data-plane. The active nature >> of RLOC-probing provides an effective mechanism to determine >> reachability and, in case of failure, switching to a different >> locator. Furthermore the mechanism also provides useful RTT >> estimates of the delay of the path that can be used by other network >> algorithms. > > We should say that echo-noncing and RLOC-probing can work together. That is > if a nonce is not echoed, a ITR could RLOC-probe to determine if the path is > up (because the return bidirectional path may have went silent). Or, when > echo-noncing determines a forward path to an RLOC is up, RLOC-probes can be > suppressed to save sending extra messages. > See my updated paragraph below: It is worth noting that RLOC probing and Echo-nonce can work together. Specifically if a nonce is not echoed, an ITR could RLOC-probe to determine if the path is up because the return bidirectional path may have failed. Alternatively, when echo-noncing determines a forward path to an RLOC is up, RLOC-probes can be suppressed to save messages. >> Additionally, LISP also recommends inferring reachability of locators >> by using information provided by the underlay, in particular: >> >> ICMP signaling: The LISP underlay -the current Internet- uses the >> ICMP protocol to signal unreachability (among other things). LISP >> can take advantage of this and the reception of a ICMP Network >> Unreachable or ICMP Host Unreachable message can be seen as a hint >> that a locator might be unreachable, this should lead to perform >> additional checks. >> >> Underlay routing: Both BGP and IBGP carry reachability information, >> LISP-capable routers that have access to underlay routing information >> can use it to determine if a given locator or path are reachable. >> >> 3.3. ETR Synchronization >> >> All the ETRs that are authoritative to a particular EID-prefix must >> announce the same mapping to the requesters, this means that ETRs >> must be aware of the status of the RLOCs of the remaining ETRs. This >> is known as ETR synchronization. >> >> >> >> Cabellos & Saucez (Ed.) Expires March 26, 2015 [Page 15] >> Internet-Draft LISP Introduction September 2014 >> >> >> At the time of this writing LISP does not specify a mechanism to >> achieve ETR synchronization. Although many well-known techniques > > Well this is not totally true. If each ETR sends Map-Registers with > merge-semantics, the Map-Notifies returned can inform an ETR of the other > ETRs that are regsitering the same EID-prefix. So this is implied > synchronization. > As far as I know this has not been specified. >> could be applied to solve this issue it is still under research, as a >> result operators must rely on coherent manual configuration >> >> 3.4. MTU Handling >> >> Since LISP encapsulates packets it requires dealing with packets that >> exceed the MTU of the path between the ITR and the ETR. Specifically >> LISP defienes two mechanisms: >> >> Stateless: With this mechanism ITRs fragment packets that are too >> big, typically reassembly is performed at the destination host. > > I would say "the ITR encapsulates fragments and therefore the destination > will do resassembly after the ETR decapsulates". > >> Stateful: With this mechanism ITRs keep track of the MTU of the >> paths towards the destination locators by parsing the ICMP Too Big >> packets sent by intermediate routers. > > This is not accurately stated. What the stateful appraoch does is indeed keep > track of effective MTU per RLOC, but the ITR will also SEND ICMP Too Big > messages so the source can lower the packet size so when LISP headers are > added, it remains under the effective MTU. See my updated paragraph below: Stateful: With this mechanism ITRs keep track of the MTU of the paths towards the destination locators by parsing the ICMP Too Big packets sent by intermediate routers. Additionally ITRs will send ICMP Too Big messages to inform the sources about the effective MTU. > >> >> In both cases if the packet cannot be framgneted (IPv4 with DF=1 or >> IPv6) then the ITR drops it and replies with a ICMP Too Big message >> to the source. >> >> 4. Mobility >> >> LISP can also be used to enable mobility of devices not located in >> LISP networks. The problem with mobility of such devices is that > > How about stating that LISP enables IP address mobility. I don't know why it > is state for devices not located in LISP networks. It is actually false > because if an EID is in a LISP site and moves to a non-LISP area of the > network, there really is not way it can be found and packets sent to it > (other than with mechanisms like injecting host routes or mobile-IP). > > Certainly way too complex for this intro document. This is indeed out of the scope of this document. > >> their IP address changes whenever they change location, interrupting >> so flows. >> >> To enable mobility on such devices, the device can implement the xTR >> functionality where the IP address presented to applications is an >> EID that never changes while the IP address obtained from the network > > A device can be mobile, have a static EID, and not run LISP in the device. A > network device can do the encap/decap and registration of new RLOCs for the > EID. > >> is used by the xTR as RLOC. Packets are then transported on the >> network using the IP address assigned to the device by the visited >> network while at the application level IP addresses remain >> independent of the location of the device. >> >> Whenever the device changes of RLOC, the ITR updates the RLOC of its >> local mapping and registers it to its Map-Server. To avoid the need > > The ETR does. This section needs rewriting. It is confusing and doesn't get > to the simple points. > >> of a home gateway, the ITR also indicates the RLOC change to all >> remote devices that have ongoing communications with the device that >> moved. The combination of both methods ensures the scalability of >> the system as signalling is strictly limited the Map-Server and to >> hosts with which communications are ongoing. > > Totally bad wording. > What about this new text: The separation between locators and identifiers in LISP was initially proposed for traffic engineering purpose where LISP sites can change their attachement points to the Internet (i.e., RLOCs) without impacting endpoints or the Internet core. In this context, the border routers operate the xTR functionality and endpoints are not aware of the existence of LISP. However, this mode of operation does not allow seamless mobility of endpoints between different LISP sites as the EID address might not be routable in a visited site. Nevertheless, LISP can be used to enable seamless IP mobility when LISP is directly implemented in the endpoint. Each endpoint is then an xTR and the EID address is the one presented to the network stack used by applications while the RLOC is the address gathered from the network when it is visited. is that better? >> 5. Multicast >> >> LISP also supports multicast environments, the operational changes >> required to the multicast protocols are documented in [RFC6831]. > > Should say, that LISP supports transporting IP multicast packets sent from > EIDs. > >> In such scenarios, LISP creates multicast state both at the core and > > "may create" > >> at the sites (both source and receiver). In order to create > > "When signaling is used ..." > >> multicast state at the sites, LISP routers unicast encapsulate PIM >> Join/Prune messages from receiver to source sites. At the core, ETRs >> build a new PIM Join/Prune message addressed to the RLOC of the ITR >> servicing the source. An simplified sequence is shown below: >> >> 1. An end-host that belongs to a LISP site transmits a PIM Join/ >> Prune message (S-EID,G) to join a multicast group. > > Sigh, not true. An end-host sends an IGMP report. When multicast PIM routers > at the LISP site propagate PIM joins toward the ETR, then number 2 is done. See my updated paragraphs below: LISP also supports transporting IP multicast packets sent from the EID space, the operational changes required to the multicast protocols are documented in [RFC6831]. In such scenarios, LISP may create multicast state both at the core and at the sites (both source and receiver). When signaling is used create multicast state at the sites, LISP routers unicast encapsulate PIM Join/Prune messages from receiver to source sites. At the core, ETRs build a new PIM Join/Prune message addressed to the RLOC of the ITR servicing the source. An simplified sequence is shown below: 1. An end-host willing to join a multicast channel sends an IGMP report. Multicast PIM routers at the LISP site propagate PIM Join/Prune messages (S-EID, G) towards the ETR. > >> 2. The join message flows to the ETR, upon reception the ETR builds >> two join messages, the first one unicast LISP-encapsulates the >> original join message towards the RLOC of the ITR servicing the >> source. This message creates multicast state at the source site. >> The second join message contains as destination address the RLOC >> of the ITR servicing the source (S-RLOC, G) and creates multicast >> state at the core. > > This is good and simple wording. > >> 3. Multicast data packets originated by the source (S-EID, G) flow >> from the source to the ITR. The ITR LISP-encapsulates the >> multicast packets, the outter header includes its own RLOC as the >> source (S-RLOC) and the original multicast group address (G) as >> the destination. Please note that multicast group address are >> logical and are not resolved by the mapping system. Then the >> multicast packet is transmitted through the core towards the >> receiving ETRs that decapsulates the packets and sends them using >> the receiver's site multicast state. > > It should be said that there are non-PIM mechanisms that can signal and > maintain multicast state. And there is also signal-free mechanisms as well. I suggest adding the following sentence at the end of the Multicast section: LISP also support non-PIM mechanisms to maintain multicast state. > >> >> 7.2. LISP for IPv6 Transition > > Should be titled IMO "LISP for IPv6 Co-Existence". > >> >> LISP encapsulations permits to transport packets using EIDs from a >> given address family (e.g., IPv6) with packets with addresses >> belonging to another address family (e.g., IPv4). The absence of >> correlation between the address family of RLOCs and EIDs makes LISP a >> candidate to ease the transition to IPv4. > > Allows IPv6 to be deployed when all of the core network may not have IPv6 > enabled. > […] LISP a candidate to allow IPv6 to be deployed when all of the core network may not have IPv6 enabled. >> For example, two IPv6-only data centers could be interconnected via >> the legacy IPv4 Internet. If their border routers are LISP capable, >> sending packets between the data center is done without any form of >> translation as the native IPv6 packets (in the EID space) will be >> LISP encapsulated and transmitted over the IPv4 legacy Internet by >> the mean of IPv4 RLOCs. >> >> 7.3. LISP for Network Virtualization > > Should be titled IMO "LISP for Virtual Private Networks". > ok >> It is nowadays common to operate several virtual networks over the >> same physical infrastructure. The current approach usually rely on >> BGP/MPLS VPNs, where BGP is used to exchange routing information and >> MPLS to segregate packets of the different logical networks. This >> functionality could be achieved with LISP where the mappings and the > > "... is achieved with LISP ..." > >> mapping system are used instead of BGP and the LISP encapsulation is >> used to replace MPLS. > > I think comparing to BGP/MPLS does not help describe what it is. And it is > not a wholesale replacement because BGP/MPLS VPNs typically run within a > single ISP where LISP VPNs can run anywhere (i.e. a mobile phone can be in a > VPN and encapsulates to a multi-tennant environment in the data center). what about just keeping It is nowadays common to operate several virtual private networks over the same physical infrastructure. > >> >> Cabellos & Saucez (Ed.) Expires March 26, 2015 [Page 19] >> Internet-Draft LISP Introduction September 2014 >> >> >> In virtual networks, it is essential to distinguish to which virtual private >> network a packet belongs and tags or labels are used for that >> purpose. With LISP, the distinction can be made with the Instance ID >> field. When an ITR encapsulates a packet from a particular virtual >> network (e.g., known via the VRF or VLAN), it tags the encapsulated >> packet with the Instance ID corresponding to the virtual network of >> the packet. When an ETR receives a packet tagged with an Instance ID >> it uses the Instance ID to determine how to threat the packet. > > "... treat the packet." too much of threat :) > >> Appart from the simplicity of managing mappings, the advantage of >> using LISP for virtual network is that it does not impose any >> requirement on the underlying network, except running IP. > > It should be stated that with LISP VPNs the EID space can be segmented and > reused while not segmenting the mapping system or core network. That is a > shared core network with global RLOC space and a shared mapping system which > distinguishes EID addresses by instance-ID can be accomplished. This allows > for a lower OpEx infrastructure while virtualizing the edges. -> The complete separation between the mapping system and the encapsulation mechanism in LISP permits to logically segment and reuse the EID space without segmenting the core network and mapping system hence reducing the operational complexity. I prefer not saying OpEX as it may be not accepted by some people. > >> >> 7.4. LISP for Virtual Machine Mobility in Data Centers >> >> A way to enable seamless virtual machine mobility in data center is >> to conceive the datacenter backbone as the RLOC space and the >> subnetworks where servers are hosted as forming the EID space. A >> LISP router is placed at the border between the backbone and each >> sub-network. When a virtual machine is moved to another subnetwork, > > Change "sub-network" to "subnet", everywhere in this section. ok. > >> it can (temporarily) keep the address of the sub-network it was >> hosted before the move so to allow ongoing communications to subsist. > > No, not true. The EID is static and can be assigned and used indefinitely. > EID are not always static. >> When a subnetwork detects the presence of a host with an address that >> does not belong to the subnetwork (e.g., via a message sent by the >> hypervisor), the LISP router of the new subnetwork registers the IP > > Remove the parenthetitcal comment. You don't want to assume what is moving is > only VMs. A server can be relocated. xTRs discover dynamic-EIDs by listening > to packets and ARP messages to discover new sources. hence the e.g., and not an i.e., what about: (e.g., via a message sent by the hypervisor or traffic inspection) > >> address of the virtual machine as an EID to the Map-Server of the >> subnetwork and associates its own address as RLOC. >> >> To inform the other LISP routers that the machine moved and where, >> and then to avoid detours via the initial subnetwork, every Map- >> Server can listen on a predefined multicast address that is used as > > What? Where did this come from. This is simply not true, never has been true. > ITRs that have been encapsulating to RLOCs that have changed for an EID will > be informed with Solicit-Map-Request messages. > >> source address for Map-Register. As a result, the Map-Notify sent >> back by the Map-Server will be received by all the LISP routers that >> hence automatically learn the new location of the virtual machine. > > This is not what is done. A Map-Notify is sent by Map-Servers but it is sent > to the old RLOCs when a new registration comes in with new RLOCs. > ok, we remove all that and say the following instead: To inform the other LISP routers that the machine moved and where, and then to avoid detours via the initial subnetwork, mechanisms such as the Solicit-Map-Request messages are used. >> >> 10. Acknowledgements >> >> To Do. > > You should indicate that there is a long list of individuals acknowledged in > RFC 6830. > >> Appendix A. A Brief History of Location/Identity Separation >> >> The LISP system for separation of location and identity resulted from >> the discussions of this topic at the Amsterdam IAB Routing and >> Addressing Workshop, which took place in October 2006 [RFC4984]. >> >> A small group of like-minded personnel from various scattered >> locations within Cisco, spontaneously formed immediately after that >> workshop, to work on an idea that came out of informal discussions at >> the workshop. The first Internet-Draft on LISP appeared in January, >> 2007, along with a LISP mailing list at the IETF. > > I don't recall any mailing list other than using the [email protected] mailing > list for early discussions. I know cisco had mailing lists but those were are > not related to IETF. Please see below my updated paragraph: A small group of like-minded personnel from various scattered locations within Cisco, spontaneously formed immediately after that workshop, to work on an idea that came out of informal discussions at the workshop and on the RRG IRTF mailing list. The first Internet-Draft on LISP appeared in January, 2007, along with a LISP mailing list at the IETF. > >> A.1. Old LISP Models >> >> LISP, as initilly conceived, had a number of potential operating > > Spell check "initially". Ok. > >> modes, named 'models'. Although they are now obsolete, one >> occasionally sees mention of them, so they are briefly described >> here. > > I would just say they are not used anymore. Ok. > > Great job guys! > Thanks! > Dino > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
