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! 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
