Hello Brian Can you bit elaborate what do mean by multipath management? It seems to go beyond <src, dst, sport, dport> tuple. Having multipath management in the hosts requires some visibility into the network topology beyond having multiple src, dest addresses or multiple locators.
- Hannu >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >Of ext Brian E Carpenter >Sent: Thursday, August 14, 2008 01:54 >To: Iljitsch van Beijnum >Cc: Scott Brim; rrg Group >Subject: Re: [RRG] On identifiers, was: Re: Does every host need a FQDN > >... >> Let's inventory what we need identifiers for: >> >> 1. demultiplexing >> 2. access control >> 3. error detection >> 4. referrals > >What about session labels, e.g. for security associations? >That is more than demultiplexing. > >What about multipath management? Again, that seems more than >just demultiplexing. > >> >> And what we need locators for: >> >> 5. forwarding packets >> 6. sending back control messages >> >> Note that all of these uses of identifiers can be limited to the >> application or session layers so there is no need for identifiers to >> appear in any layer 3 or 4 headers - > >True, but they will "appear" invisibly in transport and >cryptographic checksums. Decoupling these from >locator-addresses seems to be a feature (among other things, >it makes NAT transparent to checksums). > >> if we don't mind changing >> applications and APIs to map application layer identifiers to >> transport and lower layer locators. >> >> But changing applications is a non-starter, because the number of >> applications is so huge and application writers simply lack the >> knowledge to interact with the network properly. After 10 >years there >> are still applications that don't know how to work over >IPv6, for instance. >> >> Now NOT changing applications means that the identifiers must look a >> lot like regular IP addresses. > >More precisely, it means we can't change the socket API, so I >think a shim in the socket layer may be the way to go. > > Brian > > >> With shim6, we avoided a mapping system at significant cost: we need >> assistence from applications when the initially chosen identifier is >> not currently a reachable locator. Also, >> shim6 feedback indicates that a pure host solution is not what most >> people want, and requiring changes on both ends is a big deployment >> barrier. >> >> If we want to do all of this in middleboxes we pretty much end up in >> LISP territory. The data plane issues with that are fairly well >> understood by now, but this requires a identifier-to-locator mapping >> service, which is not that well understood currently. >> >> Do we have consensus yet on what would be the best place to >solve the >> problem? >> >> -- >> to unsubscribe send a message to [EMAIL PROTECTED] with the word >> 'unsubscribe' in a single line as the message text body. >> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg >> > >-- >to unsubscribe send a message to [EMAIL PROTECTED] with the >word 'unsubscribe' in a single line as the message text body. >archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg > -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
