Major practical decision
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
 |
Major practical decision
by Noel Chiappa
::
Rate this Message:
So, this high-level conversation has been interesting and educational, but
I'd like to ask a more "brass-tacks" question. In doing so, I'm basically recognizing that while it's nice to theorize with a blank sheet of paper, when it comes to specifying bits you have practical constraints. I get the sense that it is now generally accepted that widespread multi-homing has to be handled by use of multiple routing-names, and identity/location separation. However, it's not clear to me that a new end-end naming layer (e.g. SHIM6 or HIP) is really a viable solution, because of the amount of legacy equipment out there. (And a top of the hatly hat to David Conrad for first raising this issue.) I.e. if your site is multi-homed, and you've deployed HIP/whatever, that's not much use if many of the people trying to talk to you haven't. David's contention was that because of this we may be forced to convert the current IPvN addresses into end-end names, "jack up" the internetwork layer, and insert a new layer underneath, and deploy some sort of mapping system to map from IPvN "addresses" to some new routing-name namespace. I think that's a really good argument - that this is the only solution that's viable in a short time-frame. However, I'm very interested to hear what everyone else thinks on this point. (I note that it's always better to deploy something designed to a purpose, and it would be better to name end-end entities out of a new namespace designed for that purpose, but alas, we may be stuck.) I ask this because jack-up assumes a new routing-name namespace, which has implications for the routing: it immediately lands us with what seems to me, after a moderate look, to be a fairly hard problem in that part of the system - although one more soluble than routing PI addresses, before anyone says anything! So, what's it to be: jack-up (i.e. insertion of a new internetworking layer), or new end-end names (i.e. insertion of a new end-end naming layer)? Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Major practical decision
by Mark Handley
::
Rate this Message:
On 12/8/06, Noel Chiappa <jnc@...> wrote:
> So, what's it to be: jack-up (i.e. insertion of a new internetworking layer), > or new end-end names (i.e. insertion of a new end-end naming layer)? I'm not sure these are the only possibilities. We've been playing with the idea of using edge-to-edge tunnelling to construct an infrastructure for defending against DDoS attacks. An unpublished paper is here if you're interested: http://nrg.cs.ucl.ac.uk/mjh/tmp/e2etun.pdf Anyway, this sort of edge-to-edge tunnelling doesn't require any end-host changes, but does permit multiple routing names (in this case, the decapsulator addresses) for each end-host IP address, and it should be incrementally deployable. I hadn't intended it as a multi-homing architecture, but it might work OK. In any event, it's an example of an architecture that isn't quite either of the two you listed above. - Mark _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Major practical decision
by marcelo bagnulo braun
::
Rate this Message:
Hi Noel,
El 08/12/2006, a las 17:54, Noel Chiappa escribió: > So, this high-level conversation has been interesting and educational, > but > I'd like to ask a more "brass-tacks" question. In doing so, I'm > basically > recognizing that while it's nice to theorize with a blank sheet of > paper, > when it comes to specifying bits you have practical constraints. > > > I get the sense that it is now generally accepted that widespread > multi-homing has to be handled by use of multiple routing-names, and > identity/location separation. > > However, it's not clear to me that a new end-end naming layer (e.g. > SHIM6 or > HIP) is really a viable solution, because of the amount of legacy > equipment > out there. (And a top of the hatly hat to David Conrad for first > raising this > issue.) I.e. if your site is multi-homed, and you've deployed > HIP/whatever, > that's not much use if many of the people trying to talk to you > haven't. > yes, these approaches need that the peer supports the protocol (either the end node itself or some form or proxy) > David's contention was that because of this we may be forced to > convert the > current IPvN addresses into end-end names, "jack up" the internetwork > layer, > and insert a new layer underneath, and deploy some sort of mapping > system to > map from IPvN "addresses" to some new routing-name namespace. > > I think that's a really good argument - that this is the only solution > that's > viable in a short time-frame. However, I'm very interested to hear what > everyone else thinks on this point. i am not following what kind of approach could provide multihoming support (preserving established communications) without requiring support from both peers of the communications? (by peers i mean either the end nodes themselves or devices on the edge next to each peer that perform the multihoming functions for them) If we do actually manage to define a solution that _only_ requires modifications to the multihomed site and does not requires modifications to the peers that it is communicating with (nor the the network outside the multihomed site) this would be indeed a really nice feature, because only those who actually get the multihoming benefits have to pay the costs of supporting the multihoming support tools, which is very nice, but i am not sure i have ever seen a proposal that does this.... could you expand? regards, marcelo > > (I note that it's always better to deploy something designed to a > purpose, and > it would be better to name end-end entities out of a new namespace > designed > for that purpose, but alas, we may be stuck.) > > > I ask this because jack-up assumes a new routing-name namespace, which > has > implications for the routing: it immediately lands us with what seems > to me, > after a moderate look, to be a fairly hard problem in that part of the > system > - although one more soluble than routing PI addresses, before anyone > says > anything! > > So, what's it to be: jack-up (i.e. insertion of a new internetworking > layer), > or new end-end names (i.e. insertion of a new end-end naming layer)? > > Noel > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@... > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Major practical decision
by Tony Li
::
Rate this Message:
> So, what's it to be: jack-up (i.e. insertion of a new > internetworking layer), > or new end-end names (i.e. insertion of a new end-end naming layer)? My $.02: We're supposed to be architecting a fix for the Internet that should last for the foreseeable future. Not just the next 10 or 20 years, but the next 100 or so. The jack-up model is somewhat less clean and inevitably introduces suboptimalities at the interface between the layers. Thus, I'm in favor of replacing the namespace. Regards, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
|
|
|
RE: Major practical decision
by Bound, Jim
::
Rate this Message:
> I get the sense that it is now generally accepted that
> widespread multi-homing has to be handled by use of multiple > routing-names, and identity/location separation. We need to crisply define and obtain consensus on Routing-Names. > > However, it's not clear to me that a new end-end naming layer > (e.g. SHIM6 or > HIP) is really a viable solution, because of the amount of > legacy equipment out there. (And a top of the hatly hat to > David Conrad for first raising this > issue.) I.e. if your site is multi-homed, and you've deployed > HIP/whatever, that's not much use if many of the people > trying to talk to you haven't. This is a deployment issue yes but not an insurmountable one the industry is capable of adapting such as the application move today to SOA. But, more importantly at this point in the architecture discussion I believe it must remain on the table as a viable option. > > David's contention was that because of this we may be forced > to convert the current IPvN addresses into end-end names, > "jack up" the internetwork layer, and insert a new layer > underneath, and deploy some sort of mapping system to map > from IPvN "addresses" to some new routing-name namespace. These are three efforts that can happen regarding our work to define an architecture in parallel, I don't see that as a problem. > > I think that's a really good argument - that this is the only > solution that's viable in a short time-frame. However, I'm > very interested to hear what everyone else thinks on this point. I think we must define short and long term before one can answer this question. > > (I note that it's always better to deploy something designed > to a purpose, and it would be better to name end-end entities > out of a new namespace designed for that purpose, but alas, > we may be stuck.) This is my view currently we should move to a new namespace for end-to-end entities. > > > I ask this because jack-up assumes a new routing-name > namespace, which has implications for the routing: it > immediately lands us with what seems to me, after a moderate > look, to be a fairly hard problem in that part of the system > - although one more soluble than routing PI addresses, before > anyone says anything! > > So, what's it to be: jack-up (i.e. insertion of a new > internetworking layer), or new end-end names (i.e. insertion > of a new end-end naming layer)? I think for now we have to pursue these multiple paths. /jim > > Noel > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@... > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
RE: Major practical decision
by Bound, Jim
::
Rate this Message:
I don't think we can develop a solution that will last 100 years. 30
years maybe. I beleive something else will break the system that has nothing to do with the namespace decision or IP layer. This is not to say we should not replace the namespace but to attempt to provide an architecture that can be implemented by engineers that lasts 100 years seems a bit impossible to me. /jim > -----Original Message----- > From: Tony Li [mailto:tony.li@...] > Sent: Friday, December 08, 2006 11:44 PM > To: Noel Chiappa > Cc: architecture-discuss@... > Subject: Re: [arch-d] Major practical decision > > > > So, what's it to be: jack-up (i.e. insertion of a new > internetworking > > layer), or new end-end names (i.e. insertion of a new > end-end naming > > layer)? > > > My $.02: > > We're supposed to be architecting a fix for the Internet that > should last for the foreseeable future. Not just the next 10 > or 20 years, but the next 100 or so. The jack-up model is > somewhat less clean and inevitably introduces suboptimalities > at the interface between the layers. Thus, I'm in favor of > replacing the namespace. > > Regards, > Tony > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@... > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
RE: Major practical decision
by Bound, Jim
::
Rate this Message:
Interesting is anyone
proposing an alternative to hierarchical routing if so I would like to hear that
logic?
/jim
_______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Major practical decision
by Marshall Eubanks
::
Rate this Message:
On Dec 9, 2006, at 6:36 AM, Bound, Jim wrote: > I don't think we can develop a solution that will last 100 years. 30 > years maybe. I beleive something else will break the system that has > nothing to do with the namespace decision or IP layer. This is not to > say we should not replace the namespace but to attempt to provide an > architecture that can be implemented by engineers that lasts 100 years > seems a bit impossible to me. I see extra-terrestrial routing in all seriousness as a major issue for the next 100 years (maybe not the next 20 years, but certainly the next 100). Adopting the 100 year rule would imply that there should be a DTN component to the current work, and also probably that we should worry about relativistic synchronization effects, which seems to be a little premature. I am sure that others can come up with likely or possible new issues with a 100 year time horizon. While it might be interesting to enumerate them, I am not sure it would be fruitful to incorporate them in the current work. Regards Marshall > > /jim > >> -----Original Message----- >> From: Tony Li [mailto:tony.li@...] >> Sent: Friday, December 08, 2006 11:44 PM >> To: Noel Chiappa >> Cc: architecture-discuss@... >> Subject: Re: [arch-d] Major practical decision >> >> >>> So, what's it to be: jack-up (i.e. insertion of a new >> internetworking >>> layer), or new end-end names (i.e. insertion of a new >> end-end naming >>> layer)? >> >> >> My $.02: >> >> We're supposed to be architecting a fix for the Internet that >> should last for the foreseeable future. Not just the next 10 >> or 20 years, but the next 100 or so. The jack-up model is >> somewhat less clean and inevitably introduces suboptimalities >> at the interface between the layers. Thus, I'm in favor of >> replacing the namespace. >> >> Regards, >> Tony >> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@... >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@... > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Major practical decision
by Pekka Nikander
::
Rate this Message:
Mark,
On 12/8/06, Noel Chiappa <jnc@...> wrote: >> So, what's it to be: jack-up (i.e. insertion of a new >> internetworking layer), or new end-end names (i.e. insertion of a >> new end-end naming layer)? On 8 Dec 2006, at 20:02, Mark Handley wrote: > I'm not sure these are the only possibilities. > > We've been playing with the idea of using edge-to-edge tunnelling > to construct an infrastructure for defending against DDoS > attacks. ... > > Anyway, this sort of edge-to-edge tunnelling doesn't require any > end-host changes, but does permit multiple routing names (in this > case, the decapsulator addresses) for each end-host IP address, and > it should be incrementally deployable. I hadn't intended it as a > multi-homing architecture, but it might work OK. > > In any event, it's an example of an architecture that isn't quite > either of the two you listed above. Hmm. I'm not that sure. What you seem to suggest looks like another, more implementation related dimension to me. Basically, what I understand Noel saying is that we either must add a layer above the current IP layer or one below it. This can be, of course, be implemented at various points in the network: at end- hosts, at edge routers, somewhere at the first ISP closest to the end site, or in the core. Or some combination of those. To me, that looks like another, basically orthogonal dimension, which is more implementation related than where-in-the-stack to insert the new layer. For example, I could imagine a solution that would be initially implemented in many laptops, in big boxes used by many major corporations, and by some advanced ISPs, and then gradually, over a longer term, by all hosts. Hence, what you seem to propose looks like an implementation strategy to me. Related to your paper, I think that in the long term an architecture that allows keeping the routing names (locators) as relative secrets provides some pretty effective protection against DDoS. Furthermore, if you use overlay routing instead of resolution to initially map the location-independent identifiers into locators, you can allow the responding (server) host or site to make the decision whether to reveal its locators to the initiator (client). [That's the approach we proposed to be used in Host Identity Indirection Infrastructure (Hi3).] --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
Re: Major practical decision
by Pekka Nikander
::
Rate this Message:
On 8 Dec 2006, at 18:54, Noel Chiappa wrote:
> However, it's not clear to me that a new end-end naming layer (e.g. > SHIM6 or > HIP) is really a viable solution, because of the amount of legacy > equipment > out there. (And a top of the hatly hat to David Conrad for first > raising this > issue.) I.e. if your site is multi-homed, and you've deployed HIP/ > whatever, > that's not much use if many of the people trying to talk to you > haven't. What I think we need is a gradual, proxy based solution approach, as alleged e.g. by Marcelo Bagnulo. Let's consider briefly what's behind that proposal. When deploying a new naming layer, we will have four kinds of situations: legacy- legacy, new-new, legacy-new and new-legacy. Legacy-legacy and new- new are, in general, not very interesting from an architectural point of view, even though there will be numerous engineering and security concerns there. This leads to the following straw man analysis: A. Legacy (site/host) connecting to a new (site/host) A.a New (site/host) still providing legacy connectivity by publishing a legacy address This is provided by both HIP and SHIM6, with the difference that SHIM6 is oblivious whether the peer supports SHIM6 when the initial connection is made. With HIP, the choice must be currently made during initial contact, but there's been discussions about delayed HIP state set-up. A.b New (site/host) being reachable only with the new connectivity (no published legacy address) A.b.a New identifiers being routable in the legacy system This is the interesting case, IMHO. If the new identifiers can be embedded into the legacy addressing system (e.g. as suggested in draft-laganier-ipv6-khi-05.txt), it may be possible to make them routable. For example, the prefix could be routed to one or a few sites in the core network, providing a service that would encapsulate the legacy traffic (along a similar way Mark Handley et al suggested in their e2efa paper) and provide connectivity to the new "world". Any site adopting the new system could then, independently, provide the same encapsulation service locally, for those hosts that don't implement it natively. A.b.b New identifiers not routable in the legacy system This seems to lead to a situation where the legacy hosts are not able to communicate with new systems that do not provide legacy connectivity. This may be a desirable end state, providing the remaining legacy sites an incentive to upgrade. B. New (site/host) connecting to a legacy (site/host) B.a New (site/host) being able to directly connect with to legacy addresses Again, this is provided by both HIP and SHIM6. B.b New (site/host) not being able to directly connect with legacy systems B.b.a "Reverse" proxy service Under certain not-so-simple circumstances we could imagine a proxy service that would provide any interested legacy systems a "presence" in the new system. That is, any legacy host/site could register with the proxy service, the proxy service would allocate it an ID in the new system, and allow new sites/hosts connect to the legacy one through it. I'm sure there are options I'm not listing above, but I must go now. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@... https://www1.ietf.org/mailman/listinfo/architecture-discuss |
|
|
|
|
|
|
|
|
|
|
|
Re: Major practical decision
by Tony Li
::
Rate this Message:
|
