Subject: Re: [Monami6] Re: MCoA vs Flow Bindings: Solving same problem?

From: Koshiro MITSUYA <[email-masked]>
Date: Wed, 05 Jul 2006 14:00:40 +0900

Hi Nicolas,

Please fine my comments inline.

<snip>
> > > >>> For example, if a flow identification option includes some error,  
> > > >>> you
> > > >>> have to re-send the binding update even the binding itself was valid
> > > >>> just to register a CoA.  Am I right?
> > > >>
> > > >> => No, you're not. Perhaps the current draft wasn't the clearest  
> > > >> but I
> > > >> think the new versions is much clearer. We don't invalidate the BU
> > > >> because the flow option was not valid.
> > > >
> > > > OK.  But what do you do to register an invalid flow option?
> > > 
> > > If the BU is valid, but not the Flow id option, the BU is accepted,  
> > > i.e. the CoA is registered in the BC of the receiving node (without  
> > > flow binding extension).
> > 
> > Yes, I've understood this point.  My question was what do you do to
> > register/fix the invalid flow id option again?
> 
> If the Flow Id option was refused, there might be 2 reasons:
> 	- either the node does not support the extension. The MN can see that
> if the flow id option is not included in the BA. In this case, I am
> afraid there is nothing that can be done, except using Standard MIP
> 	- or the flow Id option was refused for technical or administrative
> reason. This reason will be transported in the BA (in a flow id option)
> 
> I guess this is not specific to our protocol, it is always like that.
> 

Yes, this operation is normal. 

I meant if you found such error, what do you do?  Do you resend the
singing including error again and again?  Or you keep the error-state
somewhere and never send such flow id option again?  Is is not clear
in your draft.

> > > >>> If so, binding signaling is used to negotiate policies.  This  
> > > >>> goes to
> > > >>> be complicated, I think.  How do others in WG think?
> > > >>
> > > >> => The premise is not true, so it's a non-issue.
> > > >
> > > > Why do you think it is not issue?
> > > 
> > > Hesham was saying that your "if so" which refers to the sentence  
> > > above is not true.
> > > In our draft, Binding signaling is used to set policies on HA/CN, but  
> > > this does not degrade MIP, since a bad-formed flow id option will be  
> > > ignored, and the BU will be treated as a standard BU.
> > > 
> > 
> > Yes. I understood.
> > 
> > > The point of the flow binding draft, is that if you register multiple  
> > > CoAs within MIPv6, you need policies that indicate how to use these  
> > > addresses. if you don't associate policies with these multiple CoAs,  
> > > it is almost useless to register several addresses (you can use this  
> > > method for backup and early registration).
> > > 
> > 
> > I agree this point.  We need policy from the beginning.  But there is
> > a case that we do not a dynamic policy exchange protocol.  For
> > example, policy is already installed when the equipment is shipped.
> 
> Which equipment do you talk about? MN or HA?

MN, in the above sentence. 

> > > So IMHO, as soon as you register multiple CoA, you need policies.  
> > >  From that point, IMHO it makes sense to include these policies  
> > > within BU in order to save bandwidth, instead of developing something  
> > > else.
> > 
> > You always needs to include these policies, right?  If 1000 BU sent, I
> > don't think we could really save the bandwidth.
> 
> I don't understand this point. Can you explain it? (Is it for NEMO,
> multiple CoAs, multiple policies for the same CoA?)
> (Just note thta you can include several Flow Id option within a single
> BU.)

IMO, if policy is not so dynamic, not changed often, it is waste of
bandwidth to always include FID option in every BU when much BU is
sent.  Sorry, if I misunderstood your draft.

regards, 
Koshiro

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

---

From: Koshiro MITSUYA <[email-masked]>
Date: Wed, 05 Jul 2006 13:44:50 +0900

Hi Koojana,

Good point.  Actually, I expect that a solution like MCoA does such
work.  Exchanging policy and Distribuing available pairs of CoA and
HoA do not always have to be the same protocol.

regards, 
Koshiro

