[Added Spring too, as one of the chairs, Bruno asked us to discuss] Hi Pablo,
Please see in in-line [Uma]: -- Uma C. From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com] Sent: Tuesday, July 17, 2018 11:25 AM To: Uma Chunduri <uma.chund...@huawei.com> Cc: dmm@ietf.org; Arashmid Akhavain <arashmid.akhav...@huawei.com>; Alberto Rodriguez Natal (natal) <na...@cisco.com> Subject: Comment on SRv6-mobile-userplane Hi Uma, During the presentation of draft-bogineni-dmm-optimized-mobile-user-plane you have raised a comment saying that SRv6 mandates an integration in between the overlay and the underlay transport network. I would like to clarify that this is NOT true. Please read https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1 The Traditional mode is only offering GTP replacement for specific PDU sessions with complete independence from the transport network. No matter whether the transport is MPLS, IPv6 or whatever -without any SR at all-. [Uma]: It is positioned as one of the alternative to replace GTP-U in the data path. From Section 5.1 “ In the traditional mobile network, an UE session is mapped 1-for-1 with a specific GTP tunnel (TEID). This 1-for-1 mapping is replicated here to replace the GTP encaps with the SRv6 encaps, while not changing anything else. This mode minimizes the changes required to the entire system and it is a good starting point for forming the common basis. Note that in this mode the TEID is embedded in each SID.” I also believe, that way because this is being sent as response to CT4 as a replacement alternative to GTP-U with SRv6 underlay in traditional mode. https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01#section-6.1 “ In its most basic form, SRv6 can be used as a simple drop-in alternative for GTP tunnels. The control plane in this approach remains the same, and still attempts to establish GTP-U tunnels and communicate TEIDs between the tunnel end points. However, at the next level, SRv6 capable nodes use SIDs to direct user traffic between the UPFs.” If we propose this is a drop-in replacement for GTP-U – this could force (with the approval of IETF and 3GPP) every operator to use SRv6; as TEID functionality is basic to any 3GPP procedure (not only for Xn, N2 and whatever mobility case out there, service request, paging and you name it..). I don’t think you want to exclude SR-MPLS if operator wants (or any TE) it or transitioning to. On the other hand if it is only for some PDU sessions then this need to be specifically mentioned in the draft as well as the “optimized mobile user plane” response. Hence, if an operator would like to have integration of the overlay and underlay (for end-to-end network slicing), he can have such integration. If this is not desired, the dmm-srv6-mobile-uplane proposal can work completely independently from the transport, as already documented in the draft. [Uma]: It would be great if we strive to achieve that independence as much as possible while focusing on the value and feature SRv6 brings it to the table. I will check with the rest of co-authors of the draft to see whether we should clarify in the draft the independence from the transport network. [Uma]: Sure, thanks for your consideration. Cheers, Pablo.
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
