Subject: Re: [MEXT] multiple coa draft 11

From: Christian Kaas-Petersen <[email-masked]>
Date: Fri, 6 Mar 2009 07:51:09 +0000 (GMT)

Suppose a mobile node sends a BU with BID1 referring to v6CoAx,
and then later sends  another BU with BID2 referring to v6CoAx.  Then the
home agent should reject the second BU because two different BID-values
are expected referring to different care-of addresses.  To me this
is an inter-operability problem; and I think it is similar to the
problem of a mobile node sending a BU with BID=0 (see section 4.3
where "the value of zero is reserved and MUST NOT be used").
It was not obvious to me, which of the status values found in
section 4.4 would be appropriate.

Christian

--- Den tors 5/3/09 skrev George Tsirtsis <[email-masked]>:

> Fra: George Tsirtsis <[email-masked]>
> Emne: Re: [MEXT] multiple coa draft 11
> Til: "Christian Kaas-Petersen" <[email-masked]>
> Cc: [email-masked]
> Dato: torsdag 5. marts 2009 13.38
> some more inline...
> 
> On Thu, Mar 5, 2009 at 10:44 AM, Christian Kaas-Petersen
> <[email-masked]>
> wrote:
> >
> > Thanks a lot.  Two further comments inline
> >
> > --- Den tors 5/3/09 skrev George Tsirtsis <[email-masked]>:
> >
> >> Fra: George Tsirtsis <[email-masked]>
> >> Emne: Re: [MEXT] multiple coa draft 11
> >> Til: "Christian Kaas-Petersen" <[email-masked]>
> >> Cc: [email-masked]
> >> Dato: torsdag 5. marts 2009 11.02
> >> Hi Christian, some comments
> >> inline...
> >>
> >> On Thu, Mar 5, 2009 at 8:20 AM, Christian
> Kaas-Petersen
> >> <[email-masked]>
> >> wrote:
> >> >
> >> >
> >> > Hi Ryuji
> >> >
> >> > Reading draft-ietf-monami6-multiplecoa-11, I
> have some
> >> comments and
> >> > questions.
> >> >
> >> >  * There was a discussion on the mail-list
> in
> >> relation to draft 10,
> >> >   whether two diffent BID-values can map to
> the same
> >> care-of address.
> >> >   Draft 11 is not explicit on this.  As the
> entries
> >> in the
> >> >   binding cache are separate,
> >> >   and can be updated one by one, the benefit
> of
> >> having two BID-values
> >> >   point to the same care-of address comes
> when
> >> introducing flow
> >> >   identifier: flow identifiers can remain
> mapped to
> >> the same BID-value
> >> >   even when care-of addresses change.  It
> would help
> >> implementers
> >> >   if the draft somewhere (section 2?) states
> "Two BID
> >> values MAY
> >> >   refer to the same care-of address."
> >> >
> >>
> >> GT> You are reading MCoA and thinking Flow
> >> Bindings....which is not a
> >> good thing to do :-). The way MCoA and Flow
> Bindings have
> >> been
> >> designed, flow movement is based on mapping FIDs
> to
> >> different BIDs.
> >> BIDs simply identify available CoAs (i.e.,
> available
> >> paths). I do not
> >> see why would one point two BIDs to the same CoA.
> >
> > Will it be acceptable to add a statement like "Two
> BID-values
> > MUST NOT refer to the same care-of address" to the
> draft?
> >
> 
> GT2> MUST NOT is only appropriate if the action causes
> interoperability problems, which I am not sure it does
> here. I would
> like to hear other opinions though WRT to this since I have
> not
> thought about it in detail for some time. If there is no
> other
> foreseeable use of multiple BIDs pointing to the same CoA
> then, I
> would say something like "more than one BIDs  SHOULD
> NOT be mapped to
> the same CoA".
> 

      ___________________________________________________________ 
Skal du købe ny bil? Sammenlign priser på brugte biler med Kelkoo og find et godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 6 Mar 2009 18:34:00 +0900

