Multipath management requires the posibility to deal with all forwarding paths to a given destination: best paths, detouring but loopless paths, detouring paths which include a crankback loop but are safe against endless loops. And to take care that a once selected path is consistently pursued. To enforce compliant forwarding the packet needs to convey a respective information. IMO, the hardly used v6FlowLevel should rather be redefined to become such a respective multipath-directive information ( I know, Robin suggested another usage)
But in order to provide all such capabilities you need to do routing "right".
Fundamentally right !!! Which includes the elimination of the scalability problem once and forever just as a side effect.
Heiner
-------- Kabel E-Mail Reply ---------------
From: hannu.flinck@nsn.com
To : rrg@psg.com
Date: 14.08.2008 08:58:41
Hello Brian
Can you bit elaborate what do mean by multipath management? It seems to
go beyond 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: & 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: & 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: & ftp://psg.com/pub/lists/rrg