Hello Albert, inline...
On 05/10/2014 22:30, Albert Cabellos wrote: > 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. > Looks good (with Dino's comment incorporated). More... >> 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. Looks good... perhaps broken into two sentences. Stateless: With this mechanism the effective MTU is assumed from the ITR's perspective. If a payload packet is too big for the effective MTU, and can be fragmented, the payload packet is fragmented on the ITR, such that reassembly is performed at the destination host. More... <snip> >>> 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? Fine. Thanks Christian > >> Thanks again >> Christian >> > > Thanks > > Albert > . > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