Hi Christian, and all,

> are expected referring to different care-of addresses.  To me this

The MCoA doc does not prohibit assigning multiple BIDs to the same CoA.
Why does HA rejects the second BU?
The binding is managed independently for BID1 and BID2 (i.e. two  
bindings).
It does not cause any issue if HA accepts the second BU.

I don't think there is interoperability issue here..

> section 4.4 would be appropriate.

We didn't mention which status code is used for this case.
We can use MCOA MALFORMED. I will update the draft.

regards,
ryuji

> Skal du købe ny bil? Sammenlign priser på brugte biler med Kelkoo og  
> find et godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 07 Mar 2009 00:29:26 +1100

FWIW, I can't think of any reason why the MN would want to assign two BIDs
to the same CoA. I've commented on this before and don't know how it was
handled in the draft. I can understand how muliple FIDs can be assigned to
one BID (or CoA) but I can't think of any reason for assigning multiple BIDs
to the same CoA. It's at minimum confusing and can cause problems with
implementations. If there is no need for it, why would the spec be vague or
even allow it? 

Hesham

On 6/03/09 6:51 PM, "Christian Kaas-Petersen" <[email-masked]> wrote:

> Skal du købe ny bil? Sammenlign priser på brugte biler med Kelkoo og find et
> godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 9 Mar 2009 04:15:38 +0900

Hi Hesham, George, Christian,

Gerardo gives an example use case when MCoA is run with flow binding.
However, I agree the spec should not be vague.

As George suggested, I will add some texts saying multiple BID SHOULD  
NOT be assigned to a same CoA.
I don't see any interoperability issue, SHOULD NOT is ok.
If the Gerardo's use case is real (I think it is), you can overwrite  
the MCoA in the flow binding draft.

regards,
ryuji

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 9 Mar 2009 15:33:17 -0700

Sorry I had missed this email.

The resolution is fine with me.

Thanks
Gerardo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ryuji
> Wakikawa
> Sent: Sunday, March 08, 2009 12:16 PM
> To: Hesham Soliman
> Cc: [email-masked]
> Subject: Re: [MEXT] multiple coa draft 11
>

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 10 Mar 2009 09:45:56 +1100

Works for me.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 10 Mar 2009 14:12:05 -0400

Hi George/Ryuji,

> NOT be assigned to a same CoA.

This will just add an useless check :-). I still do not see what breaks 
when this check is not done. I prefer allowing multiple BIDs to point to 
the same CoA.

Cheers
Suresh

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 10 Mar 2009 19:32:21 +0000

Hey Suresh,

Beyond calling this whole thing "useless" :-)

Maybe you want to also tell us why you want this.
Also, tell us what you think about the downside discussed in this
thread i.e., having two ways of pointing flows to CoAs with both FIDs
and BIDs .....as opposed with just one (FIDs).

George

On Tue, Mar 10, 2009 at 6:12 PM, Suresh Krishnan
<[email-masked]> wrote:
>> As George suggested, I will add some texts saying multiple BID SHOULD NOT
>> be assigned to a same CoA.
>
> This will just add an useless check :-). I still do not see what breaks when
> this check is not done. I prefer allowing multiple BIDs to point to the same
> CoA.
>
> Cheers
> Suresh
>
>
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 11 Mar 2009 13:05:04 -0400

Hi George,

> Maybe you want to also tell us why you want this.

I believe that the use case brought up by Gerardo is valid and this is 
one of the ways how I was intending to use the BIDs.

> and BIDs .....as opposed with just one (FIDs).

I do not see this as a problem at all. As long as there are no 
interoperability issues, I feel that we should not worry about this. In 
other words, I fail to see the downside unless someone comes up with a 
scenario/use case that will cause an issue.

Cheers
Suresh

---

From: Benjamin Lim <[email-masked]>
Date: Thu, 12 Mar 2009 08:52:27 +0800

Hi all,

<snip from Christian's mail>
> I understand the SHOULD NOT to mean to the following:
>
> 1) The motivation for SHOULD NOT:  No known use case.

