Subject: Re: [Monami6] Flow Bindings and destination address in draft-soliman-monami6-flow-binding-00.txt

From: Gábor Fekete <[email-masked]>
Date: Fri, 2 Jun 2006 00:06:38 +0300

Hi Nicolas,

On Thursday 01 June 2006 21:53, Nicolas Montavont wrote:

snip

> > event:
> > o the HA receives a BU for (HoA-1, CoA-1) with FID (dst=IP-X, E set, D not-set)
> > 
> > The draft says in Section 7.3:
> >   "When the home agent receives a BU which includes at least one Flow
> >    Identification option, it first performs the operation described in
> >    section 10.3.1 of RFC3775."
> >   So, the algorithm jumps to 10.3.1.
> > 
> > RFC 3775 10.3.1:
> >   "If home agent accepts the Binding Update, it MUST then create a new
> >    entry in its Binding Cache for this mobile node or update its
> >    existing Binding Cache entry, if such an entry already exists."
> >   So, the algorithm updates the (HoA-1, CoA-1) binding.
> 
> In this case, the HA will not automatically update the existing entry.
> The BC is proposed to be extended to include additional fields, such as
> a Flow Id. With these extension, a BC entry is identified by the couple
> (HoA, Flow Id). Therefore, the BC entry is updated only if the HoA and
> the Flow Id in the BU are already identifying an existing entry.
> Otherwise, either a new entry will be created or the BU will be rejected
> depending on the validity of the FID option.
> 
I see.

> > 
> > Later in the draft in Serction 7.3:
> >   "o  Action = 0: add flow binding.  If the FID in the BU is the same as
> >       the FID in an existing binding cache entry for the same home
> >       address, the home agent sends back to the mobile node a BA with a
> >       error code 136 (FID already in use).  Otherwise, the home agent
> >       needs to create a new entry in the binding cache with the
> >       associated flow policies."
> >   So, the algorithm "needs to create a new entry". But what entry?
> 
> In your example, you never specified which Flow Id are used. Is the one
> in the BU is the same than the one stored in the BC?

Sorry! I meant a completely different FID.

> 	-> The FID is different, so a new entry may be created. However, as
> IP-X is different from HoA1, I fail to see when this entry would be
> used... 
> 
Exactly. That's one reason for the existence of this thread. :)

> >  A new
> >   binding cache entry or just a Flow Identifier attached/associated to
> >   the existing entry or a totally new binsing cache entry with HoA set
> >   to IP-X (assuming IP-X being a HoA that is diferent from HoA-1)?
> >   (And it is a HA BU, so no Return Routability is needed.)
> 
> As we wrote the draft, the additional fields are part of the BC and BUL.
> 
So does it mean that we can have a BC with these entries? :

HoA-1, CoA-1, ..., FID-1, ...
HoA-1, CoA-1, ..., FID-2, ...

If no, then why is it allowed to have multiple Flow Identifier options
in one single BU (Section 2, 1st paragraph) and why does the BC entry
modified to contain only a single FID?
If yes, then according to the draft, would the following BC entry be created
in my scenario (regardless when this entry would be used)? :

IP-X, Coa-1, ..., FID-from-the-BU

> > 
> > The draft is quite chaotic to me. It does not clearly define the relation
> > between Binding Cache entries and Flow Identifiers.
> 
> We'll try to clarify this in the next revision.
> 
Great! E.g. with some visual ASCII-art BC representations :)

> > It suggests that Flow Identifiers are managed separately from the
> > BU in which it was delivered (and in that case, piggybacked). E.g. why
> > the Dest Addr in the Flow Identifier Option needed? For HMIP? Why?
> > 
> > Section 2 of the draft:
> >   "Destination Address
> > 
> >       This field identifies the destination address of the data packet
> >       as seen by the receiver of the binding update.  For a
> >       correspondent node, the destination is the home address of the
> >       mobile node.  However, a mobility anchor point would see the
> >       destination address as the regional care-of address of the mobile
> >       node.  Hence, the mobile node needs to specify this field as seen
> >       by the receiver of the binding update."
> > 
> > And Section 6.1 of RFC4140 (HMIPv6), 1st paragraph:
> >   "After forming the RCoA based on the prefix received in the MAP
> >    option, the mobile node sends a local BU to the MAP with the A and M
> >    flags set.  The local BU is a BU defined in [1] and includes the
> >    mobile node's RCoA in the Home Address Option.  ..."
> >   So even for BUs to MAPs, this Dest Addr in the Flow Identifier is not
> >   needed since the HoA is set properly (i.e. to the RCoA) by the
> >   protocol-obeying HMIPv6 MN.
> > 
> > > I think FID can be used to select a specific CoA in case of multiple CoAs 
> > > bound to the same HoA.
> > > Let's focus on the packet forwarding, when HA receive the packet from CN to 
> > > MN(destination address of IP header is HoA), HA will search the binding in 
> > > the BC and select a specific BC entry (different CoA, same HoA) to forward 
> > > the packet according to FID(such as port number, protocol number ).
> 
> That's correct.
> 
> > > 
> > I think the same but the draft is not clear.
> > 
> > > In your example, FID is bound to a destination address IP-X. IMHO, it's 
> > > useless because FID is used to forward the packet whose destination address 
> > > must be  HoA.
> 
> That's correct. That's why I think Destination address must be the HoA
> (except in HMIP)
> 
And do you think that the Destination Address is needed in the Flow Identifier
option? Please, see my comments above about the HMIP case.
I fail to see the usefulness and necessity of the destination address field.
In my opinion all it causes is confusion and it is totally unnecessary.
Or do I fail to see some use case for it which cannot live without it?

> > > 
> > Exactly, it is useless if the draft "works" in the way you and I think.
> > But if it works in a different way then it makes me wonder if it's just broken
> > or I just simply don't understand it.
> > 
> > I wonder if the draft authors are planning to release an updated version.
> 
> Sure, we definitely need it :)
> 
> Nicolas
> 

Regards,
Gabor

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

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 8 Jun 2006 12:02:21 +0200

Hi Gabor,

> HoA-1, CoA-1, ..., FID-2, ...

Yes, this is totally correct, and it is the idea behind this draft.

> IP-X, Coa-1, ..., FID-from-the-BU

I think the misunderstanding is here. For me, the IP-X must be one  
home address. If nobody is against, I will clarify this in the draft,  
and as you suggested, either we'll use a MUST instead of "is the" in  
the definition of the destination address, or we can simply remove  
the field as you suggest below.

> Or do I fail to see some use case for it which cannot live without it?

I think you are right. I also fail to see the purpose of the  
destination address.

Tx again for the review

Nicolas

---

From: "Benjamin Lim" <[email-masked]>
Date: Fri, 9 Jun 2006 08:55:07 +0800

Hi Nicolas,

Pls see my small comments below. 

