IETF Logo Mail Archive

Re: [Pidloc] Pidloc in IETF Prague #104

<Dirk.von-Hugo@telekom.de> Fri, 29 March 2019 15:50 UTC

Return-Path: <Dirk.von-Hugo@telekom.de>
X-Original-To: pidloc@ietfa.amsl.com
Delivered-To: pidloc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D6E12046E for <pidloc@ietfa.amsl.com>; Fri, 29 Mar 2019 08:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 DNGJ3eQ3Naq2 for <pidloc@ietfa.amsl.com>; Fri, 29 Mar 2019 08:50:10 -0700 (PDT)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 90173120404 for <pidloc@ietf.org>; Fri, 29 Mar 2019 08:50:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1553874604; x=1585410604; h=from:to:subject:date:message-id:mime-version; bh=AKPH4ShkxUSVmTZNEHJD/HeNDfyM56hgyJFKoPRooPA=; b=ttQ8ei93JRt3waql3DKfTbpMr7m0x1FTab3e5SR81M0EM5wI7kuGrI0W OyIXAENkPG4eXveYNMwl6YnLB9vnh78i5tMUnaT8QDvohWWdNXnEV5Vy7 D2cT+wZjQCN6xA7949xrVU2uvdgHV10vZPszRyvxjYIlb/9WGKlbX7TPz InnBGd6LJXxs61xNFsxxQIzg7Cu569U0HTemjHLwJf/RuPI3AVmzsKtlN ztCvwKGfQWK2EIlUyHL23Cxpp7H24bmEtcgkza+bOjKsSHAvhtQcbnghp /7S5EKA7EL2V5nX3rWsZNfq7KRzMNux49+J7t8VTI46WwQb8Lh6mIBC0o Q==;
Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2019 16:50:01 +0100
X-IronPort-AV: E=Sophos;i="5.60,284,1549926000"; d="pdf'?scan'208,217";a="502333575"
Received: from he101943.emea1.cds.t-internal.com ([10.169.119.83]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 29 Mar 2019 16:50:00 +0100
Received: from HE105651.EMEA1.cds.t-internal.com (10.169.119.62) by HE101943.emea1.cds.t-internal.com (10.169.119.83) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 16:49:50 +0100
Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105651.EMEA1.cds.t-internal.com (10.169.119.62) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 29 Mar 2019 16:49:50 +0100
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.21) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 16:49:50 +0100
Received: from LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE (10.158.167.18) by LEXPR01MB0670.DEUPRD01.PROD.OUTLOOK.DE (10.158.167.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Fri, 29 Mar 2019 15:49:48 +0000
Received: from LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE ([fe80::483d:5dbd:db94:e84e]) by LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE ([fe80::483d:5dbd:db94:e84e%4]) with mapi id 15.20.1730.019; Fri, 29 Mar 2019 15:49:48 +0000
From: Dirk.von-Hugo@telekom.de
To: pidloc@ietf.org
Thread-Topic: Pidloc in IETF Prague #104
Thread-Index: AdTmQ1mz3M0UO0PHTCCpL9dcG6vIRw==
Date: Fri, 29 Mar 2019 15:49:48 +0000
Message-ID: <LEXPR01MB06697AD320805F58B004443FD15A0@LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dirk.von-Hugo@telekom.de;
x-originating-ip: [212.201.104.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 99736cda-088a-4ecf-4168-08d6b45e2cb2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:LEXPR01MB0670;
x-ms-traffictypediagnostic: LEXPR01MB0670:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <LEXPR01MB0670E104E3CC0814E3E4FDE7D15A0@LEXPR01MB0670.DEUPRD01.PROD.OUTLOOK.DE>
x-forefront-prvs: 0991CAB7B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(1496009)(396003)(376002)(136003)(39850400004)(366004)(346002)(199004)(189003)(6306002)(66066001)(256004)(54896002)(236005)(6916009)(5640700003)(9686003)(71200400001)(476003)(606006)(81156014)(74482002)(55016002)(790700001)(99936001)(2501003)(2906002)(53936002)(3846002)(106356001)(2351001)(1730700003)(5024004)(6116002)(71190400001)(6246003)(75402003)(8936002)(86362001)(8676002)(5660300002)(81166006)(14454004)(68736007)(105586002)(7736002)(316002)(102836004)(33656002)(229853002)(413944005)(7696005)(52396003)(72206003)(478600001)(186003)(966005)(97736004)(26005)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0670; H:LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: MeYA9m3gmCkwSi5aLdIL8dQQ33qF+MPq5cSG99LgomgujC327H8MuR1Kr9x0uhDRxq6kqlu9mBC1xT0MtLlxPH7yk8BJFnybJgpAsIEoB7mUe3N93NfFbkbOvHSJgJ3YOD9yY28n9vXb1L+1kFq9IVg0NtgTl0L56hQsyWAw8T9teVAlL8Q19Q/XCZFtRcjpyoLiZX94PAvG4osniLtCh/rAC+/dHbojv+6aFxrCx9z9q+5ERHBockCNjsGimgVi32kTtaR3WWci1+l5wvNUf0TVCbFlf4zbbqxq6A0h3pVYn2ntR5FTzrNQKYJ6jXq0QSS1wTxL9iEX5yla6t5Pyv2Hb7qMwTQtYEGGUrEwok3zMha/wIk5xmDCR7BPWhSu7ck2y0ToTZOWOML2CQo2HA6eptyLpbpLONUH5AjqoZQ=
Content-Type: multipart/mixed; boundary="_005_LEXPR01MB06697AD320805F58B004443FD15A0LEXPR01MB0669DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 99736cda-088a-4ecf-4168-08d6b45e2cb2
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 15:49:48.8037 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0670
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/zzWqwPwlI2xTD4A3EKDmQ_ZFzHI>
Subject: Re: [Pidloc] Pidloc in IETF Prague #104
X-BeenThere: pidloc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <pidloc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pidloc>, <mailto:pidloc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pidloc/>
List-Post: <mailto:pidloc@ietf.org>
List-Help: <mailto:pidloc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pidloc>, <mailto:pidloc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2019 15:50:23 -0000

Dear all,
as announced before we actually had our side meeting here in Prague and some fruitful discussions.
I’d like to share with you some notes of the 1-hour session where seven people attended on site and about four more on the phone/webex. Sorry for the inconvenience of a sub-optimum audio connection.
I will also attach the slides shown and the link provided by Marco.

Dirk presented chairs slides - focus was more on the open questions (gaps and problems) to be solved than on solutions.
Erik commented on use cases as edge computing in IoT (location is an issue here) and consumers sharing voluntarily Id and Location on application layer – which of course also should not be leaked beyond intended recipients.
VPN like closed groups pose less problem than rather consumer scale device numbers (walled garden or separate domains).

Shunsuke presented 5G use case attempting to include Id-Loc compatible with 3GPP architecture.
Location exposure of nearest UPF to local (non-3GPP) Data Networks (maybe untrusted) may raise privacy issues on related location information (from UPF to derive that of UE).

Next steps might be a more complete collection and classification of use cases and thereof identification of a requirements set to be demanded from potential solutions.

Marco and Umberto promised and meanwhile did to provide a link to related slides in DMM (draft at https://www.ietf.org/id/draft-fattore-dmm-n6-trafficsteering-01.txt) pointing to the LDN problem:

ID-LOC applies to the data network’s DPN and the user’s current (edge) UPF (serving as session anchor).

https://datatracker.ietf.org/meeting/104/materials/slides-104-dmm-control-data-plane-for-n6-traffic-steering-00

A question was whether slicing shall be provided via Id-Loc? Rather than that a low latency service on DP/UP would be the goal.
Somebody mentioned that also tunneling between two endpoints could be seen as Id-Loc approach.
Thanks for comments and updates/corrections by all participants.
Let’s continue discussion on the list.

Kind regards
Dirk

v2.23.0 | Report a Bug | By Email