The above is not true.  We know of a use case with flow binding for
multiple BIDs to point to same CoA as what Gerardo describe.

If we want to put text in the MCoA draft for clarity, I prefer to say
something along the line that multiple BIDs MAY be assigned to the same CoA.

Regards,
Benjamin Lim

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 12 Mar 2009 12:12:11 +1100

> multiple BIDs to point to same CoA as what Gerardo describe.

=> Can someone point me to this case? I didn't see that email. Gerardo?

Hesham

---

From: Benjamin Lim <[email-masked]>
Date: Thu, 12 Mar 2009 09:18:07 +0800

Hi Hesham,

Mail was sent by Gerardo last week (friday on my client).  I snip his
respond.

<snip>
> As Christian mentioned there has been some discussions about the
> opportunity of having same CoAs for multiple BIDs. This may have a
> some advantages in some specific flow binding scenarios. However this
> is really something related to flow binding and I am not sure how to
> address it here. I think a MAY is fine as it does not create any
> interoperability issue.
>
> As a background, the scenario is the following:
> - MN has three interfaces with BID1, BID2, BID3 with some FIDs
> associated to each BID
> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In
> this case you have two possibilities:
> 1. the MN deregisters the BID2 and maps one by one all FIDs to other
> BIDs
> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid sending
> all the FID options. Automatically the FIDs are still bound to BID2
> but with an active CoA
>
> In some scenarios option 2 gives you an optimization in terms of
> signaling.
>
> Gerardo
</snip>

Regards,
Benjamin Lim

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 12 Mar 2009 12:43:19 +1100

Thanks, my response inline:

>> 1. the MN deregisters the BID2 and maps one by one all FIDs to other

=> There is "no one by one" mapping, they're all done at the same time.

>> all the FID options. Automatically the FIDs are still bound to BID2

=> I think this can cause a lot of confusion, but luckily we don't need to
go there. Please see below. You're assuming that the HA somehow knows where
to map FIDs when they're bound to multiple BIDs. I don't understand how you
think this will work. Perhaps you can send a step by step explanation.

>> In some scenarios option 2 gives you an optimization in terms of

=> I think this is a misunderstanding. This can be done with 1 message
anyway. Here it goes:

FID1 -> BID1->CoA1
FID2, FID5, FID7 -> BID2->CoA2
FID3 -> BID3->CoA3

Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU that
includes the following:
CoA3, BID3, FID2, FID5, FID7, FID3
Which results in the following binding:
FID1 -> BID1->CoA1
FID2,FID3, FID5, FID7 -> BID3-> CoA3

Hesham

---

From: Benjamin Lim <[email-masked]>
Date: Thu, 12 Mar 2009 09:58:25 +0800

Hi Hesham,

> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU
> that includes the following:

The example you give above is for possibility 1 in Gerardo's mail.  From
what I understand in possibility 2,  MN need not send a BU with FIDs.
All MN send is a normal BU that indicates change of CoA.  So the BU
(after CoA2 cannot be used) would be something like BID2->CoA1.

Hence, in the BCE at HA, it becomes:

FID1 -> BID1->CoA1
FID2, FID5, FID7 -> BID2->CoA1
FID3 -> BID3->CoA3

Do you feel that this would cause confusion at HA?

Regards,
Benjamin Lim

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 12 Mar 2009 13:05:29 +1100

> (after CoA2 cannot be used) would be something like BID2->CoA1.

=> BID2 -> CoA ? That doesn't map to the BCE you have below.

> Do you feel that this would cause confusion at HA?

=> Not only will the HA be confused, I'm confused! How do you think this
will work? Can you send me step by step messages and be clear on how the HA
handles having multiple FIDs pointing to multiple BIDs at the same time?
Until we see this, I don't think this scenario works at all unless I'm
missing something. 

Hesham

---

From: Benjamin Lim <[email-masked]>
Date: Thu, 12 Mar 2009 11:18:53 +0800