> -----Original Message-----
> From: Nicolas Montavont [mailto:[email-masked]] 
> Sent: Thursday, June 08, 2006 6:02 PM
> To: Monami6 WG
> Subject: Re: [Monami6] Flow Bindings and destination address 
> indraft-soliman-monami6-flow-binding-00.txt
> 
> Hi Gabor,
> 
> >>> o the HA receives a BU for (HoA-1, CoA-1) with FID 
> (dst=IP-X, E set, 
> >>> D not-set)
> >>>
> >>>    Identification option, it first performs the operation 
> described 
> >>> in
> >>>   "If home agent accepts the Binding Update, it MUST then 
> create a 
> >>> new
> >> The BC is proposed to be extended to include additional 
> fields, such 
> >> as a Flow Id. With these extension, a BC entry is 
> identified by the 
> >> couple (HoA, Flow Id). Therefore, the BC entry is updated 
> only if the 
> >> HoA and the Flow Id in the BU are already identifying an existing 
> >> entry.
> >> Otherwise, either a new entry will be created or the BU will be 
> >> rejected depending on the validity of the FID option.
> >>
> > I see.
> >
> >>>
> >> In your example, you never specified which Flow Id are 
> used. Is the 
> >> one in the BU is the same than the one stored in the BC?
> >
> >>>   binding cache entry or just a Flow Identifier attached/ 
> associated 
> >>> to
> >>>   the existing entry or a totally new binsing cache entry 
> with HoA 
> >>> set
> >> As we wrote the draft, the additional fields are part of 
> the BC and 
> >> BUL.
> >>
> > If yes, then according to the draft, would the following BC 
> entry be 
> > created in my scenario (regardless when this entry would be used)? :
> >
> I think the misunderstanding is here. For me, the IP-X must 
> be one home address. If nobody is against, I will clarify 
> this in the draft, and as you suggested, either we'll use a 
> MUST instead of "is the" in the definition of the destination 
> address, or we can simply remove the field as you suggest below.
> 
> >
> >>>
> >>> The draft is quite chaotic to me. It does not clearly define the 
> >>> relation between Binding Cache entries and Flow Identifiers.
> >>
> >>> It suggests that Flow Identifiers are managed separately 
> from the BU 
> >>> in which it was delivered (and in that case, piggybacked).
> >>> E.g. why
> >>>       node.  Hence, the mobile node needs to specify this 
> field as 
> >>> seen
> >>>   So even for BUs to MAPs, this Dest Addr in the Flow 
> Identifier is 
> >>> not
> >>>> I think FID can be used to select a specific CoA in case of 
> >>>> multiple CoAs bound to the same HoA.
> >>>> Let's focus on the packet forwarding, when HA receive the packet 
> >>>> from CN to MN(destination address of IP header is HoA), HA will 
> >>>> search the binding in the BC and select a specific BC entry 
> >>>> (different CoA, same HoA) to forward the packet according to 
> >>>> FID(such as port number, protocol number ).
> >>
> >> That's correct.
> >>
> >>>>
> >>>> useless because FID is used to forward the packet whose 
> destination 
> >>>> address must be  HoA.
> >>
> >> That's correct. That's why I think Destination address must be the 
> >> HoA (except in HMIP)
> >>
> > And do you think that the Destination Address is needed in the Flow 
> > Identifier option? Please, see my comments above about the 
> HMIP case.
> > I fail to see the usefulness and necessity of the 
> destination address 
> > field.
[Benjamin] For mobile host, there might not be a good purpose for it.
However, it can be useful when one considers NEMO and the use of destination
prefix. I feel that it is best to make this field optional for the NEMO
case. For the work group's consideration.

Regards,
Benjamin Lim

> >>> But if it works in a different way then it makes me 
> wonder if it's 
> >>> just broken or I just simply don't understand it.
> >>>

---

From: Nicolas Montavont <[email-masked]>
Date: Fri, 09 Jun 2006 10:02:48 +0200

Hi,

On Fri, 2006-06-09 at 08:55 +0800, Benjamin Lim wrote:

[snip]

> case. For the work group's consideration.

Yes, that's just what I thought when I was writing the option for the
updated version. In the case of NEMO it is very useful to have a
destination address/prefix option.

Just an example: if a MR has 2 CoAs and 2 LFN, the MR may want to direct
the traffic intended to LFN1 to CoA1 and the traffic intended to LFN2 to
CoA2.

Nicolas

---

From: Gábor Fekete <[email-masked]>
Date: Fri, 9 Jun 2006 16:50:47 +0300

Elo elo,

I see.

So, now I see that the conceptual BC entry would contain these
(among others):

- HoA
- Prefix 1, ..., Prefix N    (for NEMO)
- FID 1, ..., FID M          (for finer grade flow management)
- ...
- CoA

A FID may include a destination address field. The packet is
routed according to the BC entry that best (most tightly) matches
the packet. The HoA, the prefixes and the FIDs are used in the BC
entry lookup process (Of course the BC may be mapped to whatever
OS specific routing rules/routes).
The HoA, the prefixes and the destination IP addresses in the FIDs
stand in an "or" relationsip. FIDs themselves stand in an "or"
relationship.
The prefixes and FIDs are optional in a BC entry but it MUST
contain at least a HoA (since these infos are sent in a BU).

Then, in my original example, the entry that is created from the BU
would be this:

HoA-1, CoA-1, ..., FID-from-BU

with the FID containing IP-X. In this BC entry HoA-1 and FID.IP-X
stand in an "or" relationship for the entry lookup algorithm.

Now the only problem is that "the destination address in the FID must
be authorized" thing (which I just heard from Hesham and is not mentioned
in the draft at all).

I wonder if the destination IP address in the FID should be restricted
only to addresses that belong to the MNPs of the Mobile Router.

Thanks,
Gabor

---

From: Nicolas Montavont <[email-masked]>
Date: Fri, 09 Jun 2006 16:22:45 +0200

Hi,

> - FID 1, ..., FID M          (for finer grade flow management)

Yes, I would have not represent the fields like this, but this is the
information which is contained in the BC.

> be authorized" thing (which I just heard from Hesham and is not mentioned

That's right, and IMHO I don't think this is something we want to do. I
would prefer to restraint ourselves from using the destination address
for single nodes.

> only to addresses that belong to the MNPs of the Mobile Router.

I'd like to say yes, because I fail to see use cases for other addresses
than those belonging to MNP. Do you?

Nicolas

---

From: Tom Wan <[email-masked]>
Date: Tue, 13 Jun 2006 09:09:38 +0800

Hi,all:

The Monami6 WG will support NEMO protocol. But there are few considerations 
on NEMO,
I have two question:

1 In fact, MR is different from MN in the multiple interfaces scenarios.
   For example,MR may not support preference interface selection.

