On Wed, Jul 18, 2018 at 9:31 AM, Uma Chunduri <[email protected]> wrote: > 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, is the unintended consequence is we are making > 3GPP > functionalities that are associated with TEID specific to one transport > underlay.
Uma, This might another case of nuanced terminology being used in the draft that obscures what is happening and make things seem more complicated than they actually are. In the case of traditional mode, there is no segment routing header in the packet and hence there are not really any SIDs. There is the destination IP address which presumably takes the role of one SID in the segment routing architecture, however to the rest of the world this is just the destination IP address. IP addresses are quite large, so it's convenient to encode things like TEIDs, VNIs in network virtualization, and other context for the overlay in IPv6 addresses. This is a benefit of IP/IP encpasulation (traditional SRV6 mode) over GTP since the overhead GTP and UDP headers are eliminated. ILA takes encoding information in IPv6 addresses one step further to completely eliminate the need and overhead for any encapsulation. It's true that these techniques impose some requirements on the underlay that it's IPv6 and how addresses need to be structured, but I don't see this to be significantly more constraining than using a protocol specfiic UDP encapsulation. Tom > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
