Hi Uma, Please see my replies inline [Arashmid]
Cheers, Arashmid From: Uma Chunduri Sent: Wednesday, July 18, 2018 11:50 AM To: Arashmid Akhavain <[email protected]>; Pablo Camarillo (pcamaril) <[email protected]> Cc: [email protected]; Alberto Rodriguez Natal (natal) <[email protected]>; [email protected] Subject: RE: Comment on SRv6-mobile-userplane Arash, In-line [Uma]: -- Uma C. From: Arashmid Akhavain Sent: Wednesday, July 18, 2018 9:18 AM Hi Uma, I am not sure if I understand your concern. In traditional mode, we encode the TEID into a SID. This is the mode that draft bogineni refers to as the simplest form of using SRv6 for the N9 interface. [Uma]: 2 quick and minor corrections for the above first. 1. “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? 2. Traditional mode as documented ietf-dmm-srv6 applies to both N3 and N9 [Arashmid] Yes, it does, but the focus of draft bogenini is N9 >Only the head nodes know that TEID has been encoded into the SID. Tandem nodes >treat the traffic as normal SRv6 traffic. Are you saying that the use of SRv6 >in general forces the underlying say MPLS transport to convert to SRv6? [Uma]: The problem with removing GTP header and keeping the same in each SRH SIDs make the underlay specific to SRv6. Pablo’s below response says – “The Traditional mode is only offering GTP replacement for specific PDU sessions with complete independence from the transport network.” I don’t see the draft text reflects this. [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. For example in interworking model when we need to deal with IPv4 GTP tunnels, the SA and DA part of the SID will remain the same, but the TEID will be different. 4 GTP tunnels for the above mentioned UE sessions will produce 4 SIDs which differ by the bits identifying the TEID Cheers, Arash From: Uma Chunduri Sent: Tuesday, July 17, 2018 3:10 PM To: Pablo Camarillo (pcamaril) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Arashmid Akhavain <[email protected]<mailto:[email protected]>>; Alberto Rodriguez Natal (natal) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: Comment on SRv6-mobile-userplane [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:[email protected]] Sent: Tuesday, July 17, 2018 11:25 AM To: Uma Chunduri <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Arashmid Akhavain <[email protected]<mailto:[email protected]>>; Alberto Rodriguez Natal (natal) <[email protected]<mailto:[email protected]>> 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.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
