Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in 3GPP
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] のメール: > > 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:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima > Sent: Tuesday, November 14, 2017 8:54 PM > To: Charlie Perkins > Cc: dmm@ietf.org > 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 のメール: >> >> 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 >> >> >> >> ___ >> dmm mailing list >> dmm@ietf.org >> 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 > dmm@ietf.org > https://na01.safelinks.pr
Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in 3GPP
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:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima Sent: Tuesday, November 14, 2017 8:54 PM To: Charlie Perkins Cc: dmm@ietf.org 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 のメール: > > 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 > > > > ___ > dmm mailing list > dmm@ietf.org > 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 dmm@ietf.org 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 dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in 3GPP
Sri, As I wrote to Marco Thursday afternoon III clashes with 5G IP meeting. Please do not use that slot :) Regards, Behcet On Wed, Nov 15, 2017 at 10:56 AM, Sri Gundavelli (sgundave) < sgund...@cisco.com> wrote: > Thats a great idea. Lets find a slot to discuss with Charlie and > understand the comments. > > Any one interested in attending, send me a unicast note. > > Sent from my iPhone > > On Nov 15, 2017, at 10:52 AM, Marco Liebsch > wrote: > > Can we quickly set up an ad-hoc site meeting here at IETF100? > > E.g. Thursday Afternoon III or later would be possible for me. > > Would be an opportunity to follow-up f2f and further elaborate on that. > > > > marco > > > > > > > > > > > > *From:* dmm [mailto:dmm-boun...@ietf.org ] *On > Behalf Of *Sri Gundavelli (sgundave) > *Sent:* Mittwoch, 15. November 2017 03:42 > *To:* vojislav vucetic > *Cc:* Charlie Perkins; dmm@ietf.org > *Subject:* Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work > in 3GPP > > > > Like I said, concern is valid. The deliverable about that study. If it > turns out there is no significant optimizations that operators can convince > operators, then we will drop the work. > > > > > > Sri > > > > *From: *vojislav vucetic > *Date: *Tuesday, November 14, 2017 at 6:35 PM > *To: *Sri Gundavelli > *Cc: *Charlie Perkins , "dmm@ietf.org" < > dmm@ietf.org> > *Subject: *Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work > in 3GPP > > > > He put you on the spot👹 > > Sent from my iPhone > > > On Nov 14, 2017, at 7:13 PM, Sri Gundavelli (sgundave) > wrote: > > Hi Charlie, > > > > Fair point! As part of these efforts, we need to understand and quantify > those optimizations. For not all work items, we need blessing from anyone > before we initiate any new work, we do what the community believes is the > right thing here. This work is less about building a solution, and more > about investigation. This is one of those items where can bring possibly > great optimizations to the mobile data plane. We lost the signaling war > (after CDMA2000 ended) for various reasons, less technical and more about > legacy and other reasons, but that does not mean we will fail every time. > > > > > > Sri > > > > > > *From: *dmm on behalf of Charlie Perkins < > charles.perk...@earthlink.net> > *Date: *Tuesday, November 14, 2017 at 4:43 PM > *To: *"dmm@ietf.org" > *Subject: *[DMM] Fwd: Re: [5gangip] To initiate user-plane study work in > 3GPP > > > > 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 > > > > > > > > ___ > 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] 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 のメール: > > 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 > > > > ___ > 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] Fwd: Re: [5gangip] To initiate user-plane study work in 3GPP
Thats a great idea. Lets find a slot to discuss with Charlie and understand the comments. Any one interested in attending, send me a unicast note. Sent from my iPhone On Nov 15, 2017, at 10:52 AM, Marco Liebsch mailto:marco.lieb...@neclab.eu>> wrote: Can we quickly set up an ad-hoc site meeting here at IETF100? E.g. Thursday Afternoon III or later would be possible for me. Would be an opportunity to follow-up f2f and further elaborate on that. marco From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Mittwoch, 15. November 2017 03:42 To: vojislav vucetic Cc: Charlie Perkins; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in 3GPP Like I said, concern is valid. The deliverable about that study. If it turns out there is no significant optimizations that operators can convince operators, then we will drop the work. Sri From: vojislav vucetic mailto:vvuce...@outlook.com>> Date: Tuesday, November 14, 2017 at 6:35 PM To: Sri Gundavelli mailto:sgund...@cisco.com>> Cc: Charlie Perkins mailto:charles.perk...@earthlink.net>>, "dmm@ietf.org<mailto:dmm@ietf.org>" mailto:dmm@ietf.org>> Subject: Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in 3GPP He put you on the spot👹 Sent from my iPhone On Nov 14, 2017, at 7:13 PM, Sri Gundavelli (sgundave) mailto:sgund...@cisco.com>> wrote: Hi Charlie, Fair point! As part of these efforts, we need to understand and quantify those optimizations. For not all work items, we need blessing from anyone before we initiate any new work, we do what the community believes is the right thing here. This work is less about building a solution, and more about investigation. This is one of those items where can bring possibly great optimizations to the mobile data plane. We lost the signaling war (after CDMA2000 ended) for various reasons, less technical and more about legacy and other reasons, but that does not mean we will fail every time. Sri From: dmm mailto:dmm-boun...@ietf.org>> on behalf of Charlie Perkins mailto:charles.perk...@earthlink.net>> Date: Tuesday, November 14, 2017 at 4:43 PM To: "dmm@ietf.org<mailto:dmm@ietf.org>" mailto:dmm@ietf.org>> Subject: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in 3GPP 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 ___ dmm mailing list dmm@ietf.org<mailto:dmm@ietf.org> https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
