Subject: MCoA vs Flow Bindings: Solving same problem? (was Re: [Monami6] Flow Bindings and destinationaddressindraft-soliman-monami6-flow-binding-00.txt)

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 22 Jun 2006 18:19:14 +0800

Hello all,

I felt the discussion has diverted from the OP's post to warrant a new
thread.  IMHO, its much more a serious issue at hand now.

Original discussion that lead to this has been copied below.

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 think it will be better to have the flow binding capability added on
top of MCoA, giving us two solutions which solves different problems.

MCoA solves the problem of binding multiple CoAs to a single HoA.

Flow binding then provides the capability of binding different flows to
each of these CoAs.

Any thoughts from the rest of the WG?

/rgds
/cwng

On Thu, 2006-06-22 at 11:04 +0200, Nicolas Montavont wrote: 
> Gabor,
> 
> On 22 juin 06, at 10:31, Gábor Fekete wrote:
> 
> > Hi Nicolas,
> >
> > On Thursday 22 June 2006 10:54, Nicolas Montavont wrote:
> >> Hi Chan-Wah,
> >>
> >> On 22 juin 06, at 03:50, Chan-Wah Ng wrote:
> >>
> >>>
> >>
> >> SNIP
> >>
> >>>>>>
> >>>>>> There is a misunderstanding here. The flow binding draft is a
> >>>>>> standalone
> >>>>>> optimization, and does not need the MCoA functionalities. So the
> >>>>>> flow
> >>>>>> binding mechanism does not need to run on top of MCoA.
> >>>>>>
> >>>>>
> >>>>> Hmmm...  this is unexpected ...
> >>>>>
> >>>>> Except for dropping packets from unwanted flow, I don't see any
> >>>>> use in
> >>>>> flow bindings without MCoA.  So I assume it to be run on top of
> >>>>> MCoA.
> >>>>> Is there any other reason why flow binding should be  
> >>>>> implemented if
> >>>>> there is only one CoA-HoA binding?
> >>>>
> >>>> No, the flow binding also allows you to bind several CoAs to a  
> >>>> single
> >>>> HoA. The differentiation between several entries is made with  
> >>>> the FID
> >>>> (which is equivalent to the BID of MCoA). The difference with  
> >>>> MCoA is
> >>>> that the policies are transported with the BU.
> >>>>
> >>>> Please look at section 4 of the draft, there is a simple example
> >>>> which
> >>>> makes things clear (I hope).
> >>>>
> >>>
> >>> I will, but offhand, something is not very right.  MCoA is now a WG
> >>> draft, and if flow binding draft independently provides another  
> >>> way of
> >>> multiple CoA registrations, the implications will be, if the current
> >>> flow binding draft is promoted to WG Work item status, Monami6 is
> >>> providing two solutions to the same problem of multiple  
> >>> registrations.
> >>> Somehow I don't think that is desirable.
> >>
> >> It is not the same solution. MCoA allows a MN to register multiple
> >> CoA for the same HoA on a single HA. It does not provide indications
> >> on how to use these CoAs, but it can be something proprietary for
> >> example.
> >>
> >> Flow binding draft provides an extension to MIPv6 in order to direct
> >> flows from correspondent to different CoAs. It can be viewed as an
> >> extension to exchange rules on how to use several CoAs.
> >>
> >
> > But then, doesn't it make more sense to build on top of MCoA and  
> > provide
> > an open (non-proprietary) solution to the "how to use the CoAs  
> > registered
> > with MCoA" question?
> 
> Maybe, but the problem we had with using MCoA, was that a single CoA  
> can only be registered once in the BC/BUL. It means, in MCoA, that  
> you can have:
> HoA1 -> CoA1, BID=1
> HoA1 -> CoA2, BID=2
> 
> While in the flow binding draft, we can have the same CoA to appear  
> in several bindings, like this:
> HoA1 -> CoA1, FID=1, default
> HoA1 -> CoA2, FID=2, port 22
> HoA1 -> CoA2, FID=3, port 443
> 
> We thougth that it was unnecessary to use MCoA extensions for flow  
> bindings.
> 
> > I think it does. Sure, to me the flow-binding draft looks like as  
> > if it
> > answered these questions:
> >
> > o How to register multiple coas? and
> > o How/when to use the registered CoAs
> 
> That's right.
> It makes me think that we didn't describe the behavior when a MN  
> register a non-default CoA with a Flow Identification Option, without  
> any parameters...
> 
> >
> > So, I somewhat agree with Chan-Wah. I thought that the draft
> > will be changed to be an "extension" of the MCoA draft as suggested in
> > "10.1.  Usage of the FID" in the flow-binding draft.
> 
> Thanks to point me out this text, I realize that it is not clear at  
> all (we use FID instead of BID in the text).
> The text should appear like this:
> 
> The document [3] defines extensions to Mobile IPv6 to register
>     multiple Care-of addresses to a single home address.  Flags included
>     in the Binding Update indicate to the receiver how to treat the new
>     Care-of address: either the Care-of address will be added to the
>     existing entries, or the new Care-of address will replace an old
>     Care-of address.  In order to differentiate between several bindings
>     for the same home address, a Binding Identifier (BID) is used.   
> It can
>     be noted that [3] does not define policies for multiple Care-of
>     addresses usage.
> 
>     Considering the registration of flow policies as presented in this
>     document, it can be considered to use the Binding Identifier as  
> defined
>     in [3] to select a CoA to register a flow policies.  This  
> solution is
>     currently under discussion.
> 
> So, what we wanted to say here, is that we could define a way (in  
> flow binding draft) to map a flow to a particular CoA by using the  
> BID. It means, instead of using the source address of the BU or the  
> alternate CoA option to register a flow binding, we could use the  
> BID. That was the issue raised in this section.
> 
> In conclusion, if we adopt this behavior, the Flow bindings  
> extensions could be used on its own, without MCoA, or in combination  
> with MCoA.
> 
> Does it make sense?
> 
> Nicolas
> 
> >
> > Regards,
> > Gabor
> >

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 22 Jun 2006 04:46:28 -0700