Hi Hesham,

I can try to explain in more detail.  Hopefully, it does not confuse you
more.  Pls see below for my example.

MN powers on its 3 IFs, does SA with HA and does an initial MCoA binding
at HA.

BCE @ HA
BID1 -> CoA1 (This is for IF1)
BID2 -> CoA2 (This is for IF2)
BID3 -> CoA3 (This is for IF3)

Now over a period of time, MN start binding flows to the BID to do flow
filtering.

BCE @ HA with FIDs
FID1       -> BID1 -> CoA1
FID2, FID3 -> BID2 -> CoA2
FID4       -> BID3 -> CoA3

HA does flow filtering based on the FIDs i.e. FID2 and FID 3 routed to CoA2.

Next, MN's IF2 changes point of attachment and gets a new CoA (CoA4).
MN sends BU1 to update the change of CoA to HA.

BU1 from MN to HA
Scr Addr: CoA4
BID Opt : BID2

When HA receives BU1 from MN, the BCE is modified as follows,

BCE @ HA with FIDs after receiving BU1
FID1       -> BID1 -> CoA1
FID2, FID3 -> BID2 -> CoA4 (change from CoA2)
FID4       -> BID3 -> CoA3

Flows matching FID2 and FID3 will now be routed by HA to CoA4.

Now, IF2 powers down and MN decides to move the flows to IF3.  For this,
MN sends BU2 to HA.

BU2 from MN to HA
Scr Addr: CoA3
BID Opt : BID2

When HA receives BU2 from MN, the BCE is modified as follows,

BCE @ HA with FIDs after receiving BU2
FID1       -> BID1 -> CoA1
FID2, FID3 -> BID2 -> CoA3 (change from CoA4)
FID4       -> BID3 -> CoA3

Hence, flows for FID2 and FID3 arriving at HA will now go to CoA3.

Regards,
Benjamin Lim

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 12 Mar 2009 17:14:45 +1100

Thank you! Some comments below.

> FID2, FID3 -> BID2 -> CoA3 (change from CoA4)

=> Ok, this example shows multiple BIDs pointing to the same CoA, but not
one BID pointing to more than one address, which is what I thought you were
suggesting (in addition to Gerardo's scenario), and that would be very
confusing. But it doesn't look like you're suggesting that. So I understand
the suggestion better now.

Regarding the scenario above, when IF2 goes down ( in the last step) you can
send a BU to bind FID2, FID3 to BID3, right? BID2 would still point at CoA4.

The question now is what happens in your example when CoA3 changes to CoA9?
Lets say the MN moved or for whatever reason the address on IF2 changed. You
need to update all BIDs (2 and 3) to point to CoA9, which is ok for the HA,
but not for the CN (it's treated as bulk registration).
So you're saving a non-critical message (removal of CoA4 which can be done
at any time) here but later you're adding a message at a critical time (say
the MN moved). I haven't read MCoA for some time but I believe it treats any
presence of more than one BID option as a bulk registration.
Am I missing something?

Hesham

---

From: Benjamin Lim <[email-masked]>
Date: Thu, 12 Mar 2009 15:23:06 +0800

Hi Hesham,

My replies inline.

> send a BU to bind FID2, FID3 to BID3, right? BID2 would still point at CoA4.
[Ben] Yes.  Since IF2 is down, you can also de-reg the binding for CoA4.

> presence of more than one BID option as a bulk registration.
[Ben] You are right to say that in MCoA bulk registration is not
supported to CN.  But, MN can always based on its BCE to determine if it
should send a bulk BU or individual BUs to the destination.  If the
destination is CN for the above case, MN would send 2 individual BUs to
change CoA3 to CoA9.

I agree that there is a tradeoff for such optimization but my point is
that we should not disallow binding a CoA to multiple BIDs in the MCoA
draft.

Regards,
Benjamin Lim

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 12 Mar 2009 18:45:28 +1100

> that we should not disallow binding a CoA to multiple BIDs in the MCoA

