Noel, >-----Original Message----- >From: Noel Chiappa [mailto:[email protected]] >Sent: Friday, January 16, 2009 9:27 AM >To: [email protected] >Cc: [email protected] >Subject: Re: [rrg] No liveness requirement in the ID/Loc Split concept > > > > From: [email protected] (Noel Chiappa) > > > a LISP EID does _not_ name an interface, but rather a 'stack' - i.e. an > > endpoint, with a collection of TCP connections. > >A private reply pointed out that a LISP EID in fact _also_ names an >interface, just like an IPv4 address. That's a consequence of the fact that a >LISP design goal was to allow unmodified hosts, so one can only change the >semantics of existing namespaces a little. > > >Interesting historical note: the Nimrod deployment plan: > > http://ana-3.lcs.mit.edu/~jnc/nimrod/deploy.txt > >looked a lot like LISP's deployment plan - the existing IP layer was 'jacked >up' and a new layer inserted underneath; unmodified hosts were unaware that >this all was happening, and continued to emit and receive classic IPv4 >packet; Nimrod agent-routers were responsible for invisibly translating the >IPv4 'addresses' in those packets into Nimrod locators, and doing the >encapsulation. Although the Nimrod deployment plan spoke of turning IPv4 >'addresses' into endpoint names (EIDs, to be exact - ironically), it's clear >that there, IPv4 addresses also retained minimal interface naming semantics. > > >It's almost inevitable, in any plan which supports unmodified hosts, that >the IPvN addresses used by those hosts will retain the basic semantics of >IPvN addresses.
If what LISP is calling an EID is indeed an IPvN address (it is) then it is routable within a certain scope. Otherwise, all end systems would have to also be xTRs, and we would have to get into a messy discussion on strong vs. weak end system model. Fred [email protected] > Noel >_______________________________________________ >rrg mailing list >[email protected] >http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
