Hell Charlie, First, of course it’s ok to forward and thank you for sharing it for DMM list.
Yes, I think that many operators have met various requirements for networks which are supporting mobile user-plane nowadays. My understanding is that mobility management itself is a bit complicated system so that it is important that keep it simple as much as possible in terms of mobility management. So other features should be isolated or modulated as an independent pluggable feature into the system. I can see that concept in current cellular mobile systems and also in the Rel-15 control-plane SBA which indicates that concept more explicitly IMO. But when we see the user-plane, modulated concept that features in addition to mobility management have decoupled horizontally to deploy in where like Gi-LAN, and vertically decoupled in underlying layers, like VPWS/VPLS on top of pseudo-wires and MPLS TE(TP)-LSPs. You can see them in the E-Line/E-LAN spec in MEF to provide backhaul connectivity services for MNOs. So, the outcome in the user-plane has been well complicated as you find in the picture. I’ve learned that even the control-plane protocols and functions are modulated to keep mobility management simple, almost those actual services are implemented in the data-plane network(s). Otherwise, those are useless. IMO to simplify whole data-plane while mobility management still be simple (ironic?), mobile user-plane need to be capable to integrate rest of data-plane roles into it. # I use the term ‘data-plane’ here in more generic while ‘user-plane’ means mobility tunnel specifically. Actually there's rest of the story of that picture. If we have plenty ID space in one single data-plane layer to represent all required feature including mobility, there’s no need to employ additional layers and horizontally decoupling. This is my background thought for the SRv6 mobile user-plane I-D. SRv6 is able to represent network functions as an 128bits ID or a set of IDs. So it enable us to simplify the data-plane by integrating all required functions into one IPv6 layer. IMO What specific functions are required is not argument here, what integration mechanism we really need for our solution would be a trigger we embark. Of course I believe that it is SRv6. Cheers, --satoru > 2017/11/15 8:43、Charlie Perkins <charles.perk...@earthlink.net>のメール: > > Hello folks, > > I stumbled across this terrific diagram from email that was sent by > Satoru-san yesterday. I think it's an indication that current operators are > not really asking for a simplified data plane. Or, at least, that we really > need to understand under what conditions they would accept an IETF-designed > simplified data plane before embarking on a solution for their needs. > Regards, > Charlie P. > PS. I hope it is O.K. to forward this email... > > ====================================================================== > > Alex, > > .... > Please take a look at the attached picture which one of the realities > happened in some operator. > > Cheers, > --satoru > <PastedGraphic-5.png> > > > <Attached Message Part.txt>_______________________________________________ > 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
