[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-ietf-shim6-proto-01.txt

Hi Shinta,

will try to address some of the points you bring...

El 14/10/2005, a las 11:21, Shinta Sugimoto escribió:


Hello,

I've read draft-ietf-shim6-proto-01.txt.  I found the document very
helpful to figure out how shim6 would work. Please find my comments and 
questions below:

- From Section 1.3:


   Central to this approach is to not introduce a new identifier name
   space but instead use one of the locators as the upper-layer ID,
while allowing the locators used in the address fields to change over 
   time in response to failures of using the original locator.
This implies that the ULID selection is performed as today's default 
   address  selection as specified in [11].


  To me, what is stated in the last sentence does not seem to be an
ideal case. I believe it should be up to application whether to facilitate shim for a particular flow. Current protocol document seems to be taking 
  very flexible stance on how ULID is selected from the locators.
However, from application standpoint, ULID selection is significant in a sense that IP transaction should be based on ULID if the application 
  wants to preserve established communication taking advantage of shim.
IMHO, upper layer protocol should be able to get involved in ULID selection, 
  or at least, it should be able to distinguish ULID from the locators.
While perhaps is not completely there I think this is exactly what is being pursued in the spec... 
Let me try to expand on this:
with the respect to the ULID selection, rfc3484 states that if the application selects a given pair of src and dest address, this choice must be honnoured, (as long as there is no problem with the scopes). this behaviour is preserved here, meaning that if the app wants to choose the ULID, it can. Of course, maybe there will be some apps that will delegate to the lower layers to select the addresses, especially the src address, in which case, the selection is performed below the app 

With respect to the locator selection, we can say that:
- as long as the ULID is reachable, the ulid will be used as locator, so selecting the ulid implies selecting the locator. so considering the above comments, the app can choose the locators used at least before a rehoming event, since it selects the ulid - after a rehoming event, the locators are selected by the shim. At this point, the ulp can influence in the locator selection through forking. Now, i think that so far the spec doesn't includes a full description of how this is done, but the idea as i understand it is to allow the ulp to indicate the shim which locators to use for different flows. This would result in different apps using the same ulid pari, but using different locator pairs. (please find the fork word through the spec and see wome useful definitions about this point there)
I think that through these two techniques, the app can choose the ULID and the locators used for the communication, obtaining quite a lot of control of how packets are delivered through the shim... 
do you think that something else is needed?
- Section 1.5 discusses renumbering and its implications to shim. I agree 
  that there is a serious concern with regard to the ownership of ULID.
  A host may intentionally/unintentionally claim invalid ULID which is
  actually owned by different node. CGA would solve this.
- Section 5 provides details of the message formats. Very basic question 
  but why shim6 control message is designed as IPv6 extension header?
well, shim is a new layer in the stack (inside the ip layer) so as such it needs a header to pass information 


  I think the choice is reasonable.  Just curious about the motivation
  behind the design choice (piggyback?).


not sure what other options you where thinking here....
the only other option that was discussed was using a new destination option, but this was discarded because of problems related to how to handle the destiantion option when multiple destiantion options are there (i.e. ordering of the options, which one process first, how to construct the destiantion option header when there are multiple sources of destiantions options and the ordering would affect the resulting behaviour) 


  As for payload message,
  there is no doubt that extension header is suitable to carry the
  context tag (better than using flowlabel).  Another comment about
wording: Current texts in Section 5, especially in the first paragraph, 
  the design choice to use IPv6 extension header is not explicitly
  mentioned.  IMHO, it should be mentioned.
yes, the idea is to try to summarize the design alternatives in an appendix or separate document 


- Section 5.1 gives description about payload message format.


   2), there is a choice whether the shim applies inside the tunnel or
   outside the tunnel, which effects the location of the shim6 header.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |       0       |1|       Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Receiver Context Tag                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Why a bit followed by the Hdr Ext Len is set as "1" ? Is it for making 
  distinction between the payload message header and control header?


right


  I think a description about this bit would be helpful for readers.



agree


regards, marcelo


- (This is rather editorial comment though) Section 14 and 15 provides
  process of packet before/after the locator switch.  But I would
  prefer to descriptions separated in terms of direction of the traffic
  (inbound/outbound) rather than splitting before/after the locator
  switch.


Regards,
Shinta