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