> 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.

 > 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: Thu, 22 Jun 2006 13:52:00 +0200

The use of flow information to distinguish binding is not always  
right choice.
Our approach is separation of binding registration and flow  
distribution.

The below draft is one of approach for flow distribution of MCoA.
draft-mitsuya-monami6-flow-distribution-policy-00.txt

regards
ryuji

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 22 Jun 2006 20:22:21 +0800

>    provides additional flow filtering capabilities, and one do not"

My point is there are now two solutions for multiple CoA registrations.
Is that what we want from the WG?  I recall one factor contributing to
draft-wakikawa being elevated to WG status is that there are no
perceived alternate solutions to multiple CoA registration.  Apparently
there is.

As I see it, the WG has the following options:

(1) standardize two different solutions for multiple CoA registrations,
MCoA and draft-soliman, where draft-soliman also provide flow filtering
capability

(2) standardize one solution (draft-soliman) to provide multiple CoA
registrations, and flow filtering capability

(3) standardize one solution (MCoA) to provide multiple CoA
registrations, and another to provide flow filtering capability on top
of MCoA.

Personally I think (1) is undesirable.  I can accept (2) or (3).

/rgds
/cwng

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Thu, 22 Jun 2006 15:25:08 +0300

> Any thoughts from the rest of the WG?

Hello,

I have this concern as well. Now that the 
draft-ietf-monami6-multiplecoa-00.txt is accepted as a WG draft, I would 
  be even more worried if there would be another draft that is not 
utilizing the accepted draft's functionality. If the aim is to create 
two drafts in the WG, these two drafts should together form a solution, 
which doesn't seem to be the case currently.

Just my 2 cents...
-- 
Tero

