Handling multipath [Re: successful termination?]

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Joel,

I thought about that, but forgot to mention it. Thanks for the
reminder.

The same issue arises for SCTP. That's discussed
in draft-ietf-shim6-applicability section 5.3, which could
be expanded appropriately. And the SHIM_DONTSHIM option
in draft-ietf-shim6-multihome-shim-api probably solves the problem.

Of course, a more intimate blending of layers 3 and 4 might
be more optimal, but that seems like a research issue at the
moment.

   Brian

On 2009-04-06 09:50, Joel M. Halpern wrote:
> Actually, there is one reason for possibly sticking shim6 and
> multi-pathing in the same room for a little while.  (Not for making them
> the same working group.)
> As currently defined, shim6 will hide from multi-pathing the very
> information and control it wants.  This seems counter-productive.  A bit
> of cooperation ought to allow us to find a way to have the two bettter
> co-exist.
> 
> Yours,
> Joel
> 
> Brian E Carpenter wrote:
>> Hi Lixia,
>>
>> On 2009-04-05 16:53, Lixia Zhang wrote:
>>> On Apr 4, 2009, at 6:58 PM, Brian E Carpenter wrote:
>>>
>>>> Jari,
>>>>
>>>> If I look at both Geoff's and Olivier's (relayed) comments,
>>>> it's clear to me that there is work to be done.
>>>>
>>>> I agree that the address-pair selection issue is broader
>>>> than just shim6 (and is related to other things, such as
>>>> egress router selection). But there may still be some work
>>>> do here, on 'SHIM6 Requirements for Address Pair Selection',
>>>> even if the actual specification belongs in 6MAN.
>>>>
>>>> I agree that there is commonality of interest with multipath
>>>> transport, but it's far from clear to me that there is
>>>> actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
>>>> and multipath transport sure seems like a layer 4 shim,
>>>> which was a direction that MULTI6 explicitly choose not to
>>>> follow up.
>>> I wondered how to interpret the phrase "actual overlap" in the above...
>>> yes one solution works at transport and the other works at layer 3, so
>>> yes in terms of layers they are not at the same place.
>>> But in terms of goals, would you agree that their goals overlap?
>>
>> Sort of. But the shim6 goals were clearly aimed at RFC3582,
>> whereas I understand the goals of multipath transport to be
>> more aimed at load sharing, with failover as a secondary effect.
>> However, the mechanisms are so different that I don't see anything
>> to gain by sticking them in the same room at the IETF.
>>
>>>> That said, it's clear that the union of Geoff's and Olivier's
>>>> messages add up to a program of work, basically to find out if
>>>> SHIM6 is deployable and useful. I think it would be a shame
>>>> to pause before doing that.
>>> to see if I got it right: are you suggesting that we should first "find
>>> out if SHIM6 is deployable and useful", before making the decision on
>>> whether the WG should go dormant?
>>
>> No, I'm suggesting we should recharter the WG now, with the items
>> that Geoff and Olivier describe, most of which speak to making
>> shim6 (more) useful. Actual deployment work items would fall
>> under v6ops, I suppose.
>>
>>    Brian
>>
>>> if so, how does one go about to find that out?
>>> no matter how, I suppose this could be done quick?
>>>
>>> Lixia
>>>
>>
>>
>