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

From: Romain KUNTZ <[email-masked]>
Date: Mon, 03 Jul 2006 17:27:40 +0900

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

Actually, the MCoA draft already is usable on its own. The bid priority 
gives a sorted list of bindings, that can be used for example for a 
multihomed MR to achieve fault-tolerance. If one binding is deprecated, 
the next prefered one can be used without delay. But I agree that MCoA 
might not be the best solution for such scenario.

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

Possible scenario have not been discussed, so I would not be so 
confident about that. If I have for example 1000 taxis that embeds a MR, 
I would prefer to put the policies on the HA, and let learn the MR about 
the policies each time they change, rather than the opposite. Having a 
unidirectional mechanism may not fit all possible scenario.

Regards,

-- 
Romain KUNTZ
[email-masked]

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 3 Jul 2006 01:58:35 -0700

> the next prefered one can be used without delay. 

=> I'm not sure about that scenario either. For a binding to be
deprecated due to a "fault" as you describe, the MN would have to remove
the binding from the HA. Therefore the fault has to be detected and the
MN would have to signal to remove the binding. This could easily be done
today with one BU. So what's the gain?

 > the policies each time they change, rather than the 
 > opposite. 

=> This scenario is not prohibited in draft-soliman, it's completely
orthogonal to the draft as I mentioned before. The MRs can learn the
policies through any available means. The *request* for policy
enforcement though has to come from the MR. This is what draft-soliman
does. It does *not* specify policies.

   Having a 
 > unidirectional mechanism may not fit all possible scenario.

=> It's a unidirectional *request* for policy enforcement. If you have
an alternative mechanism for requesting the enforcement please explain
it. 

Hesham

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 03 Jul 2006 19:02:46 +0900

> today with one BU. So what's the gain?

The alternate tunnel is already ready to use at least in the MN-HA way.
One may find that the gain is not enough compared to the solution deployed.

> policies through any available means. 

I understood this point.

> The *request* for policy

The draft says in introduction:
"This specification extends Mobile IPv6 to allow it to specify policies 
associated with each binding."

