(I'm rarely connecting to mail right now; please forgive if this thread is old)
Excerpts from Noel Chiappa on Tue, Dec 16, 2008 02:00:34PM -0500: > - The initial spec provides for use of IPv4 between xTRs - but with > a system of xTRs deployed, it would be feasible to replace that > inter-xTR protocol with something better - a layer that e.g. > recognized traffic aggregates as first-class objects (so that > traffic engineering would no longer have to rely on routing hacks), > or had built-in tools for aggregation of routing information (think > a hierarchy of nested areas), instead of having to have it be > hand-configured as now. I think we've seen that deploying new stuff > like this is virtually impossible _if the hosts have to understand > it_ - so it makes great sense to initially hide it behind a set of > mapping boxes - but how does one get the mapping boxes deployed to > do it? Well, you have to offer them some short-term benefit.... afaict the only way to replace a protocol that is shared among all DFZ-edge routers is either to (1) do yet another jack-up, or (2) do it in a particular part of the Internet and interwork. Does having a map-and-encap mechanism in place help you in either of these cases? The best thing, to me, about having something in the core that is a routing solution but does not provide session identifiers is that those two problems are decoupled, and you can evolve solutions to them independently. Identification and session control are endpoint problems and should be dealt with by the endpoints. > - The initial concept is that routers and hosts would not need to be > modified, to make deployment feasible. (See Figure 1.) However, once > there is some added value to what's on the other side of the xTR, it > might make sense to incrementally move that boundary closer and > closer to the hosts, and perhaps eventually expose the hosts to the > new inter-xTR protocol directly. Or let there be xTRs wherever it is convenient for any of the parties along the path, and simultaneously -- independently -- deploy something for e2e session control. > While LISP clearly doesn't provide the same degree of separation of > location and identity as HIP, I think it's incorrect to say any > claims it makes to separation of location and identity are '[purely] > marketing'. LISP EIDs may initially have limited location scope, but > they certainly don't have global location scope - and the design is > the way it is for seem like good reasons: the ability to work with > _unmodified_ hosts and routers - needed to make that initial > snowball feasible. We either have to give up making EIDs purely > identifiers (i.e. retain some location semantics, within a local > scope), or else we have to modify all the internal routers at a site > - and the latter is a non-starter for deployment. > > LISP certainly does allow an organization to do a number of > _practical_ things, like change its ISP without changing its host > addresses - and not just inside the site, but in external places as > well, such as configuration data on other sites (e.g. for access > control). Right. It provides site-level liberation from topological location. Scott _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