---

From: Gábor Fekete <[email-masked]>
Date: Thu, 22 Jun 2006 15:23:19 +0300

Hi everyone,

Please, see my inlines!

On Thursday 22 June 2006 13:19, Chan-Wah Ng wrote:

snip

> > HoA1 -> CoA2, FID=3, port 443

You don't necessarily have to store the Flow Identifiers inside the BC/BUL
entries explicitly. You can do:

  BCache                                                 Flow table
-------------------                                   ----------------------
HoA1 -> CoA1, BID=1 <---- association/mapping ----->  FID1=default
HoA1 -> CoA2, BID=2 <---- association/mapping ----->  FID2=port 22, FID3=port 443

And anyway, if a node implements both MCoA and Flow-bindings and if Flow-bindings
is an extension of MCoA then it can freely ask for BC modification like so:

  BCache
-------------------
HoA1 -> CoA1, BID=1, FID1=default
HoA1 -> CoA2, BID=2, FID2=port 22, FID3=port 443

> > We thougth that it was unnecessary to use MCoA extensions for flow  
Well, yes. Of course it is unnecessary. But why not build on it if it's there?

> > extensions could be used on its own, without MCoA, or in combination  
I don't think it makes sense to have multiple separate solutions for the
"how to register multiple IP addresses" question.
But then, the same may apply to the "how to make use of the multiple
registered IP addresses" question. It is hard to see clearly at this
early stage.

I would suggest, if it is not too complicated, trying to build a flow
draft on top of MCoA.

Regards,
Gabor

---

From: Heikki Mahkonen <[email-masked]>
Date: Thu, 22 Jun 2006 15:49:18 +0300

Hi,

> perceived alternate solutions to multiple CoA registration.  Apparently
==> This was my original concern as well when I started asking the 
authors what is the relation between BID (MCoA) and FID (draft-soliman). 
And after I found out that there is none I kind of ignored the whole 
draft as it seems that it's not written in the line with the WG 
deliverable goals.

> MCoA and draft-soliman, where draft-soliman also provide flow filtering
==> I think it is not a good idea to standardize two solutions for one 
single problem when these solution are not even interoperable between 
each other. At least the interoperability should be designed as well.

> registrations, and flow filtering capability
==> I don't think that the draft-soliman is flexible and good enough to 
solve all (or even most of) the scenarios and cases defined in the 
Monami6 WG drafts which analyze and motivates the WG work. At least this 
draft must be edited a lot to provide the solution for them. I hope that 
  people aim to solve at least most of these cases described in these WG 
drafts (otherwise I don't see any point even write this kind of 
documents in the first place). I know that MCoA draft need to be worked 
on to be usable in all of the cases as well.

> registrations, and another to provide flow filtering capability on top
==> My opinion is that this is the only logical decision to make and 
that the Monami6 WG has been thinking more a long this line. At least, I 
get this impression from the WG deliverables list. Two documents one for 
the MCoA and one for the flow binding functionality. These two drafts 
should of course support each other and justify each others existence 
not under mind it. I don't know if the solution presented in the draft 
"draft-mitsuya-monami6-flow-distribution-policy-00.txt" is the best one 
for the flow distribution nor if the draft-soliman should be used for 
the flow distribution or anything at all but this discussion should be 
raised separately.

> Personally I think (1) is undesirable.  I can accept (2) or (3).
==> Personally I think that (1) is impossible and that (2) is not good 
choice and that (3) is the only logical choice.

Best regards,

Heikki Mahkonen

---

From: Koshiro MITSUYA <[email-masked]>
Date: Thu, 22 Jun 2006 22:59:38 +0900

Hi,

> abstract concept with the BID useful by itself? 

That's not the point for me.  Carrying flow polices within binding
signaling is too much.  I prefer to keep a binding update just to
register care-of addresses.  If I remeber well, this is the concern of
MIP6 WG when draft-wakikawa was submitted with a kind of flow binding
feature.

