Hi, Tricci, I think the words "interoperate" and "interwork" are stronger than just "non-interference" or "co-existence" and the former imply some kind of protocol messages between DMM and centralized mobility management. We should avoid words like "interoperate" and "interwork". If we mean co-existence or non-interference we should say so.
I agree that DMM can be specified so as to support DMM-unaware MNs. However, we should be clear that those DMM-unaware MNs may not get the same service they were used to receiving with centralized mobility management. -Pete [email protected] wrote: > Dear Peter, > > For your first comment, I sincerely believe that you mis-interpret of > what I meant. Interworking and interoperable, IMHO, imply the DMM > network solution SHALL NOT interfere the existing network's already > deployed centralized mobility management scheme. Do you agree? > > As of co-existence, IMHO, as it is written, implies that both > solutions can be co-existed, however, it does not imply that the given > solution does not need to make change in order to be co-existed with > the other solution. > > Hence, the wording "compatible" applies to DMM is a perfect term > because, IMHO, compatible means "both" co-existence and > interworkable/interoperable. Hoping that you can agree with this > sentiment from me also. > > As for your 2nd comment, I believe that we already have the agreement, > i.e. >>>>>> >> As I mentioned in my previous email, I believe that the DMM generic >> requirement could allow the MN to be DMM aware; however, it SHALL >> NOT mandate that the MN must be DMM aware. > > That's ok as long as we don't require the DMM solution to provide > total IP address transparency to any MN, whether DMM-aware or not. >>>>>> > Hence, I prefer not to lead us into another lengthy discussions on > this specific point. > > As for your last question, the "this" that I am referring to is the > DMM solution. IMHO, the DMM solution should not neglect the legacy > MNs out there and NOT to provide them the DMM support just because > that they are NOT DMM-aware. Could we also agree on this one? > > Thank you for your time for discussing this subject with me. Tricci > > > > > > Peter McCann <[email protected]> > > 06/08/2012 08:40 AM To > "[email protected]" <[email protected]> > cc > "[email protected]" <[email protected]>, "[email protected]" > <[email protected]> Subject > RE: [DMM] 答复: Re: draft requirement REQ-4: compatibility > > > > > > > Hi, Tricci, > > Please see inline. > > [email protected] wrote: >> Dear Peter, >> >> Thank you for your prompt responses. >> >> I am confused where would the GTP-C come from in the context of >> interwork and interoperate? DMM today discussion is in the context of >> IETF, and 3GPP support both DSMIP and PMIP? Hence, why would GTP-C >> consideration turn up? > > If we require interworking and interoperation, that seems to imply > that the DMM protocol must somehow be connected to the centralized > mobility management scheme. One interpretation is to require the DMM > elements to speak the same tunnel set-up protocol used by the > centralized mobility management scheme, which as you say could be > GTP-C, PMIP, or DSMIP depending on the scenario. > > I think it would be a mistake to require any such signaling from the > DMM-enabled elements. > >> Regarding to your 2nd suggestions, I have two major concerns: (a) You >> seem to try to adjust the requirements based on implementation >> considerations, and I don't think that we should take this kind of >> approach to craft the requirement > > If we require something that is un-implementable or that requires a > very complex implementation then we aren't doing a very good job > specifying requirements. > >> (b) If your concern is regarding to the IP address transparency >> support, may I ask, why the consideration only apply to the network, >> but not to the MN? > > I'm not sure I understand your point (b). Can you re-state it? > >> When you suggested that the MN isn't capable of handling the >> acquisition and release of address during its packet data session, you >> seem to assume certain IP address allocation scheme that must be used >> by the MN (e.g. IPv6 Local Prefix). > > No, I'm not assuming any particular scheme. Whatever protocol is used > to allocate an address (DHCP, IPCP, SLAAC), some MNs might not be > capable of handling a change in the assigned address. That was all I > was trying to say. > >> As I mentioned in my previous email, I believe that the DMM generic >> requirement could allow the MN to be DMM aware; however, it SHALL >> NOT mandate that the MN must be DMM aware. > > That's ok as long as we don't require the DMM solution to provide > total IP address transparency to any MN, whether DMM-aware or not. > >> IMHO, this is not practical to >> support many legacy MN out there? > > Couldn't quite parse this sentence. What is the "this" in the above? > > -Pete > >> What do you think? Thanks >> Tricci >> >> >> >> >> >> Peter McCann <[email protected]> >> >> 06/08/2012 07:43 AM To "[email protected]" <[email protected]> cc >> "[email protected]" <[email protected]>, "[email protected]" >> <[email protected]> Subject RE: [DMM] 答复: Re: draft requirement >> REQ-4: compatibility >> >> >> >> >> >> >> Hi, Tricci, >> >> I am fine with co-existence, it should be possible to run DMM in >> parallel with an existing centralized solution. >> >> However, when you say "interwork and interoperate" it makes me wonder >> if we are requiring a DMM protocol to send and receive GTP-C. I think >> that would be a mistake. >> >> On the question of supporting legacy MNs, I think we can do this in a >> couple of different ways. One is to detect that they are legacy and >> then hook them up to the centralized mobility management scheme that is >> deployed in parallel to DMM. Another would be to connect them to the >> DMM-enabled part of the network and give them some degree of IP address >> transparency; however, if the MN isn't capable of handling the >> acquisition and release of addresses during its packet data session it >> may not get the full transparency that it expects. I want to make sure >> it is ok to spec out a DMM protocol that does not provide full IP >> address transparency to these legacy MNs. >> >> -Pete >> >> [email protected] wrote: >>> Dear Peter, >>> >>> For your first question regarding the term "compatible", IMHO, it >>> implies: >>> >>> (a) the DMM support can be "co-existed" with existing network >>> deployment with the centralized mobility management protocol. >>> >>> =====> I hope that you are NOT suggesting that, just because the >>> DMM is deployed, the network must get rid of all centralized >>> mobility management protocol, right? >>> >>> (b) the DMM support can interwork and interoperate with network >>> that may or may not support DMM; likewise, the DMM support can >>> interwork and interoperate with MN that may or may not support DMM >>> >>> =====> More specifically for the latter part in (b) above related to >>> the MN, it shall NOT be mandatory to require the MN to be DMM aware in >>> order to enable the DMM support in the network. Certainly, a given >>> proposed solution is allowed to have the MN to be DMM aware. However, >>> from the generic requirement perspective, it SHALL NOT mandate that >>> the UE must be DMM aware. >>> >>> I believe my latter description above answered your 2nd question also. >>> >>> Thanks. >>> Tricci >>> >>> >>> >>> >>> >>> Peter McCann <[email protected]> >>> >>> 06/08/2012 06:25 AM To >>> "[email protected]" <[email protected]>, "[email protected]" >>> <[email protected]> cc "[email protected]" <[email protected]> Subject >>> RE: [DMM] 答复: Re: draft requirement REQ-4: compatibility >>> >>> >>> >>> >>> >>> >>> In my opinion, the DMM solution should reduce or eliminate the need >>> for centralized mobility management protocols. So, I am not sure what >>> it would mean for DMM to be compatible with them. It may be a >>> substitute for them in many cases. >>> >>> Also, on the question of impact to the MN: I thought it was >>> generally agreed that we would allow for optimizations that take >>> into account the fact that some applications and mobile nodes do >>> not need IP address transparency throughout the lifetime of their >>> packet data session. I would hope that we can take advantage of >>> the presence of such mobile nodes, which might have special >>> software in them to deal with IP address transition issues. >>> >>> -Pete >>> >>> [email protected] wrote: >>>> >>>> Hi Tricci: >>>> >>>> Thank you for reminding us such an important aspect, the >>>> compatibility is a very important feature for the DMM of course. If >>>> the DMM supports the compatibility, it will help the DMM to be >>>> deployed in the real world. So ,basically, I agree the "SHOULD" >>>> should be change to "SHALL". >>>> >>>> Thanks for your suggestion. >>>> BR >>>> Luowen >>>> >>>> >>>> >>>> >>>> [email protected] >>>> 发件人: [email protected] >>>> >>>> 2012/06/08 14:16 收件人 >>>> h chan <[email protected]> >>>> 抄送 >>>> "[email protected]" <[email protected]> >>>> 主题 >>>> Re: [DMM] draft requirement REQ-4: compatibility >>>> >>>> >>>> >>>> >>>> >>>> >>>> Dear Anthony and LuoWen, >>>> >>>> Sorry for jumping in late to this discussion. If I have missed some >>>> prior discussion and repeat the same question, please forgive me. >>>> >>>> I agree with Anthony's view that, "“Other mobility protocols” can >>>> only refer to the existing mobility protocols that are already >>>> deployed. It cannot refer to “future protocols” or “any protocol in >>>> the literature which has not been deployed in the same environment in >>>> which dmm is being deployed. " >>>> >>>> However, when I refer to the current writing of the REQ#4: >>>>>>>>> >>>> REQ4: Compatibility >>>> >>>> The DMM solution SHOULD be able to work between trusted >>>> administrative domains when allowed by the security measures deployed >>>> between these domains. Furthermore, the DMM solution SHOULD preserve >>>> backwards compatibility with existing network deployment and end >>>> hosts. For example, depending on the environment in which dmm is >>>> deployed, the dmm solutions may need to be compatible with other >>>> existing mobility protocols that are deployed in that environment or >>>> may need to be interoperable with the network or the mobile >>>> hosts/routers that do not support the dmm enabling protocol. >>>> >>>> Motivation: The motivation of this requirement is to allow >>>> inter-domain operation if desired and to preserve backwards >>>> compatibility so that the existing networks and hosts are not >>> affected and do not break. >>>>>>>>> >>>> >>>> First question to ask is that, why the backward compatibility with >>>> existing network deployment and end hosts is "optional", and not >>>> "mandatory"? Wouldn't the compatibility with the existing >>>> deployment be the "fundamental" requirement? Hence, the "SHOULD" >>>> needs to be changed to "SHALL". >>>> >>>> Secondly, IMHO, compatibility has two aspects: >>>> (1) backward compatible with existing deployment that has been >>>> discussed above, but also >>>> (2) no impact with the mobile host but still able to enable the >>>> DMM solution at the network >>>> >>>> I don't believe that we are proposing the DMM solution requirement >>>> that must require the mobile node's support, correct? >>>> >>>> If we can agree on these two above fundamental sentiment, then, I >>>> would like to suggest a friendly amendment to REQ4 as follows: >>>>>>>>> >>>> REQ4: Compatibility >>>> >>>> The DMM solution SHOULD be able to work between trusted >>>> administrative domains when allowed by the security measures deployed >>>> between these domains. Furthermore, the DMM solution SHALL preserve >>>> backwards compatibility with existing network deployment and end >>>> hosts. For example, depending on the environment in which dmm is >>>> deployed, the dmm solutions SHALL BE compatible with other existing >>>> mobility protocols that are deployed in that environment or SHOULD BE >>>> interoperable with the network or the mobile hosts/routers that do >>>> not support the dmm enabling protocol. In addition, it SHOULD BE >>>> feasible to enable DMM network solution without the necessity to >>>> impact the existing mobile hosts. >>>> >>>> Motivation: The motivation of this requirement is to allow >>>> inter-domain operation if desired and to preserve backwards >>>> compatibility so that the existing networks and hosts are not >>> affected and do not break. >>>>>>>>> >>>> >>>> Hoping that you can accept these changes. Thanks in advance. >>>> Tricci >>>> >>>> >>>> >>>> h chan <[email protected]> Sent by: [email protected] >>>> >>>> 06/07/2012 09:41 PM >>>> >>>> To >>>> "[email protected]" <[email protected]> cc "[email protected]" >>>> <[email protected]>, "[email protected]" >>>> <[email protected]>, Peter McCann <[email protected]> Subject >>>> Re: [DMM] draft requirement REQ-4: compatibility >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Luowen, >>>> >>>> I understand that we earlier had a list of at least 3 requirements >>>> bundled inside this REQ-4. We are now adding a 4th and possibly >>>> 5th into this list regarding inter-domain. So I try to simplify 3 >>>> of them by examining the end result: whether existing network >>>> deployment and end hosts will break. >>>> >>>> What the dmm solution needs to do will then depend on the >>>> environment in which it is deployed. >>>> >>>> “Other mobility protocols” can only refer to the existing mobility >>>> protocols that are already deployed. It cannot refer to “future >>>> protocols” or “any protocol in the literature which has not been >>>> deployed in the same environment in which dmm is being deployed. >>>> >>>> If you want to be more specific, I suggest to append an >>>> explanatory sentence to explain the requirement rather than adding >>>> more requirements to the list. >>>> >>>> H Anthony Chan >>>> >>>> From: [email protected] [mailto:[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]> > <mailto:[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]> > > <mailto:[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]> > <mailto:[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]> > > > ] Sent: Thursday, June 07, 2012 >>>> 8:21 PM To: h chan Cc: [email protected]; [email protected]; jouni >>>> korhonen; Peter McCann Subject: 答复: RE: Re: [DMM] draft requirement >>>> REQ-4: compatibility >>>> >>>> >>>> Hi Antony, >>>> >>>> Yes, I agree, the DMM solution shall be compatibile with the exsiting >>>> network deployments. But only say "Existing network deployment and >>>> end hosts also SHOULD NOT break" or "the DMM solution SHOULD preserve >>>> backwards compatibility with existing network deployment and end >>>> hosts" may not be very specific. >>>> >>>> how about >>>> >>>> The DMM solution SHOULD enable working between trusted administrative >>>> domains when allowed by the security measures deployed between these >>>> domains. Furthermore, the DMM solution SHOULD preserve backwards >>>> compatibility with existing network deployment and end hosts that do >>>> not support the DMM enabling protocol. >>>> >>>> And put those description such as "The DMM solutions SHALL support >>>> existing network deployment with IPv6 (e.g. existing IPv6 address >>>> assignment), be compatible with other mobility protocols, and be >>>> interoperable with the network or the mobile hosts/routers that do >>>> not support the DMM enabling protocol so that the existing network >>>> deployments and end hosts are not broken." into the motivation, e.g >>>> >>>> Motivation: The motivation of this requirement is to ensure the DMM >>>> solutions to support existing network deployment with IPv6 (e.g. >>>> existing IPv6 address assignment), to be compatible with other >>>> mobility protocols, and to be interoperable with the network or the >>>> mobile hosts/routers that do not support the DMM enabling protocol, >>>> so that the existing network deployments and end hosts are not broken. >>>> >>>> Does it make sense? >>>> >>>> BR >>>> Luowen >>>> >>>> >>>> h chan <[email protected]> >>>> >>>> 2012/06/08 07:13 >>>> >>>> 收件人 >>>> "[email protected]" <[email protected]> >>>> 抄送 >>>> "[email protected]" <[email protected]>, "[email protected]" <dmm- >>>> [email protected]>, jouni korhonen <[email protected]>, Peter >>>> McCann <[email protected]> >>>> 主题 >>>> RE: Re: [DMM] draft requirement REQ-4: compatibility >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Luo, >>>> >>>> I think “existing network deployments which are not DMM enablded” >>>> are included in “existing network deployments. >>>> >>>> The end result is the compatibility with existing network deployment >>>> and end hosts. So whatever the dmm solution needs to do to ensure >>>> such compatibility. Do you agree? >>>> >>>> H Anthony Chan >>>> >>>> From: [email protected] [mailto:[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]> > <mailto:[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]> > > <mailto:[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]> > <mailto:[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]> > > > ] Sent: Wednesday, June 06, 2012 >>>> 1:15 AM To: h chan Cc: [email protected]; [email protected]; jouni >>>> korhonen; Peter McCann Subject: 答复: Re: [DMM] draft requirement >>>> REQ-4: compatibility >>>> >>>> >>>> Hi Anthony: >>>> >>>> It seems the REQ-4 is changed a lot. Interworking between trusted >>>> administrative domains is good to me, and the interworking with >>>> existing network deployments which are not DMM enablded is also very >>>> important. I believe we have already have consistency about this. So, >>>> how about mergering this two parts as following ? >>>> >>>> ------------------------------------------------------------------ - >>>> - - - - ---------- The DMM solutions SHALL support existing network >>>> deployment with IPv6 (e.g. existing IPv6 address assignment), be >>>> compatible with other mobility protocols, and be interoperable with >>>> the network or the mobile hosts/routers that do not support the DMM >>>> enabling protocol so that the existing network deployments and end >>>> hosts are not broken. Furthermore, the DMM solution MUST NOT break >>>> when being deployed between trusted administrative domains and SHOULD >>>> allow inter-working with the security measures deployed between these >>>> domains. >>>> ------------------------------------------------------------------ - >>>> - - - - ---------- >>>> >>>> Hope this make sense. >>>> >>>> BR >>>> Luowen >>>> >>>> h chan <[email protected]> >>>> 发件人: [email protected] >>>> >>>> 2012/06/06 01:26 >>>> >>>> >>>> >>>> 收件人 "[email protected]" <[email protected]>, Peter McCann >>>> <[email protected]>, jouni korhonen <[email protected]> 抄送 >>>> 主题 Re: [DMM] draft requirement REQ-4: compatibility >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Replacing REQ-4 with the following: >>>> >>>> REQ-4: compatibility >>>> The DMM solution MUST NOT break when being deployed between >>>> trusted administrative domains and SHOULD allow inter-working with >>>> the security measures deployed between these domains. Existing >>>> network deployment and end hosts also SHOULD NOT break. >>>> >>>> H Anthony Chan >>>> >>>> >>>> -----Original Message----- From: [email protected] >>>> [mailto:[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]> > >>>> <mailto:dmm- <mailto:dmm-> <mailto:dmm- <mailto:dmm-> > >>>> [email protected]> <mailto:dmm- <mailto:dmm-> <mailto:dmm- >>>> <mailto:dmm-> > <mailto:dmm- <mailto:dmm-> <mailto:dmm- >>>> <mailto:dmm-> > > [email protected]> ] On Behalf Of h chan Sent: >>>> Wednesday, May 23, 2012 8:02 PM To: Peter McCann; jouni korhonen Cc: >>>> [email protected] Subject: Re: [DMM] draft requirement REQ-4: compatibility >>>> >>>> An attempt to clean up the text for REQ-4: >>>> >>>> REQ-4: compatibility The DMM solutions SHALL support existing network >>>> deployment with IPv6 (e.g. existing IPv6 address assignment), be >>>> compatible with other mobility protocols, and be interoperable with >>>> the network or the mobile hosts/routers that do not support the DMM >>>> enabling protocol so that the existing network deployments and end >>>> hosts are not broken. REQ-4M (Motivation for REQ-4) Motivation: The >>>> motivation of this requirement is not to break existing network >>>> deployments and end hosts. OTHER related problem O-PS3: Complicated >>>> deployment with too many variants and extensions of MIP Deployment is >>>> complicated with many variants and extensions of MIP. When >>>> introducing new functions which may add to the complicity, existing >>>> solutions are more vulnerable to break. >>>> >>>> H Anthony Chan >>>> >>>> -----Original Message----- >>>> From: Peter McCann >>>> Sent: Friday, May 18, 2012 10:00 AM >>>> To: jouni korhonen; h chan >>>> Cc: [email protected] >>>> Subject: RE: [DMM] draft requirement REQ-4: compatibility >>>> >>>> Hi, Jouni, >>>> >>>> jouni korhonen wrote: >>>>> >>>>> On May 7, 2012, at 9:04 PM, h chan wrote: >>>>> >>>>>> REQ-4: compatibility The DMM solutions SHALL support existing >>>>>> network deployment with IPv6 (e.g. existing IPv6 address >>>>>> assignment), be compatible with other mobility protocols, and be >>>>>> interoperable with the network or the mobile hosts/routers that >>>>>> do not support the DMM enabling protocol so that the existing >>>>>> network deployments are unaffected. >>>>>> >>>>>> REQ-4M (Motivation for REQ-4) Motivation: The motivation of this >>>>>> requirement is to be able to work with network architectures of >>>>>> both hierarchical networks and flattened networks, so that the >>>>>> mobility management protocol possesses enough flexibility to >>>>>> support different networks, and so that the existing networks and >>>>>> hosts are not affected and do not break. >>>>> >>>>> Isn't the motivation just "SHALL not break existing network >>>>> deployments and end hosts" ? Either the network or the host may >>>>> not have any idea of the solutions developed in DMM. >>>> >>>> I think that's a reasonable simplification. We need a strategy >>>> for backwards compatibility. >>>> >>>> -Pete >>>> >>>>> - JOuni >>>>> >>>>>> >>>>>> OTHER related problem O-PS3: Complicated deployment with too >>>>>> many variants and extensions of MIP Deployment is complicated >>>>>> with many variants and extensions of >>>>> MIP. When introducing new functions which may add to the >>>>> complicity, existing solutions are more vulnerable to break. >>>>>> >>>>>> (The above has been drafted with contributions, inputs and >>>>>> discussions from various people. Additional contributions and >>>>>> comments are most >>>>>> welcome.) >>>>>> >>>>>> H Anthony Chan >>>>>> > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