Did I misunderstood the goal of the draft? The flow ID option can bring 
many information that the HA can use to install policies. Isn't the 
purpose of the draft for a MR to ask the HA to install the policies 
according to the selectors in the Flow ID option? Or just to confirm the 
policies received from a third part (is it what you call "policy 
enforcement"?).

 From what you said, this is unclear to me. Sorry if I missed something 
and if this has been discussed previously.

-- 
Romain KUNTZ
[email-masked]

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 3 Jul 2006 04:56:56 -0700

> One may find that the gain is not enough compared to the 

=> There is a difference between "ready to use" and "used". For the
tunnel to be used, the MN needs to signal that.

 > associated with each binding."

=> Thanks for pointing this out, we should change it to 
  "This specification extends Mobile IPv6 to allow  the installement 
   of flow bindings in the receivers of the binding update message."

 > policies received from a third part (is it what you call "policy 

=> I hope the new wording above clarifies it more. The MN/MR request
forwarding policies from the HA/CN/MAP. Where the policies originally
came from is out of the scope of this draft. I believe the latter point
is explicitly mentioned in the draft.

Hesham

---

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

On 2006/06/30, at 14:34, Soliman, Hesham wrote:

>
>> Soliman, Hesham wrote:
>>> 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?
>>
>> 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.
>

why not binding flows and BID, and signaling BID instead of FID??

Note that policy is not always needed.
As nicolas mentioned, MN may use multiple binding for interface  
switching, etc, (i.e. other than flow distribution.)

>>
>> 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?
>
> => See above.
>
>>
>> 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.
>
> => It's completely orthogonal to draft-soliman IMO.
>

I am not objective to carry policy by BU, but I want to say draft- 
soliman SHOULD NOT be only solution for MONAMI.
draft-mitsuya points out the other way to exchange policy.

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 5 Jul 2006 00:09:57 -0700

> why not binding flows and BID, and signaling BID instead of FID??

=> Because the BID binds one address to another, the FID binds a flow to
an address. We need the latter, the former is already done automatically
if you call the message a BU...

Hesham

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 5 Jul 2006 16:26:05 +0900

> if you call the message a BU...

The former is not done automatically.
You also utilize FID to distinguish Flow binding (i.e. CoAs).
BU is used to register a binding entry which is to bind HoA and CoA.
We should not use "flow" info to distinguish bindings.

ryuji

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 05 Jul 2006 13:36:19 +0200

Hi Hesham,

> tunnel to be used, the MN needs to signal that.

Of course, it must be signaled to the HA, but the MN can use the 
alternate tunnel without prior notice, as it has already been registered 
previously using MCoA. For UDP flow from the MN to the Internet, it 
results in a very short vertical handover (around 15 ms in our 
implementation). For the HA, one deregistration BU for the failed 
interface is enough to redirect the flow to antoher interface, which may 
be less processing-time consuming (on the HA) than a registration BU for 
a new CoA.

> is explicitly mentioned in the draft.

I understand that where the policies comes from is out of scope, but if 
the HA and the MN learns their policy from a third entity, for example 
using draft-mitsuya, I still fail to understand what's the point for the 
MN to use draft-soliman and advertise flow bindings in the MR-HA BU.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 5 Jul 2006 04:45:28 -0700

> Of course, it must be signaled to the HA, 

=> Good, so this is not different from sending a BU with the new CoA.

   but the MN can use the 
 > alternate tunnel without prior notice, as it has already 

=> What does that mean? You mean it has unidirectional connectivity in
the uplink?
Sorry but I think this is useless. It really isn't anything worth the
trouble of a whole new solution.

 > implementation). 

=> What kind of one way application do you have in mind that would
benefit from this
optimisation? 

For the HA, one deregistration BU for the failed 
 > be less processing-time consuming (on the HA) than a 

=> Now we're speculating and hair-splitting I think. A micro second here
or there (*if* what you're saying is correct) is a non issue IMO.

 > MN to use draft-soliman and advertise flow bindings in the MR-HA BU.

=> Because a policy is something that says :
app1 use eth0
app2 use eth1 
...etc
You can't write a policy based on a CoA that will change regularly or
port numbers that can also change regularly, let alone network
conditions or interfaces going up and down. So draft-soliman 's
implementation would take the result of that policy at a given moment
and tell the HA to enforce it. 

Hesham

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 05 Jul 2006 18:45:00 +0200

Soliman, Hesham wrote:
> benefit from this optimisation? 

Any unidirectional and 1-to-1 or 1-to-N (multicast for example)
application from the MN to correspondant(s). But I think we get away
from the real problem. I just wanted to point some other possibilities.

> You can't write a policy based on a CoA that will change regularly or

Using MCoA, the policy can be independent from the CoA by using the BID
as a target.

> and tell the HA to enforce it. 

And what does draft-mitsuya cannot do in that case? With draft-mitsuya,
if a port or any policy parameter changes, the MN can also advertises
that to the HA/CN. More, if a parameter changes on the CN application,
it can advertises the MN, who will be able to adjust his behaviour.

Saying that, I do not think that draft-mitsuya and draft-soliman are
orthogonal. draft-mitsuya can also be used for what draft-soliman does.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 5 Jul 2006 23:49:18 -0700

> from the real problem. I just wanted to point some other 

=> I don't think there is a great applicability domain there; but
independently of that, the point is we don't need to standardise a
solution which solves this very small subset of the problem when you
have to solve the more general problem anyway. Seems silly to do it
twice.

 > And what does draft-mitsuya cannot do in that case? With 

=> I'm not talking about draft-mitsuya, I was answering your question
about what draft-soliman's role is in the scenario we were discussing. 

 > it can advertises the MN, who will be able to adjust his behaviour.

=> Sure, let's invent a new protocol with all the security requirements
for address spoofing ...etc and send everything in text for good
measure! I don't agree with those design decisions. I prefer to reuse
what is already there and do it in a BW efficient manner unless what's
already there doesn't work. The MCOA draft did exactly that, it reuses
what's already there and does it relatively efficiently. I just don't
think the concept is useful. 

 Hesham

---

From: Heikki Mahkonen <[email-masked]>
Date: Thu, 06 Jul 2006 15:15:00 +0300

Hi Hesham,

> if you call the message a BU...
==> I don't see your point here. We can call the message BU but it is
not done automatically. BIDs are definitely needed in this message so
the multiple bindings can be managed efficiently. I mean its better to
refer the BC/BUL entries with the BID (2 bytes) than a CoA (16 bytes) in
a BU message. Functionality to distinguish between BC/BUL entries is
needed when binding multiple CoAs to one HoA. For instance when one of
the CoAs changes you only want to update the BC entry for that CoA and I
think the best way to reference this BC entry is to use the BID than to
use the old CoA. So when there already is a need to have BID in the BC
and BUL why not put the BID to some other use as well? Why not map the
Flow Binding to a BID and when the CoA changes you don't have to do
anything because the Flow Binding to BID association does not change. Of
course, BID seems to be redundant when the Flow Binding mechanism is
designed as in draft (draft-soliman-monami6-flow-binding-01.txt) but it
does not mean that the BID is altogether redundant.

Best regards,

Heikki Mahkonen

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 6 Jul 2006 06:14:16 -0700

Hi Heikki, 

I'll respond to the details soon because I'm in a rush, but I just want
to reiterate what the authors said before: We *want to* use the BID if
it makes sense. We started off with the assumption that we should use
the BID. So if it makes the solution more useful we'd be more than happy
to include it. I'll read your email carefully and respond in the next
couple of days. 

Hesham

 > -----Original Message-----
 > From: Heikki Mahkonen [mailto:[email-masked]] 
 > Sent: Thursday, July 06, 2006 10:15 PM
 > To: Monami6 WG
 > Subject: Re: MCoA vs Flow Bindings: Solvingsame 
 > problem?(wasRe: 
 > [Monami6]FlowBindingsanddestinationaddressindraft-soliman-mon
ami6-flow-binding-00.txt)
 > 
 > Hi Hesham,
 > 
 > Soliman, Hesham wrote:
 > >  > > => I think you're not using the right terminology 
 > here. Policies  
 > >  > > are not
 > designed as in draft 
 > (draft-soliman-monami6-flow-binding-01.txt) but it

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 Jul 2006 08:51:49 -0700 (PDT)

Hi Heikki,

----- Original Message ----
From: Heikki Mahkonen <[email-masked]>
To: Monami6 WG <[email-masked]>
Sent: Thursday, July 6, 2006 7:15:00 AM
Subject: Re: MCoA vs Flow Bindings: Solving same problem?(wasRe: [Monami6]FlowBindings anddestinationaddressindraft-soliman-monami6-flow-binding-00.txt)

Hi Hesham,

==> IMHO FID is also like BUI but it might make more sense to use FIDs because in practice, MN might have many more flows than interfaces.

Best regards,

Heikki Mahkonen

Regards,

--behcet

---

From: Gábor Fekete <[email-masked]>
Date: Thu, 6 Jul 2006 22:36:13 +0300

Hi Heikki and Behcet and Hesham and others interested!

On Thursday 06 July 2006 18:51, Behcet Sarikaya wrote:

[snip]

> does not mean that the BID is altogether redundant.
[This ^^^^^ was written by Heikki]

> ==> IMHO FID is also like BUI but it might make more sense to use FIDs 
> because in practice, MN might have many more flows than interfaces. 
> 
[This ^^^^^ was written by Behcet]

Behcet, could you please stick to BID and not BUI for now? I think it just
makes confusion (e.g. for new people). For now, BID is in
draft-wakikawa (MCoA) and not BUI.

OK! So, here are some simple scenarios to compare draft-soliman with
a potential flow filter built on top MCoA (MCoA + Flows).
I tried to show for each scenario what would be carried in BUs needed
to accomplish the operations.
The list is incomplete, but in the end I have a conclusion anyway :)
(Set your mail reader to use fixed fonts, otherwise this is going to be
a mess!)

Current BC and BUL state:

MCoA + Flows                          draft-soliman
--------------------------          ---------------------
HoA - CoA1 - BID1 - FID1            HoA - CoA1 - FID1
    - CoA2 - BID2 - FID2                - CoA2 - FID2
           - BID3 - FID3                       - FID3
                  - FID4                       - FID4

Scenarios:

1. Change CoA to CoA3 for FID4:
  1.1   BU(HoA, CoA3, BID4, FID4) or
        BU(HoA, CoA3, FID4) with optimization
  1.2   BU(HoA, CoA3, FID4)
  2.3   Score: 0-0 (with optimization)
2. Change CoA to CoA3 for BID3:
  2.1   BU(HoA, CoA3, BID3)
  2.2   BU(HoA, CoA3, FID3, FID4)
        It does not expose info on FID grouping info, only on the MN!
  2.3   Score: 1-0
3. Add FID5 for BID3
  3.1   BU(HoA, CoA2, BID3, FID5)
  3.2   BU(HoA, CoA2, FID5)
        It does not expose info on FID grouping info, only on the MN!
  3.3   Score: 1-1
4. Del FID3
  4.1   BU(HoA, CoA2, BID3, FID3) or
        BU(HoA, CoA2, FID3) with optimization
  4.2   BU(HoA, CoA2, FID3)
  4.3   Score: 1-1
5. Del BID3
  5.1   BU(HoA, CoA2, BID3)
  5.2   BU(HoA, CoA2, FID3, FID4)
        It does not expose info on FID grouping info, only on the MN!
  5.3   Score: 2-1

Current BC and BUL state:

MCoA + Flows                          draft-soliman
--------------------------          ---------------------
HoA - CoA1 - BID1 - FID1            HoA - CoA1 - FID1
    - CoA2 - BID2 - FID2                - CoA2 - FID2
           - BID3 - FID3                       - FID3
                  - FID4                       - FID4

Bulk operation scenarios (using e.g. AltCoA options):

a. Change CoA to CoA3 for FID1, and CoA4 for FID4
  a.1   BU(HoA, CoA3, BID1, FID1,
                CoA4, BID4, FID4) or
        BU(HoA, CoA3, FID1,
                CoA4, BID4, FID4) with optimization
  a.2   BU(HoA, CoA3, FID1,
                CoA4, FID4)
  a.3   Score: 0-1
b. Change CoA to CoA3 for FID1 and CoA4 for BID3
  b.1   BU(HoA, CoA3, BID1, FID1,
                CoA4, BID3) or
        BU(HoA, CoA3, FID1,
                CoA4, BID3) with optimization
  b.2   BU(HoA, CoA3, FID1,
                CoA4, FID3, FID4)
        It does not expose info on FID grouping info, only on the MN!
  b.3   Score: 1-1
c. Add FID5 for BID2; add FID6, FID7 for BID3
  c.1   BU(HoA, CoA2, BID2, FID5,
                CoA2, BID3, FID6, FID7) or
        BU(HoA, CoA2-in-ipv6-header, BID2, FID5,
                                     BID3, FID6, FID7) with optimization
  c.2   BU(HoA, CoA2, FID5, FID6, FID7)
        It does not expose info on FID grouping info, only on the MN!
  c.3   Score: 1-2
d. Add FID5 for BID1; add FID5, FID6 for BID3
  d.1   BU(HoA, CoA1, BID1, FID5,
                CoA2, BID3, FID6, FID7)
  d.2   BU(HoA, CoA1, FID5,
                CoA2, FID6, FID7)
        It does not expose info on FID grouping info, only on the MN!
  d.3   Score: 1-3
e. Del BID1 and BID3
  e.1   BU(HoA, CoA1, BID1,
                CoA2, BID3) or
        BU(HoA, BID1, BID3) with optimization
  e.2   BU(HoA, CoA1, FID1,
                CoA2, FID3, FID4) or
        BU(HoA, FID1, FID3, FID4) with optimization
        It does not expose info on FID grouping info, only on the MN!
  e.3   Score: 2-3

Conclusion:
o The BID adds valuable(?) grouping capabilities, resulting in reduced
  BU size.

Suggestion:
Add FID grouping functionality to draft-soliman (resulting in
modified-draft-soliman)!
o For the current draft-soliman it means
  a. an extra group ID field in FIDs and
  b. the BID suboption (or some other suboption to represent whole
     FID groups, e.g. a FID option with zero FID and only a positive
     group ID field).

Then,
1. Nodes implementing MCoA and the modified-draft-soliman:
   Everything is fine. Modified-draft-soliman just extends the MCoA
   capable node. The implementation should handle the group ID as the BID.
   Plus, other flow binding solutions that build on MCoA may be used in
   parallel with the modified-draft-soliman.
2. Nodes implementing MCoA but not implementing the modified-draft-soliman:
   They can use other flow binding solutions and reject modified-draft-soliman
   BUs. 

As a final note, keep on working on both draft-soliman and the 
other flow binding drafts. Time will tell which one survives.
As I see, draft-soliman focuses on network efficiency and the others on
probably cleaner design. These goals are quite orthogonal.

Regards,
Gabor

---

From: Gábor Fekete <[email-masked]>
Date: Fri, 7 Jul 2006 10:04:48 +0300

OK, some explanation for the scenarios.

o points "x.1" belong to MCoA + Filter
o points "x.2" belong to draft-soliman
o the Score shows if MCoA + Filter or draft-soliman
  has the lead in the comparison so far.
o "BID" in BUs mean a Bindind Unique Identifier Sub-option
  including a BID.
o "FID" in BUs mean a Flow Identifier Sub-option including
  a FID.

The startup condition for BC/BUL is:

 MCoA + Flows                          draft-soliman
 --------------------------          ---------------------
 HoA-+-CoA1---BID1---FID1            HoA-+-CoA1---FID1
     |                                   |
     +-CoA2-+-BID2---FID2                +-CoA2-+-FID2
            |                                   |
            +-BID3-+-FID3                       +-FID3
                   |                            |
                   +-FID4                       +-FID4

Gabor

---

From: Heikki Mahkonen <[email-masked]>
Date: Fri, 07 Jul 2006 12:08:46 +0300

Hi Gábor,

	I added my comments to your scenarios below.

> MCoA + Flows                          draft-soliman

==> My thinking is that in the MCoA + Flows approach the BID3 should be
taken out in the beginning. It should look something like this:

HoA - CoA1 - BID1 - FID1
   - CoA2 - BID2 - FID2
               - FID3
               - FID4

So only one BID per CoA (BC/BUL entry). Multiple FIDs for one BID is OK
of course and multiple BIDs for on FID (bi-casting and load balancing).

>   2.3   Score: 0-0 (with optimization)

==> This means that the MN adds a new CoA3 and wants to use it for FID4?
Here I think you could not use the optimization. Can you explain how you
thought the optimization could be used? I see this packet this way:
    1.1   BU(HoA, CoA3, BID3, FID4)
    1.2   BU(HoA, CoA3, FID4)
    1.3  Score: 0-1

HoA - CoA1 - BID1 - FID1            HoA - CoA1 - FID1
   - CoA2 - BID2 - FID2                - CoA2 - FID2
               - FID3                      - FID3
   - CoA3 - BID3 - FID4                - CoA3  - FID4

>         It does not expose info on FID grouping info, only on the MN!
==> This means that in the first scenario you added a CoA3 and now it
changes? If I understand this correctly FID3 does not have to be sent as
it now references CoA2 - so:
    2.1   BU(HoA, newCoA3, BID3)
    2.2   BU(HoA, newCoA3, FID4)
    2.3   Score: 0-1

HoA - CoA1 - BID1 - FID1            HoA - CoA1 - FID1
   - CoA2 - BID2 - FID2                - CoA2 - FID2
               - FID3                      - FID3
   - newCoA3 - BID3 - FID4              - newCoA3  - FID4

>         It does not expose info on FID grouping info, only on the MN!
==> In this case you can leave the already known CoA2 out of the message
and it comes down to:
    3.1   BU(HoA, BID3, FID5)
    3.2   BU(HoA, CoA2, FID5)
    3.3   Score: 1-1 (sizeof(CoA2) > sizeof(BID3))

HoA - CoA1 - BID1 - FID1            HoA - CoA1 - FID1
   - CoA2 - BID2 - FID2                - CoA2 - FID2
               - FID3                      - FID3
   - newCoA3 - BID3 - FID4              - newCoA3  - FID4
                 - FID5                       - FID5

>         BU(HoA, CoA2, FID3) with optimization
==> Ithink when deleting a FID in MCoA + Flow case you only have to send
the FID3 which should be deleted to the other end not hte CoA2.
    4.1   BU(HoA, BID3, FID3, remove flag)
    4.2   BU(HoA, CoA2, FID3)
    4.3   Score: 2-1 (sizeof(CoA2) > sizeof(BID3))

HoA - CoA1 - BID1 - FID1            HoA - CoA1 - FID1
   - CoA2 - BID2 - FID2                - CoA2 - FID2
   - newCoA3 - BID3 - FID4              - newCoA3  - FID4
                 - FID5                       - FID5

>         It does not expose info on FID grouping info, only on the MN!
==> In this case what happens to the Flow Bindings/Rules? I have left
them as unreferenced entities after BID3 is removed. Also, this just
means that you de-register a CoA so no need to send FIDs either, right?
    5.1   BU(HoA, BID3, remove flag)
    5.2   BU(HoA, CoA3)
    5.3   Score: 3-1

                 FID4 (not used)
                 FID5 (not used)

In this final scenario the draft-soliman approach would remove the FIDs
when the BC entry for CoA3 is removed, right? Thats why I took them out
from the BC listing.

I send my comments on the bulk cases in an other mail a bit later.

> o The BID adds valuable(?) grouping capabilities, resulting in reduced
==> Yes, but only one BID for CoA is my opinion.

Best regards,

Heikki Mahkonen

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Fri, 07 Jul 2006 13:31:46 +0300

> when the BC entry for CoA3 is removed, right? Thats why I took them out

To clarify this a little bit. We have been thinking a way to separate 
the transfer of filter rules (i.e. flow bindings/rules) and the transfer 
of that which associates these filter rules to BIDs (i.e. FID to BID). 
To that end, we think that even if the association is removed it would 
not necessarily have to mean that the rule is removed as well.

/Tero

---

From: Heikki Mahkonen <[email-masked]>
Date: Fri, 07 Jul 2006 14:23:15 +0300

Hi Gábor,

	OK, I got this thing a bit wrong in the first mail. Let me try this
again. One CoA is always in the IPv6 header and if you have to reference
any other CoA then you can leave it out from the BU and use BID insted.

Gábor Fekete wrote:

> --------------------------          --------------------- HoA - CoA1
> - BID1 - FID1            HoA - CoA1 - FID1 - CoA2 - BID2 - FID2
> - CoA2 - FID2 - BID3 - FID3                       - FID3 - FID4
> - FID4

==> This I think should be like follows:

> Scenarios:
> 
> 1. Change CoA to CoA3 for FID4: 1.1   BU(HoA, CoA3, BID4, FID4) or
> BU(HoA, CoA3, FID4) with optimization 1.2   BU(HoA, CoA3, FID4) 2.3
> Score: 0-0 (with optimization)

1. Change CoA to CoA3 for FID4:
   1.1   BU(HoA, CoA3, (BID sub-option BID2)) or
   1.2   BU(HoA, CoA3, (FID sub-option FID4))
   2.3   Score: 0-0 (with optimization)

> 2. Change CoA to CoA3 for BID3: 2.1   BU(HoA, CoA3, BID3) 2.2
> BU(HoA, CoA3, FID3, FID4) It does not expose info on FID grouping
> info, only on the MN! 2.3   Score: 1-0

2. Change CoA to CoA3 for BID2:
   2.1   BU(HoA, CoA3, (BID2))
   2.2   BU(HoA, CoA3, (FID2), (FID3), (FID4))
   2.3   Score: 1-0

> 3. Add FID5 for BID3 3.1   BU(HoA, CoA2, BID3, FID5) 3.2   BU(HoA,
> CoA2, FID5) It does not expose info on FID grouping info, only on the
> MN! 3.3   Score: 1-1

3. Add FID5 for BID2
   3.1   BU(HoA, CoA2, (BID2, FID5))
   3.2   BU(HoA, CoA2, (FID5))
   3.3   Score: 1-1* (1-0)

> 4. Del FID3 4.1   BU(HoA, CoA2, BID3, FID3) or BU(HoA, CoA2, FID3)
> with optimization 4.2   BU(HoA, CoA2, FID3) 4.3   Score: 1-1

4. Del FID3
   4.1   BU(HoA, CoA2, (BID2, FID3)) or
   4.2   BU(HoA, CoA2, (FID3))
   4.3   Score: 1-2* (1-0)

> 5. Del BID3 5.1   BU(HoA, CoA2, BID3) 5.2   BU(HoA, CoA2, FID3, FID4)
>  It does not expose info on FID grouping info, only on the MN! 5.3
> Score: 2-1

5. Del FID3 and FID4 from BID2
   5.1   BU(HoA, CoA2, (BID2, FID2))
   5.2   BU(HoA, CoA2, (FID3), (FID4))
   5.3   Score: 2-2 (2-0)

* = Assuming that one FID sub-option is smaller than one BID sub-option
with FID. The score in parenthesis is when they are equal in length. Of
course if BID sub-option is smaller (4-0)...

> --------------------------          --------------------- HoA - CoA1
> - BID1 - FID1            HoA - CoA1 - FID1 - CoA2 - BID2 - FID2
> - CoA2 - FID2 - BID3 - FID3                       - FID3 - FID4
> - FID4

> Bulk operation scenarios (using e.g. AltCoA options): a. Change CoA
> to CoA3 for FID1, and CoA4 for FID4 a.1   BU(HoA, CoA3, BID1, FID1, 
> CoA4, BID4, FID4) or BU(HoA, CoA3, FID1, CoA4, BID4, FID4) with
> optimization a.2   BU(HoA, CoA3, FID1, CoA4, FID4) a.3   Score: 0-1
a. Change CoA to CoA3 for FID1, and CoA4 for FID4
   a.1   BU(HoA, CoA3, (BID sub-option BID1),
                 (BID sub-option BID4, CoA4, FID4)) or
   a.2   BU(HoA, CoA3, (FID sub-option FID1), CoA4,
                     (FID sub-option FID4))
   a.3   Score: 0-1

> b. Change CoA to CoA3 for FID1 and CoA4 for BID3 b.1   BU(HoA, CoA3,
> BID1, FID1, CoA4, BID3) or BU(HoA, CoA3, FID1, CoA4, BID3) with
> optimization b.2   BU(HoA, CoA3, FID1, CoA4, FID3, FID4) It does not
> expose info on FID grouping info, only on the MN! b.3   Score: 1-1

b. Change CoA to CoA3 for FID1 and CoA4 for BID2
   b.1   BU(HoA, CoA3, (BID1), (BID2, CoA4)) or
   b.2   BU(HoA, CoA3, (FID1), CoA4, (FID2), (FID3), (FID4))
   b.3   Score: 1-1

> c. Add FID5 for BID2; add FID6, FID7 for BID3 c.1   BU(HoA, CoA2,
> BID2, FID5, CoA2, BID3, FID6, FID7) or BU(HoA, CoA2-in-ipv6-header,
> BID2, FID5, BID3, FID6, FID7) with optimization c.2   BU(HoA, CoA2,
> FID5, FID6, FID7) It does not expose info on FID grouping info, only
> on the MN! c.3   Score: 1-2

c. Add FID5 for BID2; add FID6, FID7 for BID2 ==> Add FID5, FID6, FID7
for BID2
   c.1   BU(HoA, CoA2, (BID2, FID5, FID6, FID7)) or
   c.2   BU(HoA, CoA2, (FID5), (FID6), (FID7))
   c.3   Score: 2-1

> d. Add FID5 for BID1; add FID5, FID6 for BID3 d.1   BU(HoA, CoA1,
> BID1, FID5, CoA2, BID3, FID6, FID7) d.2   BU(HoA, CoA1, FID5, CoA2,
> FID6, FID7) It does not expose info on FID grouping info, only on the
> MN! d.3   Score: 1-3

d. Add FID5 for BID1; add FID5, FID6 for BID2
   d.1   BU(HoA, CoA1, (BID1, FID5), (BID2, FID6, FID7))
   d.2   BU(HoA, CoA1, (FID5), CoA2, (FID6), (FID7))
   d.3   Score: 3-1 (Only one CoA needed in BU in d.1)

> e. Del BID1 and BID3 e.1   BU(HoA, CoA1, BID1, CoA2, BID3) or BU(HoA,
> BID1, BID3) with optimization e.2   BU(HoA, CoA1, FID1, CoA2, FID3,
> FID4) or BU(HoA, FID1, FID3, FID4) with optimization It does not
> expose info on FID grouping info, only on the MN! e.3   Score: 2-3

e. Del BID1 and BID2
   e.1   BU(lifetime == 0, HoA, CoA1, (BID2)) (No BID1 needed because
de-registration can be deducted from the LT == 0 and CoA1)  or
   e.2   BU(LT==0, HoA, CoA1) + BU(LT==0, HoA, CoA2)
   e.3   Score: 4-1

> Conclusion: o The BID adds valuable(?) grouping capabilities,
> resulting in reduced BU size.

==> My conclusion is also that because of this "grouping functionality"
the MCoA + Flow Binding approach reduces the overhead. In the case where
you have many FIDs associated to one BID and the CoA for those FIDs
changes you only have to update the binding like described in the MCoA
draft and the FID to BID association remains the same. At the same time
of course the mechanism in draft
(draft-soliman-monami6-flow-binding-01.txt) can be enhanced to use the
same kind of grouping functionality. In addition, I think that Hesham
can see some places where the scenarios above can be optimized for the
mechanism described in that draft.

> Suggestion: Add FID grouping functionality to draft-soliman
> (resulting in modified-draft-soliman)! o For the current
> draft-soliman it means a. an extra group ID field in FIDs and b. the
> BID suboption (or some other suboption to represent whole FID groups,
> e.g. a FID option with zero FID and only a positive group ID field).

==> In our approach we add the FIDs to the BID sub-option which should
be grouped to the BID. Is this what you mean? At least then you have
grouped FIDs with that BID. In addition, we have thought about adding a
group FID (i.e. a FID that consists of several FIDs).  When CoA changes
the MN uses BID to reference all the FIDs whose CoA changed. In addition
this new group FID can be used when updating or deleting Filter Rules.
This is done separately from the MIPv6.

> Then, 1. Nodes implementing MCoA and the modified-draft-soliman: 
> capable node. The implementation should handle the group ID as the
> BID. Plus, other flow binding solutions that build on MCoA may be
> used in parallel with the modified-draft-soliman. 2. Nodes
> implementing MCoA but not implementing the modified-draft-soliman: 
> They can use other flow binding solutions and reject
> modified-draft-soliman BUs.

==> Yes, so this means that every node should use the MCoA functionality.
I agree on this. However, what happens when a host which uses the MCoA
and some other Flow Binding functionality tries to communicate with a
host which uses the MCoA and mechanism specified in draft
(draft-soliman...) modified or not modified. I mean they are not
inter-operable and isn't this one of the points of trying to standardize
this whole thing so every host is inter-operable with each other.

> As a final note, keep on working on both draft-soliman and the other
> flow binding drafts. Time will tell which one survives. As I see,
> draft-soliman focuses on network efficiency and the others on 

==> Yes of course, work must continue and we need more detailed
simulation/implementation information I guess to see what is the best
way to go. Or then democratic decision should be made at some point.

BR,

Heikki & Tero

---

From: Gábor Fekete <[email-masked]>
Date: Fri, 7 Jul 2006 15:00:20 +0300

Hi Heikki,

Sorry, for being ambiguous!
There are some misunderstandings.

So
o Each scenario is a separate one and they do not
  constitute (run in) a sequence.
  That is, for each scenario the initial BUL is the one
  in the figure.
o If the scenario says "Change" then it is a change in
  the BUL.
  If it says "Add" then it is addition.
  If it is "Del" then it is deletion.

See my inlines too!

> taken out in the beginning. It should look something like this:
Why "should" it be taken out? What if the MN's intent with this
startup BUL was to manage FID3 and FID4 together.
That is the whole point!

> of course and multiple BIDs for on FID (bi-casting and load balancing).
See my comment on this in the end of this email!

> ==> This means that the MN adds a new CoA3 and wants to use it for FID4?

No! It is "Change" and not "add".

> thought the optimization could be used? I see this packet this way:

Sorry, you are right. So the BU is BU(HoA, CoA3, BID4, FID4). No optimization.

> changes? If I understand this correctly FID3 does not have to be sent as

No! Damn! Sorry! I mean all the scenarios apply to the original BUL.
They are not executed as a sequence! They are separate examples.

> ==> In this case you can leave the already known CoA2 out of the message

Yes I know, but what is the point? The end result is the same, i mean,
you subtract the same value from both sides of the equation.
But I agree, I just do not think it is important for a comparison.

>     4.3   Score: 2-1 (sizeof(CoA2) > sizeof(BID3))
I assumed there is no load balancing, in which case
both 4.1 and 4.2 becomes BU(HoA, FID3).
You are right if there is load balancing supported (same FID for multiple
BUL entries). But if there is not, then a FID uniquely identifies a
BUL entry (a branch in the "Binding Update Tree").

> them as unreferenced entities after BID3 is removed. Also, this just

My point again was grouping of FIDs using BIDs, so I assumed that with
removing a BID all its associated FIDs are killed also.

> ==> Yes, but only one BID for CoA is my opinion.
I don't see why that restriction is necessary.
I intentionally represented the BUL as a tree to show that you can implement
the BUL in a way that for one BID you have multiple FIDs.
If you have multiple FIDs for one BID (grouping) but you have separate
BUL entry for each FID then it is impossible to have
"only one BID for CoA"!

Regards,
Gabor

---

From: Gábor Fekete <[email-masked]>
Date: Fri, 7 Jul 2006 15:06:54 +0300

Hi Tero,

> not necessarily have to mean that the rule is removed as well.
I understand. But, IMO, it is a implementation/design detail/decision of a
specific flow binding solution.
So, just to clarify my view...I don't care if rules stay or go on BID
(group) deletion. A flow binding implementation can keep them around for 
whatever reason. I do not consider that.
And it does not change my point that I see that the only
things that justify to keep BIDs from the draft-soliman point of view
(maybe in the form of filter group IDs) is to use them for filter grouping.

Regards,
Gabor

---

From: Heikki Mahkonen <[email-masked]>
Date: Fri, 07 Jul 2006 15:33:33 +0300

Hi Gábor,

>   If it is "Del" then it is deletion.
==> Yes I figured out the first bullet by the second mail I sent in.  So
I think that the problem was at this end. =) I hope that the second mail
captures what we were thinking better. I don't comment on the scenarios
in this mail a they are quite wrong so I'll snip those parts out.

