Re: [DMM] Preparing for DMM future steps and rechartering
Hi Pete, This obviously wouldn't work for billions of MNs. But, with DMM people are starting to realize that MNs don't need completely stable global addresses that live forever. Most don't, but some do. We need to account for them as well. So I think DMM should focus on localized mobility management. This is not sufficient. Think of the typical case where MN moves from cellular network of one operator to WiFi network of another operator. This can be a physically localized, but topologically a global handover. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Hi Marco, On 11/15/13 1:56 AM, Marco Liebsch marco.lieb...@neclab.eu wrote: Depends. I assume that the session you describe is a mobility session (binding ID-Locator), not a data session. If the mobility session remains anchored at the previous attachment point, there will be a tunnel towards the new attachment point, which may serve as MAG. Optionally, the new attachment point may provide a new anchor and an additional mobility session, hence an additional HoA, which depend on the MN to handle multiple IPs. Other approach would imply moving the MN's mobility session from the previous anchor/point of attachment to the new one. Then there is at least no tunnel needed to forward packets from the previous anchor to the new one. But the anchored HoA or HNP at the new anchor is topologically incorrect. That means the routing plane above anchors can take care about delivering downlink packets to the MN's current anchor. Agree that that's an impact to the routing policy plane, but a valid approach to achieve more optimal routes. Dated: 01/Aug/2011, reflecting our progress. http://www.ietf.org/mail-archive/web/mext/current/msg04766.html IMO, one can realize DMM by the the ways of a.) Adopting improved Gateway Selection approaches b.) Carrying property meta-data in PIO options and evolving the client. Additionally, aggregating the control plane and distribute the DP is another consideration. With this, one can realize a flat network with optimized data plane. We can get there with incremental extensions to the current protocols. With the approach of allocating short lived sessions, can we not avoid session re-anchoring and avoid impact to data plane ? Will this work ? Without re-anchoring the previous mobility session at the new anchor means the previous anchor remains involved in the packet delivery. I was talking about the case where the previous mobility session will be transferred and anchored at the new mobility anchor. Only that enables short delivery paths, as the anchor points of the MN's IP address is close to the MN. But in that case the routing plane needs to support packet delivery for that MN. So, either by introducing tunnels in the routing plane (e.g. according to LISP), which I'd like to avoid. Or by using per-host routes. Or by using address translation to a routable address, which delivers the packet to the mobile's current anchor. But, if the approach is to allocate short lived sessions, then why deal with re-anchoring issue ? We can completely avoid RIB impact, avoid host route pollution, or exporting modified locator Id to EID mapping. The non-optimized DP lives there for a very short period after a MN migration and for certain sessions and for reasons of global reachability. Regards Sri ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Hi Pete, On 11/15/13 12:13 PM, Peter McCann peter.mcc...@huawei.com wrote: There can be (but does not have to be) a centralized control plane element that has a global view of all the MNs currently attached and keeps track of which MAG they are currently on. From the point of view of DMM, that's just an operational detail of a particular deployment. We certainly should not require the data plane traffic to go through that node, and we should allow for mechanisms other than tunneling to redirect packets to the new MAG after a mobility event. The centralized control plane (if it exists) can be involved in setting up that redirection state, or a distributed routing protocol can take care of it. The goal of shifting / stitching the flows on the forward path that we choose sounds perfectly fine from the view of realizing optimized data plane. But, we still have to show how an operator can manage the subscriber session and enforce the policies. Without such considerations, we cannot meaningfully evaluate the solution, IMHO Regards Sri ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Donnerstag, 14. November 2013 06:22 To: Marco Liebsch; Peter McCann Cc: dmm@ietf.org Subject: Re: Preparing for DMM future steps and rechartering Hi Marco, My intention is not to eliminate a tunnel that exists in any of the tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM primarily distributes topological anchor point for the MN's IP address(es). Forget about the C-plane for now. Tunnels apply solely below (well, towards access) such anchor. If we distribute them to an extreme, they are placed on radio access points and the tunnel disappears. Then we arrive at Pete's model. If anchor points are somewhere above, say in the backhaul, the tunnel remains at least between the anchor and some node in the access (network based mobility mgmnt) or the MN (host based mobility mgmnt). Ok. Distributing topological anchor points at the access edge can be done today without any new standards extensions. This is more about deployment and selection of a gateway at the access edge. But, any time the MN moves and attaches to a different point in the network, that tunnel and the CP is expected to be there between the previous home-anchor and the current access-anchor. But, here, the proposals hide the tunnel (at the initial attachment point and what can be argued as a home link and which is fine), but when the MN moves the session is re-anchored to a different gateway with a churn in the routing infrastructure and with major impact to policy plane. So, there is no tunnel and there is no CP in this model. Depends. I assume that the session you describe is a mobility session (binding ID-Locator), not a data session. If the mobility session remains anchored at the previous attachment point, there will be a tunnel towards the new attachment point, which may serve as MAG. Optionally, the new attachment point may provide a new anchor and an additional mobility session, hence an additional HoA, which depend on the MN to handle multiple IPs. Other approach would imply moving the MN's mobility session from the previous anchor/point of attachment to the new one. Then there is at least no tunnel needed to forward packets from the previous anchor to the new one. But the anchored HoA or HNP at the new anchor is topologically incorrect. That means the routing plane above anchors can take care about delivering downlink packets to the MN's current anchor. Agree that that's an impact to the routing policy plane, but a valid approach to achieve more optimal routes. I think none of the proposals wants to discuss away the tunnels as per MIP/PMIP. But above anchor level, regular routing applies to plain data packets of the U-Plane. A key component for DMM, IMO, is how to accomplish that routing towards the MN's current anchor point, even if the anchored IP address is topologically incorrect. To accomplish this, my intent is to not introduce tunnels above anchor level. So, it's not about eliminating tunnels, but it is about not introducing tunnels where never have been tunnels before :-) :) If you can show this working without re-anchoring the session to a different gateway, then I will agree. You see this from the point of view of IP routing, but I'm looking for that subscriber session which I'm not able to find. Without re-anchoring the previous mobility session at the new anchor means the previous anchor remains involved in the packet delivery. I was talking about the case where the previous mobility session will be transferred and anchored at the new mobility anchor. Only that enables short delivery paths, as the anchor points of the MN's IP address is close to the MN. But in that case the routing plane needs to support packet delivery for that MN. So, either by introducing tunnels in the routing plane (e.g. according to LISP), which I'd like to avoid. Or by using per-host routes. Or by using address translation to a routable address, which delivers the packet to the mobile's current anchor. Tunnels hide the topology and make that reachability work; it gives me a stable anchor point that my operator can manage my session. Sure, anchors as well as tunnels from that anchor to a locator should be kept. After anchor relocation, the new anchor takes care about tunnel management to deliver packets to the current MN's location. However, the routing plane above anchor level may take care about delivering packets to the current anchor, which is a prerequisite to allow the new anchor doing his job. Greetings, marco Regards Sri ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Hi Pete, My definition of CP is between the AG and the MA, what is out there today. Now, if there is a functional split of CP and DP on any entity, and if there is a interface between those two in the form of some CP interface, then I don't have a term for that interface. We can probably agree that CP/DP split approaches are outside the scope of this discussions. I can still have an SDN-style network with a separate controller making policy decisions. Ok. I understand now. Only the DP is moved, but the session CP state is anchored on a central node ? I call that central node as a mobility anchor, now if that anchor is in the data path or not is one consideration. But, functionally, there is still a mobility anchor. Regards Sri On 11/14/13 5:19 AM, Peter McCann peter.mcc...@huawei.com wrote: Hi, Marco, Sri, I think that Marco's analysis works, in the sense that it places both classes of solutions within a cohesive framework. I am more doubtful, however, that the two kinds of solutions would co-exist in the same access network, as they both seem to implement a kind of local mobility management. Yes, Sri, I think this is a re-anchoring if we define the anchor as the point to which IP packets are delivered by the routing infrastructure. I don't see why you say there is no control plane; I can still have an SDN-style network with a separate controller making policy decisions. It is true that there is no single router that handles the user's traffic for the life of the IP session, but I thought the point of DMM was to get rid of such scalability and fault bottlenecks. I am a little confused as to what is your definition of a control plane. It seems you apply this term to the LMA, but in today's specs the LMA is a combined CP/DP entity. -Pete Sri Gundavelli (sgundave) wrote: Hi Marco, My intention is not to eliminate a tunnel that exists in any of the tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM primarily distributes topological anchor point for the MN's IP address(es). Forget about the C-plane for now. Tunnels apply solely below (well, towards access) such anchor. If we distribute them to an extreme, they are placed on radio access points and the tunnel disappears. Then we arrive at Pete's model. If anchor points are somewhere above, say in the backhaul, the tunnel remains at least between the anchor and some node in the access (network based mobility mgmnt) or the MN (host based mobility mgmnt). Ok. Distributing topological anchor points at the access edge can be done today without any new standards extensions. This is more about deployment and selection of a gateway at the access edge. But, any time the MN moves and attaches to a different point in the network, that tunnel and the CP is expected to be there between the previous home- anchor and the current access-anchor. But, here, the proposals hide the tunnel (at the initial attachment point and what can be argued as a home link and which is fine), but when the MN moves the session is re- anchored to a different gateway with a churn in the routing infrastructure and with major impact to policy plane. So, there is no tunnel and there is no CP in this model. I think none of the proposals wants to discuss away the tunnels as per MIP/PMIP. But above anchor level, regular routing applies to plain data packets of the U-Plane. A key component for DMM, IMO, is how to accomplish that routing towards the MN's current anchor point, even if the anchored IP address is topologically incorrect. To accomplish this, my intent is to not introduce tunnels above anchor level. So, it's not about eliminating tunnels, but it is about not introducing tunnels where never have been tunnels before :-) :) If you can show this working without re-anchoring the session to a different gateway, then I will agree. You see this from the point of view of IP routing, but I'm looking for that subscriber session which I'm not able to find. Tunnels hide the topology and make that reachability work; it gives me a stable anchor point that my operator can manage my session. Regards Sri ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Please see inline, Carlos. -Original Message- From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] Sent: Mittwoch, 13. November 2013 12:48 To: Marco Liebsch Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org Subject: Re: [DMM] Preparing for DMM future steps and rechartering Hi Marco, On Wed, 2013-11-13 at 11:23 +, Marco Liebsch wrote: Carlos, just to clarify my view here: I do not see them as different approaches, but in a way that the routing approach can complement mobility anchor-based approaches (MIP-like protocols). And such routing support is needed only in certain deployments, i.e. in case of a runtime change of the MN's anchor while the new anchor imports the MN's IP address (binding) context to enable IP address continuity. To enable routing the MN's downlink data to its current anchor in the transport network above anchor level, e.g. host routes can be used. I'm not sure I agree on this. To me this seem to already assume a certain solution. And I'm biased because I also have some solutions in mind :D Not a solution, but a deployment model. The solution would dig into the protocol bits of a selected protocol e.g. BGP to solve that. That's not what I am writing about. I write this only to abstract the available solutions to deployment models and see where the DMM group can do some work to enable a variety of them. For example, I think we should not limit only to downlink, unless the ingress filtering is not considered an issue (if it is not, this also kind-of assumes a certain type of solution). For sure not. I refrained from describing the complete sequence, as it's not relevant for this discussion. Just trying to draw some models and see which gaps DMM can close. We end up in a routing-only approach if these anchors will be distributed to an extreme and placed e.g. on radio access points and the approach uses something else than MIP protocols to transfer IP address context between these access points. Then we have Pete's DMM deployment model. Agree, but a routing approach could also be applied even if the anchors are not placed on the radio access points. That's why I see routing as an alternative solution to IP mobility protocols. Sure. But I am not sure that it should be the DMM group that builds a new alternative to IP mobility. What's the gap analysis then about? Interesting to research about, though. Do you agree to that view? I think there is common understanding that DMM is a lot about deployment. Any of those deployment models are valid. Whereas the DMM WG cannot work on all extensions needed to enable all models, we should converge on a reasonable set of first work items to allow operators to enable DMM in their network. I agree. It would be helpful to get some feedback from operators on which deployments they have more interest on. Good. Thanks, marco Thanks, Carlos marco -Original Message- From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] Sent: Mittwoch, 13. November 2013 11:51 To: Marco Liebsch Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org Subject: Re: [DMM] Preparing for DMM future steps and rechartering Hi, I'm also jumping into the discussion a bit late. Without going into all the detailed discussions that have taken place recently, I just want to share my view on the MIP-based vs routing-based approach. IMHO, we probably need to further look at both approaches in this group, but with enough energy level (otherwise we risk to end up with nothing after several years). I personally have my doubts that a distributed routing-based approach scales in a moderately large domain (we also saw many years ago proposals of doing mobility with routing that did not take off because of convergence, scalability and administrative issues). I think a MIP-based approach (network or host based) would work, though it would imply keeping multiple anchors active for a given MN. We believe this routing-based vs MIP-based comparison is quite interesting, and we are actually working at UC3M on experimentally evaluating both, so we can make a more educated statement on pros and cons of each of them. My two cents, Carlos On Wed, 2013-11-13 at 10:10 +, Marco Liebsch wrote: Hi Sri, all, let me step in here (with some delay..) to clarify one point you raised. Please see inline. -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Montag, 11. November 2013 16:30 To: Peter McCann Cc: dmm@ietf.org Subject: Re: [DMM] Preparing for DMM future steps and rechartering Hi Pete, I'm not sure, I agree with this, or understand this to be precise. I do not know know CP (in the form of PMIP, GTP or some other protocol XYZ) can be completely eliminated. There needs to be some interface between the access gateway and the mobility anchor. I assumed your's, Marco's
Re: [DMM] Preparing for DMM future steps and rechartering
Hi Pete, Speaking with no hat on... On 11/12/13 4:29 PM, Peter McCann wrote: Hi, Sri, Even if we agree that those services are necessary (and I would point out once again that most of them are not beneficial to the end-user) I don't think we should be architecting the network in such a way that we lose the basic benefits of IP (shortest path routing and fault-tolerance). We can implement those services without taking all the packets to a central location; maybe just the first packet or meta-information about the first packet can be taken to an SDN controller that can make some decision and pass it down to the user plane. I really don't think this is such fantastic science-fiction. ;) The degree to which this is science fiction really depends on what scope you think these host routes will have in the routing system. * Are you assuming mobility within a single enterprise or Autonomous System? * Limited mobility within a consortium of networks? * Is this global mobility for any/all nodes? Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Hi, Brian, Brian Haberman wrote: Hi Pete, Speaking with no hat on... On 11/12/13 4:29 PM, Peter McCann wrote: Hi, Sri, Even if we agree that those services are necessary (and I would point out once again that most of them are not beneficial to the end-user) I don't think we should be architecting the network in such a way that we lose the basic benefits of IP (shortest path routing and fault-tolerance). We can implement those services without taking all the packets to a central location; maybe just the first packet or meta-information about the first packet can be taken to an SDN controller that can make some decision and pass it down to the user plane. I really don't think this is such fantastic science-fiction. ;) The degree to which this is science fiction really depends on what scope you think these host routes will have in the routing system. * Are you assuming mobility within a single enterprise or Autonomous System? Yes, at the most this will be one AS. * Limited mobility within a consortium of networks? No. At the most this will be one AS, possibly less depending on scalability. * Is this global mobility for any/all nodes? No. I think global mobility should be handled with client MIP because we should not assume any relationship between previous/next visited networks. The Boeing experiment (not science fiction, but also not scalable) tried global mobility with BGP: Dul, A., Global IP Network Mobility using Border Gateway Protocol (BGP), Available at: http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf This obviously wouldn't work for billions of MNs. But, with DMM people are starting to realize that MNs don't need completely stable global addresses that live forever. So I think DMM should focus on localized mobility management. Regards, Brian -Pete ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Le 13/11/2013 16:39, Peter McCann a écrit : Hi, Brian, Brian Haberman wrote: Hi Pete, Speaking with no hat on... On 11/12/13 4:29 PM, Peter McCann wrote: Hi, Sri, Even if we agree that those services are necessary (and I would point out once again that most of them are not beneficial to the end-user) I don't think we should be architecting the network in such a way that we lose the basic benefits of IP (shortest path routing and fault-tolerance). We can implement those services without taking all the packets to a central location; maybe just the first packet or meta-information about the first packet can be taken to an SDN controller that can make some decision and pass it down to the user plane. I really don't think this is such fantastic science-fiction. ;) The degree to which this is science fiction really depends on what scope you think these host routes will have in the routing system. * Are you assuming mobility within a single enterprise or Autonomous System? Yes, at the most this will be one AS. I agree. In search of a qualifying metric the number of ASes is very good. If need to go in further detail (sci-fi?) one may also consider metrics such as the level of aggregation of prefixes in the addressing architecture, and the IP distance between two Access Routers (not the geographical distance). I assume with fully hierarchical addressing, and small IP distance between ARs may lead to acceptance of route updates on that scale. (in the Connexion by Boeing test case the IP distance between ARs is known to be very low although spanning wide geographical areas - no route churn). Alex * Limited mobility within a consortium of networks? No. At the most this will be one AS, possibly less depending on scalability. * Is this global mobility for any/all nodes? No. I think global mobility should be handled with client MIP because we should not assume any relationship between previous/next visited networks. The Boeing experiment (not science fiction, but also not scalable) tried global mobility with BGP: Dul, A., Global IP Network Mobility using Border Gateway Protocol (BGP), Available at: http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf This obviously wouldn't work for billions of MNs. But, with DMM people are starting to realize that MNs don't need completely stable global addresses that live forever. So I think DMM should focus on localized mobility management. Regards, Brian -Pete ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Rather than sink into a re-chartering discussion, I would like the WG to focus on completing the existing work items. It was suggested that an interim (or 2) get set up to work on these items. Please focus on this rather than re-chartering. Regards, Your friendly AD On 11/13/13 3:43 PM, Behcet Sarikaya wrote: As for the next steps, my suggestion is that Jouni posts a draft charter based on the slide he showed in Vancouver where different pieces of a dmm solution was listed. We can have email discussions based on that proposal and hopefully come to a consensus in a reasonable amount of time. However, Jouni did not post his slides in the proceedings, I checked all the presentations and the chair's slides are not there. So maybe the first step should be that Jouni posts his slides so we can have a look. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Hi Brian, I personally think that Interim(s) would not work for dmm. Only a few people could go to such meetings. Most of us already have a heavy travel schedule, squeezing another trip seems not so reasonable. Regards, Behcet On Wed, Nov 13, 2013 at 2:53 PM, Brian Haberman br...@innovationslab.netwrote: Rather than sink into a re-chartering discussion, I would like the WG to focus on completing the existing work items. It was suggested that an interim (or 2) get set up to work on these items. Please focus on this rather than re-chartering. Regards, Your friendly AD On 11/13/13 3:43 PM, Behcet Sarikaya wrote: As for the next steps, my suggestion is that Jouni posts a draft charter based on the slide he showed in Vancouver where different pieces of a dmm solution was listed. We can have email discussions based on that proposal and hopefully come to a consensus in a reasonable amount of time. However, Jouni did not post his slides in the proceedings, I checked all the presentations and the chair's slides are not there. So maybe the first step should be that Jouni posts his slides so we can have a look. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
I never said they had to be face-to-face meetings. It is completely acceptable to hold virtual (on-line) meetings. Regards, Brian On 11/13/13 4:01 PM, Behcet Sarikaya wrote: Hi Brian, I personally think that Interim(s) would not work for dmm. Only a few people could go to such meetings. Most of us already have a heavy travel schedule, squeezing another trip seems not so reasonable. Regards, Behcet On Wed, Nov 13, 2013 at 2:53 PM, Brian Haberman br...@innovationslab.netwrote: Rather than sink into a re-chartering discussion, I would like the WG to focus on completing the existing work items. It was suggested that an interim (or 2) get set up to work on these items. Please focus on this rather than re-chartering. Regards, Your friendly AD On 11/13/13 3:43 PM, Behcet Sarikaya wrote: As for the next steps, my suggestion is that Jouni posts a draft charter based on the slide he showed in Vancouver where different pieces of a dmm solution was listed. We can have email discussions based on that proposal and hopefully come to a consensus in a reasonable amount of time. However, Jouni did not post his slides in the proceedings, I checked all the presentations and the chair's slides are not there. So maybe the first step should be that Jouni posts his slides so we can have a look. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Hi Marco, Thanks for the discussion. Please see inline below. On Wed, 2013-11-13 at 11:59 +, Marco Liebsch wrote: Please see inline, Carlos. -Original Message- From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] Sent: Mittwoch, 13. November 2013 12:48 To: Marco Liebsch Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org Subject: Re: [DMM] Preparing for DMM future steps and rechartering Hi Marco, On Wed, 2013-11-13 at 11:23 +, Marco Liebsch wrote: Carlos, just to clarify my view here: I do not see them as different approaches, but in a way that the routing approach can complement mobility anchor-based approaches (MIP-like protocols). And such routing support is needed only in certain deployments, i.e. in case of a runtime change of the MN's anchor while the new anchor imports the MN's IP address (binding) context to enable IP address continuity. To enable routing the MN's downlink data to its current anchor in the transport network above anchor level, e.g. host routes can be used. I'm not sure I agree on this. To me this seem to already assume a certain solution. And I'm biased because I also have some solutions in mind :D Not a solution, but a deployment model. The solution would dig into the protocol bits of a selected protocol e.g. BGP to solve that. That's not what I am writing about. I write this only to abstract the available solutions to deployment models and see where the DMM group can do some work to enable a variety of them. Well, I'm not sure about that. To me, keeping always a single anchor by effectively moving the it using a routing approach is a different solution that using multiple distributed anchors, and keeping old ones while there active communications ongoing (and using more optimal ones for new communications). For example, I think we should not limit only to downlink, unless the ingress filtering is not considered an issue (if it is not, this also kind-of assumes a certain type of solution). For sure not. I refrained from describing the complete sequence, as it's not relevant for this discussion. Just trying to draw some models and see which gaps DMM can close. OK. We end up in a routing-only approach if these anchors will be distributed to an extreme and placed e.g. on radio access points and the approach uses something else than MIP protocols to transfer IP address context between these access points. Then we have Pete's DMM deployment model. Agree, but a routing approach could also be applied even if the anchors are not placed on the radio access points. That's why I see routing as an alternative solution to IP mobility protocols. Sure. But I am not sure that it should be the DMM group that builds a new alternative to IP mobility. What's the gap analysis then about? Interesting to research about, though. Agree. Do you agree to that view? I think there is common understanding that DMM is a lot about deployment. Any of those deployment models are valid. Whereas the DMM WG cannot work on all extensions needed to enable all models, we should converge on a reasonable set of first work items to allow operators to enable DMM in their network. I agree. It would be helpful to get some feedback from operators on which deployments they have more interest on. Thanks, Carlos Good. Thanks, marco Thanks, Carlos marco -Original Message- From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] Sent: Mittwoch, 13. November 2013 11:51 To: Marco Liebsch Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org Subject: Re: [DMM] Preparing for DMM future steps and rechartering Hi, I'm also jumping into the discussion a bit late. Without going into all the detailed discussions that have taken place recently, I just want to share my view on the MIP-based vs routing-based approach. IMHO, we probably need to further look at both approaches in this group, but with enough energy level (otherwise we risk to end up with nothing after several years). I personally have my doubts that a distributed routing-based approach scales in a moderately large domain (we also saw many years ago proposals of doing mobility with routing that did not take off because of convergence, scalability and administrative issues). I think a MIP-based approach (network or host based) would work, though it would imply keeping multiple anchors active for a given MN. We believe this routing-based vs MIP-based comparison is quite interesting, and we are actually working at UC3M on experimentally evaluating both, so we can make a more educated statement on pros and cons of each of them. My two cents, Carlos On Wed, 2013-11-13 at 10:10 +, Marco Liebsch wrote: Hi Sri, all, let me step in here (with some delay..) to clarify one point you raised. Please see inline
Re: [DMM] Preparing for DMM future steps and rechartering
Hi Marco, My intention is not to eliminate a tunnel that exists in any of the tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM primarily distributes topological anchor point for the MN's IP address(es). Forget about the C-plane for now. Tunnels apply solely below (well, towards access) such anchor. If we distribute them to an extreme, they are placed on radio access points and the tunnel disappears. Then we arrive at Pete's model. If anchor points are somewhere above, say in the backhaul, the tunnel remains at least between the anchor and some node in the access (network based mobility mgmnt) or the MN (host based mobility mgmnt). Ok. Distributing topological anchor points at the access edge can be done today without any new standards extensions. This is more about deployment and selection of a gateway at the access edge. But, any time the MN moves and attaches to a different point in the network, that tunnel and the CP is expected to be there between the previous home-anchor and the current access-anchor. But, here, the proposals hide the tunnel (at the initial attachment point and what can be argued as a home link and which is fine), but when the MN moves the session is re-anchored to a different gateway with a churn in the routing infrastructure and with major impact to policy plane. So, there is no tunnel and there is no CP in this model. I think none of the proposals wants to discuss away the tunnels as per MIP/PMIP. But above anchor level, regular routing applies to plain data packets of the U-Plane. A key component for DMM, IMO, is how to accomplish that routing towards the MN's current anchor point, even if the anchored IP address is topologically incorrect. To accomplish this, my intent is to not introduce tunnels above anchor level. So, it's not about eliminating tunnels, but it is about not introducing tunnels where never have been tunnels before :-) :) If you can show this working without re-anchoring the session to a different gateway, then I will agree. You see this from the point of view of IP routing, but I'm looking for that subscriber session which I'm not able to find. Tunnels hide the topology and make that reachability work; it gives me a stable anchor point that my operator can manage my session. Regards Sri ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Le 11/11/2013 16:29, Sri Gundavelli (sgundave) a écrit :
Hi Pete,
I'm not sure, I agree with this, or understand this to be precise. I
do not know know CP (in the form of PMIP, GTP or some other protocol
XYZ) can be completely eliminated. There needs to be some interface
between the access gateway and the mobility anchor. I assumed
your's, Marco's and Ryuji's goal is for eliminating the tunnel,
which I don't believe it can be achieved, but still thought we can
discuss this. IMO, its not just about inserting a RIB route and
redistributing it, but even there in DP there is a state transfer
needed from the CP and the DP. Starting point appears like a simple
route propagation, very soon it will end up with a bunch of state
that gets moved between the two nodes. But, may be I don't
understand the ideas clearly on eliminating CP and eliminating
tunnels. I'm not going to oppose this, I don't see this converging,
IMHO.
I think it may converge.
I am not sure whether we have reached a point where we can discuss
without assuming a particular protocol (i.e. neither MIP, nor BGP), but
I think we can discuss route update method vs tunnel-based method.
We can also discuss whether new functionality is needed on the mobile
entity, vs whether the first-hop router does much on its behalf
('proxy'). Which may bring in a question of whether a Mobile Host or a
Mobile Router is considered.
Effects of route updates may be too heavy on a network ('route churn')
or less so; it may depend, among several factors, on the topology and
the addressing architecture of the fixed network.
Routing protocols are highly distributed concepts, yet many include
particularly designated entities, which have particular roles (not all
routers are equal) - these could host what we expect to be more
controlling points.
Alex
Regards Sri
On 11/10/13 3:13 PM, Peter McCann peter.mcc...@huawei.com wrote:
Hi, Sri,
I think you will agree that PMIP is a control protocol for setting
up tunnels. A tunnel implies that we are not using the
destination IP of the inner packet for routing and by definition
will lead to a non-optimal route and a bit of state on some box
that can fail and lose that state.
I hope that DMM can consider other approaches such as injecting
routes from the latest L2-attachment point into the access network,
which is a truly Distributed Mobility Management protocol for
getting the packets to the mobile node. It will lead to more
optimal routes and more robust fault-tolerant operation of the
network.
I think we can continue to use the term MAG to apply to that
first-hop router which is hopefully co-located with the L2
termination point (it may not be so in every technology depending
on the extent to which that technology has evolved to support truly
Distributed operation). Anything that happens below the MAG
(between the MAG and the L2 termination point) should be out of
scope and we should not define any protocol there and we should
discourage any separation between the two.
However, we should not require the MAG to run any form of PMIP
because tunnels should not be required in the architecture. We
should not require an LMA, because this would imply a central point
of state maintenance and possibility of failure.
It is fine to consider a split between CP and DP but I thought we
had agreed that any discussion of the protocol to use on such an
interface would be out of scope for this WG. IMHO we should leave
that to the Wireless Mobile Working Group of ONF.
Now, the proponents of OpenFlow and other CP/DP splits have argued
that it is better to centralize the algorithms such as routing
protocols on a logically centralized server or servers with a
synchronized global view of the network. I have no problem with
that, in which case this centralized controller just needs to get
notified about the MN's current attachment point, so it can
install the routes (or tunnels, if an operator wishes to use them)
into the DP. But, the mechanisms for doing so are out of scope for
the DMM WG because we are not working on a CP/DP split. I think it
would be appropriate for the DMM WG (which exists in the IETF, a
standards body that has a long history of developing distributed
and fault-tolerant routing protocols) to describe a more
distributed alternative, building on foundational Internet
technologies such as I-BGP, in such a way that will bring down the
costs, reduce the latency, and increase the robustness of wireless
access networks.
I actually don't think we need to define any new extensions or IEs
for BGP; I would like to read more about Ryuji's proposed
extensions here. All we need is for the MAG to learn what IPs have
been assigned to the MN, decide which of those IPs are in the scope
of the local AS, and inject routes for those prefixes to itself. We
could work on alternative mechanisms for discovering this list of
addresses - the fundamental requirement is that we use an
authenticated MN ID (probably an
Re: [DMM] Preparing for DMM future steps and rechartering
Alex - So, the proposal is to get rid of the MIP signaling plane and
piggyback on some routing updates, or over OpenFlow ? So, what is the
result, we use a generic non-MIP interfaces and make them look like MIP
interfaces ? What is the point ? This is DMM ?
Regards
Sri
On 11/11/13 7:51 AM, Alexandru Petrescu alexandru.petre...@gmail.com
wrote:
I think it may converge.
I am not sure whether we have reached a point where we can discuss
without assuming a particular protocol (i.e. neither MIP, nor BGP), but
I think we can discuss route update method vs tunnel-based method.
We can also discuss whether new functionality is needed on the mobile
entity, vs whether the first-hop router does much on its behalf
('proxy'). Which may bring in a question of whether a Mobile Host or a
Mobile Router is considered.
Effects of route updates may be too heavy on a network ('route churn')
or less so; it may depend, among several factors, on the topology and
the addressing architecture of the fixed network.
Routing protocols are highly distributed concepts, yet many include
particularly designated entities, which have particular roles (not all
routers are equal) - these could host what we expect to be more
controlling points.
Alex
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
I think we need a draft from Pete on this so we can all understand what is being proposed. Regards, Behcet On Mon, Nov 11, 2013 at 9:29 AM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Hi Pete, I'm not sure, I agree with this, or understand this to be precise. I do not know know CP (in the form of PMIP, GTP or some other protocol XYZ) can be completely eliminated. There needs to be some interface between the access gateway and the mobility anchor. I assumed your's, Marco's and Ryuji's goal is for eliminating the tunnel, which I don't believe it can be achieved, but still thought we can discuss this. IMO, its not just about inserting a RIB route and redistributing it, but even there in DP there is a state transfer needed from the CP and the DP. Starting point appears like a simple route propagation, very soon it will end up with a bunch of state that gets moved between the two nodes. But, may be I don't understand the ideas clearly on eliminating CP and eliminating tunnels. I'm not going to oppose this, I don't see this converging, IMHO. Regards Sri On 11/10/13 3:13 PM, Peter McCann peter.mcc...@huawei.com wrote: Hi, Sri, I think you will agree that PMIP is a control protocol for setting up tunnels. A tunnel implies that we are not using the destination IP of the inner packet for routing and by definition will lead to a non-optimal route and a bit of state on some box that can fail and lose that state. I hope that DMM can consider other approaches such as injecting routes from the latest L2-attachment point into the access network, which is a truly Distributed Mobility Management protocol for getting the packets to the mobile node. It will lead to more optimal routes and more robust fault-tolerant operation of the network. I think we can continue to use the term MAG to apply to that first-hop router which is hopefully co-located with the L2 termination point (it may not be so in every technology depending on the extent to which that technology has evolved to support truly Distributed operation). Anything that happens below the MAG (between the MAG and the L2 termination point) should be out of scope and we should not define any protocol there and we should discourage any separation between the two. However, we should not require the MAG to run any form of PMIP because tunnels should not be required in the architecture. We should not require an LMA, because this would imply a central point of state maintenance and possibility of failure. It is fine to consider a split between CP and DP but I thought we had agreed that any discussion of the protocol to use on such an interface would be out of scope for this WG. IMHO we should leave that to the Wireless Mobile Working Group of ONF. Now, the proponents of OpenFlow and other CP/DP splits have argued that it is better to centralize the algorithms such as routing protocols on a logically centralized server or servers with a synchronized global view of the network. I have no problem with that, in which case this centralized controller just needs to get notified about the MN's current attachment point, so it can install the routes (or tunnels, if an operator wishes to use them) into the DP. But, the mechanisms for doing so are out of scope for the DMM WG because we are not working on a CP/DP split. I think it would be appropriate for the DMM WG (which exists in the IETF, a standards body that has a long history of developing distributed and fault-tolerant routing protocols) to describe a more distributed alternative, building on foundational Internet technologies such as I-BGP, in such a way that will bring down the costs, reduce the latency, and increase the robustness of wireless access networks. I actually don't think we need to define any new extensions or IEs for BGP; I would like to read more about Ryuji's proposed extensions here. All we need is for the MAG to learn what IPs have been assigned to the MN, decide which of those IPs are in the scope of the local AS, and inject routes for those prefixes to itself. We could work on alternative mechanisms for discovering this list of addresses - the fundamental requirement is that we use an authenticated MN ID (probably an NAI) as an index to lookup the set of IPs in a distributed database. I've proposed using DNS for this but there are other alternatives. We also need a way to make sure the latest UPDATE gets used by all the BGP peers. I've proposed putting a timestamp in LOCAL_PREF but there are probably other alternatives. It would also be nice to have a well-defined fall-back mechanism in case the MN moves to a different AS or just too far from the original MAG, in which case the I-BGP approach wouldn't scale. For these cases, I think a client MIP tunnel to an HA located in the original AS for each assigned IP address would be ideal. The HA can behave just like
Re: [DMM] Preparing for DMM future steps and rechartering
Hi, Alex,
When it comes to injecting routes into the routing infrastructure,
I think we have to use the proxy model. It doesn't make sense for
the MN to be speaking to the access network's routing protocol. This
means the MAG will need to authenticate the MN and check that the
IP addresses assigned to that MN ID were in fact really assigned to
that MN. I think it can be done easily with forward/reverse DNS
lookups.
Sri, if we can make the tunnels a fall-back mechanism for use only
when the MN has moved too far to make the routing update scalable,
then yes, we can eliminate the PMIP signaling from the access network.
I think client MIP should be used when we need to fall back - especially
because there is likely to be no relationship between the previous and
new domains, other than the fact that they are both connected to the
Internet.
-Pete
Alexandru Petrescu wrote:
Sri,
Sorry if my mail was too direct. It is not my intention to suggest
getting rid of anything.
Frankly speaking I don't know what DMM is, and I still have to review
the draft-ietf-dmm-best-practices-gap-analysis-02
Whenever one says one particular protocol I have a problem with each.
For example, but just an example, I have growing problems articulating
an explanation of the lack of MIP deployment.
Deployment, testing and prototype interest are valuable indicators.
Alex
Le 11/11/2013 17:08, Sri Gundavelli (sgundave) a écrit :
Alex - So, the proposal is to get rid of the MIP signaling plane and
piggyback on some routing updates, or over OpenFlow ? So, what is
the result, we use a generic non-MIP interfaces and make them look
like MIP interfaces ? What is the point ? This is DMM ?
Regards Sri
On 11/11/13 7:51 AM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
I think it may converge.
I am not sure whether we have reached a point where we can discuss
without assuming a particular protocol (i.e. neither MIP, nor BGP),
but I think we can discuss route update method vs tunnel-based
method.
We can also discuss whether new functionality is needed on the mobile
entity, vs whether the first-hop router does much on its behalf
('proxy'). Which may bring in a question of whether a Mobile Host or
a Mobile Router is considered.
Effects of route updates may be too heavy on a network ('route
churn') or less so; it may depend, among several factors, on the
topology and the addressing architecture of the fixed network.
Routing protocols are highly distributed concepts, yet many include
particularly designated entities, which have particular roles (not
all routers are equal) - these could host what we expect to be more
controlling points.
Alex
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
