Subject: [MEXT] Comments on draft-ietf-mext-flow-binding-00

From: Romain KUNTZ <[email-masked]>
Date: Mon, 24 Nov 2008 00:12:03 +0100

Hello,

Here are some comments on draft-ietf-mext-flow-binding-00.
On the protocol side, I don't see the motivation behind the "Refresh"  
operation. The document says (section 4.7):

   The refresh operation is included in this specification due to the
   nature of the BU message.  The BU message updates existing bindings
   with new information.  Hence, all information previously sent in the
   last BU message need to be resent in all new messages, otherwise such
   information will be lost.

The flow bindings information are saved in the BCE, so as long as the  
BCE exists, the flow bindings remain, and when the BCE is deleted, the  
flow bindings are deleted. If I've read correctly, the draft never  
explicitly says that the flow bindings have to be deleted if they are  
not refreshed, and instead says that the flow bindings are deleted  
only when the BCE is deleted. So in the current state of the draft,  
refreshing seems useless.

Besides, note that refreshing can be a costly operation: Mobile  
Routers may have hundreds of rules, e.g. depending on the number of  
clients they serve.

Another concern is why another method to update a CoA is defined in  
this document (section 6.2)? First, I don't really see the motivations  
behind this, and if I understood correctly how n-casting is specified  
in the BC, one (HoA, FID) pair may reference multiple entries, which  
makes the CoA update impossible in case n-casting is used (see my  
other comment on that later).

* Some more detailed comments:

- Section 3.1, page 7, the Flow ID option shows a FID field of 16 bits  
but it is described as an "an 8-bit unsigned integer".
- Page 9, it is said "If this value is used, one or more Binding  
Reference sub-options MUST exist.". Actually only a single Binding  
Reference sub-option is used but one or more BIDs must be indicated  
inside of it.

- Section 3.2: The BID sub-option is 16 bits in the MCoA draft while  
here only 8 bits are used to specify a BID.
- Some indication is needed on how this option (which can have a  
variable length) should be aligned and padded using the MIPv6 padding  
options

- Section 4.2: "an entry is now identified by the pair (home address,  
FID)". This is true only when we want to update the flow bindings. To  
update a CoA (e.g. with a BU that only contains a BID option and no  
flow id options), the (HoA, BID) pair remains the key to lookup the BC/ 
BUL. Note also that the pair (HoA, FID) can refer to multiple entries  
when n-casting is used.

- Section 4.5: what happens if the flow id option has the PRO field  
set to 1 (modify) and no flow description is present? Section 6.2  
explains that it should be considered as a CoA update, but IMHO this  
should rather be considered as a request to modify the existing flow  
description in the BCE to a wild card request.

- Section 6.1.1: "The FID field includes a value that does not already  
exist in the mobile node's binding update list.": [...] for that HA or  
MAP
- "If the Binding Update sub-option includes only one BID," -> which  
sub-option, the Binding Reference sub-option?

- Section 6.1.2: "the mobile node MUST NOT refresh or delete bindings  
associated with any care-of address other than the one included in the  
BU message." -> why?

- Section 6.2: the "MODIFY" code is used but is never defined. It  
would be good to define the ADD/MODIFY/DELETE terms in section 3.1 and  
to use them through the document.

