Re: [RRG] On identifiers, was: Re: Does every host need a FQDN

[Brian Carpenter <brian@cs.auckland.ac.nz>]

[re-sent because once again psg.com is rejecting messages from gmail]

On 2008-08-14 18:49, Flinck, Hannu (NSN - FI/Espoo) wrote:
>  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. 

Not necessarily, if you believe Mark Handley. In his model, transport
congestion management automatically finds the best paths without any
topological knowledge. And in shim6, the reachability detection finds
working paths without any topoloogical knowledge. In these cases
we don't need any routing-type imformation in the hosts.

   Brian

> 
> - Hannu
> 
>> -----Original Message-----
>> From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 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 rrg-request@psg.com 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 rrg-request@psg.com 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 rrg-request@psg.com 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 rrg-request@psg.com 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