Re: [MEXT] Important considerations for directionality of flow bindings

["Yuri Ismailov" <yuri.ismailov at ericsson.com>]

Julien,
I agree entirely with your comment about Internet area and support of a
perfect couple.
I wrote many times that this is not the place for such standardization
or may be does not have to be standardized at all because in many cases
it probably will not exposed to the outside world, just staying in an
administrative domain.

I'm trying to focus on flow mobility and a best possible match between
available interfaces and flow requirements under policies constraints.
I made an attempt to summarize my assumptions (my last email) in order
to see if there is any future of this discussion.
If we will not agree on assumptions then there is no reason in
convincing anybody

/yuri


-----Original Message-----
From: Julien Laganier [mailto:julien.laganier.ietf at googlemail.com] 
Sent: Friday, June 05, 2009 12:13 PM
To: Yuri Ismailov
Cc: mext
Subject: Re: [MEXT] Important considerations for directionality of flow
bindings

Yuri,

Sorry for the late answer but I had other commitments. Please see
inline.

On Tue, Jun 2, 2009 at 4:17 PM, Yuri Ismailov
<yuri.ismailov at ericsson.com> wrote:
> Julien,
>
> Probably some missunderstanding comes from the different scope of 
> viewing at the general deployment of MIP protocol(s) I'm trying
(whether successful or not?) not to restrict the view to just flow
binding as such but to look at somewhat bigger context where MIP support
is a part of the whole, playing important role.

I'm all for looking at the big picture as long as we do not try to use
the IP mobility sub-layer for things which are unrelated to IP mobility.
If we can agree on this, let's proceed.

>> How do you make your HA know that the address XYZ your MN just
SLAAC'd at the starbucks downdown is assigned towards on a 54Mbs WiFi
link?
>> Are you driving back to home to configure appropriately your HA while
the MN stays at starbucks?
>
> The key is that one may use (I definetly would) applciation level to
communicate any kind of parameters between HA and MN. I do not mean
routing rules. Basically anything else. If one finds that the fact of MN
being attached to 54Mbs WiFi link is useful information for HA, then
there is nothing preventing to send this information to HA without
involving MIP.

For the purpose of discussing the point above only:

If you'd like you can assume that MN and HA are exchanging "any kind of
parameters", and thus that the HA knows all the useful information it
needs/want to know about the MN context.

But once you're making this assumption, you have to let me conversely
assume that the MN knows all the useful information it needs/want to
know about the HA context.

So what's the point? Why do I care devising application layer
relationships in a perfect couple while I'm sitting in the Mobile IPv6
Extensions WG in the Internet Area...?

> Next important thing, in my view, is that the logic generating this or
that set of routing rules whether implemented in MN or HA or both has
nothing to do with MIP. This logic is about how to choose an interface
for a particular flow and in theory may be delegated to a third party
node (do not think this is a good idea though). This is the reason why I
don't entirely agree with your statement:
>
>> I believe there's a valid reason which is called protocol layering.
>> Rules dealing with choice of a MIPv6 Care-of address do belong to the
>> MIPv6 layer. Policies regarding which access technology to use for a 
>> given app/service/etc. do not belong to that layer

I agree with you that the "logic is about how to choose an interface for
a particular flow".

The point I tried to make above is that once the choice is made (and
wherever that happens, e.g. in a third party) and interface X is
selected, the enforcement of that choice requires selecting a CoA for
the flow, a CoA is a concept that belongs entirely to mobility
sub-layer, and the only entity that can derive from "interface X" the
CoA to use for the flow is the MN.

> Basically rules is instantiation of policies and as I see it, first
the choice of access is made, secondly an IP address is pointed out, but
not because the IP address is suitable for a flow or belongs to IP
layer, but because it turned out to be configured on the suitable
access. Thus, I would not state that rules are dealing with any kind of
choice, on the other hand rules are the result of choice.

There we agree again.

>> An information is important in a given context. I do not care what's
the status of your WiFi card, I care about the status of my card.
>>
>
> This is sad:-) If you could get a hint about my status, you could
possibly make a better choice. Not for the sake of analogy, just an
example: SIP has negotiation procedure of session parameters, which
makes things nicer. The word "hint" characterizes quite well the fact of
sending rules from HA to MN. As I wrote earlier, MN does not have to
follow the HA generated rules, however may take into account.

Again, wherever the policy is applied in selecting an interface,
whatever is the process, using hints, or any other input parameter in
the decision, this does not change the fact that the MN only knows which
CoA to pick to satisfy the choice of interface resulting of the policy.
In my view this is a fact, and I'm guessing this is our main (and only?)
point of disagreement.

>> 51% majority is not "rough consensus", this is voting.
>>
> What is the rough consensus then? Who decides that the rough consensus
is achieved?

Quoting RFC 2418, a.k.a. IETF Working Group Guidelines and Procedures:

    "It is up to the Chair to determine if rough consensus has been
reached."

Hope it clarifies.

--julien