[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