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