<snip>
</snip>

> BUL entry for each FID then it is impossible to have

==> You are absolutely right! I didn't think of that. I was just
thinking that the MCoA draft says that one BID/CoA and thats it. Of
course it is a good functionality to group some of the FIDs with one BID
and use another BID with other(s). However, I think that when multiple
BIDs are used for one CoA these BIDs should be added to the same BUL/BC
element. Therefore just one of them needs to be used when CoA of this
BUL/BC changes. This also mandates some changes to the MCoA draft. I
mean this functionality needs to be added there as well, right? I check
the scenarios again and see if there will be a lot of changes to what I
wrote or if the scenarios are actually the same which you already sent
in the original mail.

BR,

Heikki

---

From: Gábor Fekete <[email-masked]>
Date: Fri, 7 Jul 2006 15:56:46 +0300

Hi Heikki,

> in this mail a they are quite wrong so I'll snip those parts out.
Phew! Great, I was a bit worried of being out of sync for a long time
in this thread :)

> element. Therefore just one of them needs to be used when CoA of this

This is multiple BID for one CoA:
HoA - CoA1 - BID1
HoA - CoA1 - BID2

MCoA allows this. :) So I guess you wanted to say
"Multiple FIDs for one BID", didn't you?

This indeed mandates some changes, but! If we talk about Binding Update Tree
and not Binding Update List then these restrictions (like multiple BID
for a CoA, or multiple FID for a BID) seems to be unnecessary.

