Re: [shim6] WG Last Call for draft-ietf-shim6-multihome-shim-api

[Miika Komu <[e-mail]>]

Brian E Carpenter wrote:

Hi,

thanks for your comments! I basically I agree with the rest of your 
comments, but I think the comments on SCTP and multipath TCP needs more 
discussion.

 > ...
> Also in the Introduction
> 
>>    This document recommends that the switching of identifier and locator
>>    is done only once inside the TCP/IP stack of an endhost.  That is, if
>>    multiple shim sub-layers exist at the IP layer, any one of them
>>    should be applied exclusively for a given flow.
> 
> I agree with this, but does it really belong in the API spec? It seems
> more like something for an applicability statement. However, if this
> stays, I think it should be very explicit, adding something like:
> 
>   Specifically, only one of SHIM6 and HIP should be in use, and neither
>   of them are compatible with SCTP or multipath TCP.

this interesting grey area at least for me. Why SHIM6 and HIP are not 
compatible with SCTP and mTCP? Both SHIM6 and HIP are low layer 
mechanisms where as SCTP and mTCP are operating at the transport layer. 
I'm not sure if the SHIM protocols are incompatible with the transport 
layer ones, but they do offer somewhat overlapping functionality.

> (see http://www.ietf.org/mail-archive/web/multipathtcp/current/msg00178.html
> for example)

Are you familiar with this work:

http://tools.ietf.org/html/draft-pierrel-hip-sima-00
http://www.cs.helsinki.fi/u/gurtov/papers/broadnets09.pdf

>> 4.  Requirements
> ...
>>    o  Turn on/off shim.  An application should be able to request to
>>       turn on or turn off the multihoming support by the shim layer:
>>       *  Apply shim.  The application should be able to explicitly
>>          request the shim sub-layer to apply multihoming support.
>>       *  Don't apply shim.  The application should be able to request
>>          the shim sub-layer not to apply the multihoming support but to
>>          apply normal IP processing at the IP layer.
> 
> We might add a note that this function is also required by any multipath
> transport layer such as SCTP or MPTCP, with the details being operating
> system dependent.

Just based on your earlier incompatibility statement, I don't really see 
why we should drag SCTP and mTCP all the way here, but I'll wait for 
your comments on the incompatibility first.