Uma, As I already clarified in my previous email, the proposal of draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network.
>Only the head nodes know that TEID has been encoded into the SID. Tandem nodes >treat the traffic as normal SRv6 traffic. The proposal of the draft requires that for example the UPFs are SRv6 capable. However, any transport network in between the two SRv6 UPFs does not need to be SRv6 capable. It just needs to forward IPv6 packets. This is defined in RFC8200. Hence, it does not matter what underlay transport you use. It is independent. Are you saying that the use of SRv6 in general forces the underlying say MPLS transport to convert to SRv6? No. Its independent. Underlay can be anything. As I already said in my previous email, we will clarify this in the next revision of the draft. Thanks, Pablo. From: Uma Chunduri <[email protected]> Date: Wednesday, 18 July 2018 at 11:50 To: Arashmid Akhavain <[email protected]>, "Pablo Camarillo (pcamaril)" <[email protected]> Cc: "[email protected]" <[email protected]>, "Alberto Rodriguez Natal (natal)" <[email protected]>, "[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) 2. Traditional mode as documented ietf-dmm-srv6 applies to both N3 and 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. 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.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
