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