Hi Marco, Your proposal satisfies my concern! I agree with your proposed additional requirement:
"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." Best regards, Georgios > -----Original Message----- > From: Marco Liebsch [mailto:[email protected]] > Sent: dinsdag 5 juni 2012 15:54 > To: Jouni; Karagiannis, G. (EWI) > Cc: [email protected] > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) > > 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