regards, 
Koshiro

At Thu, 22 Jun 2006 04:46:28 -0700,

---

From: Gábor Fekete <[email-masked]>
Date: Thu, 22 Jun 2006 17:39:02 +0300

Elo everyone,

> MIP6 WG when draft-wakikawa was submitted with a kind of flow binding
Good good good :)
So, when I first read the monami6 drafts I had the idea that for
carrying flow bindings we should have a separate protocol.
Having it carried in BU is good only that it requires less signaling when
MIPv6 is used. BUT!
If we have a separate protocol then others (SCTP, DCCP, HIP...) can use
it too to utilize the multiple IP addresses in a multihomed node.
So there would be a single flow mapper and each protocol could talk to it
to see when to use which IP of the multihomed node.

Regards,
Gabor

---

From: "Soliman, Hesham" <[email-masked]>
Date: Sun, 25 Jun 2006 10:12:04 -0700

> register care-of addresses. 

=> That's a subjective opinion I think. What does "too much" mean?

 If I remeber well, this is the 
 > concern of

=> 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.

Hesham

---

From: "Asanga Udugama" <[email-masked]>
Date: Sun, 25 Jun 2006 19:54:07 +0200

Hello all,

I too tend to agree with Hesham in the sense that multi-CoA draft might
not have a value on its own unless it is used for the purpose of
enabling flow management (considering the current focus). 

Kind regards,
Asanga

> -----Original Message-----
> From: Soliman, Hesham [mailto:[email-masked]]
> Sent: Sunday, June 25, 2006 7:12 PM
> To: Monami6 WG
> Subject: RE: MCoA vs Flow Bindings: Solving same problem?(wasRe:
> [Monami6]FlowBindings
anddestinationaddressindraft-soliman-monami6-flow-
> binding-00.txt)

---

From: Koshiro MITSUYA <[email-masked]>
Date: Tue, 27 Jun 2006 00:01:14 +0900

Hello Hesham,

> => That's a subjective opinion I think. What does "too much" mean?

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?

If so, binding signaling is used to negotiate policies.  This goes to
be complicated, I think.  How do others in WG think?

> 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.

regards,
Koshiro

---

From: Koshiro MITSUYA <[email-masked]>
Date: Tue, 27 Jun 2006 00:08:29 +0900

Hello,

There are two approach to exchange the policy so far: one is such as
draft-soliman (including policy in bindings), and one is such as
draft-mitsuya (using another transport to exchange policy).  I think
both can be developed and used depending on individual situation.

To live together, draft-soliman MUST be on the top of MCoA.

regards, 
Koshiro

At Sun, 25 Jun 2006 19:54:07 +0200,

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 26 Jun 2006 08:56:49 -0700

> 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.

 > be complicated, I think.  How do others in WG think?

=> The premise is not true, so it's a non-issue.

 > 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. 

Hesham

 > >  > >  > Gabor and myself are arguing that flow binding 
 > should be an 
 > >  > >  > extension to
 > >  > >  > be added on top of MCoA.
 > >  > >  >

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 26 Jun 2006 08:53:43 -0700

> To live together, draft-soliman MUST be on the top of MCoA.

=> Perhaps you for got to add "in my opinion" above. Since you don't
provide good technical reasons, it'd be nice to add that it's an
unexplained opinion.

Hesham

 > > > => I don't think so. The flow binding work has been 
 > around for 5-6
 > > years
 > > > and
 > > >  > >    provides additional flow filtering capabilities, 
 > and one do
 > > not"
 > > >  > >    But anyway, more below.
 > > >  > >
 > > >  > > the BID in the MCOA draft as it already has an 
 > index for each
 > > flow

---

From: Koshiro MITSUYA <[email-masked]>
Date: Thu, 29 Jun 2006 00:04:10 +0900

Hesham,

OK, I was wrong to refer draft-soliman here.  Please forget.

