Subject: Re: [shim6] Comments on the draft-ietf-shim6-multihome-shim-api-08

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 03 Jun 2009 11:27:56 +0900

Hello Samu,

Thank you very much for reviewing the multihome shim API draft.
Please find my comments inline:

Varjonen Samu wrote:
> Hi,
> 
> Some comments on the draft-ietf-shim6-multihome-shim-api-08.
> 
> Section 1. Introduction. I would prefer "network layer" instead of 
> "IP-layer" (2 instances in introduction and 1 in fig. 1).

Ok, will change "IP-layer" to "network layer".

> Shim is explained as a sub-layer in network layer and is referred as 
> "shim sub-layer" and "shim layer" through out the document. I would just 
> use one form uniformly through out the document. Sub-layer one would be 
> my choice and it would rule out any ambiguity from the text as some 
> parts talked about shim like it would have been its own layer.

Ok, I will keep it consistent throughout the document.
I agree that "shim sub-layer" would be more suitable term.

> 
> Section 1. Introduction (second paragraph) tells that locator changes 
> should be hidden from upper layer protocols. In general this is true but 
> how about protocols/applications based on location awareness?

We believe that some applications may want to be aware of locators that 
are used to send or receive IP packets, and that's one of the reasons 
why we wrote this API document.

The second paragraph intends to explain the meaning of the shim layer in 
a general sense by addressing the problem of IP address change under the 
multihomed environment.  The IP address which is considered as a 
communication endpoint from the upper layer protocol (i.e., identifier) 
should be kept unaltered during the session lifetime, while the IP 
address used for routing packets (i.e., locators) may be changed.  And 
the sentence you referred are talking about the former, the need for 
having a stable communication endpoint.  I will rephrase the text to 
avoid confusion.

> Section 4. Requirements. To me it looks like the requirements is missing 
> one important case. Application may want to set used addresses 
> (SHIM_LOC_*_RECVs and SHIM_LOC_*_SENDs). The current version looks like 
> applications only need to obtain the information from shim sub-layer.

I don't think I am following you hear.  Could you elaborate more about 
SHIM_LOC_*_RECVs and SHIM_LOC_*_SENDs?  What do you mean by "used 
addresses"?

> Section 5. Socket Options...
> In descriptions on most options that have "o" in get and set just say 
> "request" (get) or "inform" (set) or "specify" (set) while it is 
> possible to get and set the information. I think this should be "Get or 
> set the option" for all "get and settable" in this list. Same goes for 
> the sections 5.*. Some of them start "can be set" and then later in 
> example it is mentioned that it can also be obtained.

Ok.  Let me do sanity check of Section 5, and I will try to keep 
consistency.

> Section 5.4 has double specify in the first sentence.

Noted.

> In sections 7.2 and 7.3 the explanations of reserved fields, in my 
> opinion, should be unified to say "Must be initialized to zero and must 
> be ignored by the receiver"

Ok.

> The document left me puzzled on the situation if I deferrer the ctx 
> setup and start off with plain IP and then upgrade to shim. Does the 
> shim handshake start simultaneously with the plain IP communication or 
> after some timer or can the implementor trigger it (with SHIM_DONTSHIM 
> set to 1 in the middle of the communication?) and can I turn shim off 
> during the communications? To my knowledge shim6 does not have any close 
> procedures, so to me it looks like I would have to abandon the ctx for 
> garbage collection by closing the socket.

In the case of deferred context setup, the way to initiate SHIM6 context
establishment is an implementation specific issue, I think.  I mean,
implementation can choose any strategy about when (or under what 
circumstance) a context establishment shall be initiated.