=> I thought the discussion was circulating around one valid scenario for
not disallowing this. But in this scenario there doesn't seem to be much
benefit anyway. That's why I was questioning the need to worry about this.

Hesham

>>>>>>>>> something along the line that multiple BIDs MAY be assigned to the
>>>>>>>>> same
>>>>>>>>> CoA.
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Benjamin Lim
>>>>>>>>> 
>>>>>>>>> Suresh Krishnan wrote:
>>>>>>>>>> Hi George,
>>>>>>>>>>

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 12 Mar 2009 09:53:06 +0000

I think I still agree with Hesham on this.

What Gerardo proposed and Ben expanded on, seems to provide at best an
optimization in terms of message length, with no difference in either
the number of exchanges or the functionality achieved.

BIDs, as well as FIDs, are just sort-labels identifying CoAs and Flow
Descriptors correspondingly.
I think we all agree that it is "possible" to associate multiple BIDs
with the same CoA. With the same way of thinking though it is also
"possible" to associated multiple FIDs with the same Flow Descriptor.
Should we do that too? I do not think so. Should we absolutely forbid
it? I do not think so either.

As I have stated before I think most of this does result necessarily
in incompatibility. It is mostly about emphasis and what the design
intention is. I think the drafts should make very clear how the draft
is intended to be used in the simple more generic case: i.e.,
- identify each available CoA with a BID --> one to one CoA-BID
mapping is a SHOULD
- identify each Flow of interest with a FID --> one to one
FlowDesc-FID mapping is a SHOULD
- Point FIDs to BIDs as needed.

This basic capability is already VERY advanced if you consider the
state of mobile Internet deployed today. So, limiting the obvious ways
of using this (using SHOULDs), while not forbidding other less-obvious
ways of using this, might not be a bad idea for now.

Regards
George

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 12 Mar 2009 21:08:22 +1100

FWIW I think SHOULD NOT strikes the right balance too, so count me in.

On 12/03/09 8:53 PM, "George Tsirtsis" <[email-masked]> wrote:

>>>>>>>>>>>> interoperability issues, I feel that we should not worry about
>>>>>>>>>>>> this.
>>>>>>>>>>>> In
>>>>>>>>>>>> other words, I fail to see the downside unless someone comes up
>>>>>>>>>>>> with
>>>>>>>>>>>> a

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 13 Mar 2009 14:57:31 -0700

Hi Hesham, Ben and George,

As I mentioned I am fine with SHOULD NOT. The scenario I brought up is a very specific scenario; with the solution I was suggesting and Ben highlighted you can indeed save some bits in some scenarios but if we look at the big picture it really does not imply much benefit.

For the records, the solution may make sense (i.e. saving of some bits) in a scenario where RO is not used and CoA is never changed within one technology (i.e. Mobile IP is only used for inter-technology handovers). This is one specific scenario 3GPP is looking at and this is why I brought it up. However I think the gain is not enough to justify the possible complexity and drawbacks.
 
Let's go with SHOULD NOT and consider the issue closed.

Gerardo

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hesham
> Soliman
> Sent: Thursday, March 12, 2009 3:08 AM
> To: George Tsirtsis
> Cc: [email-masked]
> >>>>>> will work? Can you send me step by step messages and be clear on how
> the
> >>>>>> HA
> >>>>>>>> => I think this can cause a lot of confusion, but luckily we don't
> need
> >>>>>>>> to
> >>>>>>>> to map FIDs when they're bound to multiple BIDs. I don't understand
> how
> >>>>>>>> you
> >>>>>>>>>>>> I believe that the use case brought up by Gerardo is valid and
> this
> >>>>>>>>>>>> is

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 13 Mar 2009 18:42:07 -0400

Hi Hesham/George,
   While I agree with you that this may not be useful in all scenarios, 
I think that SHOULD NOT implies that there is something inherently 
harmful with doing this. I simply fail to see any harm in allowing this. 
I was happy with the old text that said nothing :-)

Thanks
Suresh