> mean this functionality needs to be added there as well, right? I check

If the BUL is implemented as a tree then no modification is needed.
The biggest mistake here is that both RFC 3775 and wakikawa has the
assumption the Bindings are stored in a list. That is even thou they
say "we don't care about the data structure" they still suggest that
it has to be a list. Which is bad bad bad. And now we see why.

E.g. In this case:

MCoA + Flows                      
--------------------------        
HoA-+-CoA1---BID1---FID1          
    |                             
    +-CoA2-+-BID2---FID2          
           |                      
           +-BID3-+-FID3          
                  |               
                  +-FID4          

BID3 appears only once in the tree, so does CoA2. If it were
a list data structure then you have "trouble" having BID3
appearing multiple times.

> wrote or if the scenarios are actually the same which you already sent
Forget the scenarios! Unless you want to show something really important
with them to me other than "grouping is OK and there is no other point
keeping around both BID and FID". Because it takes a lot of time to check
them. :)

Regards,
Gabor

---

From: Gábor Fekete <[email-masked]>
Date: Fri, 7 Jul 2006 17:03:04 +0300

> MCoA + Flows                          draft-soliman

I don't agree with the "only one BID per one CoA" restriction in the first
place. See my comments on tree vs. list for BUL in other emails in this thread.
So, without that restriction, no! It not "should be", but rather COULD BE.
Therefore, my original BUL example is a "COULD BE" too.

