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

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

Hello Marcelo,

Sorry for the delay, but let me resume discussion on the email
thread which was suspended due to my absence about two weeks ago.
We were having discussions about need of interaction between ULP
(application) and shim6 in terms of activating shim6 feature for
particular flow.  I've snipped the points on which we already agreed.
Please find my responses inline.

On Mon, 17 Oct 2005 17:47:46 +0200
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

[snipped]

> 
> > 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?)
> 
> ok, now i lost it
> for now, all locators are ULIDs and all ULIDs are valid locators (we 
> are exploring the possibility of using ulids that are not valid 
> locators, but not there yet)
> 
> So, when the ULP selects the ulid, it is actually selecting the locator 
> to be used initially as long as no failure occurs
> through forking the ulp can change to other locator
> After a failure, the shim selects the alternative locator to use, but 
> there are also forking here and also preferences
> 
> But i feel that this is not the point here. A i understood your point 
> above is that you think that it would be useful to allow a ULP to avoid 
> using the shim for its traffic.

Yes.  This may sound negative, but I think it is needed.

> As i see it, this is not performed by selecting a given ULID or locator 
> (as it would be in MIP, selecting the CoA)

Right.

> Here as i see it we would need something else, for instance:
> - an extended API (TBD) which allows ULP to indicate the shim that no 
> shim services are required for that flow

Yes, this is the one suggested by Erik (having socket option something
like IPV6_DONTSHIM).

> - configuration of the heuristics that trigger the shim establishment, 
> so that the shim context is not established for those flows that use 
> certain apps (this is somehow limited, because in case that we have two 
> apps, one that wants the shim and other that doesn't want it, then this 
> mechanism wouldn't work, and we would need to use the API above)
> 
> [Please note that shim protocol as currently defined supports this. I 
> mean, because we are using the shim payload header to indicate if a 
> packet needs to be rewritten, we can have two apps using the same 
> locators, one of which need to be rewritten by the shim and the other 
> that doesn't requires locators to be rewritten.

Yes, it's true that current shim6 design allows receiver to determine if
the packet requires demux or not by checking appearance of shim payload
header.

> for example, consider app1 uses A1 and B1 as ULIDs and locators.
> Now consider app2, that uses A2 and B2 as ulids and locators.
> Now suppose that app1 doesn't want to use the shim and that app2 does 
> want to use the shim.
> so a shim context with ulids A2 and B2 is created and suppose that A1 
> and B1 are alternative locators for those ulids (for app2)
> Now, for any reason, app2 traffic starts using A1 and B1 as locators
> At this point, both app1 and app2 traffic would be flowing using A1 and 
> B1 as addresses in the IPv6 packets. However, packets corresponding to 
> app1 wouldn't carry the shim header so no need to rewrite while packets 
> corresponding to app2 would carry the shim payload header, so they will 
> be rewritten, so no proble with supporting one app traffic that don't 
> requires the shim. The only problem here is how the app indicates the 
> shim that it doens't want shim services, agree?]

Yes, that's exactly the point that I was trying to make.  It's slightly
more than that, actually.  Please find my further comments below.

> 
> >   - 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?
> >
> 
> i think that this point is important, see above for the optins that i 
> can think of, do you have another idea of how this could be done?

As for negative indication, I think we need to define a new socket
option which indicates a request from application that it does not want
its flow get shimmed.  It seems to me that we may also need a mechanism
for "positive indication" which allows application to proactively
request particular flow get shimmed.  But I am not sure how this should
be realized.  One option would be to specify default behavior of source
of the shim node in terms of activating shim for particular flow.  Note
that this is different from the source address selection issue.  Another
option would be to define a new socket option (something like IPV6_SHIM)
which can be used for positive indication provided by the application
layer requesting for shim support for its flow.  Another approach would
be to let application make decision through proactive source address
selection.  If this is the case, system should specify which IPv6
address can be used for ULID.  This is rather similar to the case of
MIPv6 in which permanent identifier (=HoA) is given by the system.
Then the issue (how app can activate/deactivate shim6) can be simplified.
It's up to source address selection (RFC3484 + bis).

Well, my personal view on concept of ULID may be different from others,
I appreciate if you could hear your thoughts on this.


Regards,
Shinta