2 Many flow based solution may need to consider NEMO too, I think. But the 
flow based solution
   will need transport layer support. It has something to do with the 
UDP,TCP protocol.
   If MNN and CN have a security alliance, MR will not be able to know the 
transport layer information.
   In these scenarios, currently solution will not work.

How do you think about it?

BR
Tom

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 13 Jun 2006 10:30:00 +0800

Hello Tom,

>    For example,MR may not support preference interface selection.

Don't quite catch what you meant by this.  The same can be said for
MN ... "MN may not support preference interface selection" ...

Could you elaborate a bit?

>    In these scenarios, currently solution will not work.
Yes, but this has nothing to do with MR/NEMO.  If MN and CN uses IPSec,
neither can HA perform flow filtering based on port numbers.  In such
cases, the only way is for MN and CN to use flow labels or some other
IPv6 extension headers to mark their packets.  This is outside the scope
of Monami6, I think.

OTOH, apart from VPN, most security associations between MN and CN
nowadays exists in the upper layers, such as SSL, TLS, etc.  These will
not prevent port-number based flow filtering.

/rgds
/cwng

---

From: Tom Wan <[email-masked]>
Date: Tue, 13 Jun 2006 11:46:19 +0800

Hi,cwng:

The following is copied from the monami6 work group chater:

The objective of the Monami6 WG is to produce a clear problem
statement and to produce standard track specifications to the
straight-forward problems associated with the simultaneous use of
multiple addresses for either mobile hosts using Mobile IPv6 or mobile
routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6,
etc).

So I do not think NEMO is out of scope of MONAMI6. DO you think so?

ipsec is a basic protocol, and it must be supported by our solution.
I think it a basic princple.

In the first question, I mean that it is hard for MR to support preference 
settings
which is mentioned in the ps draft.

Tom

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 13 Jun 2006 13:30:21 +0800

Hello Tom,

> So I do not think NEMO is out of scope of MONAMI6. DO you think so?

I did not saying NEMO is out-of-scope (in fact, I am the one pushing for
it :)).  I say the use of flow labels or other extension headers to mark
flows for the use of flow filtering is out-of scope.  What is in scope
is that flow filtering using BUs must support the identification of
flows using flow labels or extension headers (which AFAICT, its already
there).  How the MN and CN synchronize themselves to do this is out-of
scope.

And my original point was not whether NEMO is in scope or not.  My point

>    In these scenarios, currently solution will not work.

is not specific to NEMO. Normal MIP6 flow filtering will have the same
problem with looking into TCP/UDP headers when MN and CN uses IPSec.

> I think it a basic princple.

It is supported.  Nobody say it is not supported.  You can use other
methods to differentiate flows that are protected by IPSec, such as
using the SPI, etc, etc.  Again, what is needed is that the filters
specification allows the SPI or flow label to be used as a parameter to
identify the flows.  How the MN or CN actually do it is out of scope,
IMO.

/rgds
/cwng

---

From: Tom Wan <[email-masked]>
Date: Tue, 13 Jun 2006 14:04:47 +0800

Hi cwng:

I do not want to argue against current solutions.
I am afraid of the result:
If all the solutions in the monami6 work group think that
NEMO is out of scope of their solutions. Then NEMO will be
really out of scope of monami6 work group.
If we do not consider NEMO in our solutions, will IESG accept
our solutions? This is my misgivings.

It may be a problem to consider mobile router in our solutions.
So I want to discuss this topic, and I have no anwser on
this topic now.
Anyway, I do not mean that flow based solutions are bad.

Tom

---

From: Michael Ye <[email-masked]>
Date: Tue, 13 Jun 2006 14:36:29 +0800

Hi Tom,
	Yes, I agree with you.
	Now,there is no good solution for NEMO route Optimization
though some solutions were put forward.
	The route Optimization solutions of NEMO using MONANMI6 NETLMM
etc is perhaps a good one I think.
BR 
Michael Ye 

-----Original Message-----
From: Tom Wan [mailto:[email-masked]] 
Sent: Tuesday, June 13, 2006 11:46 AM
To: Monami6 WG
Subject: Re: [Monami6]about NEMO

Hi,cwng:

The objective of the Monami6 WG is to produce a clear problem statement
and to produce standard track specifications to the straight-forward
problems associated with the simultaneous use of multiple addresses for
either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic
Support and their variants (FMIPv6, HMIPv6, etc).

ipsec is a basic protocol, and it must be supported by our solution. I
think it a basic princple.

In the first question, I mean that it is hard for MR to support
preference 
settings
which is mentioned in the ps draft.

Tom

----- Original Message ----- 
From: "Chan-Wah Ng" <[email-masked]>
To: "Monami6 WG" <[email-masked]>
Sent: Tuesday, June 13, 2006 10:30 AM
Subject: Re: [Monami6]about NEMO

> Don't quite catch what you meant by this.  The same can be said for MN