What I wanted to say is that we can avoid to develop two independent
solutions for multiple care-of address registrations by adding a flow
binding capability on top of a multiple care-fo address registration
protocol.

If the WG develops two solutions for policy exchange,
  (A) one is adding options on the binding signaling
  (B) one is using another transport
a solution like MCoA is needed for (B) to maintain multiple tunnels
and identify them.  And we can develop a flow binding capability added
on the top of the solution.

regards, 
Koshiro

At Mon, 26 Jun 2006 08:53:43 -0700,

---

From: Koshiro MITSUYA <[email-masked]>
Date: Thu, 29 Jun 2006 00:09:37 +0900

Hello, 

> because the flow option was not valid.

OK.  But what do you do to register an invalid flow option?

> => The premise is not true, so it's a non-issue.

Why do you think it is not issue?

> submitted shortly after for MIPv4. 

So, both are true.

regards, 
Koshiro

>  > and one do not"

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 28 Jun 2006 17:41:19 +0200

Hi Koshiro,

> 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).

> 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.

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).

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.

Nicolas

---

From: Koshiro MITSUYA <[email-masked]>
Date: Thu, 29 Jun 2006 10:07:15 +0900

Hi Nicolas,

> i.e. the CoA is registered in the BC of the receiving node (without  

Yes, I've understood this point.  My question was what do you do to
register/fix the invalid flow id option again?

> ignored, and the BU will be treated as a standard BU.

Yes. I understood.

> 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.

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

You always needs to include these policies, right?  If 1000 BU sent, I
don't think we could really save the bandwidth.

Koshiro

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Thu, 29 Jun 2006 10:49:58 +0200

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 seems to adopt the position that flow binding is 
> > >>>>>>> independent of MCoA.
> > >>>>>>>
> > >>>>>>> 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.
> > >>>>>>

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 29 Jun 2006 10:44:29 +0200

HI,

> 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.

> example, policy is already installed when the equipment is shipped.

Which equipment do you talk about? MN or HA?

> 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.)

Nicolas

---

From: Romain KUNTZ <[email-masked]>
Date: Fri, 30 Jun 2006 13:40:47 +0900

Hello all,

> abstract concept with the BID useful by itself? 

I think this is not very useful, but it does not force us to do it in an 
unique draft. Having 2 separated draft (one for MCoA registration, one 
for flow distribution) would be more flexible, allowing to build 
different policy distribution mechanisms on top of MCoA.

Actually I have several concerns with draft-soliman. The first one is 
that it does not match the monami6 charter:

- 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 [Standard Track].

draft-soliman does not allow to exchange policy from the HA to the MN. 
Policy exchange can only be done in one way, from MN to HA.

My second concern is that the HA can only learn policies from the MN. 
What about the cases when both MN and HA learn policies from a third 
entity, via ftp for example, or any other application?

That's why I personnaly prefer a solution such as 
draft-mitsuya-monami6-flow-distribution-policy-01 which allows all of 
this, while being built on top of MCoA.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 29 Jun 2006 22:34:14 -0700

> different policy distribution mechanisms on top of MCoA.

=> Ok. We agree on parts of that, I'm still not sure about the utility
of the MCOA draft on its own, but anyway. 

 > Policy exchange can only be done in one way, from MN to HA.

=> I think you're not using the right terminology here. Policies are not
in scope here. I think the wording in the charter might be unfortunate
too. Policies are done on a separate plane here. The MN can be
configured with policies or can get them from anywhere. 
draf-soliman only deals with the mechanism to request the *policy
enforcement*. Makes sense that the MN requests that because it is the
only one aware of its own interfaces. The HA can't tell the MN what to
do when it doesn't even know what interfaces are available to it. 

 > entity, via ftp for example, or any other application?

=> See above.

 > this, while being built on top of MCoA.

=> It's completely orthogonal to draft-soliman IMO. 

Hesham