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]> > > ] 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]> > > ] 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:dmm- <mailto:dmm-> [email protected]> <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
