Albert, Damien,

Thanks for the document. It provides a good overview of LISP. I have the 
following comments:

Section 2.3.1 page 7.
“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.”
Please expand on the instance ID description to state that it is used to 
support segmentation of *EID* space.

Section 2.4.2
The start of this section refers to Map-Requests and Map-Reqplies as “queries" 
and “responses". Their definition below does not refer to the “query” and 
“response” role. Either modify the definitions to tie the two together or use 
the standard terms from the beginning of the section.

Section 2.4.2
“Map-Notify:  When requested by the ETR, this message is sent by the Map-Server 
in response to a Map-Register to acknowledge the correct reception of the 
mapping.”
The Map-Notify message is also used to convey the latest Map-Server state on 
the EID to RLOC mapping.

Section 2.4.2
“Please note that a Map-Reply may contain a negative reply if the queried EID 
is not part of the LISP EID space. In such cases the ITR typically forwards the 
traffic natively (non encapsulated) to the public Internet.”
Worth mentioning that this behaviour is defined to support incremental 
deployment of LISP.

Section 2.4.3.1
“Every ETR involved in the ALT topology advertises its EID prefixes making the 
EID routable on the overlay”
The Map-Servers participate in ALT, ETRs do not as the mapping system interface 
hides the fact that the ALT is in use. The MS advertises the EID prefixes that 
are registered against it in the ALT.

Section 2.4.3.1
“When an ITR needs a mapping, it sends a Map-Request to a nearby ALT router.”
The ITR sends the Map-Request to a nearby Map-Resolver that is ALT connected.

Section 2.5
“In some scenarios, LISP sites may be unable to send encapsulated packets to 
the legacy Internet.”
Should this be “unable to send unencapsulated packets with a local EID address 
as a source”?

Section 3.1
Please add references to the RFCs defining the cache management mechanisms.

Section 3.2
“LSB is a passive technique, the LSB field is carried by data-packets in the 
LISP header and can be set by a ETRs to specify which RLOCs are up/down.”
Worth describing that the RLOCs to which the LSBs refer as those of the site of 
the ETR.

Section 3.2
“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 return a Map-Reply, also sent on the 
data-plane.”
I am not sure what “on the data-plane” means. Can you please clarify.

thanks
Isidor


On Sep 22, 2014, at 23:40, Albert Cabellos <[email protected]> wrote:

> Hi all
> 
> Below you can find the -05 version of draft-ietf-lisp-introduction. We
> have changed the structure and content based on the feedback posted on
> the list
> 
> We´ll gather more feedback and produce a new version before cut-off,
> please review and comment ASAP.
> 
> Albert
> 
> 
> ---------- Forwarded message ----------
> From:  <[email protected]>
> Date: Mon, Sep 22, 2014 at 10:06 PM
> Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-05.txt
> To: [email protected]
> Cc: [email protected]
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Locator/ID Separation Protocol
> Working Group of the IETF.
> 
>        Title           : An Architectural Introduction to the LISP
> Location-Identity Separation System
>        Authors         : Albert Cabellos
>                          Damien Saucez
>        Filename        : draft-ietf-lisp-introduction-05.txt
>        Pages           : 24
>        Date            : 2014-09-22
> 
> Abstract:
>   This document describes the Locator/ID Separation Protocol (LISP)
>   architecture, its main operational mechanisms as well as its design
>   rationale.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-lisp-introduction-05
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> lisp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to