> ... "MN may not support preference interface selection" ...
>
>> 2 Many flow based solution may need to consider NEMO too, I think. 
>> But
>> the
>> flow based solution
>>    If MNN and CN have a security alliance, MR will not be able to
know 
>> the
> Yes, but this has nothing to do with MR/NEMO.  If MN and CN uses 
> IPSec, neither can HA perform flow filtering based on port numbers.  
> In such cases, the only way is for MN and CN to use flow labels or 
> some other IPv6 extension headers to mark their packets.  This is 
> outside the scope of Monami6, I think.
>
> nowadays exists in the upper layers, such as SSL, TLS, etc.  These 
> will not prevent port-number based flow filtering.
>
> /rgds
> /cwng
>
> [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 13 Jun 2006 15:14:33 +0800

Hi Tom,

> our solutions? This is my misgivings.

Once and for all, please read my previous posts more carefully.  Nobody
said anything about NEMO being out-of-scope. As I have said before,
being one of participants who push for NEMO to be in the charter, and
being the Editor for Multihoming NEMO Problem Statement, I am the last
person to say NEMO is out of scope.

> So I want to discuss this topic, and I have no anwser on

I thought that's what we are doing ... discussing.  I merely pointed out
to you that what you mentioned is not specific to NEMO.  It happens to
MIPv6 hosts as well.

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 13 Jun 2006 13:13:51 +0300

Hi Tom,

El 13/06/2006, a las 4:09, Tom Wan escribió:

> Hi,all:
>
> The Monami6 WG will support NEMO protocol. But there are few 
> considerations on NEMO,
> I have two question:
>

I fail to understand what do you think the problem is here... could you 
expand on this?

> 2 Many flow based solution may need to consider NEMO too, I think. But 
> the flow based solution
>   If MNN and CN have a security alliance, MR will not be able to know 
> the transport layer information.

as Chan-Wah mentioned this issue is not nemo specific... i guess the 
question is general about how to process IPSec flows and set 
preferences is those cases.... i guess that one option would be to 
classify flows based on the SPI... i don't know if current drafts 
consider this, but again, there is nothing nemo specific in this case 
AFICT

Regards, marcelo

---

From: Gábor Fekete <[email-masked]>
Date: Tue, 13 Jun 2006 17:10:16 +0300

Helo Nicolas,

On Friday 09 June 2006 17:22, Nicolas Montavont wrote:

snip

> than those belonging to MNP. Do you?
No, I don't. But I did not see the NEMO case either ;)

Gabor

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 13 Jun 2006 17:34:28 +0200

Hi,

On 13 juin 06, at 12:13, marcelo bagnulo braun wrote:

> I fail to understand what do you think the problem is here... could  
> you expand on this?
>
>> But the flow based solution
>>   will need transport layer support. It has something to do with  
>> the UDP,TCP protocol.
>> know the transport layer information.
> as Chan-Wah mentioned this issue is not nemo specific... i guess  
> the question is general about how to process IPSec flows and set  
> consider this, but again, there is nothing nemo specific in this  
> case AFICT

Yes it does consider the SPI as a possible parameter for flow binding.

Nicolas

---

From: Tom Wan <[email-masked]>
Date: Wed, 14 Jun 2006 10:41:43 +0800

Hello guys:
Thank you for replying to my question. But maybe I should elaborate my 
opinion.
I am not doubting your drafts. I just want to discuss on this topic, because 
all guys in this WG may
write their drafts, and they will have to confront this problem.

assumptions:
As we all know ipsec is a end-to-end protocol, and NEMO is supported by the 
monami6 WG.

scenarios:

 CN<---->HA <---->MR<----> MNN

problems:

there is a SA between MNN and CN. the packets sent from MNN to CN is 
encrypted, and there is a ESP header.
When the packet is routed to MR, MR will not know the transport layer 
information of the packet. So MR can not
use the flow policy on this packet.In current draft, flow policy is between 
MR and HA. It is not between MNN and
 HA, so flow policy will not work.

I am afraid that MR is different from MN, because MR will act as a router 
and Current solutions are all end-to-end
solutions, routers in the middle will not be able to decide policy for MNN. 
So when MR acts as a router, the flow
policy will not work.

conclusions:
MR is different from MN.If we think they are the same, there may be some 
problems.

BR
Tom

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 14 Jun 2006 09:38:20 +0300

Hi Tom,

El 14/06/2006, a las 5:41, Tom Wan escribió:

> I am not doubting your drafts.

FWIW i don't have any drafts in this wg :-)

>  I just want to discuss on this topic, because all guys in this WG may

>
> assumptions:
> As we all know ipsec is a end-to-end protocol, and NEMO is supported 
> by the monami6 WG.
>
> scenarios:
>
> use the flow policy on this packet.In current draft, flow policy is 
> between MR and HA. It is not between MNN and
> I am afraid that MR is different from MN, because MR will act as a 
> router and Current solutions are all end-to-end
> solutions, routers in the middle will not be able to decide policy for 
> MNN. So when MR acts as a router, the flow
> policy will not work.
>

ok, i think it is important to distinguish between the two directions 
of the communications:
- in the case of packets flowing from the CN to the MNN (located in the 
nemo), the one that needs to select the path is the HA, right? in this 
case, if the traffic is encrypted, the HA won't be able to perform 
policy based on the upper layer protocol information (e.g. TCP ports). 
Now this is the case both for nemo and for MIP (so nothing nemo 
specific in this case...)

- in the case of the packets flowing from the MNN to the CN, then i 
agree that in the MIP case, the MN can perform some form of policy 
based on upper layer protocol information, but in the nemo case the MR 
won't be able to do that since the upper layer information is hidden 
with the ESP.

So, the options here would be to perform policing based on the visible 
fields. One option would be the SPI field (that Nicolas mentioned that 
is already supported in the current draft, so no problem with this i 
guess). The other option could be doing it based on the flow label...

Anyway, the other additional tool that may be needed is a protocol to 
allow the MNN to inform the MR about the policy for each SPI value... 
However, i am not sure that this would be such a good idea, since it 
would require the host to be involved and in the current nemo approach 
the nemo support is transparent to MNN. Besides this would only be 
needed for the encrypted traffic...

Regards, marcelo

> conclusions:
> MR is different from MN.If we think they are the same, there may be 
> some problems.
>
> BR
> Tom
>
>
>
>

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 14 Jun 2006 10:21:21 +0200

> needed for the encrypted traffic...

Well, this has nothing to do with mobility management, so nothing
"forbids" such an exchange of information. It would have some value, but
not only in the mobility context, though, as for other things, this is
in mobile environments where interfaces come up and down at different
locations in the network topology that it would be the most useful.

Thierry
-- 
Thierry ERNST, PhD
INRIA Rocquencourt Project-Team IMARA
+33 1 39 63 59 30 (office)

---

From: Tom Wan <[email-masked]>
Date: Wed, 14 Jun 2006 16:59:18 +0800

Hi,Thierry :

Mobility managemant procedure is implemented on MR, MNN may not support mip 
protocol.
So it seems no way to solve this problem. Maybe MR should only apply the 
policy on those packets
whose source or destination address is MR. Or MR must ignore the policy. 
Maybe the ps draft should
mention this point? Just my own opinion.

BR
Tom

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 14 Jun 2006 11:47:01 +0200

Hi Tom,

What I said is that policy routing has nothing to do with mobility
support, so this has nothing to do with MIP and support policy routing
is orthogonal to a feature to support mobility. In addition, such a
feature would be useful in mobile environments as well as in fixed
environements.

Thierry.

On Wed, 14 Jun 2006 16:59:18 +0800

---

From: Tom Wan <[email-masked]>
Date: Wed, 14 Jun 2006 18:13:20 +0800

Hi Thierry:

It is true that normal policy routing has nothing to do with mobility 
support.
Usually, they are defined in the Qos related standards such as rsvp etc.

But in the mcoa scenarios, the choose of coa is a kind of policy too, and 
the
choice will lead todifferent routing method.

In the scenario I mentioned,  when MR receives a packet from MNN, it must
encapsulate it into a tunnel. Thus it must decide which COA to use as the 
tunnel end.
How can MR decide this? If the packet is ESP encrypted,  MR knows nothing 
about
the transport layer information of the packet.  So it can not decide which 
COA to use.
Do you think that it has nothing to do with mobility management?
To deal with this kind of packets, MR may not be able to use current flow 
binding/filtering policy,
I think.

I think other solutions may not be suitable with this scenario too.
So maybe we should mention it in the ps.
Do you think so?

BR
Tom

---

From: qinxia <[email-masked]>
Date: Tue, 20 Jun 2006 09:03:01 +0800

Hello all,

             Could you kind to give me comments ?

  The Bulk BU may be used in this draft, considering the default entry.
For, the default entry should be exist in the binding cache,  for the
following scenario:
The mobile node has two binding entries.

IF1 , BID1, FID1, COA1,HOA,other parameters   default flag
IF2, BID2, FID2,COA2,HOA,other parameters

If the IF1 is disabled , the BID1 should be deleted,  it is a default entry,
so the home agent has to delete the two entries.

But, in fact, the IF2 is still available, the BID 2 should not be obsoleted.
The mobile node may send a Bulk BU to the home agent.
In this bulk BU, simultaneously the home agent could get the deleteing of
COA1, and the appending of the new default entry( BID2 ).

Otherwise, the home agent has to delete all entries at first step, and the
home agent appends the BID2 as the default entry, since it receives the BU
from IF2.

[snip]  from that draft :

              7.4.1.  A binding cache entry expires

   If the default entry in the binding cache expires, the home agent
   MUST delete all other entries associated with the same home address,
   even for different CoAs.

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 20 Jun 2006 11:14:54 +0200

Hi,

>              Could you kind to give me comments ?

sure :)

