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
