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

[Shinta Sugimoto <shinta@sfc.wide.ad.jp>]

Hello Marcelo,

Thank you for your comments. Please find my replies inline.

On Sat, 15 Oct 2005 18:46:32 +0200
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

> Hi Shinta,
> 
> will try to address some of the points you bring...
> 
> El 14/10/2005, a las 11:21, Shinta Sugimoto escribis:
> 
> > 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

Ok, I agree with your statements above.

> 
> 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

Yes, it sounds reasonable.

> - 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)

Yes, application would definitely get involved in context forking in
which context is handled in finer granularity than ULID pairs.

> 
> 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?

Hmm.  I am not completely sure but I see slightly different issue with
regard to the interaction between the ULP and shim6.  Let me try to
explain that:

I think ULP (or simply application) may want to decide whether to use
shim6 or not.  In other words, whether if the application wants to have
shim6 support for its flow.  IMO, this decision is different from what
is called ULID selection.  ULID selection is (if I understand it correctly)
a choice of which ULID to use for particular flow.  As you mentioned,
ULID selection can be made through source address selection.

For instance, in MIP6, ULP may choose not to take advantage of MIP6 by
specifying source address as one of the locators (CoA).  This is quite
simple.  As far as the system provides a piece of information to
distinguish HoA from the other IPv6 addresses, this would work.  Although
CoA and HoA are both in form of IPv6 address, they are distinct
IP address (as far as the mobile is away from its home).

In comparison to the MIP6, situation is a bit different in shim6.
Although ULID and locator are conceptually different thing, ULID is
at the same time one of locators.  This poses me following questions:

Q1: Who decides which locator to be used as ULID ? (Shim6? ULP?)
  - IMHO, it would make sense to let ULP to decide.  According
    to the decision, shim6 takes care of context establishment.

Q2: Who makes the ULID selection ?
  - I agree that one choice would be to let ULP make selection
    through source address selection. It would also possible of course
    that ULP has no specific preference on which ULID to use, which will
    result in kernel choosing the source address as defined in RFC 3484.

To summarize, I think your comments are answers to Q2 above (actually
its more than answers to Q2 but IMHO it does not cover answers to Q1).
Taking look at Q1 from slightly different angle, I wonder how could
application decide whether to request shim6 support or not.  What do you
think?

> > - 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

Yes.  Even though shim6 is conceptually a protocol inside the IP layer,
I think that shim6 header could be other than IPv6 extension header.
But I found the answer in Erik's email and some other documents.

> 
> >   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)

I see.

> 
> >   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

Ok.

[snip]

Regards,
Shinta