> From: [email protected] [mailto:[email protected]] On Behalf Of
> Noel Chiappa
> 
>     > From: Paul Vinciguerra <[email protected]>
> 
>     > What does the list think about replacing the term "node" with endpoint
> 
> The problem is that the term "endpoint" already has a fairly specific
> definition (a fate-sharing region, one end of an end-end communication),
> and some of the things you listed are not 'endpoints'.

[PV] I don't understand.  Maybe you can explain a little bit more.  Let me try 
to explain my point as well.

A physical host is an endpoint.
A virtual machine is an endpoint behind a hypervisors switch.
A mobile phone is an endpoint (as well as a site with RLOC's)
A VIP for a service is an older type of indirection to try to separate identity 
from location, no?
  We have used load balancers and GSLB for these purposes.

Two months ago, we used LISP to redirect traffic for lisp.cisco.com from San 
Jose to our datacenter.  We rsync'd the content and put up the same address on 
our boxes and used dynamic EID detection to bring them to life.

The next time we do this, we will use _different_ addresses for the host and 
assign the lisp.cisco.com address to the listening HTTP request.  In this case, 
only that granular service is the endpoint. 

You can see what we did and how here: 
http://vinciconsulting.com/blog/-/blogs/we-had-a-prestigious-guest-visit-our-datacenter-today-lisp-cisco-com

I also agree with you that node is proper, _but_ I also know that quite often 
when I ask someone how many nodes are on their networks, they typically reply 
with the number of physical devices.

> 
> 'Node' was picked precisely because it was a somewhat nebulous term, one
> which _can_ cover all the things you listed.
>

[PV] You have done a great job in classifying the moving parts of LISP (and 
there are more than a few), without a doubt.  But I have to ask if,  from the 
readers point of view, does the net being so wide make it harder for the reader 
to grasp the benefits, especially in an introductory document?   For example, 
if I did not know that LISP could deliver IPv6 over IPv4 and vice versa, I 
don't know that I would make the immediate connection with section heading 4.5, 
IP Version Reciprocal Traversal.  We have a DDT root in our datacenter, but 
until I read section 5.2.3, Indexing Subsystem, I did not make that immediate 
connection either.  I will say that once I read the section and put what I know 
into that grouping, I frequently found myself saying "wow, I never thought of 
it like that, but that's right."  

So, accuracy wise, I do not think I could have classified things better.

Maybe I should be asking a different question.  Who is the intended audience 
for these documents?  If it is written for protocol developers and designers, 
that makes sense, but deployment engineers also spend time reading RFC's and 
drafts and with that audience there is an immediate gratification reflex, an 
impatient "what's in it for me" for lack of better phrasing.

Paul

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

Reply via email to