Subject: RE: [Monami6] using MH is not a magic "re-use"

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 13 Nov 2006 19:01:11 -0800

> (following your suggestion to read
 > draft-soliman-monami6-flow-binding-03.txt)
 > 
 > I still maintain that the argument you made during of presentation
 > (using MH for flow bindings benefits from re-using existing MH
 > features) is invalid.

=> I didn't make the argument for the MH, I made the argument for MIPv6
(which includes the MH and more features).

 > 
 > After reading the draft I was wondering whether a MR preferring its
 > .11 interface for a flow over its .16 interface for another flow
 > reflects in any way a LFN's preference.  I don't think it's possible.
 >   Because the flow ID specifies IP addresses (src and dst) 
 > that must be
 > owned by itself.  There is no means for MR to act on behalf of LFN in
 > this respect, to reflect LFN's preferences.

=> The interface between the LFN and the MR is out of scope of both nemo
and monami6. But assuming that the MR is somehow informed of the LFN's
choice, I don't see the problem here. Of course the MR is authorised to
send BUs for the entire prefix, which includes all addresses, so yes it
can send a BU for a single address. 

 > 
 > This is a particular case where claiming use of MH for a new feature
 > (flow binding) magically takes advantage of existing features (NEMO).

=> I think you're the one adding "magic" here, are you putting words in
my mouth? ...sigh.

Hesham

 > 
 > Alex
 > 
 > _______________________________________________
 > Monami6 mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/monami6
 > 

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Nov 2006 05:22:11 +0100

Soliman, Hesham wrote:
>> I still maintain that the argument you made during of 
>> presentation (using MH for flow bindings benefits from re-using 
>> existing MH features) is invalid.
> 
> => I didn't make the argument for the MH, I made the argument for 
> MIPv6 (which includes the MH and more features).

Yes.

>> After reading the draft I was wondering whether a MR preferring 
>> its .11 interface for a flow over its .16 interface for another 
>> flow reflects in any way a LFN's preference.  I don't think it's
>>  possible. Because the flow ID specifies IP addresses (src and 
>> dst) that must be owned by itself.  There is no means for MR to 
>> act on behalf of LFN in this respect, to reflect LFN's 
>> preferences.
> 
> => The interface between the LFN and the MR is out of scope of both
>  nemo and monami6. But assuming that the MR is somehow informed of
>  the LFN's choice,

How?  There isn't any way for LFNs to inform MR about delegating
authorization.

> I don't see the problem here.

By not seeing a problem here you explicitely make a an assumption
about how NEMOv6 would work in order to support your statement that
flow bindings with MIPv6 and some of its features (NEMOv6 you cited)
work ok.  It doesn't work that way.

> Of course the MR is authorised

For MR to be authorized do flow bindings for the entire prefix it
would need a mechanism whereby all LFNs in that network authorize the
MR do these flow bindings.  Or, it can very well happen that not all
potential IP addresses within a prefix are assigned to a active LFN.
It can also happen that some LFNs prefer a different flow binding
than other LFNs.

> to send BUs for the entire prefix, which includes all addresses, so
>  yes it can send a BU for a single address.

I don't get that.  NEMOv6 BUs are not per-LFN, they're either explicit
(prefixes) or implicit (all hosts that HA's routing table decides).
LFN doesn't inform MR neither about BUs nor about its flows.

>> This is a particular case where claiming use of MH for a new 
>> feature (flow binding) magically takes advantage of existing 
>> features (NEMO).
> 
> => I think you're the one adding "magic" here, are you putting 
> words in my mouth? ...sigh.

Ah sigh, right, you didn't say "magic".  You said re-use MIPv6.  I
wasn't arguing about re-using MIPv6.  One could do flow bindings by
re-using MIPv6.  But that doesn't mean that all MIPv6 features work ok
with it, e.g. NEMOv6.  Which negates this feature as an advantage.
Please cite something else as a potential advantage.

Alex