[DMM] Minutes for DMM at IETF 106

David Allan I <david.i.allan@ericsson.com> Wed, 20 November 2019 02:13 UTC

Return-Path: <david.i.allan@ericsson.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 015E41200E5 for <dmm@ietfa.amsl.com>; Tue, 19 Nov 2019 18:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wbgMlnXFUVvf for <dmm@ietfa.amsl.com>; Tue, 19 Nov 2019 18:13:41 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750047.outbound.protection.outlook.com []) (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 421DF12002F for <dmm@ietf.org>; Tue, 19 Nov 2019 18:13:40 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=URSwLiVI2CM9olzOnW7rN8kDwFDvuAwO8UcXNBi9l/0KCCqx/UlFSW5+j55fVj4tDnlFOaR62/XVqiS1duSbtbpJ6euEbd6qTSWu6OaP6HUlVcxSEWDomoyHR0YXOtFGOrzm57BfOaaRVh/lQFN2x50EDVhN4fbcdS/jOeZH2M7Xn9WgCylyH8a7tjJAyy9FMbx0F23xwB8Dv1TSBBTrZKfX3zyw5CevI7Lh3q+0Ze2D/padtu43aApU3LJV0pNkKqsGUas//VbYNN34m2b08DlTk6RCDWDAT87lWjpyjAS6uGXc2WazKctc/aQ8b1ETNKFR+v65idszPYVBEGqIWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HyAnxPB3ZzY3H9N9bAkAi7MWyCesjB3IEmn0OHTqZUg=; b=fR2SNdzGjaITT4ZvntmAy8tbyu7uBUloF4G83hJ/+nQy6GxA/teZXXYJMAVWlAFNRa3Hbro+WnxbUUn1xzn/KhYHyJz9PkC5U388I6YNQDca0sWNgMlabi4Fh2jhDGCmpY1tWu3YBesj4VpxAff+M74swhXt2phycve/ku9RvwlFCUXzRfQ89ptdOMjsVxKAZUm9jM3nsCcEgth9ArkQQ0l/mh7X55BNJHGxr0hWFUFkqxOOajNvrsbAQmKoPs7cZnE8gOY4Ik2NKuvMLQYZ6S5+CEQLMFsNkxO8Udz8ANO7auj8DXkD2QC2NOGlCxk/DfmH/dW4XgKizCAceHf85Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HyAnxPB3ZzY3H9N9bAkAi7MWyCesjB3IEmn0OHTqZUg=; b=W76zH0H+fBaYiORXaJ/L0OREoi8RSvjrKM3ovA8mcTt4jGvLZvLu6ELWjSJtBFYtsG0cuTXgzN4U8pITbzCLO2iFl3kv30g70srWELi9tPd5hKIDqCqo4w4HgMHCSYQbNlFUY4sKuFDfrh+Px//EBgReakJU7Chz1DrYUk18Qxs=
Received: from BYAPR15MB3078.namprd15.prod.outlook.com ( by BYAPR15MB3398.namprd15.prod.outlook.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.30; Wed, 20 Nov 2019 02:13:36 +0000
Received: from BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::71e8:8974:a702:9622]) by BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::71e8:8974:a702:9622%3]) with mapi id 15.20.2451.031; Wed, 20 Nov 2019 02:13:36 +0000
From: David Allan I <david.i.allan@ericsson.com>
To: "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: Minutes for DMM at IETF 106
Thread-Index: AdWfRtbNPWe4lz1fTZ+KBPqF7PKb9A==
Date: Wed, 20 Nov 2019 02:13:35 +0000
Message-ID: <BYAPR15MB30780A2F2875D12751D5F605D04F0@BYAPR15MB3078.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.i.allan@ericsson.com;
x-originating-ip: [2001:67c:370:128:b5ae:f579:2ddf:ba7f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 23566691-3d3f-46e6-a462-08d76d5f4016
x-ms-traffictypediagnostic: BYAPR15MB3398:
x-microsoft-antispam-prvs: <BYAPR15MB339857446CC20D15DED5B9F5D04F0@BYAPR15MB3398.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(366004)(39860400002)(136003)(43544003)(199004)(189003)(5660300002)(66556008)(64756008)(25786009)(2906002)(76116006)(256004)(9326002)(66446008)(478600001)(66476007)(7736002)(6506007)(186003)(7696005)(74316002)(6916009)(14454004)(5024004)(14444005)(102836004)(52536014)(99286004)(8676002)(486006)(476003)(1730700003)(81156014)(81166006)(8936002)(71190400001)(71200400001)(46003)(33656002)(2501003)(66946007)(86362001)(54896002)(9686003)(316002)(6436002)(790700001)(6116002)(55016002)(6306002)(2351001)(4326008)(5640700003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB3398; H:BYAPR15MB3078.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ll1tcuO+AJ1ywy0MN8jVd8Vp4o+24bBUyG/6N+X4iYv3F8hq1qdNGoIVSigveM1a3wriO7DoVqgkjQMVYvFDUmv1re0RUBXqeUF3Jcu7Qu0DQNsSG5N9MpeHYivoChAHACKH0DesJHuVYoeEHwQAUPa6lsVJeJuGeGFkXZP5yG2Q0vKFM+MCd1uGZekXBBxNXmOvt4u5s3uVIKEQWxRohbdIMYjKZ4nkV8B/J7YlKuJT7WSG0Q/C1PD91Ymua7nG5usAt2vvr58uER68X/DJ8GqgR7eCH86W5Lu6EQowg8Xl8wcCWWCrnHBRrr72z1I7w2Wgvu/G7jAGOqpi8Q74qbVWEYSb8+v3QVIT35q1igVof9+frnhVTpYjhtwsX7znYy2HpbAO+HaaWsdtWfLoXsEQxcbgc63boq6dI/LODLfJyYftE9KZG4kg2CZHT5bd
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR15MB30780A2F2875D12751D5F605D04F0BYAPR15MB3078namp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 23566691-3d3f-46e6-a462-08d76d5f4016
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 02:13:35.8542 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FOKywntc85j94O2wsmjNqq+hrtGfFjKJpXAmYh44y+mW4nyEsLwWxGnartyjLnMLdHAzjuoPtQQBXXrwZQzyQwylxBT5B1mArdRRcGgj0Jw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3398
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/cEAwn2urGJyDXNfvDsNN_-ht-w4>
Subject: [DMM] Minutes for DMM at IETF 106
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: Wed, 20 Nov 2019 02:13:48 -0000


The following are the notes I captured on the Etherpad.  Comments I was not able to capture are indicated with <?>.  Apologies in advance for any incorrect attributions....



DMM Monday 11/18/2019

Scribe #1: Dave Allan, Ericsson

Shunsuke: CT groups looking to complete work for release 16 in March. Can we go to last call.

Suresh:  Requires WG review. We can also send a liaison.  Cannot see a way to complete this by March.

Sri: Status of different items.

FPC work ground to a halt, need a way forward.

Distributed Mobility Anchoring, shepherd notes need to be redone.  True for proxy MIP as well.

Suresh: On-demand mobility management has an RFC number assigned.  It's done.

SRv6 for Mobile User plane /Pablo

- summary of updates, removed insertion. Added drop-in, double ended GTP interworking. removed support for unstructured PDU session type. Changes to handling of ethernet means new allocations would be required.

Carlos: willing to review.

User plane message encoding-00:  Tetsuya Murakami

Goal is to carry GTP-U message information.  Proposes carrying information in the unused tag field in the SRv6 header (?) .  Proposed bit field definitions for end-marker etc.

Add a TLV to carry 3GPP information.

Penultimate Segment Popping must NOT be used.

Proposed for WG adoption.

Uma: Purpose is to remove GTP completely and replace with SRv6.   Is there any use case to send from the UE itself?

Tetsuya:  <not captured>

Sri:  Does not extend to the UE.

Suresh: Spectrum is expensive. Do not want GTP on the air.

Dave: Stuff covered is either carried over PDCP or only of significance to the gNodeB. Do not need GTP to UE.

Sri: Need more feedback from WG and the AD.  Keep doing the work and we'll see about adoption.

Transport Network Aware Mobility for 5G, Uma, John K.

Current version narrows down choices for MTNC-ID in meta data.

Looking for mapping from PDU session layer to transport network paths.

Sri: Overlay to underlay mapping is not a new problem. Right.

Uma: What has been deployed used non-standardized ways of mapping. We're looking to streamline this.

John:  Wanted to converge on one solution. Added option for encoding context ID in th outer header--> source UDP port.

Sri: Where do you get this transport network context?

John: It is not IETF work to come up with this mapping. Believe they have also selected ACTN, but details still being resolved in SA5.  TNF is a logical function, interfaces are IETF. 3GPP slice aspects NSSAI is related to what a user is supplied. May be 1000 customers and 3 slices.  Impacts N2 and N4.

Sri: Today you do mapping at a session level. What are the advantages of at a slice level?

John: DSCP is not immutable. QFI is too deep for packet inspection.

Dave: Source port normally used for ECMP. Is this turned off?

John: in the text. Only certain ranges used (?)

Satoryu:  You are proposing using the source port for mapping. What WG would define this.

Uma:  This is a local mapping.  Not a WG problem and is backwards compatible.

Suresh: If rewriting UDP ports, are you redoing the checksums?

Uma: Done at the UPF where the UDP header originates.

Xuesong: VLAN should not be excluded.  Can user other encaps to respect the information

John:  We can include that

Marco: UDP is a bi-directional thing.  Does the value need to be symmetric.

John: We are considering unidirectional flows. Assume some symmetry. If using a range on the upstream, range does not need to correspond.  QFI itself insufficient.

Tasuya:  <?>

John: Range of the UDP port handled by the IP part.

Tasuya: So do not use existing PFCP <?>

John: What about WG adoption?

Sri: Can ask the group.

Xuesong: Map in the RAN to the backhaul, this is isolated work.

Sri:  How to take this up.

Xuesong:  In the same WG.  Not sure these are tied together and could be different drafts.

John:  What part?

Xuesong: The solution space.

Carlos: Also willing to review.

Sri:  Need more discussion, good feedback.

Architecture Discussion on SRv6 mobile User plane, Miya Kohno

How to map mobility data plane.  Suggests SRv6 is the right choice for 5G.

Suggests an additional user plane ID is required for slice mapping.  PE redundancy is an additional requirement.

Goal is to have the UPF be part of the TN and not a CE.

3GPP entities do not care about IP routing??   Sidecar proxy can take care of communication state exchange.  BSID can be used for topology hiding.

URLLC with duplication and elimination requires modification of GTP-U.

Proposed for discussion.

John: Good points on URLLC. How does SRv6 allow paths to be disjoint?

Miya: Could provide TI-LFA and other tools. SR aware entities can directly control the mechanisms.

John: With a chain of N3/N9, how does SRv6 help?  <go offline>

Suresh: What is this a separate document?

Miya: SRv6 mobile user plane document simply describes the protocol. I wanted to discuss more the architectural implications.

Suresh: Text is useful, how it proceeds to be discussed. It is pretty dependent on other stuff. This comes up in IESG as supporting documents.  If it is to be separate and progress need to think about the write up.

Sri: Good points.

Uma: Good questions are asked.  Can collapse GTPU and SRv6.  We are envisioning a future of IPv6 only transport. When we started it ws NS1U.  This is a bigger discussion.

Marco: Service mesh, what does this have to do with slicing. It is an implementation matter.

Miya: Conventional box thinking needs to be evaluated.

Marco: What about proxies... <?>.

Miya:  IF there could be a proxy that could do all routing and forwarding stuff and it sits in the host. We could provide routing in host.

Rajeev: Liked the side car analogy, so the proxy was adjacent to the application itself.

Marco:  Sidecars function at a DHCP level.

Rajeev: There is also the notion of application routing. Lines are blurring and have been for some time.

Suresh:  If in a sidecar, the app does not need to know about it.

Sri: Good work, needs more discussion.

Uma: This and the last presentation are very much connected.

Mobility capability negotiation and protocol selection  Zhiwei

Two categories, network and host based solutions.

Suggests a negotiating discipline.

Possible solutions for negotiation.

ICMPv6 gets a new option.

Suresh: Everything you say has been tried before. 2007-2008, it never worked. If the network can do it, it will do it.  CMIP vs PMIP. The problem is not technical. There is no deployment scenario where this will be useful.  There is a past history of failure.  Think about where and how you would use this.

Sri: May want to work with a few people, get some feedback, and decide whether to pursue.

Rajeev: For an endpoint attached to cellular, going to a site GW, where is this message going? Could be a side gateway.  SO this notion of something in the RS an RA to allow mobility to work, needs to be compatible with outside of the cellular world.  It would have a low footprint.

Suresh: The other ones were RS RA based.

Uma:  Why did it fail, security or what?

Suresh: Not anchored in architectures anywhere.  For good or bad, architectures done elsewhere.  Stuff need to be anchored or it goes nowhere. Deployment support. Everything Rajeev said was looked at.

YANG for Protocol for Forwarding Policy Configuration (FPC)/ Satoru

FPC did not touch any over the wire protocol. Decided to define a YANG model to provide an API.

After the update by Charlie, there has not been further work, so the draft has expired.

Continuing to pursue this dependent on group/industry interest.  Comments?

Marco: co-author. This stuff is pretty stable. Since we have two pretty mature parts, need to review. But we should progress them. Need reasonable reviews to proceed. It would be a pity not to proceed.

Sri: Move this to the mailing list.  Need to go through the process and get some reviews. Suresh agrees.

Session Closed