Hello Albert, I have been through the current version of the document, and it reads well - thanks!
I have added a few nits below - feel free to pick and choose: 2.3 Data-plane In "This header is created by the source end-host and remains unchanged." "remains unchanged" -> "is left unchanged by LISP data plane processing on the ITR and ETR". (TTL processing, as part of IP forwarding, is done on that header as usual.) 3.2. RLOC Reachability You describe RLOC probing in this section which is expected. However, you may also want to allude to RLOC probing in the previous Cache Management section too; an ITR implementation can exploit RLOC probing to infer instances where it might be sensible to refresh entries in a map cache. 3.4. MTU Handling The Stateless comment is a tad misleading. I think the salient point in the stateless mechanism is that the effective MTU is assumed from ITR's perspective. The fact that ITR fragments packets that are too big, and can be fragmented is common across both stateless and stateful mechanisms. Couple of typos in here (defeines and framgented). ==== The rest are exclusively style/spelling comments - feel free to pick and choose. Oh, and I should add that English is my second language (as if it weren't obvious already) - so you would do better to get some one with a good command of the language to give it a once over. 2.1. Design Principles: "allowing to deploy new protocols" -> "allowing deployment of" "resulting from a low deployment cost." -> "resulting in low cost of deployment" In the overlay section you might want to extend the Overlay Architecture with "as well as other decoupling benefits arising from deployment of an overlay architecture". I am sure the ability to experiment with new protocols over existing infra is an important benefit of overlays, but perhaps not the most important one. 2.2 Overview of the architecture "The edge are LISP sites" -> "The edge consists of LISP sites" "EIDs can be are typically Provider Independent (PI [RFC4116]) addresses and can be thought as they don't contain intra-domain topological information. " -> "EIDs are typically Provide Independent (PI [RFC4116]) addresses and can thought of as devoid of intra-domain topolical information." "has a strong emphasis in" -> " emphasizes" "packt" -> "packet" "lookup key, in turn it" -> "lookup key. In turn it". Fullstops are free. Would be good to sprinkle a few more in that paragraph. 2.3. Data-Plane "that connect the EID with the RLOC space (ITR) and viceversa (ETR)" -> "that connect the EID to the RLOC space (ITR) and the RLOC to the EID space (ETR)" "that it is not verified in reception" -> "such that it is not verified on reception" "The Instance ID field is used to distinguish traffic that belongs to multiple tenants inside a LISP site, and that may use overlapped but logically separated addressing space." -> "The Instance ID field is used to distinguish traffic to/from different tenant address spaces at the LISP site." 2.3.2. LISP Forwarding State I would drop "to increase the forwarding speed of subsequent packets addressed to the same EID prefix." "set by the ETR" -> "advertised by ETR" 2.4.2 Mapping System Interface "Please note that a Map-Reply may contain a negative reply if the queried EID is not part of the LISP EID space." -> "Please note that a Map-Reply may contain a negative reply, for example, if the queried EID is not part of the LISP EID space." 2.4.3. Mapping System "responsible of storing mappings" -> "responsible for storing mappings." "may be used store" -> "may be used to store" "The LISP WG has discussed for the Mapping System architecture the four main techniques available in distributed systems, namely:" -> "The LISP WG has explored application of the following distributed system techniques to the Mapping System architecture:" 2.5 Internetworking Mechanisms "Proxy Engress Tunnel Router (PETR)" -> "Proxy Egress Tunnel Router (PETR)" "allows to overcome " -> "overcomes" "Finally, the RLOC of PETRs must be statically configured in ITRs." -> "There is no specified provision for the distribution of PETR RLOC addresses to the ITRs" One more inline.... On 02/10/2014 00:53, Albert Cabellos wrote: > Hi all > > This is the proposed Introduction following the comments on the list: > > This document introduces the Locator/ID Separation Protocol (LISP) > [RFC6830] architecture, its main operational mechanisms and its design > rationale. Fundamentally, LISP is built following a well-known > architectural idea: decoupling the IP address overloaded semantics. > Indeed and as pointed out by [Chiappa], 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. > > LISP creates two separate namespaces, EIDs (End-host IDentifiers) and > RLOCs (Routing LOCators), both are -typically, but not limited to- > syntactically identical to the current IPv4 and IPv6 addresses. EIDs > are used to uniquely identify nodes irrespective of their topological > location and are typically routed intra-domain. RLOCs are assigned > topologically to network attachment points and are typically routed > inter-domain. With LISP, the edge of the Internet -where the nodes > are connected- and the core -where inter-domain routing occurs- are > architecturally separated and interconnected by LISP-capable routers. The word 'architecturally' doesn't seem to add much here, and 'are' might be replaced by 'can be' - for example my IPv6 host may be reachable over LISP over IPv4 and directly over IPv6. Thanks again Christian > LISP also introduces a publicly accessible database, called the > Mapping System, to store and retrieve mappings between identity and > location. LISP-capable routers exchange packets over the Internet > core by encapsulating them to the appropriate location. > > By taking advantage of such separation between location and identity, > LISP offers Traffic Engineering, multihoming, and mobility among > others benefits. Additionally, LISP’s approach to solve the routing > scalability problem [RFC4984] is that with LISP the Internet core is > populated with RLOCs which can be quasi-static and highly > aggregatable, hence scalable [Quoitin]. > > It is important to note that this document does not specify or > complement the LISP protocol. The interested reader should refer to > the main LISP specification [RFC6830] and the complementary documents > [RFC6831],[RFC6832],[RFC6833],[RFC6834],[RFC6835], [RFC6836] for the > protocol specifications along with the LISP deployment guidelines > [RFC7215]. > > Albert > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
