Subject: Re: [lisp] intro & architecture drafts

From: [email-masked] (Noel Chiappa)
Date: Thu, 25 Oct 2012 11:03:35 -0400 (EDT)

> From: Paul Vinciguerra <[email-masked]>

    > 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'.

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

	Noel

---

From: Paul Vinciguerra <[email-masked]>
Date: Fri, 26 Oct 2012 00:12:19 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Noel Chiappa
> 
> 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