Noel Chiappa allegedly wrote on 12/01/2009 6:07 PM: > When it comes to preferring network-based or host-based solutions, when > considering _architectural_ factors, I actually prefer the latter (because I > want to move functionality out of the network, to maximize long-term > flexibility). However, _engineering_ factors (e.g. the difficulty of changing > hosts) has long led me to conclude that _initial_ deployment has to be > network-based.
Both, actually. Endpoints are going to leap ahead in LIS because they need it. Particularly, mobile endpoints are going to want to optimize their use of networks. However, they still need to be able to communicate with others that have not been upgraded, so they will need rendezvous points. > Note that I did say 'initially' I think it will happen simultaneously. It is already. Noel Chiappa allegedly wrote on 12/03/2009 10:47 AM: > > From: Scott Brim <scott.b...@gmail.com> > > > Do you think routing and addressing requires a session ID in every > > packet? If not, let the upper layers find their own solutions > > In a clean, carefully integrated architecture I might agree with you > (although robustness arguments, which often involve redundancy, might > disagree). In something that's evolving over time, starting from something > that's already got some 'bags on the side', there might be a certain value > in carrying around the semi-duplicate info. But it is of course impossible > to say specifically without examining the costs and benefits of a > particular proposed design. Noel, my question was whether routing and addressing in particular require a session identifier in every packet. I don't see this as a R&A requirement. It's something that could be added to the IP packet header syntax, but not for the sake of routing and addressing -- they don't care. Right? Joel M. Halpern allegedly wrote on 12/03/2009 10:57 AM: > My own reaction to this question is similar. > I can imagine an architecture and set of tools where the responsibility > for the identification was either dynamic or an upper layer responsibility. > However, I think that we may be better off, in trying to get to a better > state, if the network / routing / lower layers provides a useful stable > identifier. Joel, you're talking about an identifier and identification functions that can be supported in the network layer, so it's a whole-node identifier. We've been going over this for about a year or more and I still argue from practicality. A useful stable identifier for what? Which functions would actually use it? > One example is that this provides a hook on which to hang the various > kinds of security mechanisms A whole-node identifier can be used as input to a security association, but so can a higher-layer identifier, and a whole-node identifier is insufficient to support finer-grain functions. , so that security is not tied to the > locators. (security tied to the locator seems to be a problem that we > gave ourselves by not having anything else for it to be based on.) Well, what I see a lot of is packets coming in from some address which is then validated -- by some higher layer security exchange. See above. > Similarly, it seems to me that having such an identifier simplifies many > of the problems of adding and subtracting locators from a site. While > one can structure all the changes in terms of old-set->new-set, it seems > much more robust to think in terms of an identifier aquiring new locator > information. All true since you just say "identifier" generically. A whole-node identifier ... one that can be managed by the network layer ... is significantly less flexible than a group of higher-layer identifiers. > This identification would seem to also be useful > eventually in terms of policy management (which often loives at these > layers), and related issues. When I establish a security association with a management entity, I don't talk to the whole node, I talk to the management entity within that node. We can dig up old mail if we need to and go through this all again. My main point in this thread was that routing and addressing, in themselves, do not require a particular identifier to be in every packet. Scott _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