> IF2, BID2, FID2,COA2,HOA,other parameters

Note that we didn't study the interaction between MCoA and Flow Binding.
These are independant protocols by now.
Moreover, the IF is not supposed to be in the Binding cache.

> so the home agent has to delete the two entries.

Yes this is what we wrote in the current draft, as you pointed out
below.

> COA1, and the appending of the new default entry( BID2 ).

I think of a different method: the MN can simply update entry 1 with
CoA2, i.e. send a flow binding option with FID1 and CoA2. In that way,
the CN keeps 2 entries attached to the same CoA. This is very convenient
if IF1 comes up again, because the MN will be able to update the first
entry again with the new CoA.

>    MUST delete all other entries associated with the same home address,

Makes me think that the same action must be taken if the MN explicitly
remove the default entry.

Regards,

Nicolas

---

From: "Benjamin Lim" <[email-masked]>
Date: Tue, 20 Jun 2006 18:00:39 +0800

Hi Nicolas, 

> Sent: Tuesday, June 20, 2006 5:15 PM
> To: Monami6 WG
> Subject: RE: [Monami6] Flow Bindings and destination 
> addressindraft-soliman-monami6-flow-binding-00.txt
> 
> Hi,
> 
> > If the IF1 is disabled , the BID1 should be deleted,  it is 
> a default 
> > entry, so the home agent has to delete the two entries.
> 
> Yes this is what we wrote in the current draft, as you 
> pointed out below.
> 
> > 
> > In this bulk BU, simultaneously the home agent could get 
> the deleteing 
> > of COA1, and the appending of the new default entry( BID2 ).
> 
> I think of a different method: the MN can simply update entry 
> 1 with CoA2, i.e. send a flow binding option with FID1 and 
> CoA2. In that way, the CN keeps 2 entries attached to the 
> same CoA. This is very convenient if IF1 comes up again, 
> because the MN will be able to update the first entry again 
> with the new CoA.
> 
> > 
> > Otherwise, the home agent has to delete all entries at 
> first step, and 
> > the home agent appends the BID2 as the default entry, since it 
> > receives the BU from IF2.
> > 
> > 
> > [snip]  from that draft :
> > 
[Benjamin] I have a question on why must the HA delete all other entries if
the default entry has expired? IE taking the example Alice gave, once IF 1
is down, HA deletes all entries (including the entry of FID 2). Why should
HA delete the entry of FID 2 if IF 2 is still active? Shouldn’t the entries
be independent of each other?

Regards,
Benjamin Lim

> Makes me think that the same action must be taken if the MN 
> explicitly remove the default entry.
> 
> Regards,
> 
> Nicolas
> 
> > 
> > 
> > 
> > > From: Nicolas Montavont 
> [mailto:[email-masked]]
> > > >>>   "When the home agent receives a BU which includes 
> at least one 
> > > >>> Flow
> > > >> In this case, the HA will not automatically update the 
> existing 
> > > >> entry.
> > > >>>   "o  Action = 0: add flow binding.  If the FID in 
> the BU is the 
> > > >>> same as
> > > >>>       address, the home agent sends back to the 
> mobile node a BA 
> > > >>> with a
> > > >>>       error code 136 (FID already in use).  
> Otherwise, the home 
> > > >>> agent
> > > home address. If nobody is against, I will clarify this in the 
> > > draft, and as you suggested, either we'll use a MUST 
> instead of "is 
> > > the" in the definition of the destination address, or we 
> can simply 
> > > remove the field as you suggest below.
> > > 
> > > >
> > > >>>
> > > >>>       This field identifies the destination address 
> of the data 
> > > >>> packet
> > > >>>       destination address as the regional care-of 
> address of the 
> > > >>> mobile
> > > >>>    option, the mobile node sends a local BU to the 
> MAP with the 
> > > >>> A and M
> > > >>>> Let's focus on the packet forwarding, when HA receive the 
> > > >>>> packet from CN to MN(destination address of IP 
> header is HoA), 
> > > >>>> HA will search the binding in the BC and select a 
> specific BC 
> > > >>>> entry (different CoA, same HoA) to forward the 
> packet according 
> > > >>>> to FID(such as port number, protocol number ).
> > > >>
> > > >> That's correct.
> > > >>
> > > >>>>
> > > >>>> In your example, FID is bound to a destination 
> address IP-X.  
> > > >>>> IMHO, it's
> > > >> That's correct. That's why I think Destination address must be 
> > > >> the HoA (except in HMIP)
> > > >>
> > > > And do you think that the Destination Address is needed in the 
> > > > Flow Identifier option? Please, see my comments above about the
> > > HMIP case.
> > > >>> Exactly, it is useless if the draft "works" in the 
> way you and I 
> > > >>> think.
> > > >>> I wonder if the draft authors are planning to release 
> an updated 
> > > >>> version.
> > > >>

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 20 Jun 2006 12:12:45 +0200

Hi,

> be independent of each other?

The problem is that a distant node (HA or CN) must always have a default
entry. This is because if a flow does not match any parameters in the
binding cache, the node must have a default CoA to send the data flows.

If the default entry expires, how the distant node can choose among the
remaining entries? Of course, in your case there is only one other
entry, but what if there are several?
We thought that the easiest way to manage with that problem is to simply
remove all bindings linked to the HoA, because the BC and BUL must
always be synchronized.
In a certain way, the expiration of the default entry is taken as an
error.

Do you think of another solution?

Nicolas

---

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

Hello, all,

mind if I jump in ...

On Tue, 2006-06-20 at 12:12 +0200, Nicolas Montavont wrote:

<snipped>

> entry, but what if there are several?

Wait a minute ... what bindings???  I think its unfortunate that the
authors of flow bindings draft would want to choose the term "binding",
I had preferred one of the original term "Filters".  Binding can mean
flow binding or address bindings.

