Hi Christian Thanks, see inline my comments:
On Thu, Oct 2, 2014 at 4:45 PM, Christian Cassar <[email protected]> wrote: > 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.) > Ok, thanks. > 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. > What about adding the following sentence at the end of section 3.1: Finally it is worth noting that in some cases an entry of the map-cache can be proactively refreshed using the mechanisms described in the section below. > 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. > What about this: Stateless: With this mechanism the effective MTU is assumed from the ITR's perspective, in case that a packet is too big reassembly is typically performed at the destination host. > 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. > Thanks! We´ll apply all your suggestions. >> 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. > Agreed, what about logically? > Thanks again > Christian > Thanks Albert _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
