Hi John,

on 2007-02-14 18:12 [EMAIL PROTECTED] said the following:
> Jari,
> 
> At a high level, I think having a common mechanism & format for
> this kind of functionality would be a really good thing.  I think that
> this is applicable for MIPv6, NEMO, SHIM6, HIP, MoBIKE, etc. and
> defining point solutions for each protocol would be a wrong way
> to go.
> 
> I think the exact transport of the mechanism and security the
> mechanism may be a protocol specific issue, if they are defined
> within the specific protocols - however, it might be interesting
> to define a common protocol / solution, if it would meet the
> requirements of Monami (for example).  Has anyone done an
> analysis if doing this in-band is prefered over out-of-band
> (or visa-versa)?

There seems to be multiple opinions here.  Some analysis has
been done, leading to one of the monami6 proposals which
suggests out-of-band communication of filter rules: 
draft-larsson-monami6-filter-rules; but as mentioned there is
an alternative monami6 proposal which advocates in-band signalling,
so there isn't full consensus on this.

The main reason I see (as one of the authors of
draft-larsson-monami6-filter-rules) for doing this out-of-band
is that the timing of events which cause changes to the filter
rules seem to have little correlation with handover events in
monami6; and I would expect something similar for NEMO, SHIM6,
HIP and MOBIKE.

The actual *binding* of a particular filter rule to a particular
endpoint *will* change on handover, though; so it is important
to do the split between rule definition and endpoint binding
right to achieve proper decoupling.

<snip some good comments>

>>Without going into too much detail about the specific 
>>proposals it seems that there are actually a number of 
>>different topics here:
>>- carrier protocol choice
>>- policy container format
>>- timing of the policy exchange
>>- securing the transfer
>>- etc
> 
> I think those are some of the issues that need to be seen.  I'd
> think that policy container format SHOULD be common across
> protocols, and for the other bullets, based upon an analysis
> of in-band vs. out-of-band signaling uses, the other bullets
> can be sorted out.  If out-of-band signaling seems like a good
> way forward, then all of the bullets should be made so that they
> are usable by other protocols.  If we think that in-band signaling
> is a requirement, then we could define the common container
> format and then have protocol-specific solutions for the rest.

First a little note on terminology -- in the monami6 discussions,
we've tried to use the word 'policy' to cover a number of factors,
including user preferences, which could influence the choice (at
the MN) of paths for various traffic, while the actual rules conveyed
from MN to HA, which can be applied to the traffic flow, is referred
to as filter rules.  So rather than talk about policy container
format, I'd prefer to talk about filter rule container format...

Anyway, I'm in favour of the idea of making the filter rule
container format common across protocols, and I'd suggest that
in most cases, it would be appropriate to have a common defined
carrier protocol.  I'm sure we'll see cases where optimization
or other considerations will make it attractive to define in-band
filter rule transport, but if a common carrier protocol and
method for securing the transfer has already been defined, that
would hopefully be delta work, rather than complete re-invention.


        Henrik


_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area

Reply via email to