[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEXT] About the flow binding charter item



Hi Ryuji

Here is my comment on your comments

Full two-way flow binding operation is not necessary.
E.g, it seems to be unnecessary for CN to initiate flow
binding operation to MN

BR
Frank

----- Original Message ----- From: "Ryuji Wakikawa" <ryuji.wakikawa at gmail.com>
To: "marcelo bagnulo braun" <marcelo at it.uc3m.es>
Cc: "Julien Laganier" <julien.laganier.ietf at googlemail.com>; "Jari Arkko" <jari.arkko at piuha.net>; "mext" <mext at ietf.org>
Sent: Wednesday, May 20, 2009 5:56 PM
Subject: Re: [MEXT] About the flow binding charter item


Hi Marcelo,

On 2009/05/20, at 6:04, marcelo bagnulo braun wrote:

Hi,

There seems to be some discrepancies about the MEXT charter item
regarding the work on flow bindings.
Since the charter is the guide for our work, it would be important to
clarify it, so we can have a unified interpretation of the charter.
Please note that what it is in the charter is not cast in stone, but
it seems to reflect previous consensus and we need good reasons to
change it.

So, the current charter item about flow bindings reads:

- A "Flow/binding policies exchange" solution for an exchange of
policies from the mobile host/router to the Home Agent and from the
Home Agent to the mobile host/router influencing the choice of the
Care-of Address and Home Agent address. The solution involves two
specifications, one for the policy format and another for its
transport [both Standard Track].

The first problem with this text is the use and interpretation of the
word policy. Since the policy word may have a broad interpretation.
it would be important to make the charter more explicit about the
expected work. We understand that it is the WG consensus that what
need to be exchanged is a solution for the exchange of flow binding
rules.

So, we understand that it would be more explicit to replace the usage
of the expression Flow/binding policies exchange by Flow Binding
rules exchange. Would that reflect with the WG interpretation?

Second, the current charter item explicitly mentions that the
proposed approach must support sending flow binding information from
the MN to the HA and also from the HA to the MN. Moreover, the
current charter talks about influencing not only the selection of the
CoA but also the selection of the HA address. However, our current WG
document does not supports sending information from the HA and it
does not cover the possibility of influencing the HA address. So, one
possible interpretation of the charter would be that the MN sends
flow binding information to influence the CoA selection and the HA
sends flow binding information to influence the HA address selection.
Other interpretation is that both the MN and the HA send information
regarding both the HA address and the CoA selection.

So, we would like that the WG express their opinion on both items
mentioned above:

1- whether we should replace Flow/binding policies exchange by Flow
Binding rules exchange in the charter

agree

2- whether the information should be sent from the MN to the HA only
or it should also be sent from the HA to the MN and if the
information exchanged in each direction should affect the CoA and/or
the HA address.

I want to support both direction.
There is a case where an operator wants to install rules to MN.

The FID option is a mobility option and should be carried by other MH message. Ex. If FID option can be carried in generic notification message, we can easily support both directions. I don't see much difficulty to support both direction. We just relax to use other MH message to carry FID options.

btw, There is other reason that I want to decouple FID from BU.

- Updating two different status (binding and flow rules) by single message can optimize the # of signaling in some sense. However, even if only one of status change, the other status must be updated, too. Even though binding information is unchanged, MN need to send BU to refresh the rules.
  If MN changes the rules frequently, HA overhead might be increased.

regards,
ryuji










Regards, Julien and marcelo


_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext