Yes, a 128bits ID or a set of 128bits IDs (at least a pair of IPv6 SA and DA) looks sufficient. 5-tuple usually means transport layer IDs which beyond the IPv6 standard headers but of course it could be a filter condition bound to what a 128bits ID represents. --satoru
> 2017/11/15 21:35、Bertz, Lyle T [CTO] <[email protected]>のメール: > > Am I understanding that the hypothesis is that a 128 bit space (ID) is > sufficient to represent what is required in the packet to meet current and > planned mobility related use cases when coupled with the rest of the IPv6 > standard header information (5-tuple)? > > -----Original Message----- > From: dmm [mailto:[email protected]] On Behalf Of Satoru Matsushima > Sent: Tuesday, November 14, 2017 8:54 PM > To: Charlie Perkins <[email protected]> > Cc: [email protected] > Subject: Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in > 3GPP > > 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 <[email protected]>のメール: >> >> 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 >> [email protected] >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7Clyle.t.bertz%40sprint.com%7C728da357ddeb487c7caf08d52bd4d0ef%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636463115399812002&sdata=KbYQ%2FXFUxLZunyxYZl7wPLt%2FHvlIr8cejIUPWJqPZ%2BQ%3D&reserved=0 > > _______________________________________________ > dmm mailing list > [email protected] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7Clyle.t.bertz%40sprint.com%7C728da357ddeb487c7caf08d52bd4d0ef%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636463115399812002&sdata=KbYQ%2FXFUxLZunyxYZl7wPLt%2FHvlIr8cejIUPWJqPZ%2BQ%3D&reserved=0 > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the sole > use of the recipient(s). Any use by others is prohibited. If you are not the > intended recipient, please contact the sender and delete all copies of the > message. _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