>    2.3   Score: 0-0 (with optimization)

It says "Change CoA to CoA3 for FID4" then in 1.1. why do you change
the CoA of BID2 instead of FID4?

I don't comment more on these scenarios since your conclusion is similar to mine
and because I see this is moving into a "how to structure the BU" 
discussion (especially in the bulk case), and I don't want that now, plus
I am in a hurry. So,

[snip] :)

> mechanism described in that draft.
If draft-soliman can handle grouping more efficiently without a
group ID (BID) than with it then draft-soliman passed the test.
But I'd doubt draft-soliman has grouping capabilities, so I am not 
afraid of this happening, since the point is:
"What is the justification of having a BID in existence from the point
of view of draft-soliman?"
One answer could be grouping of FIDs for efficiency and/or management
purposes.

(Maybe we should start a new thread, I wonder...)

> This is done separately from the MIPv6.
I think both of these approaches are ok:
o BU(HoA, CoA, BID1 (FID1, ..., FIDN), BID2 (FIDK...FIDL), ...)
o BU(HoA, CoA, BID1, FID1, ..., FIDN, BID2, FIDK...FIDL, ...)
o BU(HoA, CoA, FID1, ..., FIDN, FIDK...FIDL, ...) having a group ID in FIDs

It all depends on how you define their parsing on the other side.
I do not consider MCoA complete, thus, I do not consider any kind of
change in BU structure impossible (as long as it complies to RFC 3775)).

> this whole thing so every host is inter-operable with each other.
I don't think this is the point!
If a node does not implement a protocol then it cannot "speak" it.
Of course if node-A speaks draft-soliman, then it cannot speak to
node-B implementing draft-whatever-other-flow-draft.

I understand what you mean, but, IMO, this is then a brand new requirement
for flow-binding solutions stated only in this thread here and now.
And come on, how can two nodes interoperate having one of them
speak only draft-mitsuya and the other only something more along
the lines of draft-larsson? Message formats are likely to be
different. How can one understand a message format if it does not
implement the corresponding parser (protocol) for that?

Even if this flow identification grouping is accepted by everyone here
(still to be found out), I am more concerned how we can keep
draft-wakikawa around and a modified draft-soliman (that handles 
grouping with the BID or whatever thing it would transform to during
the lifetime of draft-wakikawa) and yet satisfying Hesham's quest for 
efficiency.

Regards,
Gabor