I expect the draft in 7.4.1 to meant the flow bindings, but your later

> remove all bindings linked to the HoA, because the BC and BUL must

... seems to indicate the bindings of CoA-HoA should be purged as well
(since you mentioned BUL and BCE)????

I sure hope that is not what you meant!!!

/rgds
/cwng

---

From: Gábor Fekete <[email-masked]>
Date: Tue, 20 Jun 2006 14:40:09 +0300

Hi Chan-Wah,

> I sure hope that is not what you meant!!!

The title of 7.4.1 is "A binding cache entry expires". If a BC entry expires
it has to be removed. So, of course "the bindings of CoA-HoA should be purged
as well".

FIDs are bound to BC and BUL entries. If they are not then I am lost too!!!
I assume they are. So, if you remove a BC/BUL entry then FIDs go with it.
And anyway, FIDs are carried in BUs. So, for me it is natural to assume that
a FID belongs to the BC/BUL entry created/updated by that BU.
Nicolas?

Regards,
Gabor Fekete

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 20 Jun 2006 04:53:50 -0700

> flow binding or address bindings.

=> That's exactly what they are: Binding a flow to an address. 
If you want to use the word "filers" then I assume you mean "Binding a
filter
to an address", it's still a binding.

 > I sure hope that is not what you meant!!!

=> Why not? If you're removing an entry in the BC/BUL
then you're purging the binding. 

Hesham

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Tue, 20 Jun 2006 14:11:45 +0200

Hi,

> > [Benjamin] I have a question on why must the HA delete all other 
> > entries if the default entry has expired? IE taking the 
> example Alice 
> > gave, once IF 1 is down, HA deletes all entries (including 
> the entry 
> > of FID 2). Why should HA delete the entry of FID 2 if IF 2 is still 
> > active? Shouldn't the entries be independent of each other?
> 
> The problem is that a distant node (HA or CN) must always 
> have a default entry. This is because if a flow does not 
> match any parameters in the binding cache, the node must have 
> a default CoA to send the data flows.
> 
> If the default entry expires, how the distant node can choose 
> among the remaining entries? Of course, in your case there is 
> only one other entry, but what if there are several? We 
> thought that the easiest way to manage with that problem is 
> to simply remove all bindings linked to the HoA, because the 
> BC and BUL must always be synchronized. In a certain way, the 
> expiration of the default entry is taken as an error.
> 

Just a small thought. If the exsisting default entry expires, can't
HA/CN check its binding list and assign a new default entry from the
existing bindings, which has the longest lifetime. 

Koojana

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 20 Jun 2006 14:36:01 +0200

> existing bindings, which has the longest lifetime. 

Yes, but you loose synchronization with the MN/MR.

Nicolas

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 20 Jun 2006 14:35:10 +0200

> a FID belongs to the BC/BUL entry created/updated by that BU.

Very correct :)

Nicolas

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 21 Jun 2006 09:33:54 +0800

Hi Nicolas, 

> Sent: Tuesday, June 20, 2006 6:13 PM
> To: [email-masked]; Monami6 WG
> Subject: RE: [Monami6] Flow Bindings and 
> destinationaddressindraft-soliman-monami6-flow-binding-00.txt
> 
> Hi,
> 
> 
> > > 
> > > > 
> pointed out 
> > > 1 with CoA2, i.e. send a flow binding option with FID1 
> and CoA2. In 
> > > that way, the CN keeps 2 entries attached to the same 
> CoA. This is 
> > > very convenient if IF1 comes up again, because the MN 
> will be able 
> > > to update the first entry again with the new CoA.
> > > 
> > > > 
> only one other entry, but what if there are several?

[Benjamin] Actually this can be left to how implementers configure the
Filtering agent (I.e. to drop all packets that don't match any of the flow
rules, or by using an algorithm at the filtering agent to determine another
path to MN). Of course, I agree with your point that by purging the bindings
is the easiest method, but at the cost of MN losing some of its packets if a
current flow is still active during the sending of the binding updates with
the FIDs. So I guess the authors of the draft are fine with this tradeoff.

Regards,
Benjamin Lim

> We thought that the easiest way to manage with that problem 
> is to simply remove all bindings linked to the HoA, because 
> the BC and BUL must always be synchronized.
> In a certain way, the expiration of the default entry is 
> taken as an error.
>

---

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

> to an address", it's still a binding.

Yes, but it is confusing to me nonetheless.  Just like HoA and CoA are
all addresses ... and we make the effort to use their full term.  The
point is make it less ambiguous.  It is not the use of the word
"binding" that I think is unfortunately (there are only so many English
words).  It is the fact that _only_ the word "binding" is use that is
unfortunate.

> then you're purging the binding. 

Then this has nothing to do with the flow binding draft.  The
implication of this is way beyond the scope of flow bindings.  You are
removing CoA1-HoA, CoA2-HoA bindings because CoA0-HoA binding has
expired.  It should be addressed in the MCoA draft if BUL/BCE sync is
your concern.  Further, if the reason for the the purging is because of
the sync, why should a so-called non-default binding be treated any
differently from a so-called default binding?  Wouldn't the expiry of a
non-default binding caused the BUL/BCE to be out-of sync as well?

Anyway, these are the side issues, the fundamental question still
remains:  If CoA0 has expired but not CoA{1,2,3}, why should the expiry
of CoA0 cause the purging of the rest????

Sorry if i seems to miss or fail to grasp something important.

/rgds
/cwng

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 21 Jun 2006 08:42:20 +0200

HI Chan-Wah,

> words).  It is the fact that _only_ the word "binding" is use that is

So you suggest to use "flow binding", or something else?

> your concern.

Why do you talk about MCoA?

>   Further, if the reason for the the purging is because of

Your right, good point.

> of CoA0 cause the purging of the rest????

Considering flow bindings, if a node (HA/CN) does not have a default
entry for a HoA, it has no clue on how to select another CoA. I think
(please correct me if I'm wrong) that we only have 2 solutions to deal
with the expiration of the default entry:
	- either we remove all other bindings
	- or the node (HA/CN) selects by itself a new default entry.

In the second case, we might want to study what are the implications for
the MN. Does the node has to advertise the MN that it changes the
default entry? Is it correct to forward particular data flows to one CoA
of the MN while the MN did not request it.

One another possible way to deal with that, would be to set preferences
on CoAs. Rather than having a single default entry, the MN could set
preferences on CoAs, e.g.:
CoA1 -> Default
CoA2 -> pref 1
CoA3 -> pref 2
If the binding with CoA expires, the HA/CN can select the next preferred
CoA, i.e. CoA2.

Nicolas

> Sorry if i seems to miss or fail to grasp something important.

No at all, it's good to highlight these points.

Nicolas

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 21 Jun 2006 16:53:39 +0800

Hello Niclolas,

> So you suggest to use "flow binding", or something else?

Yes, I would suggest something not ambiguous. "Binding" is.  "Flow
Binding" or "Filters" or "Flow Filters" (or even "filter bindings" if
you wish) is not.

> Why do you talk about MCoA?

As far as I understand, MCoA draft is the draft that bring forth the
possibility of multiple CoA registrations.  The flow binding draft
builds on top of it to offer the capability of binding flows to these
multiple CoAs.

Now, by adding flow binding capability, you require that HA purge the
entire BCE when one out of N CoAs expires.  IMHO, what happens when 1
CoA expires out of N CoA should be addressed by MCoA draft.

> If the binding with CoA expires, the HA/CN can select the next preferred

I now understand the reason why you wanted to purge all bindings
(simpler than preference settings).  However, IMHO, any extension
feature should not cause degradation in the basic feature.  Without flow
filtering, an MN has a backup path with CoA{2,3} when CoA1 expires (or
is disrupted).  Now, with flow filtering, because of the question
whether HA should deliver packet to CoA2 or not, you choose the drastic
approach of deleting all backup paths.  It is, to me, a degradation of
the basic feature.

Since HA does not know if MN wants a packet to be delivered to CoA{2,3},
and since flow filtering does not provide any mechanism for MN to
specify if it wants a packet to be delivered to CoA{2,3} or not, IMHO,
HA should fall back to the operation as if there is no flow filtering
(i.e. MCoA).

On a side note, there are other places in the draft where similar
mandatory behavior I feel is not in line with the principle of "a new
feature should not cause an old feature to stop working" (eg a status
code > 128 when there is no default flow binding).  I am planning to do
a more detail review and submit it to the list, just wondering if the
authors are planning to submit a new draft before Montreal?  If so, I
will defer my review until the new version is published.

/rgds
/cwng

---

From: Andy Huang <[email-masked]>
Date: Wed, 21 Jun 2006 17:00:51 +0800

----- Original Message ----- 
From: "Nicolas Montavont" <[email-masked]>
To: "Monami6 WG" <[email-masked]>
Sent: Tuesday, June 20, 2006 8:36 PM
Subject: RE: [Monami6] Flow Bindings 
anddestinationaddressindraft-soliman-monami6-flow-binding-00.txt

> Yes, but you loose synchronization with the MN/MR.
Perhap purging all the bindings is the easiest method, but I don't think it 
is best method.
After HA/CN purging all the bindings MN has to register all the bindings 
once again.

IMHO, HA/CN can just assign a certain binding as default entry(according to 
priority, lifetime etc). After MN send BU to register the previous default 
binding, HA/CN will reuse the default binding so that HA/CN can keep 
synchronization with the MN/MR.

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 21 Jun 2006 02:30:33 -0700

> words).  It is the fact that _only_ the word "binding" is use that is

=> I'm not sure what you're asking for here. The word binding is
perfectly clear
to me. If you have a suggestion please make it.

 > expired.  It should be addressed in the MCoA draft if BUL/BCE sync is

=> That's a good point, I think we lumped two different cases together.
I think the MN can send a BU containing all the FIDs related to CoA0 and
binding them to CoA1 and making CoA1 the default in one message. This
way there is no need to purge anything in the HA. 
We need to describe the behaviour for the case where the MN did not
nominate another CoA to be a default. There are two choices: 
   A. Drop traffic that is not associated with an existing FID. or, 
   B. Pick one address as a default. 

We need to pick one of those two in the draft. 

   Further, if the reason for the the purging is 
 > because of

=> Sure, hence my suggestions above (A or B).

 > of CoA0 cause the purging of the rest????

=> It's no so much about purging the others, it's about forwarding the
flows that are not associated with either address. This is a side effect
to introducing policies in the HA. I agree with you that the current
description is unfortunate and needs to be changed. 

Hesham

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 21 Jun 2006 18:08:42 +0800

> to me. If you have a suggestion please make it.
I suggest using "Flow Bindings" instead of "Bindings".

> We need to pick one of those two in the draft. 

I think B is the appropriate approach. I gave my reasoning why in an
earlier respond to Nicolas on the list.

/rgds
/cwng

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 21 Jun 2006 11:36:21 +0200

> Binding" or "Filters" or "Flow Filters" (or even "filter bindings" if

So I think we agree, because in the draft we only use "flow binding".
It may be some bad shortcuts in the emails that make people use
"binding" :)

> builds on top of it to offer the capability of binding flows to these

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.

> CoA expires out of N CoA should be addressed by MCoA draft.

Ok so please launch a new threat for that, that explicitly involve MCoA.
It is right that both documents need a clear answer (which can be
different)

> approach of deleting all backup paths.  It is, to me, a degradation of

Good point.

> HA should fall back to the operation as if there is no flow filtering

Yeah, but if you fall down to a MCoA-like solution, what will be the
mechanism (as far as I know, you arbitrarily select one) ? You will send
traffic to CoA2 for example while the MN did not want to use it and
prefer stopping packets.
I would prefer another solution, such as preferences on CoAs.

> code > 128 when there is no default flow binding).

That was again the easiest way to deal with this issue. Another solution
would have been to make the first registration the default (if not
indicated), but again this involves synchronization problem.
Would you prefer that the HA accepts the BU, but refuse the Flow
Identification option?

>   I am planning to do
> authors are planning to submit a new draft before Montreal? 

Yes we will publish a new version for Montreal.

Nicolas

>  If so, I

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 21 Jun 2006 21:12:36 +0800

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

(PS> And I think its dangerous to use flow bindings for discarding
packets purposes, but that is another story.)

> traffic to CoA2 for example while the MN did not want to use it and

Correct.

> I would prefer another solution, such as preferences on CoAs.

If flow binding provide a preferences setting mechanism, yes.  But
sometimes we have to stop somewhere.  Policy control is a very complex
operation (any who had configured a Firewall would know :)).  Is it
really our intention to provide a full-fledged policy control mechanism
in mobile ip?  

I am not against preferences.  it is good, but adds complexity.  The WG
has to decide where we make the tradeoff between the amount of flow
filtering capabilities vs complexity.

> Would you prefer that the HA accepts the BU, but refuse the Flow

Yes, I think that fits in with my doctrine of graceful/no degradation.

> Yes we will publish a new version for Montreal.

Then I'll wait til it is published.

/rgds
/cwng

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 21 Jun 2006 15:31:06 +0200

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

[snip]

> filtering capabilities vs complexity.

That's a point we will raise during the next IETF.

Nicolas

---

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

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

I think some harmonization between flow binding and MCoA drafts is
necessary so that each solve their own specific problem.

/rgds
/cwng

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 22 Jun 2006 09:54:22 +0200

Hi Chan-Wah,

On 22 juin 06, at 03:50, Chan-Wah Ng wrote:

