Re: [MEXT] multiple coa draft 11

["Giaretta, Gerardo" <gerardog at qualcomm.com>]

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

> -----Original Message-----
> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On Behalf Of Hesham
> Soliman
> Sent: Thursday, March 12, 2009 3:08 AM
> To: George Tsirtsis
> Cc: mext at ietf.org
> Subject: Re: [MEXT] multiple coa draft 11
> 
> FWIW I think SHOULD NOT strikes the right balance too, so count me in.
> 
> 
> On 12/03/09 8:53 PM, "George Tsirtsis" <tsirtsis at googlemail.com> wrote:
> 
> > 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
> >
> > On Thu, Mar 12, 2009 at 7:45 AM, Hesham Soliman
> > <hesham at elevatemobile.com> wrote:
> >>
> >>
> >>> [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.
> >>
> >> => 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
> >>
> >>
> >>>
> >>> Regards,
> >>> Benjamin Lim
> >>>
> >>>>
> >>>>
> >>>> Hesham
> >>>>
> >>>>> Hence, flows for FID2 and FID3 arriving at HA will now go to CoA3.
> >>>>>
> >>>>> Regards,
> >>>>> Benjamin Lim
> >>>>>
> >>>>> Hesham Soliman wrote:
> >>>>>>
> >>>>>> On 12/03/09 12:58 PM, "Benjamin Lim" <benjamin.limck at sg.panasonic.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Hesham,
> >>>>>>>
> >>>>>>>> => 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
> >>>>>>> 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.
> >>>>>> => BID2 -> CoA ? That doesn't map to the BCE you have below.
> >>>>>>
> >>>>>>> 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?
> >>>>>> => 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Regards,
> >>>>>>> Benjamin Lim
> >>>>>>>
> >>>>>>> Hesham Soliman wrote:
> >>>>>>>> Thanks, my response inline:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 12/03/09 12:18 PM, "Benjamin Lim"
> <benjamin.limck at sg.panasonic.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> 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
> >>>>>>>> => There is "no one by one" mapping, they're all done at the same
> time.
> >>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>> => 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
> >>>>>>>>>> signaling.
> >>>>>>>> => 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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> Gerardo
> >>>>>>>>> </snip>
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Benjamin Lim
> >>>>>>>>>
> >>>>>>>>> Hesham Soliman wrote:
> >>>>>>>>>> On 12/03/09 11:52 AM, "Benjamin Lim"
> >>>>>>>>>> <benjamin.limck at sg.panasonic.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> 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.
> >>>>>>>>>> => Can someone point me to this case? I didn't see that email.
> >>>>>>>>>> Gerardo?
> >>>>>>>>>>
> >>>>>>>>>> Hesham
> >>>>>>>>>>
> >>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>> Suresh Krishnan wrote:
> >>>>>>>>>>>> Hi George,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote:
> >>>>>>>>>>>> Hey Suresh,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Beyond calling this whole thing "useless" :-)
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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).
> >>>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>> MEXT mailing list
> >>>>>>>>>>>> MEXT at ietf.org
> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> 
> 
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext