Re: [spring] [DMM] Comment on SRv6-mobile-userplane

Hi Tom,
Thank you for the reply. You are right, the underlay network doesn't care... I think this is also true for scenarios where the extension header is present.

Arashmid

-----Original Message-----
From: Tom Herbert [mailto:tom@quantonium.net] 
Sent: Wednesday, July 18, 2018 10:38 AM
To: Arashmid Akhavain <arashmid.akhavain@huawei.com>
Cc: Uma Chunduri <uma.chunduri@huawei.com>; Pablo Camarillo (pcamaril) <pcamaril@cisco.com>; spring@ietf.org; dmm@ietf.org
Subject: Re: [DMM] Comment on SRv6-mobile-userplane

On Wed, Jul 18, 2018 at 6:18 AM, Arashmid Akhavain <arashmid.akhavain@huawei.com> 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) <pcamaril@cisco.com>
> Cc: dmm@ietf.org; Arashmid Akhavain <arashmid.akhavain@huawei.com>; 
> Alberto Rodriguez Natal (natal) <natal@cisco.com>; spring@ietf.org
> 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:pcamaril@cisco.com]
> Sent: Tuesday, July 17, 2018 11:25 AM
> To: Uma Chunduri <uma.chunduri@huawei.com>
> Cc: dmm@ietf.org; Arashmid Akhavain <arashmid.akhavain@huawei.com>; 
> Alberto Rodriguez Natal (natal) <natal@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#secti
> on-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-p
> lane-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
>