Re: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-04.txt

Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com> Tue, 12 March 2019 05:47 UTC

Return-Path: <sridhar.bhaskaran@huawei.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052CB130EF2 for <dmm@ietfa.amsl.com>; Mon, 11 Mar 2019 22:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-VjilQCfLgi for <dmm@ietfa.amsl.com>; Mon, 11 Mar 2019 22:47:29 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA44D130EEE for <dmm@ietf.org>; Mon, 11 Mar 2019 22:47:29 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 83CCAA4DF26FD973D6A0 for <dmm@ietf.org>; Tue, 12 Mar 2019 05:47:27 +0000 (GMT)
Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 12 Mar 2019 05:47:26 +0000
Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Tue, 12 Mar 2019 05:47:27 +0000
Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Tue, 12 Mar 2019 05:47:26 +0000
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.242]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0415.000; Tue, 12 Mar 2019 11:17:16 +0530
From: Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com>
To: "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-04.txt
Thread-Index: AQHU2EbnnWJfZoJ9eUeIwyTYEynZXKYHfQPw
Date: Tue, 12 Mar 2019 05:47:16 +0000
Message-ID: <0E42DD26875E1748992B1E3F732A36AE0144A379@BLREML503-MBX.china.huawei.com>
References: <155233512135.23146.11968136924367475977@ietfa.amsl.com>
In-Reply-To: <155233512135.23146.11968136924367475977@ietfa.amsl.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.148.206]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/4KgDy6rxNoxdAkU8-L6XSpx1VeA>
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-04.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 05:47:33 -0000

Dear authors,

I have the following comments on the draft.
 
1. Section 4. The following statement is not clear

>> The user plane described in this document does not depend on any
   specific architecture.

What does "this document" mean here? The previous paragraph talks about TS 23.501. Does "this" document mean 23.501 or this IETF draft?

2. If "this document" meant 23.501, then the statement " does not depend on any specific architecture" is incorrect. 3GPP TS 23.501 requires, the packet detection and forwarding rules at every UPF in the forwarding path be controlled via N4. See TS 23.501 clause 5.8.2.4.1

******
The SMF is responsible for instructing the UP function about how to detect user data traffic belonging to a Packet Detection Rule (PDR). The other parameters provided within a PDR describe how the UP function shall treat a packet that matches the detection information.
*****

3. Section 4 - the following statement is not accurate

Sometimes multiple
   UPFs may be used, providing richer service functions.  A UE gets its
   IP address from the DHCP block of its UPF.

IP address allocation is not always by way of DHCP. A UPF may serve an IP pool and SMF may assign IP address to UE from the pool. Suggest to change it as "A UE gets its IP address via N1 SM NAS signaling from the SMF. The IP address management mechanism is specified in clause 5.8.2.2 of 3GPP TS 23.501"

4. Throughout the document there is this term "UE session" repeating. Its better to clarify that this refers to "UE PDU Session".

5. Section 5.1.1

         gNB_out : (gNB, U1::1) (A,Z)     -> T.Encaps.Red <U1::1>
         UPF1_out: (gNB, U2::1) (A,Z)     -> End.MAP

Also note that the conventions in section 2.2 says:

   *  U1::1 is an IPv6 address (SID) assigned to UPF1.
   o  U2::1 is an IPv6 address (SID) assigned to UPF2.

a. How does UPF1 identify the N4 session related to the UE PDU session? 
b. Does End.MAP function provide a PDU session specific mapping? 
c. Since U1::1 and U2::1 are just IPv6 addresses as specified in section 2.2, how does the UPF1 and UPF2 use it to identify the PDU session specific forwarding / packet handling rules?

6. Same question as above for downlink direction - in section 5.1.2
7. Section 5.2.1

gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red<S1,C1,U2::1>

If I understand correctly in enhanced mode, you propose to insert SID list. 

a. Isn't the SID list part of SRH? 
b. If so, why use T.Encaps.Red which is defined as encapsulation without SRH insertion? 
c. Aren't U2::1 and C1 part of the SID list?
d. How does UPF 2 identify the N4 session related to the UE PDU session?

8. Section 5.2.2

   UPF2_in : (Z,A)                              -> UPF2 maps the flow w/
                                                   SID list <C1,S1, gNB>
   UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)    -> T.Encaps.Red

First step talks about UPF 2 inserting SID list while second step talks about using T.Encaps.Red which is a function that does not insert SRH. So how is SID list inserted into the packet?
All other questions raised in /7/ above hold here as well.

9. Section 5.3.1

o  The SRGW removes GTP, finds the SID list related to DA, and adds
      SRH with the SID list.

Does the SID list added here only contain UPF or SR node addresses? How does each UPF in the SID list identify the specific N4 session related to the PDU session the packet belongs? How does each UPF apply the packet forwarding treatment as provided in the N4 session creation request into the UPF for the PDU session?

I may have number of other questions. But a basic clarity on the above is required first. Could the authors please clarify?

Regards
Sridhar Bhaskaran

-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Tuesday, March 12, 2019 1:42 AM
To: i-d-announce@ietf.org
Cc: dmm@ietf.org
Subject: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Distributed Mobility Management WG of the IETF.

        Title           : Segment Routing IPv6 for Mobile User Plane
        Authors         : Satoru Matsushima
                          Clarence Filsfils
                          Miya Kohno
                          Pablo Camarillo Garvia
                          Daniel Voyer
                          Charles E. Perkins
	Filename        : draft-ietf-dmm-srv6-mobile-uplane-04.txt
	Pages           : 28
	Date            : 2019-03-11

Abstract:
   This document shows the applicability of SRv6 (Segment Routing IPv6)
   to the user-plane of mobile networks.  The network programming nature
   of SRv6 accomplish mobile user-plane functions in a simple manner.
   The statelessness of SRv6 and its ability to control both service
   layer path and underlying transport can be beneficial to the mobile
   user-plane, providing flexibility and SLA control for various
   applications.  This document describes the SRv6 mobile user plane
   behavior and defines the SID functions for that.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-04
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-04


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm