Comments on draft-nordmark-multi6dt-shim-00.txt

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

This draft was pretty easy to read. Here are some questions/comments on the draft.

1) In section 5,

   The context state in this approach is maintained per remote ULID i.e.
   approximately per peer host, and not at any finer granularity.  It
   might make sense to merge the context state for multiple ULIDs
   assigned to the same peer host, but this is for further study.

What does "maintained" above mean ? Section 9.3 says that transmit side
locates the context based on (ULID (local, remote) and receive side based on tags etc.
A bit of clarification would help here.

Also, i don't know what merging means above ? I guess you still need to maintain
explicit state on both ends so that two connections between same hosts using different
ULID pairs (A1, B1), (A1, B2) but same locators will need to be demuxed
differently ? 

2) Section 8 protocol walkthrough does not talk about some details e.g. how HBA
is used. In 8.2, it talks about locator change. But a little bit more detail would
help here. I assume that HBA state is established initially and verified only when the
locator set is different from the ULID. Is that right ? Again this is not clearly specified
anywhere (i have not read all thedocuments closely, so i could be missing something).

3) In Section 9, will the following approach also work :

     Never use the same set of locators across two different connections between the
     same hosts. I know it is not the best option, but for discussion it is okay i guess.

I can understand how the methods 9.1.1 and 9.1.2 helps the receiver map from locators to
the identifier. But this is not sufficient to just enough to map locators to identifier. You
also need someway to find out whether the locator pair has changed and if so validate
it.  You need to do two things on the receiver :

1) Map from the locator to to the right upper layer identifier.
2) Make sure that the locators are part of the same HBA set (or some such mechanism
    to prevent redirect attacks).

How does these two steps happen for 9.1.1 and 9.1.2 ? As identifier is known a priori,
i can see how (1) happens. How about (2) ? Is there still some state maintained at M6 layer ?
How is that state looked up ?  Some clarification would help.

4) In section 9.2.1 (Flow label), 

   The limitation imposed by this approach is that all the potential source
   and destination addresses have to be known beforehand by the receiver
   in order to be recognized.  This means that before sending packets
   with a new address, the sender has to inform the receiver about the
   new address.

I thought this is needed irrespective of which scheme we use ? Why is this
specific to the method ?

5) In section 9.2.2, context tag required only when the locator is different from identifier.
M6 layer is bypassed when there is no extension header. Is that right ?

thanks
mohan