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 On 12/03/09 06:08 AM, Hesham Soliman wrote:
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. HeshamRegards, Benjamin LimHeshamHence, 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-> CoA3The 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. HeshamRegards, 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 HeshamGerardo</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? HeshamIf 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