- Section 6.3 states that n-casting is possible with the CN with some  
conditions, but section 7.1 simply forbids n-casting ("If the Action  
field indicates a request to n-cast the flow, the correspondent node  
MUST reject the option [...]")

- Section 7.1: some notes on how the the flow binding is added to the  
binding cache should be written (existence of a BID sub-option in the  
BU, lookup in the BCE with that BID, ...). Same comment for section 8.1
- This section and section 8.1 do not say what to do when a request to  
delete a flow is received.

- Section 8.1: "the home agent MUST check for the presence of the BID  
sub-option(s)." -> actually section 3.2 does not mandate the presence  
of the BID sub-options if the BID already exists in the BCE ("A BID  
sub-option is not necessarily included in the same BU [...]"). If the  
BID does not exist yet in the BCE or if no BID sub-options are  
present, then this is an error case.
- "If one or more BIDs are present in the BID Reference sub-option" ->  
Binding Reference sub-option
- The following procedure is too complex IMHO:

      If only one BID were
      included in the Binding Reference sub-option and it pointed to a
      different care-of address from the one included in the packet,
      then packets matching the flow would be bicast to those two
      addresses.

Especially because the BU may be sent using another source address  
than the one expected for n-casting. Why not just forbid this case and  
explicitly ask for at least 2 BIDs in the binding reference sub-option?

- I think it was already raised, but the document lacks some text on  
what status code should be used upon error (section 7.1, 8.1, ...) and  
how such error code should be treated on the receiver side.

- Section 8.2: this section make me think that the section talking  
about the MN side does not say what should be done when the BAck is  
not received

- Section 10: "associate some flows to an interface and other flows to  
another interface": I would replace "interface" with "CoA"

* Some editorial comments:

The document is inconsistent on how "Binding Update" / "Binding  
Acknowledgement" / "Flow Identification" / "Flow Binding" / "Flow  
Description" / "N-cast" are written (the first letter is sometimes  
lower case, sometimes upper case)

Page 11: dsecription -> description
Page 15: Acknwoledgement -> Acknowledgement
Page 22: Correspondant -> Correspondent
Page 23: authrozied -> authorized

Cheers,
-- 
Romain KUNTZ
[email-masked]
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 24 Nov 2008 16:20:39 -0800

Hi Romain,

Please find some comments inline (note that I am not an author so Hesham or others may have a different opinion)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Romain
> KUNTZ
> Sent: Sunday, November 23, 2008 3:12 PM
> To: [email-masked]
> Subject: [MEXT] Comments on draft-ietf-mext-flow-binding-00
> 
> Hello,
> 
> The flow bindings information are saved in the BCE, so as long as the BCE
> exists, the flow bindings remain, and when the BCE is deleted, the flow
> bindings are deleted. If I've read correctly, the draft never explicitly says
> that the flow bindings have to be deleted if they are not refreshed, and
> instead says that the flow bindings are deleted only when the BCE is deleted.

The point is that flow bindings do not have any lifetime information. The lifetime is bound to the main binding. This implies that if the binding expires, the flow bindings expire too (which makes sense). A refresh BU is not different from any other BU so if you don't include any flow binding it would not be clear if the flow bindings are confirmed or not. I think this needs a clarification.

> So in the current state of the draft, refreshing seems useless.
> 
> Besides, note that refreshing can be a costly operation: Mobile Routers may
> have hundreds of rules, e.g. depending on the number of clients they serve.
> 

I see your concerns and I agree we should optimize this. 

One way would be to add a new flag in the BU which indicates that flow bindings are also extended with the new lifetime. Note that BIDs also must always be included in the BU as a BU without BID will overwrite all BIDs. 

Another approach is to introduce the lifetime at the FID level but that is not good in my opinion. 

> 
> Another concern is why another method to update a CoA is defined in this
> document (section 6.2)? First, I don't really see the motivations behind this,
> and if I understood correctly how n-casting is specified in the BC, one (HoA,
> FID) pair may reference multiple entries, which makes the CoA update
> impossible in case n-casting is used (see my other comment on that later).
> 

I don't fully understand your point here. Are you saying that a CoA change should always be done as per the MCoA draft (i.e. via BID)? If this is the intention, I agree - I don't see reasons why we should introduce the FIDs unless they need to be changed (e.g. added or removed).

> - Section 3.1, page 7, the Flow ID option shows a FID field of 16 bits but it
> is described as an "an 8-bit unsigned integer".
> - Page 9, it is said "If this value is used, one or more Binding Reference
> sub-options MUST exist.". Actually only a single Binding Reference sub-option
> is used but one or more BIDs must be indicated inside of it.
> 

I think both comments are correct

> - Section 3.2: The BID sub-option is 16 bits in the MCoA draft while here only
> 8 bits are used to specify a BID.

Better: the BID field in BID sub-option is 16 bits in the MCoA draft

> - Some indication is needed on how this option (which can have a variable
> length) should be aligned and padded using the MIPv6 padding options
> 
> - Section 4.2: "an entry is now identified by the pair (home address, FID)".
> This is true only when we want to update the flow bindings. To update a CoA
> (e.g. with a BU that only contains a BID option and no flow id options), the
> (HoA, BID) pair remains the key to lookup the BC/BUL. Note also that the pair
> (HoA, FID) can refer to multiple entries when n-casting is used.
> 

I think this is correct but also the text in the draft is correct. My understanding is that the text in the draft deals with the processing of BUs when they contain the FID option. If a BU only contains the BID option, the processing of the MCoA draft applies. 

> - Section 4.5: what happens if the flow id option has the PRO field set to 1
> (modify) and no flow description is present? Section 6.2 explains that it
> should be considered as a CoA update, but IMHO this should rather be
> considered as a request to modify the existing flow description in the BCE to
> a wild card request.
> 

More in general the draft should clarify how wild card request and default bindings are supported. See my review a couple of days ago for details on which are the issues in my view.

> - Section 6.1.1: "The FID field includes a value that does not already exist
> in the mobile node's binding update list.": [...] for that HA or MAP
> - "If the Binding Update sub-option includes only one BID," -> which sub-
> option, the Binding Reference sub-option?
> 
> associated with any care-of address other than the one included in the BU
> message." -> why?
> 
> - Section 6.2: the "MODIFY" code is used but is never defined. It would be
> good to define the ADD/MODIFY/DELETE terms in section 3.1 and to use them
> through the document.
> 
> conditions, but section 7.1 simply forbids n-casting ("If the Action field
> indicates a request to n-cast the flow, the correspondent node MUST reject the
> option [...]")
> 
> - Section 7.1: some notes on how the the flow binding is added to the binding
> cache should be written (existence of a BID sub-option in the BU, lookup in
> the BCE with that BID, ...). Same comment for section 8.1
> - This section and section 8.1 do not say what to do when a request to delete
> a flow is received.
> 
> - Section 8.1: "the home agent MUST check for the presence of the BID sub-
> option(s)." -> actually section 3.2 does not mandate the presence of the BID
> sub-options if the BID already exists in the BCE ("A BID sub-option is not
> necessarily included in the same BU [...]"). If the BID does not exist yet in
> the BCE or if no BID sub-options are present, then this is an error case.
> - "If one or more BIDs are present in the BID Reference sub-option" -> Binding
> Reference sub-option
> Especially because the BU may be sent using another source address than the
> one expected for n-casting. Why not just forbid this case and explicitly ask
> for at least 2 BIDs in the binding reference sub-option?
> 

Agree on this as I mentioned in my review of the draft

Gerardo

> - I think it was already raised, but the document lacks some text on what
> status code should be used upon error (section 7.1, 8.1, ...) and how such
> error code should be treated on the receiver side.
> 
> - Section 8.2: this section make me think that the section talking about the
> MN side does not say what should be done when the BAck is not received
> 
> - Section 10: "associate some flows to an interface and other flows to another
> interface": I would replace "interface" with "CoA"
> 
> 
> Acknowledgement" / "Flow Identification" / "Flow Binding" / "Flow Description"
> / "N-cast" are written (the first letter is sometimes lower case, sometimes
> upper case)
> 
> Page 15: Acknwoledgement -> Acknowledgement Page 22: Correspondant ->
> Correspondent Page 23: authrozied -> authorized
> 
> 
> 
> Cheers,
> --
> Romain KUNTZ
> [email-masked]

---

From: Benjamin Lim <[email-masked]>
Date: Tue, 25 Nov 2008 11:25:40 +0800

Hi all,

Pls see inline for my comment.

Giaretta, Gerardo wrote:
> The point is that flow bindings do not have any lifetime information. The 
> lifetime is bound to the main binding. This implies that if the binding 
> expires, the flow bindings expire too (which makes sense). A refresh BU is not 
> different from any other BU so if you don't include any flow binding it would 
> not be clear if the flow bindings are confirmed or not. I think this needs a 
> clarification.
[Ben] In section 6.2 last paragraph, for optimization, you can send the
BU with BID and without FID.  Although this section is for change in
CoA, can the same logic apply to a BU sent to extend the lifetime of a
current CoA?

If the MN wants to modify the flow binding (i.e. switch it to another
entry in BCE), it sets PRO field to 'replace'.  If MN wants to remove
flow binding, it sets PRO field to 'remove'. If MN does not indicate
anything, the flow binding stays with the current BCE.

If my above understanding is correct, then I do not see the need for the
refresh operation.

Is my understanding correct?

Regards,
Benjamin Lim

> One way would be to add a new flag in the BU which indicates that flow bindings 
> are also extended with the new lifetime. Note that BIDs also must always be 
> included in the BU as a BU without BID will overwrite all BIDs. 
>

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 25 Nov 2008 16:36:53 +1100

> Is my understanding correct?

=> I'll try to answer all of the above by simply stating the following:
The way MIPv6 works is that one BU replaces another, there is no state
differentials that are carried across between the old and new BCEs in an
implicit manner. 
What this means is that if you want to refresh a state, you include that
state in the BU. 
If we do the above, then we're simply removing the "big BU" to the remove
operation. If a MN wants to remove all FIDs, it can simply send a BU with
none of the FIDs included. Hence, removing all data is very efficient.

If we make the assumption that refreshing all is more common that removing
all (fair assumption I think) then we can try to optimise for that.

Hesham

>> Another approach is to introduce the lifetime at the FID level but that is
>> not 
>> good in my opinion.
>> 
>> I don't fully understand your point here. Are you saying that a CoA change
>> should always be done as per the MCoA draft (i.e. via BID)? If this is the
>> intention, I agree - I don't see reasons why we should introduce the FIDs
>> unless they need to be changed (e.g. added or removed).
>> 
>> I think this is correct but also the text in the draft is correct. My
>> understanding is that the text in the draft deals with the processing of BUs
>> when they contain the FID option. If a BU only contains the BID option, the
>> processing of the MCoA draft applies.
>> 
>> More in general the draft should clarify how wild card request and default
>> bindings are supported. See my review a couple of days ago for details on
>> which are the issues in my view.
>> 
>>> binding
>>> another
>>> Description"

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 25 Nov 2008 08:41:03 -0800

Hi Hesham,

> From: Hesham Soliman [mailto:[email-masked]]
> Sent: Monday, November 24, 2008 9:37 PM
> To: Benjamin Lim; Giaretta, Gerardo
> Cc: [email-masked]
> Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00
> 
> One comment below:
> 

I think it is a fair assumption. I think the following should be the principles to implement:

- add, replace, remove flow bindings require FID option in the BU
- a BU with BID options is used to update the binding in terms of CoA and lifetime, but does not change the flow binding. Flow bindings which correspond to a specific BID are not changed in this case.
- The lifetime of the flow binding is tied to the lifetime of the CoA binding. This implies that a flow binding is removed only if there is a remove action via FID option from the MN, if the respective BID is removed or the respective BID expires
- a BU without any BID option overwrites all bindings including the flow binding

The latter is used for example when the MN wants to go through MCoA mode to single CoA mode. 

Does it make sense?

Gerardo 

> FID)".
> exist

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 27 Nov 2008 11:44:45 +0100

Hello,

On 2008/11/25, at 17:41, Giaretta, Gerardo wrote:
> - a BU with BID options is used to update the binding in terms of  
> CoA and lifetime, but does not change the flow binding. Flow  
> bindings which correspond to a specific BID are not changed in this  
> case.
> - The lifetime of the flow binding is tied to the lifetime of the  
> CoA binding. This implies that a flow binding is removed only if  
> there is a remove action via FID option from the MN, if the  
> respective BID is removed or the respective BID expires

I'm in favor with what Gerardo is proposing. This is also what I had  
in mind.

Regards,
romain

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 27 Nov 2008 11:51:02 +0100

Hi Gerardo,

On 2008/11/25, at 1:20, Giaretta, Gerardo wrote:
>> this
> I don't fully understand your point here. Are you saying that a CoA  
> change should always be done as per the MCoA draft (i.e. via BID)?  
> If this is the intention, I agree - I don't see reasons why we  
> should introduce the FIDs unless they need to be changed (e.g. added  
> or removed).

Yes that was exactly my point. I think you take it into account in  
your other mail where you propose an algorithm to process the BU.

> Better: the BID field in BID sub-option is 16 bits in the MCoA draft

Yes, this is what I meant.

Thanks,
romain

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 27 Nov 2008 21:54:22 +1100

Hi Gerardo, 

> - a BU with BID options is used to update the binding in terms of CoA and
> lifetime, but does not change the flow binding. Flow bindings which correspond
> to a specific BID are not changed in this case.
> - The lifetime of the flow binding is tied to the lifetime of the CoA binding.
> This implies that a flow binding is removed only if there is a remove action
> via FID option from the MN, if the respective BID is removed or the respective
> BID expires

=> Mostly yes. But I think we need to be explicit to some extent about the
refresh. For example, what happens if you want to modify one or more FIDs
while keeping the others unchanged?
I think if we change things to the way you propose we have to have an
explicit option that says "refresh everything except for the FIDs included
in this BU, they need to be treated on a per-FID basis"
Otherwise, the mixed operations become quite messy.

There might be a simple way of doing this if we reserve one FID to indicate
"All". For instance, the all 1s FID can be used to say the above statement.

Hesham

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Thu, 27 Nov 2008 12:53:49 +0100

Hello Hesham & all,

I got some high-level questions on the draft. 

The text of the flow binding deliverable text in our charter says: 
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.

I am not 100% sure of my interpretation of the above, but I read it as 
if it should be possible for either of the mobile node/router or the 
home agent to initiate the flow/binding policies exchange. Is that 
appropriate?

If yes, am I understanding right that your draft only address an 
exchange of policies from the mobile host/router to the home agent? 

If yes, wouldn't it make sense to also support the exchange of policies 
initiated by the home agent, i.e. from the home agent to the mobile 
host/router, as I understand our charter says?

Orthognoal to that, I've got a dummy question: Why is flow/binding 
policy exchange only considered between MN/MR and HA and excludes 
flow/binding policy exchange between MN/MR and a correspondent node? Is 
it because one can't assume an arbitrary CN supports these extensions?

Thanks.

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 28 Nov 2008 06:21:27 +1100

Hi Julien,

This draft doesn't deal with "Policy exchange". Policy exchange does
something like the following:

- If 802.11b AND port 80 then use 802.11b
- if VoIP then use 3G
....etc
This draft deals with exchanging the routing information, based on policy
decisions that were done by the MN/MR.
There were other draft proposing XML policies be exchanged between the
MN/HA. They're orthogonal to this draft.

Also, the draft deals with MN-CN relationships already in the same way that
it deals with the MN-HA relationship.

Hesham

---

From: Benjamin Lim <[email-masked]>
Date: Fri, 28 Nov 2008 10:04:17 +0800

Hi Hesham & Julien,

For clarification, if some policy decision that are done on the HA/MAP
that influence how MN/MR should send uplink traffic, can HA/MAP use the
FID option to set these routing rules on the MN/MR?

If the mechanisms is similar, can we add some text in the introduction
section (2nd last paragraph) stating that the FID option can also be
sent from HA/MAP to MN/MR.

What do you think?

Regards,
Benjamin Lim

---

From: Benjamin Lim <[email-masked]>
Date: Fri, 28 Nov 2008 10:46:21 +0800

Hi all,

My comment inline. I snip to the text.

> "All". For instance, the all 1s FID can be used to say the above statement.
[Ben] For this way, there will be quite a significant number of rules
created to cater most permutation (i.e. refresh this group of rules).
Not sure if it raises the complexity in the terminal for rules processing.

To summaries, I believe we are trying to specify the behavior of HA (who
currently have rules for MN) and MN sends a BU without FID option.
Should the HA:
(a) totally do not care.
(b) treat them as MN is refreshing all rules.
(c) treat them as MN is deleting all rules.

For (a), it is as per the current draft (although not explicitly stated)
and if MN wants to do something to the rule, MN has to indicate it to HA
with FID option (i.e. when MN sends BU to refresh CoA, MN has to tell HA
via FID options on the status of each rule bound to that entry).

For (b) and (c), it is seen as an optimization of (a), due to the case
of MR that Romain brought up (which does make sense).

The disadvantage I see for (b) is when MN wants to remove all rules from
CoA (or a significant amount of rules) and keep that CoA entry in BCE,
MN needs to include all FID options with 'delete' action.  Question is
how often does this happen?

The disadvantage I see for (c) is when rules does not change, MN would
have to keep telling HA using FID option.  A way to combat this is to
create a FID that states refresh rule(s) and MN need only to tell HA of
this FID. Question is that will this create many rules in terminal and
hence increase complexity for rule processing?

Hopes this help for discussion.

Regards,
Benjamin Lim

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 28 Nov 2008 13:52:32 +1100

I think that's way too messy to include in this draft. Policy is a
completely different beast and is not necessarily based on a flow
descriptor. 

This should be done properly in a separate draft I think. There is a lot of
work out there that can be reused. I also would do this using something like
XML. This is not something that needs to be updated regulary or has any
relationship to movement.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Fri, 28 Nov 2008 10:39:17 +0100

Hi Hesham,

Maybe I shouldn't have used the term policy exchange. 

I understand the CN can be involved too, that's good.

How about the home agent initiating a routing information exchange 
towards the MN - that doesn't seem to be supported by the draft...

--julien

On Thursday 27 November 2008, Hesham Soliman wrote:
> This draft deals with exchanging the routing information, based on
> policy decisions that were done by the MN/MR.
> There were other draft proposing XML policies be exchanged between
> the MN/HA. They're orthogonal to this draft.
>
> Also, the draft deals with MN-CN relationships already in the same
> way that it deals with the MN-HA relationship.
>
> Hesham
>
>
> > 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.
> >
> > I am not 100% sure of my interpretation of the above, but I read it
> > as if it should be possible for either of the mobile node/router or
> > the home agent to initiate the flow/binding policies exchange. Is
> > that appropriate?
> >
> > If yes, wouldn't it make sense to also support the exchange of
> > policies initiated by the home agent, i.e. from the home agent to
> > the mobile host/router, as I understand our charter says?
> >
> > flow/binding policy exchange between MN/MR and a correspondent
> > node? Is it because one can't assume an arbitrary CN supports these
> > extensions?
> >
> > Thanks.
> >
> > --julien

-- 
--julien

[ New email address: [email-masked] ]
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 28 Nov 2008 20:47:19 +1100

Hi Julien,

> towards the MN - that doesn't seem to be supported by the draft...

=> We discussed this in some detail in MIP6. The problem with this approach
is that the HA can't possibly know what to recommend. In fact, the HA has no
way of knowing if the recommended access point even works. It kind of goes
against how MIPv6 works as well if the HA just changes routing by itself. If
the HA only suggests a change of routing then it's a policy configuration :)

So, I think the clean way to do this is to have a policy config mechanism
that can be used by the HA to configure the MN. I'm sure we can reuse other
work here and we shouldn't have to do this from scratch.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Fri, 28 Nov 2008 11:05:13 +0100

Thanks for the explanation Hesham. I understand the situation better 
now.

--julien

On Friday 28 November 2008, Hesham Soliman wrote:
> => We discussed this in some detail in MIP6. The problem with this
> approach is that the HA can't possibly know what to recommend. In
> fact, the HA has no way of knowing if the recommended access point
> even works. It kind of goes against how MIPv6 works as well if the HA
> just changes routing by itself. If the HA only suggests a change of
> routing then it's a policy configuration :)
>
> So, I think the clean way to do this is to have a policy config
> mechanism that can be used by the HA to configure the MN. I'm sure we
> can reuse other work here and we shouldn't have to do this from
> scratch.
>
> Hesham
>
> > --julien
> >
> >> This draft doesn't deal with "Policy exchange". Policy exchange
> >> does something like the following:
> >>
> >>> The text of the flow binding deliverable text in our charter
> >>> says: 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.
> >>>
> >>> I am not 100% sure of my interpretation of the above, but I read
> >>> it as if it should be possible for either of the mobile
> >>> node/router or the home agent to initiate the flow/binding
> >>> policies exchange. Is that appropriate?
> >>>
> >>> Orthognoal to that, I've got a dummy question: Why is
> >>> flow/binding policy exchange only considered between MN/MR and HA
> >>> and excludes flow/binding policy exchange between MN/MR and a
> >>> correspondent node? Is it because one can't assume an arbitrary
> >>> CN supports these extensions?
> >>>
> >>> Thanks.
> >>>
> >>> --julien

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Sun, 30 Nov 2008 16:24:10 -0800

I would also add that the HA does not even know which CoA is associated with which network interface type and therefore it would be difficult to provide routing information based on the CoA.

As a side note, the approach mentioned by Hesham (policies provided by the network and then followed by the MN when initiating mobility events) is also the one 3GPP is heading to with the work on ANDSF

Gerardo

> Sent: Friday, November 28, 2008 1:47 AM
> To: Julien Laganier
> Cc: [email-masked]; Giaretta, Gerardo
> Subject: Re: Questions on draft-ietf-mext-flow-binding-00
> 
> 
> Hi Julien,
> 
> 
> > Hi Hesham,
> >

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Sun, 30 Nov 2008 17:20:24 -0800

Hi Hesham,

> Sent: Thursday, November 27, 2008 2:54 AM
> To: Giaretta, Gerardo; Benjamin Lim
> Cc: [email-masked]

One option would be that we don't allow the change of a FID during the refresh operation. That would mean that to enable the scenario you mentioned the MN will send a refresh BU with all BIDs to be renewed and after that a new BU with the FID(s) to be changed. This has the drawback of requiring two BUs for the case where the MN wants to change the FID exactly when the BC entry is expiring. But is this a real drawback? Is this a common case which needs to be optimized?

> "All". For instance, the all 1s FID can be used to say the above statement.

Would this leave unchanged all the FIDs? If it is a confirmation of all FIDs, it seems not clean to allow a change of one specific FID in the same message. But this would work, though.

Gerardo

> change
> but
> >>>>> it
> Reference
> here
> >>>>> only
> variable
> >>>>> - Section 4.5: what happens if the flow id option has the PRO field set
> to
> >> 1
> >>>>> considered as a request to modify the existing flow description in the
> BCE
> >>>>> to
> >>>>> a wild card request.
> >>>>>
> >>>>
> sub-
> BU
> field
> >>>>> indicates a request to n-cast the flow, the correspondent node MUST
> reject
> >>>>> the
> >>>>> option [...]")
> >>>>>
> sub-
> >>>>> necessarily included in the same BU [...]"). If the BID does not exist
> yet
> >>>>> in
> what