Re: [MEXT] new pad sub-option and flow identifier assignment

[Hesham Soliman <hesham at elevatemobile.com>]

> 
>> If you really understood the spec you would see that it's not
>> possible for the HA to initiate a binding. Let alone being able to
>> know what interfaces work on the MN. That's why I keep saying that
>> the HA can send policies all day long to the MN, but in the end, the
>> MN has to decide what instances it needs and install those on the
>> HA's BC. Again, we had this discussion at least twice already in
>> monami6. Just because the WG was merged doesn't mean the arguments
>> should be forgotten.
> 
> I actually happen to think that I understand the spec, thanks for your
> warm consideration...
> 
> It is correct that the CoA bindings are unidirectional. But the HA can
> of course know what interfaces are working on the MN: It only has to
> look in the binding cache! The MN will unregister any non-working CoA.

=> Oh of course if an entry is in the binding cache then the corresponding
interface, base station, cell load, app preferences and end to end
reachability must all be valid for the lifetime of the binding...makes
perfect sense...These things just don't change once the CoA is in the
binding cache. Of course the binding cache also includes the corresponding
link layer properties associated with the CoA, which also never change. The
all-knowing omnipresent HA can then direct traffic as it sees fit.

Hesham

> 
> 
> Regards,
> Michael