[netext] draft-ietf-netext-pmipv6-flowmob-04 Section 3.2.2

[Behcet Sarikaya <[e-mail]>]

Hi Carlos,
I am unabe to understand this sentence at the beginning of Sec. 3.2.2
(as we discussed in the previous thread):

A different flow mobility scenario happens when the local mobility
   anchor assigns different sets of prefixes to physical interfaces of
   the same mobile node.

Again, this statement:

Since the local mobility anchor cannot send a PBA message
   which has not been triggered in response to a received PBU message,
   new signaling messages are defined to cover this case.

Why not structure it in two sections: LMA Initiated Flow Mobility
where you need to define new signaling and
MAG Initiated Flow Mobility where existing PBU/PBA exchange can be used?

For  LMA Initiated case, why do you think Flow Identification Mobility
option initiated by MN would be sufficient? Shouldn't LMA be able to
do more things? More actions?

Below on Page 13, you have:
The MAG MAY also include the Flow
   Identification Mobility option in the PBU message that it sends to
   the LMA.  This serves as a request from MAG to LMA to consider the
   flow policy rules specified in the option.

This is basically defining MAG Initiated flow mobility.

How would a MAG know that MN has multiple interfaces?

Only LMA can inform MAG about this, please see
draft-sarikaya-netext-flowmob-ext-00 that I posted last week.

My overall comment is that in Section 3 there is too much emphasis on
the prefix assignment and not enough emphasis on the real protocol
issues. I am not convinced that playing with the way PMIPv6 assigns
HNPs is the solution to flow mobility.

Regards,

Behcet