SNIP

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

Nicolas

---

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

Hi Nicolas,

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

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.

Regards,
Gabor

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 22 Jun 2006 11:04:39 +0200

Gabor,

> an open (non-proprietary) solution to the "how to use the CoAs  

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.

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

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

---

From: Gábor Fekete <[email-masked]>
Date: Thu, 29 Jun 2006 14:02:21 +0300

Hi Nicolas,

On Thursday 22 June 2006 12:04, Nicolas Montavont wrote:

[snip]

> can only be registered once in the BC/BUL. It means, in MCoA, that  

Do you say that you still have this problem with MCoA?
According to section "6.2.  Receiving Binding Update" of
draft-wakikawa-mobileip-multiplecoa-05, it is allowed to have such
a BC:
HoA1 -> CoA1, BID=1
HoA1 -> CoA2, BID=2
HoA1 -> CoA2, BID=3

[snip]

Regards,
Gabor

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 29 Jun 2006 06:08:57 -0700

> draft-wakikawa-mobileip-multiplecoa-05, it is allowed to have such

=> I'm not sure how this helps in the flow binding case. I think there is a simple point and people seem to be talking past it: In the flow binding case we are binding *flows* therefore we need to identify *flows* therefore we have a flow id in the flow id option; exactly where it belongs. The MCoA draft binds *addresses* to each other, therefore their bindings identify *addresses* and that's what the BID does. 
In other words we bind flows to a CoA. In doing that, we can't help but bind the CoA to the HoA because that's the nature of the BU. But we don't need a BID on the address level, because we don't care about that. The MCoA draft binds CoAs to HoAs. How are you suggesting we use that? And please be specific: what is the use of the BID in the BU sent in the flow binding draft? 

Hesham

---

From: Gábor Fekete <[email-masked]>
Date: Thu, 29 Jun 2006 18:15:43 +0300

Hi Hesham,

On Thursday 29 June 2006 16:08, Soliman, Hesham wrote:
> => I'm not sure how this helps in the flow binding case. I think 
> there is a simple point and people seem to be talking past it: 
> In the flow binding case we are binding *flows* therefore we need 
> to identify *flows* therefore we have a flow id in the flow id 
> option; exactly where it belongs. The MCoA draft binds *addresses* 
> to each other, therefore their bindings identify *addresses* and 
> that's what the BID does.       
> In other words we bind flows to a CoA. In doing that, we can't 
> help but bind the CoA to the HoA because that's the nature of 
> the BU. But we don't need a BID on the address level, because we 
> don't care about that. The MCoA draft binds CoAs to HoAs. How 
> are you suggesting we use that? And please be specific: what is 
> the use of the BID in the BU sent in the flow binding draft?      
> 
OK, thanks! I see your point. So you did not want to build on MCoA
because it would have made the design less efficient?

Regards,
Gabor

PS: Anyway, just to answer your question...

The BID can be used for the same purpose as the FID.
There is issue only if you allow multiple Flow Identification
options carried in the same BU.
The flow-binding draft currently handles this case by registering multiple
BC entries resulting in:

Please, correct me if I am wrong!

But if it built on top of MCoA then it could associate each Flow
Identification option to the BID in the BU,
and therefore to the same BC/BUL entry. So you would end up with:

HoA1 -> CoA1, BID=1, default
HoA1 -> CoA2, BID=2, FlowOpt(port 22) or FlowOpt(port 443)

And here is where I see your point. Managing the Flow Identification
options (remove/update) independently is tricky this way if you don't
have separate IDs for each Flow Id option.

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Thu, 29 Jun 2006 22:24:32 +0200

Hi Gabor,

> options carried in the same BU. The flow-binding draft 
> currently handles this case by registering multiple BC 
> entries resulting in:
> 
> But if it built on top of MCoA then it could associate each
> Flow Identification option to the BID in the BU, and 
> therefore to the same BC/BUL entry. So you would end up with:
> 

In the above eg, if we use BID only, you can't uniquely identify a flow.
For E.g, if user wants to delete/modify a particular filter (e.g. to
remove "port 22"), it's not flexible.

And also, do you send 2 separate BU messages to attach more than one
filter to one BID? Or will it be sent only with one BU? In the first
case, how do you set a filter such as  "FlowOpt(port 22) AND
FlowOpt(port 443)"? In the second case, flexibility to define different
filters are limited and also BU message will be larger when you attach
more filters. 

Koojana

> And here is where I see your point. Managing the Flow
> Identification options (remove/update) independently is 
> tricky this way if you don't have separate IDs for each Flow 
> Id option.
>

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 29 Jun 2006 19:48:17 -0700

> because it would have made the design less efficient?

=> Basically, yes. You either make it less efficient or make it efficient and make the BID redundant. In the latter case there is no point in including the BID at all.

 > options carried in the same BU.

=> Exactly, which is a likely scenario.

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

=> Well, you don't have to include the last two bindings in two separate entries of course. Bindings under CoA2 can be in the same entry.

 > have separate IDs for each Flow Id option.

=> Exactly. 

Hesham

---

From: Ken Nagami <[email-masked]>
Date: Fri, 30 Jun 2006 14:16:21 +0900

Hi Hesham,

At 22:08 06/06/29, Soliman, Hesham wrote:

>there is a simple point and people seem to be talking past it: In 
>the flow binding case we are binding *flows* therefore we need to 
>identify *flows* therefore we have a flow id in the flow id option; 
>exactly where it belongs. The MCoA draft binds *addresses* to each 
>other, therefore their bindings identify *addresses* and that's what 
>the BID does.
>In other words we bind flows to a CoA. In doing that, we can't help 
>but bind the CoA to the HoA because that's the nature of the BU. But 
>we don't need a BID on the address level, because we don't care 
>about that. The MCoA draft binds CoAs to HoAs. How are you 
>suggesting we use that? And please be specific: what is the use of 
>the BID in the BU sent in the flow binding draft?

The MCoA draft has the BID between a CoA and a flowID as you mentioned.
One advantage of the MCoA draft is as follow.
Many flowIDs bind to one CoA as following figure.
When the CoA1 changes to other CoA, in the MCoA case, only one 
re-binding between CoA and BID is needed.
But in flow binding case, many re-binding between CoA and FlowID is needed.

MCoA :
         CoA1 <-> BID1 <-> FlowID1
                       <-> FlowID2
                            ....

FlowBinding:
         CoA1 <----------> FlowID1
                           FlowID2
                            ....

Ken Nagami

---

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

> The MCoA draft has the BID between a CoA and a flowID as you 

=> I don't understand this statement. There are no flow IDs in the MCOA draft and there should not be. 

 > But in flow binding case, many re-binding between CoA and 

=> That's not true at all. Only one BU would be needed in the flow binding draft. One BU would list all the FID (not the whole option just the indices). 

Hesham