Re: [lisp] Updated Intro section for lisp-introduction

[Albert Cabellos <[e-mail]>]

Hi Christian

Thanks, see inline my comments:

On Thu, Oct 2, 2014 at 4:45 PM, Christian Cassar <[e-mail]> 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