Re: [5gangip] New Version Notification for draft-xyx-5gip-ps-01.txt
Saleem Bhatti <saleem@st-andrews.ac.uk> Thu, 25 May 2017 19:21 UTC
Return-Path: <saleem@st-andrews.ac.uk>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C59128DE5 for <5gangip@ietfa.amsl.com>; Thu, 25 May 2017 12:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=universityofstandrews907.onmicrosoft.com
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 lCEM-Ep6tgno for <5gangip@ietfa.amsl.com>; Thu, 25 May 2017 12:21:25 -0700 (PDT)
Received: from mcgraw.st-andrews.ac.uk (mcgraw.st-andrews.ac.uk [138.251.8.95]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B326A127876 for <5gangip@ietf.org>; Thu, 25 May 2017 12:21:24 -0700 (PDT)
X-StAndrews-MailScanner-From: saleem@st-andrews.ac.uk
X-StAndrews-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.89, required 5, autolearn=not spam, BAYES_00 -1.90, HTML_MESSAGE 0.00, RP_MATCHES_RCVD -0.00, T_DKIM_INVALID 0.01)
X-StAndrews-MailScanner: No virus detected
X-StAndrews-MailScanner-ID: v4PJLDle004888
X-StAndrews-MailScanner-Information: Please contact the ISP for more information
Received: from unimail.st-andrews.ac.uk (exch13-srv01.st-andrews.ac.uk [138.251.8.22]) by mcgraw.st-andrews.ac.uk (8.14.9/8.14.9/Debian-4~bpo0+uos) with ESMTP id v4PJLDle004888 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 25 May 2017 19:21:15 GMT
Received: from exch13-srv01.st-andrews.ac.uk (138.251.8.22) by exch13-srv01.st-andrews.ac.uk (138.251.8.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 25 May 2017 20:21:13 +0100
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (213.199.180.181) by exch13-srv01.st-andrews.ac.uk (138.251.8.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 25 May 2017 20:21:13 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=UniversityofStAndrews907.onmicrosoft.com; s=selector1-standrews-ac-uk0e; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BrORQiaQrnz1LVY5ymuZ2suqOGlJGyiaIF+j3JOAFsk=; b=oR4BqWtHSzG6kgBJCPMS3D+JLJK5/XjQSi33+mDBXWNGtWZ/MOHUV7RaD4oFYM5nVZpy8Vra8CHtsulmbH9bO5jJSECK6ILcWG20LFrnVwsfS43licCcLBWmsvflNbk9jJsXagyPw2wWLpl4uiNne6x1M/n1vUz4KRseaeFXa9g=
Received: from DB6PR0601MB2469.eurprd06.prod.outlook.com (10.169.213.151) by DB6PR0601MB2472.eurprd06.prod.outlook.com (10.169.214.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Thu, 25 May 2017 19:21:11 +0000
Received: from DB6PR0601MB2469.eurprd06.prod.outlook.com ([fe80::60b1:9a70:f1d2:1163]) by DB6PR0601MB2469.eurprd06.prod.outlook.com ([fe80::60b1:9a70:f1d2:1163%19]) with mapi id 15.01.1124.009; Thu, 25 May 2017 19:21:10 +0000
From: Saleem Bhatti <saleem@st-andrews.ac.uk>
To: Tom Herbert <tom@herbertland.com>
CC: Cameron Byrne <cb.list6@gmail.com>, "5gangip@ietf.org" <5gangip@ietf.org>, "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>
Thread-Topic: [5gangip] New Version Notification for draft-xyx-5gip-ps-01.txt
Thread-Index: AQHS1TOiW1hfh929Gk+EmQElGyrsOqIFLakAgAAcMoCAABg4AIAAC6QA
Date: Thu, 25 May 2017 19:21:10 +0000
Message-ID: <404F6417-C15D-4E57-9FFD-DB8DA6A055EB@st-andrews.ac.uk>
References: <149547735610.22634.10661693302211465600.idtracker@ietfa.amsl.com> <CAC8QAcdiCsxRT7_ube47q5YiAdkBP9-jC7AyLWXQaGR4vAboRQ@mail.gmail.com> <1765af8f1375483dba56391633ebb4d5@HE105831.emea1.cds.t-internal.com> <CAD6AjGSYJVjnBkA0oTO49=ApPeHQBK=z5JPadBtujoP0_9iL8g@mail.gmail.com> <CALx6S35GzM7Kmj9C80VN4TZNZZjYwLWXPpZpbPD0gXS-74Va9g@mail.gmail.com> <CAD6AjGRwK+ikUeytA=H64VMO1o1GkPVV4e9q3CaSi0xNi0xHAw@mail.gmail.com> <CALx6S37mF8Ujb75SeG6xOC-X=8KQPBtPj2pNoOvCnFJK6fBtQQ@mail.gmail.com> <9735C639-84B5-4C8F-8C3B-B4E85A16EEB8@st-andrews.ac.uk> <CALx6S36H9f5Ew7b2fru9SOQesJD6YsCt7wwwb1mV=kworXmq5w@mail.gmail.com> <84FDD158-BE3D-400B-A814-53A793437470@st-andrews.ac.uk> <CALx6S35Bxei_3Rh735qKovMNZyi45ho0HTdag=9kpsLtzip71Q@mail.gmail.com>
In-Reply-To: <CALx6S35Bxei_3Rh735qKovMNZyi45ho0HTdag=9kpsLtzip71Q@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=st-andrews.ac.uk;
x-originating-ip: [81.187.216.172]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2472; 7:qE8TskTsl/vGyYPPcGRSQ+cM6QWuUbCJu1yb1NosqwbuYv7D8d/d7jgGUF5v+PJ49OzKsKXyoYmV/7t36DUzqK89WBWycn+02Fg+5+vweBT6+Eru+odpBMCI5gdHLtQvDm1bEqL2LQsZJfBw/opfLZGvsHKI8XsUwt9z6tDrPkdSPTHUjCw00Uq+Zw3NprMfL+Mx/YC35ZB1WvD6UmB+BRO0Z5h9xaNuIdaiUjv0KzYVFWv4zJQtbayRELTK1RzFrSwzfOsLklRarMpD/kYDF9ZRIlV6A1NY7pYV5L4lBS97K3iMc6xwLnG6Rxy0vU54JISaA4LrCobY9KSpw0QRlA==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39840400002)(39410400002)(39450400003)(22974007)(377454003)(24454002)(377424004)(99286003)(966005)(54906002)(54896002)(3280700002)(33656002)(6306002)(236005)(38730400002)(6246003)(5660300001)(189998001)(6512007)(81166006)(8676002)(478600001)(7906003)(230783001)(2906002)(7736002)(2900100001)(14454004)(53936002)(8936002)(3660700001)(66066001)(110136004)(86362001)(15650500001)(39060400002)(83716003)(229853002)(6436002)(3846002)(54356999)(6486002)(82746002)(36756003)(93886004)(6506006)(2950100002)(42882006)(25786009)(606005)(50986999)(76176999)(102836003)(53546009)(74482002)(4326008)(6916009)(5250100002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2472; H:DB6PR0601MB2469.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
x-ms-traffictypediagnostic: DB6PR0601MB2472:
x-ms-office365-filtering-correlation-id: a5e7fc38-00c1-4851-4a34-08d4a3a3338c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB6PR0601MB2472;
x-microsoft-antispam-prvs: <DB6PR0601MB2472099FA874E5134FC63F6FA7FF0@DB6PR0601MB2472.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105)(82608151540597)(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148); SRVR:DB6PR0601MB2472; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2472;
x-forefront-prvs: 0318501FAE
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_404F6417C15D4E579FFDDB8DA6A055EBstandrewsacuk_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2017 19:21:10.4036 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f85626cb-0da8-49d3-aa58-64ef678ef01a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2472
Archived-At: <https://mailarchive.ietf.org/arch/msg/5gangip/C-JEn0UpRd6Qwi1Qp1nI8wuunC0>
Subject: Re: [5gangip] New Version Notification for draft-xyx-5gip-ps-01.txt
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 19:21:29 -0000
Tom; On 25 May 2017, at 19:39, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote: On Thu, May 25, 2017 at 10:12 AM, Saleem Bhatti <saleem@st-andrews.ac.uk<mailto:saleem@st-andrews.ac.uk>> wrote: Tom; On 25 May 2017, at 16:31, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote: On Thu, May 25, 2017 at 1:48 AM, Saleem Bhatti <saleem@st-andrews.ac.uk<mailto:saleem@st-andrews.ac.uk>> wrote: Tom; On 24 May 2017, at 16:32, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote: On Wed, May 24, 2017 at 5:32 AM, Ca By <cb.list6@gmail.com<mailto:cb.list6@gmail.com>> wrote: Tom -- as a network operator, my ideal scenario just moves the packets. To that end, i would like to remove the anchor / touchpoint. The scaling comment is that any anchor needs to scale to N where N is some set of users total throughput. This is why ILNP appeals to me and ILA looks like more of what we already have today with less functionality. Ca, ILA is a super set of ILNP use cases. ILA can be used end to end or as a means to implement an overlay within the network or something in between. The typical deployment is a hybrid approach. If a non-ILA enable node is talking to a mobile node communications can go through a router; else if the node is ILA capable then it can get the ILA mapping to speak directly to the mobile node and eliminate the triangular routing. ILNP does not define an overlay mechanism or a tunnelling mechanism. However, I do not know a reason that ILNP could not be tunnelled, if tunnelling was required (for whatever reason). While ILNP is designed to be end-to-end, it also supports various use-cases with the deployment of an ILNP-capable site-border router (SBR), e.g. a router at the edge of a radio (access) network. Such a SBR could be used as a control and management point for a radio (access) network. RFC6748 gives an outline of some of the various use cases with an ILNP-capable SBR (perhaps not all of them are of interest to this list, however): - localised numbering (localised addressing) - site-multihoming - mobility of whole networks/sites - traffic engineering options - options for datacentres, including wide-area virtual machine image migration - identity privacy and location privacy Hi Saleem, My primary concern about ILNP is this statement from section 4, RFC6741: "So, transport protocol implementations MUST be modified in order to operate over ILNP." There are lot of transport protocol implementations, some of these are not even in the kernel (like QUIC), and some may be proprietary that we don't even know about. Agreed. I'm not sure it's feasible to require all transport implementations are updated to understand ILNP. For ILNP, any protocol state that uses address bits directly potentially needs to change, e.g. end-to-end state for TCP or UDP. However, I would not expect application protocols (apart from specific systems management/control/configuration applications) to use address bits directly (but lots do). Overall, moving from IPv6 to ILNPv6 will be much less work that moving from IPv4 to IPv6, in terms of lines of code. Of course, if there is a requirement for not refactoring transport layer code for 5G and onwards, then the solution chosen must have someway of dealing with that concern in an acceptable way. As far as I know, there is no such requirement. I totally agree, however, that aiming to minimise implementation pain is a good goal to aim for. Also, this requirement probably makes tunneling hard to do in ILNP without proxying. I am not sure I understand what you mean here, but I would imagine it depends on the type/purpose of the tunnel. These are all possible without the loss of end-to-end state, and so can all be used together. For ILNPv6, they also preserve the current IPv6 addressing and numbering practises. How does ILNP solve the /64 assignment to UEs problem? In this case it seems the identifier needs to be longer than 64 bits. A /64 assigned to an ILNPv6 host would be treated as a Locator value - a L64 value. Locator values in ILNPv6 are 64 bits. ILNPv6 Identifier values - Node ID (NID) values - are also 64 bits. So, I am not sure why an assignment of a /64 to an ILNPv6 end-node would require the identifier to be longer than 64 bits. (My apologies if I have misunderstood your question.) I think the problem is that there is no single global 64 bit identifier space in this scenario. So for example, if two UEs get a /64 address assignment they could each assign </64 prefix>::1 to their nodes. So if an external node wants to communicate by ILNP for each of these nodes, what is the identifier? 1 (or ::1 as you have it above). A ::1 identifier is not unique in the network, A NID value MUST be unique within the scope of the Locator (the /64 vlaue), which is all that is required for ILNP. That is, no two nodes would have the NID value of 1 *and* the same value for the Locator. For ILNPv6, as for ILNPv6, only the /64 - top 64 bits, the routing prefix, the Locator - is used for routing, so that is enough to get the packet to the correct UE. Once the packet is at the UE, the UE can then forward the packet to the correct node. more information is needed (probably about the UEs) to differentiate them. In other words the logical node is identified by both its UE and the address that UE assigned it within its allocation-- that's more than 64 bits of information in the case a UE is assigned a /64. That is a L64<->NID binding issue handled locally at the correspondent node (please see RFC6741, Section 5, specifically Section 5.4). Cheers, --/Saleem Tom Cheers, --/Saleem Thanks, Tom Cheers, --/Saleem Tom Finally, the 5G ship has already sailed. Many network are "launching 5G" this year, and more networks (including the one i work at ) are committed to launching "real 5G" in the next 2 to 3 years. None of the work in this group is within that 5G scope AFAIK. So, it may be most appropriate to carry on the effort at 6G to avoid folks getting confused. I still hold out hope for ILNP to replace the mobility core at some future date, the radio network just does a simple authentication and that is all. But, that is my own dream of a simpler world :) I would suggest the standard we look for in this group is: what can we remove from 3GPP 5G / 6G, not what we can add. How does the work in this group reduce NET signalling and user-plane modification from the 3GPP steady state? How is that quantified? CB On Tue, May 23, 2017 at 2:53 AM, <Dirk.von-Hugo@telekom.de<mailto:Dirk.von-Hugo@telekom.de>> wrote: Dear all, We have updated the PS draft on 5G IP issues regarding the planned BoF in Prague. Please check whether we have addressed the comments correctly and continue to discuss this towards further improvement. Thanks a lot – also on behalf of Roland, SungHoon, and Behcet Best Regards Dirk ---------- Forwarded message ---------- From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> Date: Mon, May 22, 2017 at 1:22 PM Subject: New Version Notification for draft-xyx-5gip-ps-01.txt To: Behcet Sarikaya <sarikaya@ieee.org<mailto:sarikaya@ieee.org>>, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>>, Roland Schott <roland.schott@telekom.de<mailto:roland.schott@telekom.de>>, SungHoon Seo <sh.seo@kt.com<mailto:sh.seo@kt.com>>, Roland Schott <Roland.Schott@telekom.de<mailto:Roland.Schott@telekom.de>>, Dirk von Hugo <dirk.von-hugo@telekom.de<mailto:dirk.von-hugo@telekom.de>>, Satish Kanugovi <satish.k@nokia.com<mailto:satish.k@nokia.com>> A new version of I-D, draft-xyx-5gip-ps-01.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-xyx-5gip-ps Revision: 01 Title: 5G IP Access and Session Management Protocols Document date: 2017-05-22 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-xyx-5gip-ps-01.txt Status: https://datatracker.ietf.org/doc/draft-xyx-5gip-ps/ Htmlized: https://tools.ietf.org/html/draft-xyx-5gip-ps-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-xyx-5gip-ps-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-xyx-5gip-ps-01 Abstract: This document builds upon 5G IP issues work and - based on a simplified 5G system architecture - attempts to make the case for a possible set of new protocols that need to be developed to be used among various virtualized functions in a 5G network. 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. The IETF Secretariat _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://www.ietf.org/mailman/listinfo/5gangip _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://www.ietf.org/mailman/listinfo/5gangip _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://www.ietf.org/mailman/listinfo/5gangip
- [5gangip] FW: New Version Notification for draft-… Dirk.von-Hugo
- Re: [5gangip] FW: New Version Notification for dr… Ca By
- Re: [5gangip] FW: New Version Notification for dr… d.lake
- Re: [5gangip] FW: New Version Notification for dr… Behcet Sarikaya
- Re: [5gangip] FW: New Version Notification for dr… Ca By
- Re: [5gangip] FW: New Version Notification for dr… d.lake
- Re: [5gangip] FW: New Version Notification for dr… Behcet Sarikaya
- Re: [5gangip] FW: New Version Notification for dr… Tom Herbert
- Re: [5gangip] FW: New Version Notification for dr… Behcet Sarikaya
- Re: [5gangip] FW: New Version Notification for dr… Dirk.von-Hugo
- Re: [5gangip] FW: New Version Notification for dr… Ca By
- Re: [5gangip] FW: New Version Notification for dr… d.lake
- Re: [5gangip] FW: New Version Notification for dr… Tom Herbert
- Re: [5gangip] FW: New Version Notification for dr… Lorenzo Colitti
- Re: [5gangip] New Version Notification for draft-… Saleem Bhatti
- Re: [5gangip] New Version Notification for draft-… Tom Herbert
- Re: [5gangip] New Version Notification for draft-… Saleem Bhatti
- Re: [5gangip] New Version Notification for draft-… Uma Chunduri
- Re: [5gangip] New Version Notification for draft-… Tom Herbert
- Re: [5gangip] New Version Notification for draft-… Saleem Bhatti
- Re: [5gangip] New Version Notification for draft-… Tom Herbert
- Re: [5gangip] New Version Notification for draft-… Ca By
- Re: [5gangip] New Version Notification for draft-… Tom Herbert
- Re: [5gangip] New Version Notification for draft-… Dino Farinacci
- Re: [5gangip] FW: New Version Notification for dr… Behcet Sarikaya