Hi Uma, You wrote: “However, if this is seen as GTP replacement option, by moving TEID of the GTP header encoded into each SRv6 SID, the unintended consequence is we are making 3GPP functionalities that are associated with TEID specific to one transport underlay.”
[Arashmid] Let me try a more generalized version of your statement: “Constructing SIDs based on a specific structure locks the transport underlay to the specific service for which the SID is constructed for.” The SID although routable but is only local the segment end point. How its construct locks the underlying transport layer to only a single service? From: Uma Chunduri Sent: Wednesday, July 18, 2018 12:31 PM To: Arashmid Akhavain <arashmid.akhav...@huawei.com>; Pablo Camarillo (pcamaril) <pcama...@cisco.com> Cc: dmm@ietf.org; Alberto Rodriguez Natal (natal) <na...@cisco.com>; spr...@ietf.org Subject: RE: Comment on SRv6-mobile-userplane Hi Arashmid, >>[Uma]: 2 quick and minor corrections for the above first.“we encode the TEID >>into a SID” ==> >>https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1 >>says “Note that in this mode the TEID is embedded in each SID.” >>(section 5.1.3 confirms this) >[Arashmid] Embed vs Encode? Is this issue? [Uma2:]It’s not embed or encode. It says each SID. >[Arashmid] Today each PDU session gets its own set of TEIDs between eNB and >SGW and between SGW and PGW. For example for a UE with both internet access >and VoLTE, there are two GTP tunnels between the eNB and the SGW and two other >GTP tunnels between the SGW and the PGW. >We maintain this in traditional mode. [Uma2]: I am not questioning how each bearer get a different TEID or how separate tunnels are maintained per PDU session between eNB-SGW or SGW-PGW. It’s good this being planned to achieve in traditional mode. However, if this is seen as GTP replacement option, by moving TEID of the GTP header encoded into each SRv6 SID, the unintended consequence is we are making 3GPP functionalities that are associated with TEID specific to one transport underlay. There are various other modes defined in the document, for example https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.3 (called Enhanced mode with unchanged gNB GTP behavior) In that case I see separation maintained and with a possibility of multiple SRv6 features, that can be applied in underlay as needed. -- Uma C.
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
