Hi Jouni, Georgios, please see inline.
>-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Jouni >Sent: Samstag, 26. Mai 2012 16:13 >To: [email protected] >Cc: [email protected] >Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single- >operator and cross-operator?) > > >Hi, > >On May 25, 2012, at 3:57 PM, <[email protected]> ><[email protected]> wrote: > >> Hi Jouni, >> >> Answering to your question(s): >> >>> At least we need to make a >>> distinction what cross administrative domain would mean: a) is it the >>> MN moving across administrative domains or b) possibly (current) IP >>> level anchor changing across administrative domains. >> >> Georgios: Please note that I was referring to both cases! > >Since I have difficulties believing b) would be a successful requirement >without slicing it into different use cases, I would ask you to list up what >use >cases you think b) is needed for and what assumptions there are for IP >anchoring & possible tunnel state. I think it helps if that request is moved to a lower level and discussed on the basis of handover between administrative domains versus roaming. Roaming does not imply any requirement on IP address continuity, I think the only requirement here is about authentication and authorization when the MN gets assigned an anchor in the visited network (along with a local IP address). Handover may imply some demand for IP address continuity, which should be handled by signaling according to the DMM solution. Again, more an issue of available trust and security associations to protect signaling. ..Unless inter-domain handling requires a dedicated functional entity for DMM, which I don't hope. If needed at all, what about placing a requirement just like: '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.' marco > >- Jouni > > > > > >> >> Best regards, >> Georgios >> >> >> >> >>> -----Original Message----- >>> From: Jouni [mailto:[email protected]] >>> Sent: vrijdag 25 mei 2012 14:49 >>> To: Karagiannis, G. (EWI) >>> Cc: [email protected]; [email protected]; >>> [email protected] >>> Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment >>> (single-operator and cross-operator?) >>> >>> >>> On May 25, 2012, at 3:21 PM, <[email protected]> >>> <[email protected]> wrote: >>> >>>> Hi Pierrick, >>>> >>>> Please see in line! >>>> >>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] >>>>> Sent: vrijdag 25 mei 2012 14:00 >>>>> To: Karagiannis, G. (EWI); [email protected] >>>>> Cc: [email protected] >>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment >>>>> (single-operator and cross-operator?) >>>>> >>>>> Hi, >>>>> >>>>> As an operator guy, I will not dispute a use-case dealing with roaming >>>>> :-). >>>>> However I think that it is out of the scope of our considerations >>>>> here (I mean, from the IETF standpoint). IMU, the goal of DMM is >>>>> not to specify a full system architecture (to which statement (1) >>>>> below seems to refer); the goal of DMM is, in a first stage, to >>>>> assess the use of legacy protocols in a distributed anchoring >deployment. >>>> >>>> Georgios: Not really defining a system architecture, but more the >>>> protocol >>> framework! The definition of the "distribution anchoring deployment" >>> borders is part of that! >>> >>> From my point of view, the protocol solutions (even what we have >>> today in mobility area) do not prohibit cross administrative domain >>> mobility. It is more a deployment decision loaded with non-techninal far >from trivial issues. >>> >>> I do not like seeing this as a requirement. At least we need to make >>> a distinction what cross administrative domain would mean: a) is it >>> the MN moving across administrative domains or b) possibly (current) >>> IP level anchor changing across administrative domains. >>> >>> - Jouni >>> >>> >>> >>>> >>>>> >>>>> Moreover, statement (2) below, is more a solution hints than a >>> requirement. >>>>> Typically, (2) is about HA/LMA relocation which may be, or not, a >>>>> solution to meet Anthony's req#1. So, IMHO, req#1 addresses your >>> concern. >>>> >>>> Georgios: I think that the current description of REQ-1 is not >>>> really >>> addressing my concern! >>>> >>>> Best regards, >>>> Georgios >>>> >>>>> >>>>> That's only my opinion; let's see what others think. >>>>> >>>>> BR, >>>>> Pierrick >>>>> >>>>>> -----Message d'origine----- >>>>>> De : [email protected] [mailto:[email protected]] Envoyé : >>>>>> vendredi 25 mai 2012 12:28 À : SEITE Pierrick RD-RESA-REN; >>>>>> [email protected] Cc : [email protected] Objet : RE: [DMM] >>> draft >>>>>> requirement REQ-1: Distributed deployment (single-operator and >>>>>> cross-operator?) >>>>>> >>>>>> Hi Pierrick, >>>>>> >>>>>> The goal of such a requirement is to emphasize that the DMM >>>>>> protocol(s) that will be designed/specified by the DMM WG should >>>>>> be agnostic to whether users are roaming/moving into wireless >>>>>> coverage >>>>>> area(s) managed by either one single operator or by more than one >>>>> operators. >>>>>> I think that this will have an impact on some of the requirements >>>>>> listed already by Anthony! >>>>>> Security association is one such requirement, other requirements >>>>>> are related to for example the possibility of the DMM protocol(s) >>>>>> to >>>>>> (1) easily use the user profile and mobility information when >>>>>> users are roaming away from their home operator, (2) use and >>>>>> support seamless, real time and dynamic change of the mobility >>>>>> anchors that could be located in different communication area(s) >>>>>> managed by different operators. >>>>>> >>>>>> Best regards, >>>>>> Georgios >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: [email protected] >>>>>>> [mailto:[email protected]] >>>>>>> Sent: vrijdag 25 mei 2012 9:49 >>>>>>> To: Karagiannis, G. (EWI); [email protected] >>>>>>> Cc: [email protected] >>>>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed >>>>>>> deployment (single-operator and cross-operator?) >>>>>>> >>>>>>> Hi Georgios, >>>>>>> >>>>>>> It seems to me that the requirement: "need of supporting both >>>>>>> single- operator and cross-operator mobility management" is a >>>>>>> deployment requirement. I understand the requirement but I do not >>>>>>> see how to "translate it" into an IP generic wording. FSo, >>>>>>> fcusing only on >>>>>> protocols (as we >>>>>>> are supposed to) how would you reformulate your requirement? Is >>>>>> talking >>>>>>> about "capability to establish security associations between >>>>>>> mobility >>>>>> entities" >>>>>>> would be acceptable? >>>>>>> >>>>>>> Br, >>>>>>> Pierrick >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : [email protected] [mailto:[email protected]] De la >>> part >>>>>> de >>>>>>>> [email protected] Envoyé : vendredi 25 mai 2012 07:49 À : >>>>>>>> [email protected] Cc : [email protected] Objet : Re: [DMM] >>>>>>>> draft requirement REQ-1: Distributed deployment (single-operator >>>>>>>> and >>>>>>>> cross-operator?) >>>>>>>> >>>>>>>> Hi Anthony, >>>>>>>> >>>>>>>> I am not sure whether it can be incorporated in REQ-4 or whether >>>>>>>> it could be considered as being an additional requirement! >>>>>>>> I am in favour of adding a new requirement that satisfies this >>>>>> issue! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Georgios >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> Van: h chan [[email protected]] >>>>>>>> Verzonden: donderdag 24 mei 2012 19:36 >>>>>>>> Aan: Karagiannis, G. (EWI) >>>>>>>> CC: [email protected] >>>>>>>> Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed >>>>>> deployment >>>>>>>> (single-operator and cross-operator?) >>>>>>>> >>>>>>>> Georgios, >>>>>>>> >>>>>>>> Do you think whether REQ-4 may be a better place to discuss. >>>>>>>> REQ-4 >>>>>> is >>>>>>>> talking about compatibility. It already includes compatibility >>>>>>>> with other (such as 3GPP) mobility protocols. We can check what >>>>>>>> else are needed there for cross-operator mobility. >>>>>>>> >>>>>>>> If you agree, we can move this cross-operator issue over the >>>>>>>> REQ-4 thread. >>>>>>>> >>>>>>>> H Anthony Chan >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: [email protected] [mailto:[email protected]] >>>>>>>> Sent: Thursday, May 24, 2012 1:06 AM >>>>>>>> To: h chan >>>>>>>> Cc: [email protected] >>>>>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed >>>>>>>> deployment (single-operator and cross-operator?) >>>>>>>> >>>>>>>> Hi Anthony, Hi all, >>>>>>>> >>>>>>>> During the last DMM meeting in Paris, I have raised the issue >>>>>>>> of cross-operator mobility management support. >>>>>>>> Not sure if this issue can be satisfied by incorporating it into >>>>>> REQ-1 >>>>>>>> Distributed deployment, or if it will be needed to create an >>>>>>>> additional requirement that incorporates the need of supporting >>>>>> both >>>>>>>> single- operator and cross-operator mobility management. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Georgios >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> Van: [email protected] [[email protected]] namens h >>> chan >>>>>>>> [[email protected]] >>>>>>>> Verzonden: donderdag 24 mei 2012 1:20 >>>>>>>> Aan: Jouni; Peter McCann >>>>>>>> CC: [email protected] >>>>>>>> Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed >>>>>> deployment >>>>>>>> >>>>>>>> An attempt to clean up the text for REQ-1 below: >>>>>>>> >>>>>>>> REQ-1: Distributed deployment >>>>>>>> IP mobility, network access and routing solutions provided by >>>>>>>> DMM SHALL enable a distributed deployment of mobility >management >>>>>>>> of IP sessions so that the traffic can be routed in an optimal >>>>>>>> manner without traversing centrally deployed mobility anchors. >>>>>>>> REQ-1M (Motivation for REQ-1) >>>>>>>> The goals of this requirement are to match mobility deployment >>>>>>>> with current trend in network evolution: more cost and resource >>>>>> effective >>>>>>>> to cache and distribute contents when combining distributed >>>>>>>> anchors with caching systems (e.g., CDN); improve scalability; >>>>>>>> avoid single point of failure; mitigate threats being focused on >>>>>>>> a centrally deployed anchor, e.g., home agent and local mobility >anchor. >>>>>>>> RELEVANT problems: >>>>>>>> PS1: Non-optimal routes >>>>>>>> Routing via a centralized anchor often results in a longer >>>>>>>> route, >>>>>> and >>>>>>>> the problem is especially manifested when accessing a local or >>>>>> cache >>>>>>>> server of a Content Delivery Network (CDN). >>>>>>>> PS2: Non-optimality in Evolved Network Architecture The >>>>>>>> centralized mobility management becomes non-optimal as network >>>>>>>> architecture evolves and flattens. >>>>>>>> PS3: Low scalability of centralized route and mobility context >>>>>>>> maintenance Setting up such special routes and maintaining the >>>>>>>> mobility context including the tunnel state for each MN is more >>>>>>>> difficult to scale in a centralized design with a large number >>>>>>>> of >>>>>> MNs. >>>>>>>> Distributing the route maintenance function and the mobility >>>>>> context >>>>>>>> maintenance function among different networks can be more >>> scalable. >>>>>>>> PS4: Single point of failure and attack Centralized anchoring >>>>>>>> may >>>>>> be >>>>>>>> more vulnerable to single point of failure and attack than a >>>>>>>> distributed system. >>>>>>>> >>>>>>>> H Anthony Chan >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jouni [mailto:[email protected]] >>>>>>>> Sent: Saturday, May 19, 2012 4:23 AM >>>>>>>> To: Peter McCann >>>>>>>> Cc: h chan; [email protected] >>>>>>>> Subject: Re: [DMM] draft requirement REQ-1: Distributed >>> deployment >>>>>>>> >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> On May 18, 2012, at 5:55 PM, Peter McCann wrote: >>>>>>>> >>>>>>>>> Hi, Jouni, >>>>>>>>> >>>>>>>>> jouni korhonen wrote: >>>>>>>>>> Breaking the silence.. >>>>>>>>>> >>>>>>>>>> On May 7, 2012, at 8:55 PM, h chan wrote: >>>>>>>>>> >>>>>>>>>>> REQ-1: Distributed deployment IP mobility, network access and >>>>>>>>>>> routing solutions provided by >>>>>> DMM >>>>>>>>>>> SHALL enable the functions of mobility management of IP >>>>>> sessions >>>>>>>>>>> to >>>>>>>> be >>>>>>>>>>> distributed so that the traffic is routed in an optimal >>>>>>>>>>> manner >>>>>>>> without >>>>>>>>>>> relying on centrally deployed anchors. >>>>>>>>>> >>>>>>>>>> Few comments/questions.. >>>>>>>>>> o "SHALL enable the functions of mobility management" does >>>>>>>>>> that >>>>>>>> imply >>>>>>>>>> the >>>>>>>>>> DMM "solution" must always involve or extend a mobility >>>>>> protocol? >>>>>>>> IMHO >>>>>>>>>> that should not be a SHALL requirement. >>>>>>>>> >>>>>>>>> To the extent that DMM provides an "IP mobility...solution" I >>>>>> think >>>>>>>> it does >>>>>>>>> involve or extend a mobility protocol. However, I don't think >>>>>> the >>>>>>>> requirement >>>>>>>>> implies that we will necessarily extend an existing mobility >>>>>>>> protocol. >>>>>>>> >>>>>>>> Excerpt from the charter: >>>>>>>> >>>>>>>> on managing the use of care-of versus home addresses in an >>>>>>>> efficient manner for different types of communications. >>>>>>>> >>>>>>>> Just making sure the right flavor or address is used does not >>>>>>>> necessarily extend or require any mobility protocol support. >>>>>>>> >>>>>>>>>> o "centrally deployed anchors" what if the access network >>>>>> routing >>>>>>>>>> is laid out in a way that even pure IP routing would lead >>>>>> packets >>>>>>>>>> to go through a central site/edge router? Doesn't that lead >>>>>>>>>> to similar deficiencies than with mobility anchors? >>>>>>>>> >>>>>>>>> It does indeed, which is why a good network deployment will >>>>>>>>> have >>>>>>>> redundant >>>>>>>>> back-up paths throughout the network. Unfortunately, it is >>>>>>>>> difficult >>>>>>>> to >>>>>>>>> provide redundancy when the path involves tunnel state at an >>>>>> anchor >>>>>>>> point. >>>>>>>>> >>>>>>>>>>> REQ-1M (Motivation for REQ-1) The goals of this requirement >>>>>>>>>>> are to match mobility deployment with current trend in >>>>>>>>>>> network evolution: >>>>>>>>>>> more cost and resource effective to cache and distribute >>>>>> contents >>>>>>>> when >>>>>>>>>>> combining distributed anchors with caching systems (e.g., >>>>>>>>>>> CDN); improve scalability; reduce signaling overhead; avoid >>>>>>>>>>> single >>>>>> point >>>>>>>> of >>>>>>>>>>> failure; mitigate threats being focused on a centrally >>>>>>>>>>> deployed anchor, e.g., home agent and local mobility anchor. >>>>>>>>>> >>>>>>>>>> Reduce signaling overhead.. is a very good goal. However, if >>>>>>>>>> any DMM solution builds on top of an existing mobility >>>>>>>>>> protocol that hardly reduces anything. Also if setting up >>>>>>>>>> optimal routes >>>>>> require >>>>>>>>>> establishing new tunnels, signaling is bound to increase. I >>>>>> would >>>>>>>> say >>>>>>>>>> here "does not increase the amount of present signaling" and >>>>>>>>>> the aim for solutions that would reduce it somehow. >>>>>>>>> >>>>>>>>> It should be possible to completely avoid mobility management >>>>>>>> signaling >>>>>>>>> when the MN is stationary or doesn't need a fixed address. I >>>>>> would >>>>>>>> say >>>>>>>>> that reduces signaling. >>>>>>>> >>>>>>>> From that point view ok. Extra care is then needed that one does >>>>>> not >>>>>>>> move the signaling to another layer.. take DSMIP6 (S2c) as an >>>>>> example, >>>>>>>> which avoids BU/BA exchange but then expanded the IKE signaling >>>>>>>> :) >>>>>>>> >>>>>>>>>>> RELEVANT problems: >>>>>>>>>>> PS1: Non-optimal routes >>>>>>>>>>> Routing via a centralized anchor often results in a longer >>>>>> route, >>>>>>>>>>> and the problem is especially manifested when accessing a >>>>>>>>>>> local >>>>>> or >>>>>>>> cache >>>>>>>>>>> server of a Content Delivery Network (CDN). >>>>>>>>>>> PS2: Non-optimality in Evolved Network Architecture The >>>>>>>>>>> centralized mobility management can become non-optimal as >>>>>> Network >>>>>>>>>>> architecture evolves and become more flattened. >>>>>>>>>> >>>>>>>>>> More flat is kind of superfluous.. take e.g. EPS example. You >>>>>> have, >>>>>>>> in >>>>>>>>>> an optimal case, an eNodeB connected directly to a combined >>>>>>> SGW/PGW >>>>>>>>>> from the user plane point of view. And the SGW/PGW you can >>>>>> allocate >>>>>>>>>> close to you eNodeB based on its topological location. How you >>>>>> can >>>>>>>>>> make that more flat? SGW relocation changes the situation a >>>>>>>>>> bit >>>>>> but >>>>>>>> still.. >>>>>>>>> >>>>>>>>> Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a >>>>>>>> maximally >>>>>>>> >>>>>>>> Putting SGW/PGW into eNodeB is not too realistic for a wider are >>>>>>>> deployment. LGWs we already got out there but the mobility in >>>>>>>> that case ain't too great as far as I remember. >>>>>>>> >>>>>>>>> flat architecture. However, we would then need to deal with a >>>>>>>>> change >>>>>>>> of >>>>>>>>> anchor point during the life of a session, which is something >>>>>> that >>>>>>>> wasn't >>>>>>>>> contemplated by 3GPP. That is exactly the area that DMM should >>>>>>>>> focus >>>>>>>> on, >>>>>>>>> IMHO. >>>>>>>> >>>>>>>> With a cost of additional signaling and new tunnel state? >>>>>>>> >>>>>>>>>>> PS3: Low scalability of centralized route and mobility >>>>>>>>>>> context maintenance Setting up such special routes and >>>>>>>>>>> maintaining the mobility context for each MN is more >>>>>>>>>>> difficult to scale in a centralized design with a large number of >MNs. >>>>>>>>>> >>>>>>>>>> Can I assume the mobility context involves a possible per MN >>>>>> tunnel >>>>>>>>>> state? >>>>>>>>> >>>>>>>>> Yes, I think the per-MN tunnel state is part of the mobility >>>>>> context >>>>>>>>> being talked about here. >>>>>>>> >>>>>>>> - Jouni >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -Pete >>>>>>>>> >>>>>>>>>>> Distributing the route maintenance function and the mobility >>>>>>>> context >>>>>>>>>>> maintenance function among different networks can be more >>>>>> scalable. >>>>>>>>>>> PS4: Single point of failure and attack Centralized anchoring >>>>>> may >>>>>>>> be >>>>>>>>>>> more vulnerable to single point of failure and attack than a >>>>>>>>>>> distributed system. >>>>>>>>>>> >>>>>>>>>>> (The above is drafted with contributions, inputs and >>>>>> discussions >>>>>>>>>>> from various people. Additional contributions and comments >>>>>>>>>>> are most >>>>>>>>>>> welcome.) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Jouni >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> H Anthony Chan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dmm mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> dmm mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dmm mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>> _______________________________________________ >>>>>>>> dmm mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>> _______________________________________________ >>>> dmm mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/dmm >> > >_______________________________________________ >dmm mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
