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

From: Julien Laganier <[email-masked]>
Date: Tue, 2 Jun 2009 14:42:23 +0200

Yuri,

On Fri, May 29, 2009 at 9:35 AM, Yuri Ismailov
<[email-masked]> wrote:
> Hesham,
>
> This is nice story and makes some sense for the discssion, however some
> details are ommited. In your adventure with the helpdesk, it (the helpdesk)
> is a third party service and thus your conclusions make sence. Think of the
> situation when superior of a heldesk person will tell him/her to check
> access point in some room. Would it be the same reaction? I assume not. By
> that I mean that if, for example, I'll install home agent in my home
> network, I can make it know anything I want about MN, and more intresting is
> that how I will do it, does not require any standardization. In other words,
> I'm superior of my HA.

I have nothing against being the superior or having one, but I'm a bit
lost with the point of the analogy...

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?

> This situation is not unthinkable, I personally believe that this is much
> more efficient way of using HA fnctionality as opposed to big service
> providers who will have to fight with scalability and performance. However,
> one does not exclude another.
>
> Difference between policies and rules is a convertion step. Is there any
> reason to restrict where such convertion takes place?

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.

> True that a HA does
> not know what is going on in the access network, on the other hand HA may
> know what is the network condition between HA and correspondent node. Either
> of this information is important, if not equally important.

Nobody said information X is not important while information Y is.

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.

The point is, the information of what is happening on the links to
which the MN is attached is of utmost importance in choosing which
care-of address to use because the choice of care-of address in turns
implies the choice of a link, and this is most likely a wireless link.

On the other hand, choosing a care-of adddress has no impact nor is
impacted by the network conditions between the HA and the
correspondent node.

> BTW, what is the numerical representation of "rough consensus"? I assume is
> when majority is for, is it so?

51% majority is not "rough consensus", this is voting.

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Jun 2009 07:40:32 -0700 (PDT)

It seems like some people are drawing paralels with PMIPv6 here.
I think that we shouldn't because in mext we have full MN input, e.g. MCoA draft is a good example. MCoA draft is now in IESG processing status.

Cheers,

Behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: Yuri Ismailov <[email-masked]>
Cc: mext <[email-masked]>
Sent: Tuesday, June 2, 2009 7:42:23 AM
Subject: Re: [MEXT] Important considerations for directionality of flow bindings

Yuri,

--julien
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 2 Jun 2009 16:17:21 +0200

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.

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

> MIPv6 layer. Policies regarding which access technology to use for a given app/service/etc. do not belong to that layer

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.

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

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

Regards
Yuri

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Tuesday, June 02, 2009 2:42 PM
To: Yuri Ismailov
Cc: Hesham Soliman; mext
Subject: Re: [MEXT] Important considerations for directionality of flow bindings

Yuri,

On Fri, May 29, 2009 at 9:35 AM, Yuri Ismailov <[email-masked]> wrote:
> Hesham,
>
> This is nice story and makes some sense for the discssion, however 
> some details are ommited. In your adventure with the helpdesk, it (the 
> helpdesk) is a third party service and thus your conclusions make 
> sence. Think of the situation when superior of a heldesk person will 
> tell him/her to check access point in some room. Would it be the same 
> reaction? I assume not. By that I mean that if, for example, I'll 
> install home agent in my home network, I can make it know anything I 
> want about MN, and more intresting is that how I will do it, does not 
> require any standardization. In other words, I'm superior of my HA.

I have nothing against being the superior or having one, but I'm a bit lost with the point of the analogy...

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?

> This situation is not unthinkable, I personally believe that this is 
> much more efficient way of using HA fnctionality as opposed to big 
> service providers who will have to fight with scalability and 
> performance. However, one does not exclude another.
>
> Difference between policies and rules is a convertion step. Is there 
> any reason to restrict where such convertion takes place?

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.

> True that a HA does
> not know what is going on in the access network, on the other hand HA 
> may know what is the network condition between HA and correspondent 
> node. Either of this information is important, if not equally important.

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.

The point is, the information of what is happening on the links to which the MN is attached is of utmost importance in choosing which care-of address to use because the choice of care-of address in turns implies the choice of a link, and this is most likely a wireless link.

On the other hand, choosing a care-of adddress has no impact nor is impacted by the network conditions between the HA and the correspondent node.

> BTW, what is the numerical representation of "rough consensus"? I 
> assume is when majority is for, is it so?

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 03 Jun 2009 16:33:29 +1000

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

=> So, in this statement you make the following assumptions:
1. That the MN knows what is useful for the HA to know
2. That it's useful to send information to the HA so it can respond back to
the MN with the consequences of the information sent. In essence, the MN
knows what link it is connected to, yet it sends that information to the HA
so it can tell it what to do about it. Does that really make sense to you?
Why? We really need to see a substantial list of benefits here because
otherwise this is a complete waste of a RT between the MN and the HA. What
could the HA possibly tell the MN that it doesn't already know??

> 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 orthogonal to the discussion about the directionality of rule
transmission. Of course the logic is generated by upper layers but there is
no relationship between the layer generating the information and the
direction of information flow. The same layer exists at both ends.

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 3 Jun 2009 08:46:31 +0200

As I just wrote events may take place anywhere in the network and it may
be the case that HA knows about that but not MN. If HA has relevant
information about MN parameters it can act upon event arrival, otherwise
not.
These to things are complementary and I have the rough consesus with
myself that MN has a priority in decision, but not accepting hints is a
limitation. Moreover, hints may come from any other node in the network,
not necessarily from HA.

/Yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2009 8:33 AM
To: Yuri Ismailov; Julien Laganier
Cc: mext
Subject: Re: [MEXT] Important considerations for directionality of flow
bindings

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

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

=> So, in this statement you make the following assumptions:
1. That the MN knows what is useful for the HA to know 2. That it's
useful to send information to the HA so it can respond back to the MN
with the consequences of the information sent. In essence, the MN knows
what link it is connected to, yet it sends that information to the HA so
it can tell it what to do about it. Does that really make sense to you?
Why? We really need to see a substantial list of benefits here because
otherwise this is a complete waste of a RT between the MN and the HA.
What could the HA possibly tell the MN that it doesn't already know??

> 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 orthogonal to the discussion about the directionality of rule
transmission. Of course the logic is generated by upper layers but there
is no relationship between the layer generating the information and the
direction of information flow. The same layer exists at both ends.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Fri, 5 Jun 2009 12:12:31 +0200

Yuri,

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

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

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

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

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

There we agree again.

> 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, w…

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.

> 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

---

From: "Yuri Ismailov" <[email-masked]>
Date: Fri, 5 Jun 2009 15:09:16 +0200

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:[email-masked]] 
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
<[email-masked]> 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.

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.

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.

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:
>> 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".

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

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

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

Hope it clarifies.

--julien