With regard to the SHIM_DONTSHIM socket option, we have not discussed 
much (among co-authors, I mean) about how the SHIM6 stack should react 
when the SHIM_DONTSHIM was set during the communication (and the session 
is already shimmed).  In my opinion, the SHIM6 stack must immediately 
teardown the context when the application requests to NOT apply SHIM6 
during the communication.  I think you are right that there is no close 
(teardown) negotiation specified in the SHIM6 protocol spec, and I 
wonder how the peer would know the need for tearing down the SHIM6 
context.  Suppose applications APP1 and APP2 are running on hosts H1 and 
H2.  The session was automatically SHIMmed and eventually APP1 requests 
the SHIM layer to not apply SHIM6 for the session.  Then tearing down 
the SHIM6 context can be done on H1, but not on H2.  The consequence is 
that H2 would keep sending SHIMmed packets to the H1.  Unless H1 
preserves the established context, it has no clue to demultiplex the 
SHIMmed packets.  I may be missing something, but I think your question 
is valid.  Let me discuss this issue with co-authors.

Thanks again for your comments.

Regards,
Shinta

> BR,
> Samu Varjonen
> _______________________________________________
> shim6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shim6
>

---

From: Varjonen Samu <[email-masked]>
Date: Tue, 09 Jun 2009 12:11:18 +0300

Hi,

Left out the OK parts and left the unclear parts.

Shinta Sugimoto wrote:

>> Section 4. Requirements. To me it looks like the requirements is 
>> missing one important case. Application may want to set used addresses 
>> (SHIM_LOC_*_RECVs and SHIM_LOC_*_SENDs). The current version looks 
>> like applications only need to obtain the information from shim 
>> sub-layer.
> 

Well if we forget about the SHIM_LOC_*_RECVs and SHIM_LOC_*_SENDs for 
now. I meant that for me it looked like the requirements did not include 
the possibility for the application to tell to the shim sub-layer that 
use this address as the src when sending. This actually is covered by 
RFC 5014 and simple bind(). There is nothing shim specific that would 
differ from 5014, I guess?

BR,
Samu Varjonen

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 10 Jun 2009 11:16:55 +0900

Varjonen Samu wrote:
>>> missing one important case. Application may want to set used 
>>> addresses (SHIM_LOC_*_RECVs and SHIM_LOC_*_SENDs). The current 
>>> version looks like applications only need to obtain the information 
>>> from shim sub-layer.
>>

Hi Samu,

I think now I understand what you are talking about.
Actually the API provides a tool for applications to specify src/dst 
locators as you mentioned.  Src/dst locator selection can be made by 
application using SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND.  See 
section 5.9 and 5.10 for details.  On the other hand, I notice (thanks 
to your comments) that the current document does not clearly address 
requirements from applications about the src/dst locator selection.  Let 
us revise Section 4 (Requirements) accordingly.

Please note that our API is dealing with locator selection and not 
identifier selection.  The socket options that I mentioned above allows 
applications to specify source and/or destination locator when sending 
IP packets.  The reason why we only focus on the locator selection is 
that we believe identifier selection can/should be made by the existing 
mechanism (e.g., RFC 3484, RFC 5014).  In general, application may or 
may not specify its source address when initiating a session.  In the 
former case, application explicitly specifies the source address by 
using the bind() system call as you mentioned.  In the latter case, the 
kernel selects the source address as per RFC 3484.  In any case, the IP 
address selected (either by app or kernel) can be considered as an 
identifier in the ID/Locator context.  It is because the IP address is 
regarded as an communication endpoint to the upper layer protocols.  And 
we do not intend to make any changes to the existing src/dst address 
selection mechanisms.

Hope this helps.

Regards,
Shinta

---

From: Samu Varjonen <[email-masked]>
Date: Wed, 10 Jun 2009 09:29:50 +0300

Shinta Sugimoto kirjoitti:
>>> I don't think I am following you hear.  Could you elaborate more 
>>> about SHIM_LOC_*_RECVs and SHIM_LOC_*_SENDs?  What do you mean by 
>>> "used addresses"?
>>>
>>
>> now. I meant that for me it looked like the requirements did not 
>> include the possibility for the application to tell to the shim 
>> sub-layer that use this address as the src when sending. This actually 
>> is covered by RFC 5014 and simple bind(). There is nothing shim 
>> specific that would differ from 5014, I guess?
> 
> Hi Samu,
> 

Identifiers, that was the thing that was nagging me with the bind. 
Thanks for reminding :)

-- 
BR,
Samu

"Programmer is an organism that changes caffeine into code"