[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 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: 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