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