On Wed, Jul 18, 2018 at 6:18 AM, Arashmid Akhavain <[email protected]> wrote: > 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. > > 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?
I think the terminology being used in the draft might be making this seem complicated than it actually is. AFAICT, SRv6 traditional mode is nothing more than IP in IP encapsulation, so the requirement of the underlay is that it forwards IPv6 and intermediate nodes treat the traffic as "normal IPv6 traffic". There is no segment routing involved, no extension headers needed, and the only upgrade for the network is to support IPv6. One caveat to that is that some intermediate nodes may want to do DPI into transport layer to get ports for ECMP or other reasons, if that is desirable it would be easy enough to alternatively use a UDP encapsulation-- either continue with GTP or switch to a more generic one like GUE. Tom > > > > Cheers, > > Arash > > > > From: Uma Chunduri > Sent: Tuesday, July 17, 2018 3:10 PM > To: Pablo Camarillo (pcamaril) <[email protected]> > Cc: [email protected]; Arashmid Akhavain <[email protected]>; Alberto > Rodriguez Natal (natal) <[email protected]>; [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]> > Cc: [email protected]; Arashmid Akhavain <[email protected]>; Alberto > Rodriguez Natal (natal) <[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 > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