At Thu, 29 Jun 2006 10:49:58 +0200,
Koojana Kuladinithi wrote:
> Hi Koshiro,
> > I agree this point.  We need policy from the beginning.  But 
> > there is a case that we do not a dynamic policy exchange 
> > protocol.  For example, policy is already installed when the 
> > equipment is shipped.
> > 
> 
> Though the equipments come with already set policies, there should be a
> s/w to access available CoAs and instructs HA's MIP binding cache to
> deploy policies, i.e. to tell how to distribute them among several CoAs.
> Isn't that?
> That's where "draft-soliman-" expplains these signalling
> 
> Koojana
> 
> > 
> > > Nicolas
> > > >>>> => I don't think so. The flow binding work has been around
> > > >>> for 5-6 years
> > > >>>> and
> > > >>>> I don't remember this being the WG opinion.
> > > >>>
> > > >>> In fact, draft-wakikawa was first submitted with some 
> > flow binding 
> > > >>> feature and the feature was removed by the WG suggestion.
> > > >>
> > > >> => "In fact"??? The fact is flow bindings were submitted 5 years
> > > >> ago in
> > > >> HMIPv6 then separated into another draft. draft-Fikouras was also
> > > >> submitted shortly after for MIPv4.
> > > >>
> > > >
> > > > So, both are true.
> > > >
> > > > regards,
> > > > Koshiro
> > > >
> > > >
> > > >
> > > >> Hesham
> > > >>
> > > >>>
> > > >>> regards,
> > > >>> Koshiro
> > > >>>
> > > >>>
> > > >>>>
> > > >>>> Hesham
> > > >>>>
> > > >>>>> regards,
> > > >>>>> Koshiro
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> At Thu, 22 Jun 2006 04:46:28 -0700,
> > > >>>>> Soliman, Hesham wrote:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> Gabor and myself are arguing that flow binding
> > > >>> should be an
> > > >>>>>>> extension to
> > > >>>>>>> be added on top of MCoA.
> > > >>>>>>>
> > > >>>>>>> Nicolas seems to adopt the position that flow binding is 
> > > >>>>>>> independent of MCoA.
> > > >>>>>>>
> > > >>>>>>> My concern was that this means we have two independent
> > > >>>>> solutions for
> > > >>>>>>> multiple care-of address registrations. (It does not
> > > >>>>> matter if one
> > > >>>>>>> provides additional flow filtering capabilities, and
> > > >>>>> one do not).
> > > >>>>>>
> > > >>>>>> => I don't understand why you say "It does not matter if one
> > > >>>>>>    provides additional flow filtering capabilities,
> > > >>> and one do not"
> > > >>>>>>    But anyway, more below.
> > > >>>>>>
> > > >>>>>>> I think it will be better to have the flow binding 
> > capability 
> > > >>>>>>> added on top of MCoA, giving us two solutions which solves
> > > >>>>> different problems.
> > > >>>>>>
> > > >>>>>> => Of course we attempted that at the beginning when we
> > > >>>>> were doing the
> > > >>>>>> flow binding draft. But it's not that clean to do it
> > > >>>>> unfortunately. This
> > > >>>>>> is mainly because the MCOA draft is so abstract. It
> > > >>>>> basically allows you
> > > >>>>>> to register more than one CoA without knowing the
> > > >>> purpose of this
> > > >>>>>> registration in advance. But as you can see, draft-soliman
> > > >>>>> doesn't need
> > > >>>>>> the BID in the MCOA draft as it already has an index
> > > >>> for each flow
> > > >>>>>> (FID). So apart from making things "look good" there is no
> > > >>>>> practical
> > > >>>>>> reason for building things on top of MCOA. I tried to
> > > >>>>> raise this issue
> > > >>>>>> in Dallas but we ran out of time before I got an answer to
> > > >>>>> my question.
> > > >>>>>> So I'll repeat it here:
> > > >>>>>> Do people thing there is value in defining the mechanism
> > > >>>>> for registering
> > > >>>>>> multiple CoAs without defining the use of such
> > > >>>>> registration? I.e. is the
> > > >>>>>> abstract concept with the BID useful by itself?
> > > >>>>>> Personally ,I'm struggling to see the use for it. Having
> > > >>>>> worked on two
> > > >>>>>> different solutions for registering more than one address
> > > >>>>> (For bicasting
> > > >>>>>> and flow binding), I'm inclined to think that each
> > > >>>>> solution will be self
> > > >>>>>> sufficient.
> > > >>>>>>
> > > >>>>>> Hesham
> > > >>>>>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 5 Jul 2006 14:49:06 +0900

Hi Nicolas
On 2006/06/29, at 0:41, Nicolas Montavont wrote:

> Hi Koshiro,
>
> On 28 juin 06, at 17:09, Koshiro MITSUYA wrote:
>
>> Hello,
>>
>>>> For example, if a flow identification option includes some  
>>>> error, you
> In our draft, Binding signaling is used to set policies on HA/CN,  
> but this does not degrade MIP, since a bad-formed flow id option  
> will be ignored, and the BU will be treated as a standard BU.
>
> The point of the flow binding draft, is that if you register  
> multiple CoAs within MIPv6, you need policies that indicate how to  
> use these addresses. if you don't associate policies with these  
> multiple CoAs, it is almost useless to register several addresses  
> (you can use this method for backup and early registration).

The backup and early registration are big motivation of multihoming.

> within BU in order to save bandwidth, instead of developing  
> something else.

Of course, for flow distribution to multiple tunnels, policy is  
required.
However, you only consider registering policy from MN. In real  
scenario, service operator (i.e. HA operator) may want  to put policy  
to MN.
Or the operator may want to configure policy statically on MN before  
shipping to users.
How do you handle this case?

ryuji

>>>> In fact, draft-wakikawa was first submitted with some flow binding
>>>>>>>> independent of
>>>>>>>> MCoA.
>>>>>>>> capability added on
>>>>>>>> top of MCoA, giving us two solutions which solves
>>>>>> different problems.
>>>>>>>

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Wed, 5 Jul 2006 16:05:22 +0200

Hi Koshiro,

> 
> Hi Koojana,
> 
> Good point.  Actually, I expect that a solution like MCoA 
> does such work.  Exchanging policy and Distribuing available 
> pairs of CoA and HoA do not always have to be the same protocol.
> 
> regards, 
> Koshiro
> 

I think, you misunderstood what I meant. Mapping policies to a CoA is
difficult. For. e.g. if the policy say "Secure applications has to be
forwarded only to CoA1", you can enforce this policy (using
draft-soliman) by asking HA to filter traffic that is coming from port
22 & 443 (ssh & https) to CoA1. This is where you have make granuality
to identify a flow rather than a CoA when you enforce a policy decision.

Regrads

koojana 

> > Though the equipments come with already set policies, there 
> should be 
> > a s/w to access available CoAs and instructs HA's MIP 
> binding cache to 
> > deploy policies, i.e. to tell how to distribute them among several 
> > CoAs. Isn't that? That's where "draft-soliman-" expplains these 
> > signalling
> > 
> > Koojana
> > 
> > > 
> > > something
> > > > >> => "In fact"??? The fact is flow bindings were submitted 5 
> > > > >> years ago in HMIPv6 then separated into another draft. 
> > > > >> draft-Fikouras was also submitted shortly after for MIPv4.
> > > > >>
> > > > >
> > > > > So, both are true.
> > > > >
> > > > > regards,
> > > > > Koshiro
> > > > >
> > > > >
> > > > >
> > > > >> Hesham
> > > > >>
> > > > >>>
> > > > >>> regards,
> > > > >>> Koshiro
> > > > >>>
> > > > >>>
> > > > >>>>
> > > > >>>> Hesham
> > > > >>>>
> > > > >>>>> regards,
> > > > >>>>> Koshiro
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> Personally 
> > > > >>>>>> ,I'm struggling to see the use for it. Having
> > > > >>>>> worked on two
> > > > [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
> > > 
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
> > > 
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 11 Jul 2006 03:56:43 +0900

Hi Nicolas

On 2006/06/29, at 17:44, Nicolas Montavont wrote:

> HI,
>
> On Thu, 2006-06-29 at 10:07 +0900, Koshiro MITSUYA wrote:
>> Hi Nicolas,
>>
>>

If there is an error in a flow ID option, how can HA accept the binding?
Doesn't flowbinding use the flowID to distinguish each binding?

If flowID is invalid and CoA is not the same as the CoA of the  
default binding,
does HA update the CoA of the default binding?

This isn't right operation in this case, no?

ryuji

>>> but
>>> multiple

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 11 Jul 2006 00:21:36 +0200

Ryuji,

On 10 juil. 06, at 20:56, Ryuji Wakikawa wrote:

>>>>>>> error,

This is true that if the HA has already several bindings between CoAs  
and flows, and receives a BU with an invalid flow binding, it can not  
update any binding. This is because the HA can not identify which  
entry the BU was referring to.

But if the home agent has not a binding cache for the MN yet, the  
flow id option may be ignored and the BU accepted.

Nicolas

>>> there is