From nobody Fri Jun 1 14:28:56 2018 Return-Path: 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 44C3012E048; Fri, 1 Jun 2018 14:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 6S32b5UEhc7O; Fri, 1 Jun 2018 14:28:46 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B7012E041; Fri, 1 Jun 2018 14:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1879; q=dns/txt; s=iport; t=1527888526; x=1529098126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wXX+ZOvp7OKtPT9OGIufWahCItGy3OdRP415V+8/UJI=; b=iLZC2qmZZkAIMQv9u5zAlARJr/OW7pa7YbzbilICSHal+wRdHhUkSGOM pArE+uMqJF11DoKwcNVcopThFz/1wwOIBMakp7Xs40F8su/Nw3yu3Bq9C jjg5kda85hTVlTEE+KvBbbYZASy4tqhTC7RV0zIdDzhhL1rHY+9KTRd31 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAADFuRFb/4kNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDgWEoCotxjGeWRYF4C4RsAoIFITQYAQIBAQEBAQECbCi?= =?us-ascii?q?FKQY6PxACAQg2EDIlAgQBDQUUB4UIqReIP4FoiD+BVD+BD4MNikcCkSWHRwk?= =?us-ascii?q?Cjl+BPIN3h2KQcgIREwGBJB04gVJwFYJ+kE5vjk+BGQEB?= X-IronPort-AV: E=Sophos;i="5.49,467,1520899200"; d="scan'208";a="123711751" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2018 21:28:45 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w51LSjdx026410 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2018 21:28:45 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 1 Jun 2018 16:28:45 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Fri, 1 Jun 2018 16:28:45 -0500 From: "Sri Gundavelli (sgundave)" To: Brian Haberman , "int-dir@ietf.org" CC: "draft-ietf-dmm-ondemand-mobility.all@ietf.org" , "dmm@ietf.org" Thread-Topic: Intdir early review of draft-ietf-dmm-ondemand-mobility-14 Thread-Index: AQHT+e+FlMk3qYXxA0GWCoQahMW9ew== Date: Fri, 1 Jun 2018 21:28:45 +0000 Message-ID: References: <152691268188.22908.6810216714051964245@ietfa.amsl.com> In-Reply-To: <152691268188.22908.6810216714051964245@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: text/plain; charset="us-ascii" Content-ID: <846647D9668B534298FFE284FA4E6E63@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Intdir early review of draft-ietf-dmm-ondemand-mobility-14 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 21:28:55 -0000 Hi Brian, Thanks for the review. Authors:=20 Can you please respond to these review comments and address all the issues? Unless you address all the issues from these IESG initiated reviews, this document is not going any where. Sri On 5/21/18, 7:24 AM, "Brian Haberman" wrote: >Reviewer: Brian Haberman >Review result: Not Ready > >This is an early review request for draft-ietf-dmm-ondemand-mobility. > >I am having a hard time with the thrust of this document. The following >issues >really need to be addressed in some form... > >1. Where is the concept of an IP session defined? Given that IP is >connectionless, this term is really about IP address stability and its >lifetime. A new term could/should be coined to reflect what is really >needed. > >2. The needs described in this document have a mix of the ID/Location >split >issues raised in a variety of other specifications. It would be good to >clarify >what is different here. > >3. The draft only references host-based Mobile IP specifications. What >are the >implications when other solutions (e.g., PMIP) are employed? > >4. It is problematic that this document explicitly rules out of scope any >discussion of how this API interacts with address assignment methods >(e.g., >DHCP). Clearly, there will need to be a way for this API to influence >each of >the address assignment methods available. Some of the classes of IP >addresses >described in this document require certain lifetime guarantees from the >address >assignment method. That needs to addressed since it will require changes >to >every assignment method. > >5. The IETF has a very checkered history of success in getting APIs >standardized within the appropriate group (POSIX/Austin/Open). Has this >proposed API been discussed within that community? From nobody Tue Jun 5 23:57:21 2018 Return-Path: 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 500E7130EBA; Tue, 5 Jun 2018 23:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 wMRfcfDEzmsA; Tue, 5 Jun 2018 23:57:14 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40EF130EB7; Tue, 5 Jun 2018 23:57:11 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id i5-v6so3190489plt.2; Tue, 05 Jun 2018 23:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:cc:to :message-id; bh=u4ncOb9dCJt9L8jgaIuyfVTMXbvaZ2whjF77Dp6H2no=; b=gDoDu2Abx5YGnbJmZeLNpgRIl1p+N67vofDO+ZL5YpHSnQESLgEiKMGTQUiEoGyCSg Vq6PuLSQ1z4jqHAeW0KhER9p+O3sxHtqiJHRva84w9CK62195ld0bWm00ZIWg/EbPRVz HArFjfGW2/GmJU4S5h9ORnBWkRfd2eY5ZBexWz88ih13E39tjjNQzz2CTfa3GrdrigrW A+FNEQMomuFVLiBC8vTMX8oVEQowZQ0mrZdqD+/rkeUkJZSuXhTHfFOhBHrqizjWzm9h io2ziuie5MSbOnDlj6LYayZq/aPc/TPHyo5k+MVSAXZZH6RbCQaP9YvcBMMSQ6P5iwqW BikQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:cc:to:message-id; bh=u4ncOb9dCJt9L8jgaIuyfVTMXbvaZ2whjF77Dp6H2no=; b=rvuyJIQl/JjVSs3MkHQNyjRGc9JswS754fJZU/lTaH/edMSELdlGfFVxJAzczeju3O mKQOknm7gNtPan+rAWoKLTsB/yhkQXjelCGTwK9SJX+bBy4WqOjMQaltVYlbz/dZKQ3R TvRNfkQyhw4TMU+2g9OqaRUkEFeyAMhGO4vYcwOeMVP6lkFcTv53Rgr/49WVqGcSUFnc W2DfB3Zfaei8yQI+Qq4F13FjxxEna07gWgVyohW/xg99cphjLcNuO9kF/eWHLMa85ftt fnI8aSgovYkYraKqWXyXhv//gIo/4W5qiD2Pk0gQVF2s5d0cOkvAgMHR74DgEffs9Yeg HCqQ== X-Gm-Message-State: APt69E1Kh7qeKYtJKVVMrTwggUu/uYtggUlPTCfmDLIFAXzaIU/EDAh7 75vsR5GvrVEiK00b72oAWXwW+hk0 X-Google-Smtp-Source: ADUXVKK8rst3jv9hBzBKaSjxVVbYSSwVlBVmuNuyrZ4e/r+6i/xMc7DNDg11phTRPz7/j7zLi1facA== X-Received: by 2002:a17:902:bd04:: with SMTP id p4-v6mr2051051pls.180.1528268230946; Tue, 05 Jun 2018 23:57:10 -0700 (PDT) Received: from [10.217.59.188] ([202.45.12.165]) by smtp.gmail.com with ESMTPSA id e16-v6sm11186782pff.185.2018.06.05.23.57.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jun 2018 23:57:09 -0700 (PDT) From: Satoru Matsushima Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 6 Jun 2018 15:57:06 +0900 Cc: draft-bogineni-dmm-optimized-mobile-user-plane@ietf.org To: dmm Message-Id: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [DMM] Overall review on "draft-bogineni-dmm-optimized-mobile-user-plane-00" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 06:57:19 -0000 Dear Kalyani, and the draft authors, Thank you so much for working on this I-D which brings much information = regarding user plane protocols in IETF. It looks very promising work on = IETF side corresponding to the user plane protocol study work (FS_UPPS) = in 3GPP CT4. Since I=E2=80=99m in the loop in the offline discussion of updating the = draft, let me leave to bring detail comments on this version but instead = here I=E2=80=99d bring following my overall comments on the draft as the = rapporteur of FS_UPPS on 3GPP side. 1. Clarification on the TR/TSes As the LS(*) pointed the User Plane protocol and several User Plane = related specs in 3GPP, clarifying those specs in terms of user plane are = highly appreciated. As I presented in London(**), the approach for this = study in CT4 will be investigation and comparison for the candidates = protocols including existing protocol that needs criteria to do that. = Clarifying 5G specs in terms of user plane based on IETF expert=E2=80=99s = analysis would be very helpful to figure out that criteria. In CT4 side, we don=E2=80=99t have prefer logistic for the outcome of = the clarification. The I-D has just a section of overview of 5G system = but it looks quite a document already so that another concise clarify = focused document in Internet Draft style sounds make sense to me.=20 2. Contents organization The I-D contains SRv6, LISP and ILA as the candidate user plane = protocols. Those protocols seem to have each characteristics and certain = level of impacts to the 3GPP 5G architecture. However it was difficult = to find those features and impacts when I went thorough the draft. = Though the LS asks DMM to provide any information regarding User Plane = protocol, it would be nice at least if you can provide over-the-wire = packet format, for instance, with the features of each protocol. And it = would be followed by expected impacts to the 3GPP control plane of each = candidates, as I said in London. In addition to that, distinguishably = describing more impacts to the architecture beyond Release 15 would be = much helpful to clearly understand on what those candidates require the = architecture to be changed, as INT AD, Suresh, stated in London if I = recall correctly. It would be also highly appreciated if those can be = found out at a glance from the draft. That make us easy to digest it. Please note that it does not mean the candidates need to be in = apple-to-apple evaluation. It just needs the clear differences between = the candidates to be highlighted in terms of user plane, control plane = and architectural impact. 3. Use of term =E2=80=98Optimization' The word =E2=80=9Coptimized=E2=80=9D in the draft title seems ambiguous = on that optimize for what. If you try to introduce how those candidates = optimize something, it would be better to make clear the target of the = optimization. But again the LS asks any information on user plane, the = I-D doesn=E2=80=99t necessarily describe it.=20 (*) https://datatracker.ietf.org/liaison/1572/ = (**)https://datatracker.ietf.org/meeting/101/materials/slides-101-dmm-stud= y-on-user-plane-protocol-at-3gpp-00 Hope that helps, and I=E2=80=99m happy to cooperate together on the user = plane study on both IETF/3GPP sides. Best regards, --satoru From nobody Wed Jun 6 02:10:44 2018 Return-Path: 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 8D4E0130ECF; Wed, 6 Jun 2018 02:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 wB2CcwXmI4Zw; Wed, 6 Jun 2018 02:10:34 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id D110B130E3F; Wed, 6 Jun 2018 02:10:33 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w569AWcX031706; Wed, 6 Jun 2018 18:10:32 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 0763BEA8B2D; Wed, 6 Jun 2018 18:10:32 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id E749AEA8B1C; Wed, 6 Jun 2018 18:10:31 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.28]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id E2B4140073D; Wed, 6 Jun 2018 18:10:31 +0900 (JST) References: From: Shunsuke Homma Message-ID: <896b1fc1-bd81-3417-d57e-d4193941c907@lab.ntt.co.jp> Date: Wed, 6 Jun 2018 18:10:07 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CC-Mail-RelayStamp: 1 To: Satoru Matsushima , dmm Cc: draft-bogineni-dmm-optimized-mobile-user-plane@ietf.org X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Overall review on "draft-bogineni-dmm-optimized-mobile-user-plane-00" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 09:10:42 -0000 Hi Satoru-san Your review seems very pertinent and informative for me. Actually, there are various proposals such as SRv6, LISP, ILA etc., and we need to prepare criteria for 3GPP-side to judge which technologies have worth to be used in 5GS. For providing such criteria, it would be required to analyze 5GS requirements and GTP-U specs (as the current user plane protocol) from neutral position. I assume the work is very important for both IETF and 3GPP, and I can cooperate on it. Best regards, Shunsuke On 2018/06/06 15:57, Satoru Matsushima wrote: > Dear Kalyani, and the draft authors, > > Thank you so much for working on this I-D which brings much information regarding user plane protocols in IETF. It looks very promising work on IETF side corresponding to the user plane protocol study work (FS_UPPS) in 3GPP CT4. > > Since I’m in the loop in the offline discussion of updating the draft, let me leave to bring detail comments on this version but instead here I’d bring following my overall comments on the draft as the rapporteur of FS_UPPS on 3GPP side. > > > 1. Clarification on the TR/TSes > > As the LS(*) pointed the User Plane protocol and several User Plane related specs in 3GPP, clarifying those specs in terms of user plane are highly appreciated. As I presented in London(**), the approach for this study in CT4 will be investigation and comparison for the candidates protocols including existing protocol that needs criteria to do that. Clarifying 5G specs in terms of user plane based on IETF expert’s analysis would be very helpful to figure out that criteria. > > In CT4 side, we don’t have prefer logistic for the outcome of the clarification. The I-D has just a section of overview of 5G system but it looks quite a document already so that another concise clarify focused document in Internet Draft style sounds make sense to me. > > > 2. Contents organization > > The I-D contains SRv6, LISP and ILA as the candidate user plane protocols. Those protocols seem to have each characteristics and certain level of impacts to the 3GPP 5G architecture. However it was difficult to find those features and impacts when I went thorough the draft. Though the LS asks DMM to provide any information regarding User Plane protocol, it would be nice at least if you can provide over-the-wire packet format, for instance, with the features of each protocol. And it would be followed by expected impacts to the 3GPP control plane of each candidates, as I said in London. In addition to that, distinguishably describing more impacts to the architecture beyond Release 15 would be much helpful to clearly understand on what those candidates require the architecture to be changed, as INT AD, Suresh, stated in London if I recall correctly. It would be also highly appreciated if those can be found out at a glance from the draft. That make us easy to digest it. > > Please note that it does not mean the candidates need to be in apple-to-apple evaluation. It just needs the clear differences between the candidates to be highlighted in terms of user plane, control plane and architectural impact. > > > 3. Use of term ‘Optimization' > > The word “optimized” in the draft title seems ambiguous on that optimize for what. If you try to introduce how those candidates optimize something, it would be better to make clear the target of the optimization. But again the LS asks any information on user plane, the I-D doesn’t necessarily describe it. > > (*) https://datatracker.ietf.org/liaison/1572/ > (**)https://datatracker.ietf.org/meeting/101/materials/slides-101-dmm-study-on-user-plane-protocol-at-3gpp-00 > > > Hope that helps, and I’m happy to cooperate together on the user plane study on both IETF/3GPP sides. > > Best regards, > --satoru > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service Systems Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Wed Jun 6 08:03:49 2018 Return-Path: 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 52FE8130F4C for ; Wed, 6 Jun 2018 08:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 nSr7rOQl3e_Z for ; Wed, 6 Jun 2018 08:03:42 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDCA130EC6 for ; Wed, 6 Jun 2018 08:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1874; q=dns/txt; s=iport; t=1528297422; x=1529507022; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ZbGOJ7yXKlymdlb6J3xqt47Xms/Xgpfd0/FJgMWHEks=; b=IO9E92fpOAvhZNrdTP+wgSzNNE84AE7dn2XJHKfaY6OqlMjNHmOG0bYV kUPj9j5gzlyjM5CJLKngyoA/KYTRuc4zEKD/t/EjiYaWBX41YEY900pSX uNFD2J8i6kru8YkgiAyXEu8mkAKr9IMM7ON1Jjd4LOgqJKYoezy5Z8V+N o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAAB+9hdb/4kNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYn8oCotyjGaBeZRSFIFkCyWERwKCMyE0GAECAQEBAQE?= =?us-ascii?q?BAmwcAQuFKAEBAQQdHTQXBAIBCBEEAQEfCQcyFAkIAgQTgySBfw+rHYM6gR6?= =?us-ascii?q?Da4FjBYhCgVQ/hBuBQYFQBBiBEwESAR+FVQKHKYUJjEQJAoVriHuBPYN4h22?= =?us-ascii?q?KAYcAAhETAYEkHThhcXAVO4JDgiyDUIpSbwEBjjCBH4EZAQE?= X-IronPort-AV: E=Sophos;i="5.49,483,1520899200"; d="scan'208";a="125437146" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2018 15:03:41 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w56F3frr026050 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jun 2018 15:03:41 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Jun 2018 10:03:40 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Wed, 6 Jun 2018 10:03:40 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: IETF102 - Call for agenda items Thread-Index: AQHT/aeNzZqIRJiMQk22nB4ko6aZLw== Date: Wed, 6 Jun 2018 15:03:40 +0000 Message-ID: References: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> In-Reply-To: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: text/plain; charset="us-ascii" Content-ID: <5DFA8D8154AD85489967D7F4BF0B4C28@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 15:03:46 -0000 Folks - Gentle reminder. Please send your requests for agenda slots for IETF 102. If you have already done so, you can ignore this. Please include the following information. --- Topic Name: Presenter Name: Time: Draft Reference: --- Sri > >-----Original Message----- >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >(sgundave) >Sent: Thursday, May 3, 2018 5:32 PM >To: dmm@ietf.org >Subject: [E] [DMM] IETF102 - Call for agenda items > >The DMM working group is planning to meet in IETF 102, week of 16th of >July, 2018 at Montreal. We currently have requested for one meeting, >which is a 2.5 hour slot. > >We realize in IETF101 we had many items with a fully packaged agenda, and >could not allocate enough time for any of the topics. For this meeting, >we want to avoid that problem by asking for an additional meeting slot, >but we want to be sure there are enough items for discussion before we >lock the resources. > >So, if you need a presentation slot, please send your request to the >chairs (as a response to this email) with the following information. We >still have time and so its not required that you need a published I-D, >but do let us know in the next few days if you are planning to make a >presentation.=20 > > > --- >>Topic Name: >>Presenter Name: >>Time: >>Draft Reference: (Optional) >>--- > >Regards >Dapeng & Sri >>> >> > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3DIdiS >ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=3D3YmCyVAoi= C_ >ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHrommWakT2klf1og05nny7we_JVQm8flSZ8Z= Z7 >ASgw&e=3D From nobody Wed Jun 6 08:05:28 2018 Return-Path: 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 F3880130F50 for ; Wed, 6 Jun 2018 08:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 vIxHwFCulRIp for ; Wed, 6 Jun 2018 08:05:20 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0090.outbound.protection.outlook.com [104.47.41.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625B6130F4C for ; Wed, 6 Jun 2018 08:05:20 -0700 (PDT) Received: from CO2PR05CA0088.namprd05.prod.outlook.com (2603:10b6:104:1::14) by SN1PR0501MB2111.namprd05.prod.outlook.com (2a01:111:e400:5965::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.6; Wed, 6 Jun 2018 15:05:18 +0000 Received: from SN1NAM01FT027.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::200) by CO2PR05CA0088.outlook.office365.com (2603:10b6:104:1::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.841.10 via Frontend Transport; Wed, 6 Jun 2018 15:05:18 +0000 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.81 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.81; helo=preapdm2.corp.sprint.com; Received: from preapdm2.corp.sprint.com (144.230.32.81) by SN1NAM01FT027.mail.protection.outlook.com (10.152.65.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.841.10 via Frontend Transport; Wed, 6 Jun 2018 15:05:18 +0000 Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id w56EJoPZ003339; Wed, 6 Jun 2018 11:05:17 -0400 Received: from plswe13m03.ad.sprint.com (plswe13m03.corp.sprint.com [144.229.214.22]) by preapdm2.corp.sprint.com with ESMTP id 2jbm9arbjc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Jun 2018 11:05:17 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m03.ad.sprint.com (2002:90e5:d616::90e5:d616) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 6 Jun 2018 10:05:16 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1365.000; Wed, 6 Jun 2018 10:05:16 -0500 From: "Bertz, Lyle T [CTO]" To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" Thread-Topic: IETF102 - Call for agenda items Thread-Index: AQHT4yYw0Rb3M63dqU2LakuH2Dl9gaRTiP2w Date: Wed, 6 Jun 2018 15:05:15 +0000 Message-ID: <22355cf7391e4a6b9bc7272a9b5b9ba0@plswe13m04.ad.sprint.com> References: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.81; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39380400002)(39860400002)(2980300002)(438002)(189003)(199004)(13464003)(575784001)(316002)(11346002)(426003)(6306002)(336012)(476003)(126002)(356003)(5660300001)(53936002)(966005)(478600001)(81156014)(446003)(45080400002)(81166006)(2906002)(8676002)(2900100001)(50466002)(486006)(6246003)(86362001)(46406003)(72206003)(47776003)(108616005)(24736004)(76176011)(7696005)(8746002)(6116002)(3846002)(106002)(23726003)(14454004)(5890100001)(106466001)(2501003)(8936002)(68736007)(7736002)(102836004)(97756001)(97736004)(6346003)(5250100002)(305945005)(59450400001)(26005)(229853002)(186003)(110136005)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2111; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT027; 1:XQ59OZnlnnqBiSTu7N96cMLlRPpJqKgtNbohQCeY8Vlx2vKg4QyxoarBYqEpldZojOc3SmKbw5eCPYl4nlmTmMMWH7sHxCEOUobJTGxUgE09XXtpJjcdR3ms+t2GbC0O X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4608076)(2017052603328)(7153060)(7193020); SRVR:SN1PR0501MB2111; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2111; 3:QlSktswmrVmSmHOrPGkvg4xBjhz2j5VlT4+oA8RL2FTOEniBlkqiOSGtXJY9D3yt8MNO0XLuXSx5B14nR+aO0wdb7ywYmnimVz5hCVZPHkd5rjRgceuRZfWk8n1k/pURvNfd6X5fUrXRkYwMgrehU3x2QvWKLAdpU8wPxSA2RBuCsFea9pAhsdEZIt8tAlVh0ISs2ocPfBdqaH8GFfWhfvDAtUveDH3PG7firITVK2Gajj9yib8B8L5sgWgmAi5ed0AI0E0oOxTJ6bznqJU6iUVcChV/5JEPadFlFpif3ow8s6nhoaFAiuL7RG9C3Tm4SNsel9eS2kV6XKvL7VqqnZ8bZkVLNwZFrm5k18j/FKg=; 25:lFZcDhyi9PFVqAQI5PVkzyMk1+HbBXizKf/4rYYvXBK0A+9Mwk4U6PSATOaKJaKciYsKo2qw091QKxxJmriFWMRvv6yCDjaLGEfXBVA1wjnxPKpJ3uXVKje1InX2zdc/s9HSnG/HE018VBWVybp1Y3Rvowkj+6ZPLynYiOLBNhik0SaDlg0KfbbBp1fHn2bAdnzFYTPMSuzyVKRvrHYI82laNDhfZ789Sm7PsKNYwZIq6Taw9Fb5+JeSe5bSYYGTfnKueRnRSPtzNJr8m4gvN0nl4wNX7vYHVVzzZK5kSHlqAXLs5I7ZMXeoTPDhgPiSt0j0FNnvucU+OkA96HHtGQ== X-MS-TrafficTypeDiagnostic: SN1PR0501MB2111: X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2111; 31:dLO5SF+aWrSeiXaKI+6WkTPPgOBPNtoPt/Pylya7vDkZTCABGE/tQkE1DhhmXxmaEgWspOMUYlMP5uPZsCIpQd1nYXvD24UzIlKkFafW/xYpewgdwhyYCV7cPMf5/vRfC/BGc6RV+wpF8Cygnea3HQI61JBfMHL2g85zay/SAHS23v93aPRdFig4xoVeU3ny2owNVayW4HCxNTV/XdvmNxZ8I3OnQ48v4B3Hr5lu5BI=; 20:/n/5QE5Lt/m9S8mkF3py+7A14BCNt6/iPeTsGPMGIo+O7j1s8HyhW7SR1GmpdvPIkQJHUND9rBkfL14u/TDCej1SvpdbxnvksPDcirzmimeAogEeO1iQqSShGdc9AmYFA5yoeBsQsJ3nU8tlRGla94Jg5pUkRvmkUXeE4NpZ3I/KxSMlASNIRVG91x7vPoG3MxMSDl5e6uQP3Xpd16GoNpSXafmtVHUAAyOAFpv6v8/ngEPwfMpz4HeFFGDBmb+SlHibILeCSg/dUXuNzTAEBxgCpjxtSQw/D5x5j/FYQrSeSOuK/S4+Zi2WnLhD20pSDlPkRQCO5++N76i0/jGepBa90Ew5FTI7d7LrDosI0vFTj/HigXGwO+xZrz+Ra9/NgU1B4e/cY/C6wEos2AO1nfx6+GU1H38ygBpu3a+Of3XXJPIz5NN5E8YDbf5CiSFpYYNHcjlOwWb/ZL9DlE59cqBd636XYMckubRdmt9beDeuVSRA3Jsks8IXqrt8qdtA X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(189930954265078)(219752817060721); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(10201501046)(93006095)(93004095)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:SN1PR0501MB2111; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2111; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2111; 4:6zx/xLfV+S9+9qlH725E5b1ETA7aEr5jQXQhJJiSmL55QSJGIgsYqHbAL8q/LpbWqdw3EoXbD95I/o4nwr/0sYQBXJyoA80dsmi5sdurdoYQxRFcrcyhN5uj0P0cGcO5pprwBBwyD/IT/QSIlWWNChbIaog0iuXIgbQRoRMpkCG2j/vDZNaF/dfckURBDuBz/eUm955irwyeG5rFQPwxq/+KxvNEPoP5xjGlsbm6zBH8AtnXbL91o0VwK/KSnFCLddFxYthYXpjhdkej4vzknZMnjBEiHO85423kuRLrK/W15vs/jPuTGfV2sXXYfm7QL/WpSA10/pIjQ0uiWwOjwqBhUYHZfxKpLHa5kwYM2ysmWNmVfzZWaj2f/hKhXpxt X-Forefront-PRVS: 06952FC175 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0501MB2111; 23:9OTkadwYcxky77oz59uyldqzWdO24RNlbXJ0AyC?= =?us-ascii?Q?7Jw18wGKEt9bdGl98uCUtHUMfWZeWyj8h/6O/YXEvJI1tZMHxTIHhmvstmiz?= =?us-ascii?Q?orQ2ZTumjFAIQbxjcUpTb1q3keLx0EYX1lTtwyxay47I5PiemnV4oGHfYtbZ?= =?us-ascii?Q?RBlIp6eo5o3aTio1hNgwFv+zvHYqsD6LdWcr6JxP7JrgoZvqaAA1VAaMOJh+?= =?us-ascii?Q?+ZjQl1/IvAjrGgV0XguIjoRaNCzJWiEIOlElatJUh92xEPyxMpXLAzpROlyY?= =?us-ascii?Q?fqRpTTz5gHAXhNQadOSafMJKtrjyfJ92WmappJaFfbkMavXnQy0YWJkdgG4N?= =?us-ascii?Q?VaKlk1+ltVFHvbkGU1omno2GcavrFg8q7k5nOdDZxjFNIJYJ+WwK+MKIHXyW?= =?us-ascii?Q?eqqTDr6znfKgit7XK26Fg/L3paH74+aOE5zAzv/DAH2uK69LM/JQ3AmLKIMi?= =?us-ascii?Q?4nT7MirD59x81YTZw6DnCJdxN+uHCp7JXTqayhRfk2hIdXk+jzrzzev00eXj?= =?us-ascii?Q?de0+QQmuLGagOHbY9y5OeRlPXWuDd04SpvHCM6sNLyPtzfTux02DKd7xK8gP?= =?us-ascii?Q?ZnW1Rs4THUBNuzXtROU3cOErnyut2j43NQ1bhmUft8mk7Q8eeQrEf8V4+qfz?= =?us-ascii?Q?9MWak/BIgPMF4WMIekxTXVLy1LVvjPqJxYIBAx1MWtgMKdrz7aRF3mCinSCy?= =?us-ascii?Q?1yudnlnQMITNFLJQVHGz5D3U6v/c5M2nx0GK30HTbx+ac+MgQWB3WIMDrn27?= =?us-ascii?Q?FZ48Ld+ci7Po8/wsw2oZBGJMpOtDGOojUVZw1kcMjED0G2ygzO/0/+7/zCgk?= =?us-ascii?Q?SlOhHoW7cFXG1JFng6PROhj5yTO+F2y38a7Ba6iaMfXlQl8WJC8DwPoN/Dbu?= =?us-ascii?Q?R7wvOg+jFNUcFGiVojMs6uiqrI0sojCUgJBJdYNbNCTunC6k4z+kbCoda+ab?= =?us-ascii?Q?+WmvC10CEBlr8qsaje8PL4Jjo5kUS4LpBtJ0mHL+4xwS34zjxiv8XeXgFR86?= =?us-ascii?Q?IJNi2iV7dQc17BBzfEcBsgwfdQDTBsgWQrRSxOSctGpYkdcWwgQl5vAPe8ks?= =?us-ascii?Q?g4fBop25dfg1/tNPlZnQX09d2jcEVyL8D666mkkpqIizCZwoUSPdEeDU7MWf?= =?us-ascii?Q?FlZxQhl0HO0xqMe1To4Mfeot3vY8EEP1zckRD/pp0BdlCF/NH1GL4GQjixO0?= =?us-ascii?Q?J9V4TcCAWC957yVsq0DAxZ/jSockPGp9tTFBNG80DTKTR+9LTFp9ls0vvmxi?= =?us-ascii?Q?L5FoHdzLi3hyPjjiuvIYklIJ7EjB9KGakknD99uDPYdGfVBckal7Oph0Kb9y?= =?us-ascii?Q?RNLCDtAxutpWKysvOqQyIwk58FIEtS1r3kucpt+wLj5VO0hPftzpMt0hKZAf?= =?us-ascii?Q?4A3B6p65GPEEp5PYvGm1S/TaGHKgD2Agccha7BKWXRWQSWnv3tr1MTNlGDwg?= =?us-ascii?Q?sws+Dwn7ZbrZXdEE2466p6wJg3Ec8KRo=3D?= X-Microsoft-Antispam-Message-Info: Jy67KMEsCSVs9Yzh65n8TVOJ8xfoerx3Wic78+Kkoed/ATJS0znw7gcVzItNBgFSqER+saVB/cnAg2elerOFWGHaDx+K9UJsgrnIUzOuC7yq5cca5toWerm4vl4kcBIOZ4PLjfVYV/KCJ3v7BNAZR/Yg4O5Xn83B67z+x7PUnfE/Fyqb929IzJjq0/WVxJGp X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2111; 6:0qJ5n4rctEv1uPumjh5HrMA4S2h6PVuJhQ0ko1qkBpf6bnxIjb44lEa2DHDLWa5vDeYGBeoRCnDVcKVR1fQ6cvqhBOP8twICj8zkefBwKRs/a9+qYD13NSUHGZt0DJqlz2fgjRwDoxhZvjixfGhOcdWLcbkuJTZdT28IqKmMRcXsac68c/EMIhzcTwwMNcdFIvY17FIKjIIwKpmNHejOo9cr2mFdePGU/cJP9zGSItEvjWkkgxrZakk0xGXeoh+nKZyOCvMtrytynGxHbGWcmIPuZ9aYYD3xjo3IIO8yuTdhVf418YDcKw+YOGp9E/JQvkZnGUDwrzNxnThSFJCq9ExS/5KFnSTnEYryqU972SCYV4hoteU9Tu53X19EI/rPCxETL+AZwOg/OVBMC/Q5Ncgixhq5RIFtG1R8GOtMR2S4b+RFitiDfPvC5mdX8Wa5WkFyIAgPyv+w4QBc5aJCEw==; 5:rDOyiBptMW8llbnsFtnUAsaNOFrC/ZdQjHFFIRLtD8eZWOsF+sM8l1T19fV77AyAXV0Gn4l67OlyE5UcK5woKKkYmZqMNnze6Uo7cL3GvFIkURtE95m02jeK6xiWD4GXXnAYQRxCkTWHDxTiTobCTFnTmeHiV3lTY1XCNlrqJoo=; 24:vLdp5AvEMIEJm7ht56ZhVY1IGFDnSUQFnm1LcwME5Phspyx3p974LJaXRcd2T3obEI0LL7WJGd7Yso7MAM8ovfmKn7X4VcqZKnKo4hPhfrM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2111; 7:31ck8m3rdws/K3eaHY5oZoOeSVw0qEA5nAirXlhaugKdgviZVw9PGrvKzjA4d1Tr2uOYhWN2ZEMhqR3amFa81ddpAWZEIlvDpr2JsR3gS7payT1f3noysvKTYAbfH2TQXL8uDn41udxo3mGHfukV0GwmQY3CLi/viM7ufQnudjhOWTkKqiRHkDId0JsDws9v5zOekPuImbzSMjgMiUTJQt4f5LfxfZakMbc/byXbdK3f2tzO4g1q36SbXX2+WT2r X-MS-Office365-Filtering-Correlation-Id: 31453410-2e21-41d8-af38-08d5cbbeea95 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2018 15:05:18.0664 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 31453410-2e21-41d8-af38-08d5cbbeea95 X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.81]; Helo=[preapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2111 Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 15:05:26 -0000 Topic Name: FPC version 11 Presenter Name: Lyle Bertz Time: 20 minutes Draft Reference: https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp= / > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli > (sgundave) > Sent: Wednesday, June 06, 2018 10:04 AM > To: dmm@ietf.org > Subject: Re: [DMM] IETF102 - Call for agenda items > > CAUTION: This email originated from outside of the organization. Do not c= lick > links or open attachments unless you recognize the sender and know the > content is safe. > > > Folks - Gentle reminder. Please send your requests for agenda slots for I= ETF > 102. If you have already done so, you can ignore this. Please include the > following information. > > > --- > Topic Name: > Presenter Name: > Time: > Draft Reference: > --- > > > > > Sri > > > > > > > >-----Original Message----- > >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli > >(sgundave) > >Sent: Thursday, May 3, 2018 5:32 PM > >To: dmm@ietf.org > >Subject: [E] [DMM] IETF102 - Call for agenda items > > > >The DMM working group is planning to meet in IETF 102, week of 16th of > >July, 2018 at Montreal. We currently have requested for one meeting, > >which is a 2.5 hour slot. > > > >We realize in IETF101 we had many items with a fully packaged agenda, > >and could not allocate enough time for any of the topics. For this > >meeting, we want to avoid that problem by asking for an additional > >meeting slot, but we want to be sure there are enough items for > >discussion before we lock the resources. > > > >So, if you need a presentation slot, please send your request to the > >chairs (as a response to this email) with the following information. We > >still have time and so its not required that you need a published I-D, > >but do let us know in the next few days if you are planning to make a > >presentation. > > > > > > --- > >>Topic Name: > >>Presenter Name: > >>Time: > >>Draft Reference: (Optional) > >>--- > > > >Regards > >Dapeng & Sri > >>> > >> > > > >_______________________________________________ > >dmm mailing list > >dmm@ietf.org > >https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Furlde > f > >ense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps- > 3A__www.ietf.org_mailman_&da > >ta=3D02%7C01%7Clyle.t.bertz%40sprint.com%7C12717d090f9d42469d3a08d5c > bbeb8 > >d7%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636638942384495 > 683&sdat > >a=3D40HhM9rdP%2B92GxZ79%2BLWFUwuLirD828Yjnl0fI426So%3D&reserved > =3D0 > >listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0 > PomBTQ&r=3DI > >diS > >ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT& > m=3D3YmCyVAo > >iC_ > >ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHrommWakT2klf1og05nny7we > _JVQm8flSZ8 > >ZZ7 > >ASgw&e=3D > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fdmm&data=3D02%7C01%7Clyle.t.bertz%40s > print.com%7C12717d090f9d42469d3a08d5cbbeb8d7%7C4f8bc0acbd784bf5b5 > 5f1b31301d9adf%7C0%7C1%7C636638942384495683&sdata=3DkqJ%2BbCIkP7F > UwfS2bov5TmJm98geX5TeYJSLRneD%2B3k%3D&reserved=3D0 ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Jun 6 12:51:28 2018 Return-Path: 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 8A751130FB7 for ; Wed, 6 Jun 2018 12:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable 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 7kXk_SkzeqgN for ; Wed, 6 Jun 2018 12:51:18 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 02ECF130DCB for ; Wed, 6 Jun 2018 12:51:17 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2018 12:51:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.49,484,1520924400"; d="scan'208,217"; a="60982624" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga004.fm.intel.com with ESMTP; 06 Jun 2018 12:51:16 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 6 Jun 2018 12:51:16 -0700 Received: from hasmsx107.ger.corp.intel.com (10.184.198.27) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 6 Jun 2018 12:51:16 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.43]) by hasmsx107.ger.corp.intel.com ([169.254.2.79]) with mapi id 14.03.0319.002; Wed, 6 Jun 2018 22:51:13 +0300 From: "Moses, Danny" To: "Sri Gundavelli (sgundave)" CC: "dmm@ietf.org" Thread-Topic: IETF102 - Call for agenda items Thread-Index: AQHT4yYw0Rb3M63dqU2LakuH2Dl9gaQeteiAgDSgnACAAH70IA== Date: Wed, 6 Jun 2018 19:51:12 +0000 Message-ID: References: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGNiNDA2MmUtZTdhNS00YjU1LWJmNjAtZjU2OGQyZWIzN2UxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTFhRZlhKWVNCcnc5aG5Nam1MdDhrTit6SXpJb3YyM3grSEdOam00U1wvZmRIU2JnRmtDNzl5amxHVXZCd2tHV1gifQ== dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.249.87.134] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC281401479C9HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 19:51:24 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC281401479C9HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, Please assign a slot for the following: Topic name: Response to early review of draft-ietf-dmm-ondemand-mobility-14 Presenter: Danny Moses Time: 15 minutes Draft Reference: draft-ietf-dmm-ondemand-mobility-14 Thanks, Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Wednesday, June 06, 2018 18:04 To: dmm@ietf.org Subject: Re: [DMM] IETF102 - Call for agenda items Folks - Gentle reminder. Please send your requests for agenda slots for IET= F 102. If you have already done so, you can ignore this. Please include the= following information. --- Topic Name: Presenter Name: Time: Draft Reference: --- Sri > >-----Original Message----- >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >(sgundave) >Sent: Thursday, May 3, 2018 5:32 PM >To: dmm@ietf.org >Subject: [E] [DMM] IETF102 - Call for agenda items > >The DMM working group is planning to meet in IETF 102, week of 16th of >July, 2018 at Montreal. We currently have requested for one meeting, >which is a 2.5 hour slot. > >We realize in IETF101 we had many items with a fully packaged agenda, >and could not allocate enough time for any of the topics. For this >meeting, we want to avoid that problem by asking for an additional >meeting slot, but we want to be sure there are enough items for >discussion before we lock the resources. > >So, if you need a presentation slot, please send your request to the >chairs (as a response to this email) with the following information. We >still have time and so its not required that you need a published I-D, >but do let us know in the next few days if you are planning to make a >presentation. > > > --- >>Topic Name: >>Presenter Name: >>Time: >>Draft Reference: (Optional) >>--- > >Regards >Dapeng & Sri >>> >> > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_ >listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3DI >diS >ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=3D3YmCyVAo >iC_ >ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHrommWakT2klf1og05nny7we_JVQm8flSZ8 >ZZ7 >ASgw&e=3D _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC281401479C9HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi,

 

Please assign a slot for the following:

 

Topic name: Response to early review of draft-iet= f-dmm-ondemand-mobility-14

Presenter: Danny Moses

Time: 15 minutes

Draft Reference: draft-ietf-dmm-ondemand-mobility= -14

 

Thanks,

Danny

 =

-----Original= Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve)
Sent: Wednesday, June 06, 2018 18:04
To: dmm@ietf.org
Subject: Re: [DMM] IETF102 - Call for agenda items

 

Folks - Gentle reminder. Please send your request= s for agenda slots for IETF 102. If you have already done so, you can ignor= e this. Please include the following information.

 

 

  ---

  Topic Name:

  Presenter Name:

  Time:

  Draft Reference:

---

 

 

 

 

Sri

 

 

 

 

> 

>-----Original Message-----

>From: dmm [mailto:dmm-boun= ces@ietf.org] On Behalf Of Sri Gundavelli

>(sgundave)

>Sent: Thursday, May 3, 2018 5:32 PM

>To: dmm@ietf.org

>Subject: [E] [DMM] IETF102 - Call for agenda = items

> 

>The DMM working group is planning to meet in = IETF 102, week of 16th of

>July, 2018 at Montreal. We currently have req= uested for one meeting,

>which is a 2.5 hour slot.

> 

>We realize in IETF101 we had many items with = a fully packaged agenda,

>and could not allocate enough time for any of= the topics. For this

>meeting, we want to avoid that problem by ask= ing for an additional

>meeting slot, but we want to be sure there ar= e enough items for

>discussion before we lock the resources.=

> 

>So, if you need a presentation slot, please s= end your request to the

>chairs (as a response to this email) with the= following information. We

>still have time and so its not required that = you need a published I-D,

>but do let us know in the next few days if yo= u are planning to make a

>presentation.

> 

> 

>  ---

>>Topic Name:

>>Presenter Name:

>>Time:

>>Draft Reference: (Optional)

>>---

> 

>Regards

>Dapeng & Sri

>>> 

>> 

> 

>_____________________________________________= __

>dmm mailing list

>dmm@ietf.org

>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_mailm

>an_

>listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvX= C5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DI

>diS

>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilz= aXYRYETcBynUdpT&m=3D3YmCyVAo

>iC_

>ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHro= mmWakT2klf1og05nny7we_JVQm8flSZ8

>ZZ7

>ASgw&e=3D

 

_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf= .org/mailman/listinfo/dmm

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC281401479C9HASMSX106gercor_-- From nobody Wed Jun 6 12:56:36 2018 Return-Path: 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 28433130DC6 for ; Wed, 6 Jun 2018 12:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 psRp9eBRGwPB for ; Wed, 6 Jun 2018 12:56:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7D1130DC1 for ; Wed, 6 Jun 2018 12:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15784; q=dns/txt; s=iport; t=1528314983; x=1529524583; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gYyB4NGFbMR6tUi6xzllbh8uE7NAWygy3Lv+ukKfkao=; b=euOFVSqR/ympmPp+WKpsCzJvy99jaiHNTcZDA/+QM0Ex9wBFwfKqmu46 BPCdZcVwophFPip0dHc4DGm73PZf4SKIQZIUdDV/zhz8Eej8gFeW6fOry De9SjgvTiLMzW3cAwlmwhm8oPgbDKt4C+I7vFRkywAY+ZkwM/odIKhhBL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAABpOxhb/5NdJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJOdWJ/KAqLcoxmgXmPWoR4FIFkCxgBCoRJAoI1ITQYAQI?= =?us-ascii?q?BAQEBAQECbBwMhSgBAQEEAQEbEEELDAQCAQgRAwEBASgHJwsUCQgCBA4FgyS?= =?us-ascii?q?BG2QPq3uEWINsgWMFhz2BBYFUPyVqgjxQgUGBUAEBAhiBEwESAT+FNQKHKQg?= =?us-ascii?q?Za4N9DCuMDQkChWuIe4E9g3iHbYoBhwACERMBgSQdOCY7cXAVO4JDCYFnPIN?= =?us-ascii?q?QhRSFPm8BAY4xgR+BGQEB?= X-IronPort-AV: E=Sophos;i="5.49,484,1520899200"; d="scan'208,217";a="396275593" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2018 19:56:22 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w56JuMrp016199 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jun 2018 19:56:22 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Jun 2018 14:56:21 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Wed, 6 Jun 2018 14:56:21 -0500 From: "Sri Gundavelli (sgundave)" To: "Moses, Danny" CC: "dmm@ietf.org" Thread-Topic: IETF102 - Call for agenda items Thread-Index: AQHT/dBxEWYhPPxgKEOlSXkEzlaKOg== Date: Wed, 6 Jun 2018 19:56:21 +0000 Message-ID: References: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: multipart/alternative; boundary="_000_D73D898A2BA4F7sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 19:56:31 -0000 --_000_D73D898A2BA4F7sgundaveciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Danny - Unless you are not able to resolve the comments that you have recei= ved from IESG, or if the WG disagrees with your resolutions, we may not nee= d this slot. I have not seen any responses from you guys yet for the revie= w comments. I suggest you guys propose your text to the WG/reviewer on how = you plan to resolve those comments, and lets decide if we need WG feedback.= For now, I am putting this request on hold. Sri From: "Moses, Danny" > Date: Wednesday, June 6, 2018 at 12:51 PM To: Sri Gundavelli > Cc: "dmm@ietf.org" > Subject: RE: IETF102 - Call for agenda items Hi, Please assign a slot for the following: Topic name: Response to early review of draft-ietf-dmm-ondemand-mobility-14 Presenter: Danny Moses Time: 15 minutes Draft Reference: draft-ietf-dmm-ondemand-mobility-14 Thanks, Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Wednesday, June 06, 2018 18:04 To: dmm@ietf.org Subject: Re: [DMM] IETF102 - Call for agenda items Folks - Gentle reminder. Please send your requests for agenda slots for IET= F 102. If you have already done so, you can ignore this. Please include the= following information. --- Topic Name: Presenter Name: Time: Draft Reference: --- Sri > >-----Original Message----- >From: dmm [mailto:dmm-bounces@ietf.org] On B= ehalf Of Sri Gundavelli >(sgundave) >Sent: Thursday, May 3, 2018 5:32 PM >To: dmm@ietf.org >Subject: [E] [DMM] IETF102 - Call for agenda items > >The DMM working group is planning to meet in IETF 102, week of 16th of >July, 2018 at Montreal. We currently have requested for one meeting, >which is a 2.5 hour slot. > >We realize in IETF101 we had many items with a fully packaged agenda, >and could not allocate enough time for any of the topics. For this >meeting, we want to avoid that problem by asking for an additional >meeting slot, but we want to be sure there are enough items for >discussion before we lock the resources. > >So, if you need a presentation slot, please send your request to the >chairs (as a response to this email) with the following information. We >still have time and so its not required that you need a published I-D, >but do let us know in the next few days if you are planning to make a >presentation. > > > --- >>Topic Name: >>Presenter Name: >>Time: >>Draft Reference: (Optional) >>--- > >Regards >Dapeng & Sri >>> >> > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_ >listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3DI >diS >ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=3D3YmCyVAo >iC_ >ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHrommWakT2klf1og05nny7we_JVQm8flSZ8 >ZZ7 >ASgw&e=3D _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf..org/mailman/listinfo/dmm --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_D73D898A2BA4F7sgundaveciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9666A8CC510BA34B95B25A40096761AC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Danny – Unless you are not able to resolve the comments that you= have received from IESG, or if the WG disagrees with your resolutions, we = may not need this slot.  I have not seen any responses from you guys y= et for the review comments. I suggest you guys propose your text to the WG/reviewer on how you plan to resolve those comm= ents, and lets decide if we need WG feedback. For now, I am putting this re= quest on hold.


Sri



From: "Moses, Danny" <= danny.moses@intel.com>
Date: Wednesday, June 6, 2018 at 12= :51 PM
To: Sri Gundavelli <sgundave@cisco.com>
Cc: "dmm@ietf.org" <dmm@ietf.= org>
Subject: RE: IETF102 - Call for age= nda items

Hi,

 

Please assign a slot for the following:

 

Topic name: Response to early review of draft-iet= f-dmm-ondemand-mobility-14

Presenter: Danny Moses

Time: 15 minutes

Draft Reference: draft-ietf-dmm-ondemand-mobility= -14

 

Thanks,

Danny

 =

-----Original= Message-----
From: dmm [mailto:dmm-bounces@ietf.= org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, June 06, 2018 18:04
To: dmm@ietf.org
Subject: Re: [DMM] IETF102 - Call for agenda items

 

Folks - Gentle reminder. Please send your request= s for agenda slots for IETF 102. If you have already done so, you can ignor= e this. Please include the following information.

 

 

  ---

  Topic Name:

  Presenter Name:

  Time:

  Draft Reference:

---

 

 

 

 

Sri

 

 

 

 

> 

>-----Original Message-----

>From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of Sri Gundavelli

>(sgundave)

>Sent: Thursday, May 3, 2018 5:32 PM

>To: dmm@ietf.org

>Subject: [E] [DMM] IETF102 - Call for agenda = items

> 

>The DMM working group is planning to meet in = IETF 102, week of 16th of

>July, 2018 at Montreal. We currently have req= uested for one meeting,

>which is a 2.5 hour slot.

> 

>We realize in IETF101 we had many items with = a fully packaged agenda,

>and could not allocate enough time for any of= the topics. For this

>meeting, we want to avoid that problem by ask= ing for an additional

>meeting slot, but we want to be sure there ar= e enough items for

>discussion before we lock the resources.=

> 

>So, if you need a presentation slot, please s= end your request to the

>chairs (as a response to this email) with the= following information. We

>still have time and so its not required that = you need a published I-D,

>but do let us know in the next few days if yo= u are planning to make a

>presentation.

> 

> 

>  ---

>>Topic Name:

>>Presenter Name:

>>Time:

>>Draft Reference: (Optional)

>>---

> 

>Regards

>Dapeng & Sri

>>> 

>> 

> 

>_____________________________________________= __

>dmm mailing list

>dmm@ietf.org

>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_mailm

>an_

>listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvX= C5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DI

>diS

>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilz= aXYRYETcBynUdpT&m=3D3YmCyVAo

>iC_

>ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHro= mmWakT2klf1og05nny7we_JVQm8flSZ8

>ZZ7

>ASgw&e=3D

 

_______________________________________________

dmm mailing list

dmm@ietf.org

https://www.ietf= ..org/mailman/listinfo/dmm

--------------------------------------------------------------------- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

 --_000_D73D898A2BA4F7sgundaveciscocom_-- From nobody Wed Jun 6 13:03:09 2018 Return-Path: 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 48DBF1292F1 for ; Wed, 6 Jun 2018 13:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 3Fmsr_I6l4wJ for ; Wed, 6 Jun 2018 13:03:02 -0700 (PDT) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (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 261F91292AD for ; Wed, 6 Jun 2018 13:03:02 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2018 13:03:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.49,484,1520924400"; d="scan'208,217"; a="55302041" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by FMSMGA003.fm.intel.com with ESMTP; 06 Jun 2018 13:03:01 -0700 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 6 Jun 2018 13:03:01 -0700 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 6 Jun 2018 13:03:00 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.43]) by HASMSX110.ger.corp.intel.com ([169.254.6.122]) with mapi id 14.03.0319.002; Wed, 6 Jun 2018 23:02:58 +0300 From: "Moses, Danny" To: "Sri Gundavelli (sgundave)" CC: "dmm@ietf.org" Thread-Topic: IETF102 - Call for agenda items Thread-Index: AQHT4yYw0Rb3M63dqU2LakuH2Dl9gaQeteiAgDSgnACAAH70IP//0tKAgAAymHA= Date: Wed, 6 Jun 2018 20:02:57 +0000 Message-ID: References: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDRlYzY5YzMtMmJmNi00ZDk1LWE0ZTYtNDU2ZGRiNjUwN2FmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNGNjWWw4VzB6Y1V1XC9Pc2VFcmRHTHZDa1Q2Nmh2ckV2a1M2b1ZVUXk4SE5rRnhMbzJPXC92R0Ywd0k4Rk1BeG01In0= dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.249.87.134] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28140147A0DHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 20:03:07 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28140147A0DHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I agree that if we manage to resolve the comments prior to the meeting, the= slot is not required. However, I am not optimistic and believe that we most like will need the sl= ot. So I propose to reserve the time for this topic. I will post responses before the end of this week so the WG can review and = provide feedback. Thanks, Danny From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, June 06, 2018 22:56 To: Moses, Danny Cc: dmm@ietf.org Subject: Re: IETF102 - Call for agenda items Danny - Unless you are not able to resolve the comments that you have recei= ved from IESG, or if the WG disagrees with your resolutions, we may not nee= d this slot. I have not seen any responses from you guys yet for the revie= w comments. I suggest you guys propose your text to the WG/reviewer on how = you plan to resolve those comments, and lets decide if we need WG feedback.= For now, I am putting this request on hold. Sri From: "Moses, Danny" > Date: Wednesday, June 6, 2018 at 12:51 PM To: Sri Gundavelli > Cc: "dmm@ietf.org" > Subject: RE: IETF102 - Call for agenda items Hi, Please assign a slot for the following: Topic name: Response to early review of draft-ietf-dmm-ondemand-mobility-14 Presenter: Danny Moses Time: 15 minutes Draft Reference: draft-ietf-dmm-ondemand-mobility-14 Thanks, Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Wednesday, June 06, 2018 18:04 To: dmm@ietf.org Subject: Re: [DMM] IETF102 - Call for agenda items Folks - Gentle reminder. Please send your requests for agenda slots for IET= F 102. If you have already done so, you can ignore this. Please include the= following information. --- Topic Name: Presenter Name: Time: Draft Reference: --- Sri > >-----Original Message----- >From: dmm [mailto:dmm-bounces@ietf.org] On B= ehalf Of Sri Gundavelli >(sgundave) >Sent: Thursday, May 3, 2018 5:32 PM >To: dmm@ietf.org >Subject: [E] [DMM] IETF102 - Call for agenda items > >The DMM working group is planning to meet in IETF 102, week of 16th of >July, 2018 at Montreal. We currently have requested for one meeting, >which is a 2.5 hour slot. > >We realize in IETF101 we had many items with a fully packaged agenda, >and could not allocate enough time for any of the topics. For this >meeting, we want to avoid that problem by asking for an additional >meeting slot, but we want to be sure there are enough items for >discussion before we lock the resources. > >So, if you need a presentation slot, please send your request to the >chairs (as a response to this email) with the following information. We >still have time and so its not required that you need a published I-D, >but do let us know in the next few days if you are planning to make a >presentation. > > > --- >>Topic Name: >>Presenter Name: >>Time: >>Draft Reference: (Optional) >>--- > >Regards >Dapeng & Sri >>> >> > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_ >listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3DI >diS >ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=3D3YmCyVAo >iC_ >ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHrommWakT2klf1og05nny7we_JVQm8flSZ8 >ZZ7 >ASgw&e=3D _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf..org/mailman/listinfo/dmm --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28140147A0DHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

I agree that if we man= age to resolve the comments prior to the meeting, the slot is not required.=

However, I am not opti= mistic and believe that we most like will need the slot. So I propose to re= serve the time for this topic.

 

I will post responses = before the end of this week so the WG can review and provide feedback.=

 

Thanks,

Danny

 

From: Sri= Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, June 06, 2018 22:56
To: Moses, Danny <danny.moses@intel.com>
Cc: dmm@ietf.org
Subject: Re: IETF102 - Call for agenda items

 

Danny &= #8211; Unless you are not able to resolve the comments that you have receiv= ed from IESG, or if the WG disagrees with your resolutions, we may not need= this slot.  I have not seen any responses from you guys yet for the review comments. I suggest you guys propose your= text to the WG/reviewer on how you plan to resolve those comments, and let= s decide if we need WG feedback. For now, I am putting this request on hold= .

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

From: "Moses, Danny" <danny.moses@intel.com>
Date: Wednesday, June 6, 2018 at 12:51 PM
To: Sri Gundavelli <sgundav= e@cisco.com>
Cc: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: RE: IETF102 - Call for agenda items

&n= bsp;

Hi,=

 

Please assign a slot = for the following:

 

Topic name: Response = to early review of draft-ietf-dmm-ondemand-mobility-14

Presenter: Danny Mose= s

Time: 15 minutes=

Draft Reference: draf= t-ietf-dmm-ondemand-mobility-14

 

Thanks,

Danny

 

-----Original Message= -----
From: dmm [mailto:dmm-bounces@ietf.= org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, June 06, 2018 18:04
To: dmm@ietf.org
Subject: Re: [DMM] IETF102 - Call for agenda items

 

Folks - Gentle remind= er. Please send your requests for agenda slots for IETF 102. If you have al= ready done so, you can ignore this. Please include the following informatio= n.

 

 

  ---=

  Topic Name:

  Presenter Name= :

  Time:

  Draft Referenc= e:

---=

 

 

 

 

Sri=

 

 

 

 

> =

>-----Original Mes= sage-----

>From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gund= avelli

>(sgundave)

>Sent: Thursday, M= ay 3, 2018 5:32 PM

>To: dmm@ietf.org

>Subject: [E] [DMM= ] IETF102 - Call for agenda items

> =

>The DMM working g= roup is planning to meet in IETF 102, week of 16th of

>July, 2018 at Mon= treal. We currently have requested for one meeting,

>which is a 2.5 ho= ur slot.

> =

>We realize in IET= F101 we had many items with a fully packaged agenda,

>and could not all= ocate enough time for any of the topics. For this

>meeting, we want = to avoid that problem by asking for an additional

>meeting slot, but= we want to be sure there are enough items for

>discussion before= we lock the resources.

> =

>So, if you need a= presentation slot, please send your request to the

>chairs (as a resp= onse to this email) with the following information. We

>still have time a= nd so its not required that you need a published I-D,

>but do let us kno= w in the next few days if you are planning to make a

>presentation.

> =

> =

>  ---

>>Topic Name:

>>Presenter Nam= e:

>>Time:

>>Draft Referen= ce: (Optional)

>>---

> =

>Regards

>Dapeng & Sri<= o:p>

>>> 

>> 

> =

>_________________= ______________________________

>dmm mailing list<= o:p>

>dmm@ie= tf.org

>https://urldefense.proofpoi= nt.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm=

>an_

>listinfo_dmm&= d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DI

>diS

>ODh8aDRjdCeGgd9Mz= nLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=3D3YmCyVAo

>iC_

>ugQMmv8VcJoITk2D8= QR4ZHgE34zzz0CY&s=3DAHrommWakT2klf1og05nny7we_JVQm8flSZ8

>ZZ7

>ASgw&e=3D

 

_____________________= __________________________

dmm mailing list=

dmm@ietf.o= rg

https://www.ietf..org/mailman/listinfo/dmm

-----------------------------------------------------------= ----------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential ma= terial for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28140147A0DHASMSX106gercor_-- From nobody Thu Jun 7 00:27:56 2018 Return-Path: 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 E07C412426A for ; Thu, 7 Jun 2018 00:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GoSKe68bL9k7 for ; Thu, 7 Jun 2018 00:27:45 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E3D130E8F for ; Thu, 7 Jun 2018 00:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2414; q=dns/txt; s=iport; t=1528356465; x=1529566065; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=AiPZypEpppjypctOLFIsWGphRJe1JQAM8B1732/ZX/o=; b=Q6LVYnGSjw0YVasJoyJukjx11fzFZ5tWvlskOKZVHk3ExW5LZAyHWgcA NiDYSR1sSAAYHOM9el5ENq1ss+wd6LY/j/WWDdfNSCzUBSo4vfJhxtgGX K1fJ7sOGkbHXyPDyVKv2uYo4Dn0l0RtMX2atIKkgg52f0b8B+robtS1Ry I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AQA23Rhb/xbLJq1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQlbRIoi3xfjgGDYohXiBkUgWQLGA2ERwKCWTQYAQIBAQE?= =?us-ascii?q?BAQECbBwMhSgBAQEDAQEBG1ELBQcECxEEAQEKHgcPARcfCQgGE4MkgXcID6t?= =?us-ascii?q?0gzqFHYFjBYpVhBuBQYFQAQECGIETARIBH4VVAocrJ4RiN4wQBwKFbYo6g3u?= =?us-ascii?q?HbYoEhwACBAYFAhMBgUE4YXEzPVCCQ4Isg1CFFIVAPTABAY4sgjgBAQ?= X-IronPort-AV: E=Sophos;i="5.49,486,1520899200"; d="scan'208";a="4324709" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2018 07:27:42 +0000 Received: from adreena.localnet ([10.228.42.62]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w577RgwY017533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Jun 2018 07:27:42 GMT From: Jordan =?ISO-8859-1?Q?Aug=E9?= To: "Sri Gundavelli (sgundave)" Cc: dmm@ietf.org Date: Thu, 07 Jun 2018 09:27:41 +0200 Message-ID: <1851037.C16W2Tzijb@adreena> Organization: Cisco Systems In-Reply-To: References: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Authenticated-User: augjorda Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 07:27:51 -0000 Hello, Would you be so kind to assign the following slot: Topic Name: Anchorless mobility with Hybrid ICN Presenter Name: Luca Muscariello (alt. Jordan Aug=E9) Time: 20m Draft Reference: draft-auge-dmm-anchorless-hicn-00 (to be submitted soon) Thanks. =2D- Jordan > Folks - Gentle reminder. Please send your requests for agenda slots for > IETF 102. If you have already done so, you can ignore this. Please include > the following information. >=20 >=20 > --- > Topic Name: > Presenter Name: > Time: > Draft Reference: > --- >=20 >=20 >=20 >=20 > Sri >=20 > >-----Original Message----- > >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli > >(sgundave) > >Sent: Thursday, May 3, 2018 5:32 PM > >To: dmm@ietf.org > >Subject: [E] [DMM] IETF102 - Call for agenda items > > > >The DMM working group is planning to meet in IETF 102, week of 16th of > >July, 2018 at Montreal. We currently have requested for one meeting, > >which is a 2.5 hour slot. > > > >We realize in IETF101 we had many items with a fully packaged agenda, and > >could not allocate enough time for any of the topics. For this meeting, > >we want to avoid that problem by asking for an additional meeting slot, > >but we want to be sure there are enough items for discussion before we > >lock the resources. > > > >So, if you need a presentation slot, please send your request to the > >chairs (as a response to this email) with the following information. We > >still have time and so its not required that you need a published I-D, > >but do let us know in the next few days if you are planning to make a > >presentation. > > > > --- > >> > >>Topic Name: > >>Presenter Name: > >>Time: > >>Draft Reference: (Optional) > >>--- > > > >Regards > >Dapeng & Sri > > > > > > > >_______________________________________________ > >dmm mailing list > >dmm@ietf.org > >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_ > >listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&= r=3DIdiS > >ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=3D3YmCyVA= oiC_ > >ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHrommWakT2klf1og05nny7we_JVQm8flSZ= 8ZZ7 > >ASgw&e=3D >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Jun 7 00:51:47 2018 Return-Path: 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 71BF7130E9A for ; Thu, 7 Jun 2018 00:51:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=gmail.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 whiz2CQv_hBk for ; Thu, 7 Jun 2018 00:51:30 -0700 (PDT) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695D1130E96 for ; Thu, 7 Jun 2018 00:51:30 -0700 (PDT) Received: by mail-pl0-x22d.google.com with SMTP id n10-v6so5590458plp.0 for ; Thu, 07 Jun 2018 00:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7WltQwKKSSMTJYFqEC0t5AdZ5GmkutGK+qz6CvjK6ck=; b=Z3+c53aVAnmKx9sETvQqdEPBO4XDyxpRNT7N2pihQ3c7R7huVqIbBE8ROMzt4ICi0j G7Af3Xb1jtV/CuTQBZFAtKc3QRoXJi/4kwiK16RRKZQBkYtb+DQFySi6/H/yJsIJOgnj EYPfrnMRcSRYApf23L/Pi3LpDO9p23TcCEasO/x4JFSnAlhUFtVcfPu1JbNb/rpXC6Bf 5MU84xiM2VhoRTmE4IZe/novNNvP68p5SrzDt7sxPxzEBGj1QLFL66mfgqO112CKRE6l 9Tdg148MD8NsumOLGOI/vYV94N/ebDpQpyTNsfxafEhZWM/bS6RtvRNP5ydXYykQX9iD 0iUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7WltQwKKSSMTJYFqEC0t5AdZ5GmkutGK+qz6CvjK6ck=; b=oTCVUJKoU1Zoig4TEpnswohXR9X8vNeVrm9CWNWgYC6gi6O1FHGYZWtx4gijvarXK8 AI0UkBnuDcrM9BngYiVGa1RvQLTBG96oRHspN77G7suQFViYD/PfkuiObi/LPT+AY1IA 9z79RYlPLpl1dmxKa6xAKA/sBZPoTre7tp9wrgZMIDvMtuUBvO3yQevXah5fgtcK9sFa 5QnVvbLTG8zOA77EJFsSNZraHS/t3LA8pnUmsyQBci1lFx/XGaeDUtKb2VtjlOERaYqn Jo8fi6dAGQI78hmxDAv9fb7EFhDBtV8qfjnVCP9j4AOqvcd6PMFz6iJQDgSNVc2iiQ0P UjdA== X-Gm-Message-State: APt69E3fOd03RKWsibpcw78NUAhPJVKmxuCtymYQZOpOlD9ef4MOq1MU s2xe+BCMLCi67MR/ZoiCBRE= X-Google-Smtp-Source: ADUXVKK2JeTIpRrBj/9uaidslDVjc22zgjPN4U2swjH4eS/1e9WUvuDldcWwQDM8E//DQf8P84EkfQ== X-Received: by 2002:a17:902:4203:: with SMTP id g3-v6mr911343pld.315.1528357889895; Thu, 07 Jun 2018 00:51:29 -0700 (PDT) Received: from ?IPv6:2400:2411:8900::791c:8835:4dd9:838e? ([2400:2411:8900:0:791c:8835:4dd9:838e]) by smtp.gmail.com with ESMTPSA id n68-v6sm27434554pfk.145.2018.06.07.00.51.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 00:51:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Satoru Matsushima In-Reply-To: Date: Thu, 7 Jun 2018 16:50:54 +0900 Cc: "dmm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <91CF1F1D-EB5B-4183-A7F2-47E7AED3D8B2@gmail.com> References: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> To: "Sri Gundavelli (sgundave)" X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 07:51:41 -0000 Dear DMM WG chairs, I=E2=80=99d request a 15min slot for draft-ietf-dmm-srv6-mobile-uplane = by one of the authors. Topic Name: SRv6 Mobile User Plane=20 Presenter Name: TBD Time: 15min Draft Reference: = https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane Best regards, --satoru > 2018/06/07 0:03=E3=80=81Sri Gundavelli (sgundave) = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB= : >=20 > Folks - Gentle reminder. Please send your requests for agenda slots = for > IETF 102. If you have already done so, you can ignore this. Please = include > the following information. >=20 >=20 > --- > Topic Name: > Presenter Name: > Time: > Draft Reference: > --- >=20 >=20 >=20 >=20 > Sri >=20 >=20 >=20 >=20 >>=20 >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >> (sgundave) >> Sent: Thursday, May 3, 2018 5:32 PM >> To: dmm@ietf.org >> Subject: [E] [DMM] IETF102 - Call for agenda items >>=20 >> The DMM working group is planning to meet in IETF 102, week of 16th = of >> July, 2018 at Montreal. We currently have requested for one meeting, >> which is a 2.5 hour slot. >>=20 >> We realize in IETF101 we had many items with a fully packaged agenda, = and >> could not allocate enough time for any of the topics. For this = meeting, >> we want to avoid that problem by asking for an additional meeting = slot, >> but we want to be sure there are enough items for discussion before = we >> lock the resources. >>=20 >> So, if you need a presentation slot, please send your request to the >> chairs (as a response to this email) with the following information. = We >> still have time and so its not required that you need a published = I-D, >> but do let us know in the next few days if you are planning to make a >> presentation.=20 >>=20 >>=20 >> --- >>> Topic Name: >>> Presenter Name: >>> Time: >>> Draft Reference: (Optional) >>> --- >>=20 >> Regards >> Dapeng & Sri >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >> = listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3D= IdiS >> = ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=3D3YmCyVAoi= C_ >> = ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHrommWakT2klf1og05nny7we_JVQm8flSZ8Z= Z7 >> ASgw&e=3D >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Jun 7 01:32:04 2018 Return-Path: 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 D9BD8130E97 for ; Thu, 7 Jun 2018 01:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 uAErLUPaMmxJ for ; Thu, 7 Jun 2018 01:31:57 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 770BC130E9A for ; Thu, 7 Jun 2018 01:31:57 -0700 (PDT) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w578VmYK028856; Thu, 7 Jun 2018 17:31:48 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id A196263881B; Thu, 7 Jun 2018 17:31:48 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 96568638730; Thu, 7 Jun 2018 17:31:48 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.28]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 7F08D400AA8; Thu, 7 Jun 2018 17:31:48 +0900 (JST) References: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> From: Shunsuke Homma Message-ID: <08c8437c-b0a7-8877-a3f7-899189a3c7d3@lab.ntt.co.jp> Date: Thu, 7 Jun 2018 17:31:13 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: 1 To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 08:32:02 -0000 Hi Sri, I and some volunteers started analyzing GTP-U specs and 5GS requirements for UPPS on 3GPP, and we would like to request a slot for reporting the result. --- Topic Name: Analysis on 5G System Requirements and GTP-U Specification Presenter Name: TBD Time: 15 mins Draft Reference: draft-xxx-dmm-5g-gtp-analysis-00(in progress) --- By the way, I think we need to discuss how the LS reply contents look like back to 3GPP CT4. Do we need a slot for it? Regards, Shunsuke On 2018/06/07 0:03, Sri Gundavelli (sgundave) wrote: > Folks - Gentle reminder. Please send your requests for agenda slots for > IETF 102. If you have already done so, you can ignore this. Please include > the following information. > > > --- > Topic Name: > Presenter Name: > Time: > Draft Reference: > --- > > > > > Sri > > > > >> >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >> (sgundave) >> Sent: Thursday, May 3, 2018 5:32 PM >> To: dmm@ietf.org >> Subject: [E] [DMM] IETF102 - Call for agenda items >> >> The DMM working group is planning to meet in IETF 102, week of 16th of >> July, 2018 at Montreal. We currently have requested for one meeting, >> which is a 2.5 hour slot. >> >> We realize in IETF101 we had many items with a fully packaged agenda, and >> could not allocate enough time for any of the topics. For this meeting, >> we want to avoid that problem by asking for an additional meeting slot, >> but we want to be sure there are enough items for discussion before we >> lock the resources. >> >> So, if you need a presentation slot, please send your request to the >> chairs (as a response to this email) with the following information. We >> still have time and so its not required that you need a published I-D, >> but do let us know in the next few days if you are planning to make a >> presentation. >> >> >> --- >>> Topic Name: >>> Presenter Name: >>> Time: >>> Draft Reference: (Optional) >>> --- >> >> Regards >> Dapeng & Sri >>>> >>> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ >> listinfo_dmm&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiS >> ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=3YmCyVAoiC_ >> ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=AHrommWakT2klf1og05nny7we_JVQm8flSZ8ZZ7 >> ASgw&e= > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service Systems Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Thu Jun 7 11:19:27 2018 Return-Path: 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 D5544128BAC for ; Thu, 7 Jun 2018 11:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 pYBhreGAPDd6 for ; Thu, 7 Jun 2018 11:19:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 2CB41127598 for ; Thu, 7 Jun 2018 11:19:19 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CA82DA5B3F316 for ; Thu, 7 Jun 2018 19:19:11 +0100 (IST) Received: from YYZEML701-CHM.china.huawei.com (10.218.33.71) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 7 Jun 2018 19:19:13 +0100 Received: from YYZEML702-CHM.china.huawei.com ([169.254.6.236]) by YYZEML701-CHM.china.huawei.com ([169.254.4.246]) with mapi id 14.03.0382.000; Thu, 7 Jun 2018 14:19:07 -0400 From: Arashmid Akhavain To: Marco Liebsch , Sri Gundavelli , "dmm@ietf.org" Thread-Topic: draft-gundavelli-dmm-mfa Thread-Index: AdPjJkKqeU0dQ2OyRTS8AFGEhuZHtgGEvFwQBU+0qAA= Date: Thu, 7 Jun 2018 18:19:06 +0000 Message-ID: References: <69756203DDDDE64E987BC4F70B71A26DE03A96EE@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26DE03A96EE@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.61.47] Content-Type: multipart/alternative; boundary="_000_D57109449177B54F8B9C093953AC5BCD74B923E4YYZEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] draft-gundavelli-dmm-mfa X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 18:19:24 -0000 --_000_D57109449177B54F8B9C093953AC5BCD74B923E4YYZEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marco, Sorry about my tardy reply. Please see my comments inline [Arashmid] From: Marco Liebsch [mailto:Marco.Liebsch@neclab.eu] Sent: 11 May 2018 11:47 To: Arashmid Akhavain ; Sri Gundavelli ; dmm@ietf.org Subject: RE: draft-gundavelli-dmm-mfa Hi Arashmid, please find my take inline [ml]. From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Arashmid Akhavain Sent: Donnerstag, 3. Mai 2018 23:38 To: Sri Gundavelli; dmm@ietf.org Subject: [DMM] draft-gundavelli-dmm-mfa Hi Sri, Please find below some questions and comments. Best regards, Arashmid 1- This technique certainly eliminates the need for fixed anchor points fro= m the data plane point of view. However, it is not clear what happens to other functions provided by the ex= isting 3GPP fixed anchor points. It should be possible to program the nodes for these additional functions a= s well. I think a list of existing functions or those required by 5G in 3GP= P would be a good starting point for the discussion. [ml] Good point, if we think about the MN's AG is a traditional data plane = anchor with some extensions that enable it to be changed per the operation described in this draft, all functions may move to the edge where the AG is= deployed. That may work for metering, paging initiation and QoS in case downstream labels are required for compatibility with the RAN. [Arashmid] Do you mean that we move these functions into the AG itself? If = so, then we need a mechanism to move say metering data from one AG to anoth= er as MN moves around. But then there is no QoS enforcement in a large part of the network in betw= een the CN and the MN's AG. Hence, the approach would benefit from enforcement = of downlink QoS rules on the CN's anchor /CNA. What do you think? [Arashmid] Yes, it allows policies to be enforced right at the edge. I thin= k we should capture this in the draft. But let's discuss what happens to po= licies (both uplink and downlink) as MN moves around. 2- Performance is another issue. How fast can we detect and then program MF= A nodes? This is the issue that applies to all different approaches. I thin= k performance merits a section in the draft. [ml] The draft depicts a reactive approach, which should work and in the wo= rst case it suffers from some packets' re-ordering after enforcing the optimized route. Pro-active extensions should be possible and improve t= hat situation. [Arashmid] If I am not mistaken, while things are settling down, .the old A= G can forward the packets to the new one as well. Yes we might end up with out of order packets due to path latency differentials. But as you = said, proactive measures can ease up the situation. Should this be reflecte= d in the draft? 3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document we= ll. Appendix? [ml] Are you asking for details about other data plane protocols that are c= urrently being discussed in the IETF? Since the MFA controller enforces pol= icies in the network edges (MN and CN side), these policies can result also in IL= A or LISP mappings per an ingress node operation for the packets, no? The current draft states at the beginning that it's not dependent on a part= icular data plane but it focuses on SRv6 so far. Which of the alternative d= ata plane protocols you think should be covered in the appendix? [Arashmid] I was just thinking about adding an example for SRv6 since the d= raft singles it out. But a statement regarding ILA and LISP would certainly= help to highlight the versatility of the approach. 4- Page 5, end of MFA-MNA paragraph: " Typically, the MFA-MNA function will be collocated with the UPF in the 3G= PP 5G system architecture." Couldn't it be collocated with the gNB as well? Or did you purposely took g= NB out to avoid touching the N3 interface? [ml] The draft is supposed to be independent of a particular access network= . Move the MNA closer to the access network and you may run your last mile protocol on a 1meter patch cable to the NB. = That's loose coupling and keeps the interface between control plane and the MNA decoupled from the interface between NB and contr= ol plane. Of course you may collocate and run the MNA tightly coupled with any access-specific node and even merg= e the interfaces to the control plane. [Arashmid] Yes, I agree. Thank you for clarifying. 5- When correspondent nodes are mobile themselves. e..g. UE-UE communicatio= n, isn't the MFA-CNA is just another MFA-MNA? Some clarification in the dra= ft might come handy. [ml] Sure. To differentiate between policy enforcement points on the data p= lane which are associated with the MN or the CN we chose these abbreviations. They may be of the same type of node. 6- Page 14, figure 5: Need to change MFA-NMA-->MFA-MNA, and MFA-CAN--> MFA-= CNA in the figure. [ml] Thanks for spotting this, we'll correct in the update. 7- How does paging work? Not sure about this one, but is it possible for a = UE to go to be idle (a new inactive state has also been added in the spec) = in one gNB and wake in another that connects to a different first hop route= r? [ml] adopting the IETF DMM terminology of past work ;-), the dormant monito= ring agent could be in the anchor or current MN-AG and detect packets that are addressed to a MN in dormant mode. Different options exist here. [Arashmid] The MN is usually provided with a paging cycle upon its initial = attachment. The MN in dormant mode then wakes up temporarily at each cycle = to check paging. The dormant monitoring agent in AG can detect MN and update t= he system with the new location. No? Also, in case of a reactive mode per this version of the draft, the MN's dormant state may be known only to the MFA NC, which initiates paging = instead of updating the CN's AG and the MN's current AG (which is not known as the MN is in dormant mode..). Multiple good or worse approache= s are possible and this initial draft does not focus on them yet as we want to sketch the key principles first and solicit feedback. 8- Page 19 after step 10: It might be useful to talk about how and when MFA= -CN removes the rule for H1::/64 from AG-2. I guess it is something along w= hat described in 4.3. [ml] Definitely, more details need to be covered. Also here, multiple optio= ns are possible, either remove them after the data session terminated, or k= eep them until the MN enters dormant mode. 9- Page 20, section 4.3, step 1: Might be useful to indicate how the syste= m would know when a flow is inactive and hence the rules associated with it= are no longer need. [ml] Yes, I agree. Another question is whether data flow termination should= serve as only indication to remove these states. [Arashmid] Are we talking about some sort of inactive time out period? In the view of reducing control plane load, other events should be consider= ed to remove states. Best regards, marco --_000_D57109449177B54F8B9C093953AC5BCD74B923E4YYZEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Marco,

Sorry about my tardy r= eply. Please see my comments inline [Arashmid]

 

 

From: Marco Liebsch [mailto:Marco.Liebsch@neclab.eu]
Sent: 11 May 2018 11:47
To: Arashmid Akhavain <arashmid.akhavain@huawei.com>; Sri Gund= avelli <sgundave@cisco.com>; dmm@ietf.org
Subject: RE: draft-gundavelli-dmm-mfa

 

Hi Aras= hmid,

please find my take inline [ml].

&n= bsp;

&n= bsp;

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Arashmid Akhavain
Sent: Donnerstag, 3. Mai 2018 23:38
To: Sri Gundavelli; dmm@ietf.org=
Subject: [DMM] draft-gundavelli-dmm-mfa

 

Hi Sri,

Please find below some questions and comments. =

 

Best regards,

Arashmid

 

1- This technique certainly eliminates the need for = fixed anchor points from the data plane point of view.

However, it is not clear what happens to other funct= ions provided by the existing 3GPP fixed anchor points.

It should be possible to program the nodes for these= additional functions as well. I think a list of existing functions or thos= e required by 5G in 3GPP would be a good starting point for the discussion.=

 

[ml] Good point, if we= think about the MN’s AG is a traditional data plane anchor with some= extensions that enable it to be changed per the operation
described in this draft, all functions may move to the edge where the AG is= deployed. That may work for metering, paging initiation and QoS
in case downstream labels are required for compatibility with the RAN.

 

[Arashmid] Do yo= u mean that we move these functions into the AG itself? If so, then we need= a mechanism to move say metering data from one AG to another

as MN moves arou= nd.

 

But then there is no Q= oS enforcement in a large part of the network in between
the CN and the MN’s AG. Hence, the approach would benefit from enforc= ement of downlink QoS rules on the CN’s anchor /CNA. What do you thin= k?

[Arashmid] Yes, = it allows policies to be enforced right at the edge. I think we should capt= ure this in the draft. But let’s discuss what happens to policies

(both uplink and= downlink) as MN moves around.

 

2- Performance is another issue. How fast can we det= ect and then program MFA nodes? This is the issue that applies to all diffe= rent approaches. I think performance merits a section in the draft.

 

[ml] The draft depicts= a reactive approach, which should work and in the worst case it suffers fr= om some packets’ re-ordering after enforcing
the optimized route. Pro-active extensions should be possible and improve t= hat situation.

[Arashmid] If I = am not mistaken, while things are settling down, .the old AG can forward th= e packets to the new one as well. Yes we might end

up with out of o= rder packets due to path latency differentials. But as you said, proactive = measures can ease up the situation. Should this be reflected

in the draft?

 

3- An example with SRv6 and/or SRv6 with ID-LOC migh= t serve the document well. Appendix?

 

[ml] Are you asking fo= r details about other data plane protocols that are currently being discuss= ed in the IETF? Since the MFA controller enforces policies
in the network edges (MN and CN side), these policies can result also in IL= A or LISP mappings per an ingress node operation for the packets, no?

The current draft stat= es at the beginning that it’s not dependent on a particular data plan= e but it focuses on SRv6 so far. Which of the alternative data
plane protocols you think should be covered in the appendix?

[Arashmid] I was= just thinking about adding an example for SRv6 since the draft singles it = out. But a statement regarding ILA and LISP would certainly help to

highlight the ve= rsatility of the approach.

 

4- Page 5, end of MFA-MNA paragraph:

" Typically, the MFA-MNA function will be collo= cated with the UPF in the 3GPP 5G system architecture."

Couldn't it be collocated with the gNB as well? Or d= id you purposely took gNB out to avoid touching the N3 interface?

 

[ml] The draft is supp= osed to be independent of a particular access network. Move the MNA closer = to the access network
and you may run your last mile protocol on a 1meter patch cable to the NB. = That’s loose coupling and keeps the interface between
control plane and the MNA decoupled from the interface between NB and contr= ol plane. Of course you may collocate
and run the MNA tightly coupled with any access-specific node and even merg= e the interfaces to the control plane.

[Arashmid] Yes, = I agree. Thank you for clarifying.

 

5- When correspondent nodes are mobile themselves. e= ..g. UE-UE communication, isn't the MFA-CNA is just another MFA-MNA? Some c= larification in the draft might come handy.

 

[ml] Sure. To differen= tiate between policy enforcement points on the data plane which are associa= ted with the MN or the CN we
chose these abbreviations. They may be of the same type of node.=

 

6- Page 14, figure 5: Need to change MFA-NMAàMFA-MNA, and MFA-CANà MFA-CNA in the figure.

 

[ml] Thanks for spotti= ng this, we’ll correct in the update.

 

7- How does paging work? Not sure about this one, bu= t is it possible for a UE to go to be idle (a new inactive state has also b= een added in the spec) in one gNB and wake in another that connects to a di= fferent first hop router?

 

[ml] adopting the IETF= DMM terminology of past work ;-), the dormant monitoring agent could be in= the anchor or current MN-AG and detect packets that
are addressed to a MN in dormant mode. Different options exist here. <= /o:p>

[Arashmid] The M= N is usually provided with a paging cycle upon its initial attachment. The = MN in dormant mode then wakes up temporarily at each cycle to

check paging. Th= e dormant monitoring agent in AG can detect MN and update the system with t= he new location. No?

 

Also, in case of a rea= ctive mode per this version of the draft, the
MN’s dormant state may be known only to the MFA NC, which initiates p= aging instead of updating the CN’s AG and the MN’s current AG (= which is
not known as the MN is in dormant mode..). Multiple good or worse approache= s are possible and this initial draft does not focus on them yet as we
want to sketch the key principles first and solicit feedback.

 

8- Page 19 after step 10: It might be useful to talk= about how and when MFA-CN removes the rule for H1::/64 from AG-2. I guess = it is something along what described in 4.3.

 

[ml] Definitely, more = details need to be covered. Also here, multiple options are possible, eithe= r remove them after the data session terminated, or keep them until the
MN enters dormant mode.

 

9-  Page 20, section 4.3, step 1: Might be usef= ul to indicate how the system would know when a flow is inactive and hence = the rules associated with it are no longer need.

 

[ml] Yes, I agree. Ano= ther question is whether data flow termination should serve as only indicat= ion to remove these states.

[Arashmid] Are w= e talking about some sort of inactive time out period?

In the view of reducin= g control plane load, other events should be considered to remove states.

 

Best regards,

marco

 

 

--_000_D57109449177B54F8B9C093953AC5BCD74B923E4YYZEML702CHMchi_-- From nobody Sun Jun 10 04:21:52 2018 Return-Path: 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 77C8C130DC0 for ; Sun, 10 Jun 2018 04:21:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 kVSt-HPnh2kh for ; Sun, 10 Jun 2018 04:21:48 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 6038D126CC7 for ; Sun, 10 Jun 2018 04:21:48 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2018 04:21:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,497,1520924400"; d="scan'208,217";a="231374952" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga005.jf.intel.com with ESMTP; 10 Jun 2018 04:21:45 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 10 Jun 2018 04:21:45 -0700 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 10 Jun 2018 04:21:43 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.43]) by HASMSX110.ger.corp.intel.com ([169.254.6.122]) with mapi id 14.03.0319.002; Sun, 10 Jun 2018 14:21:40 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: Response to the early review of draft-dmm-ondemand-mobility Thread-Index: AdQAq3rspm++7G2RSDu8KSi7E3IbDw== Date: Sun, 10 Jun 2018 11:21:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODM4MTM2YjItZTYzZC00M2MwLWE2OGUtMTZlODk5M2EwZDZkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiK2lJSXZaMXJEbU9ibkNMRnp3QXdqUXVMVDZlT1ZZYm03SG14NFwvVlBPRVwvUVIxMHNZcVwvZHVIVEY3Uk5TOTFpMiJ9 dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.124.184.62] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2814014D909HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] Response to the early review of draft-dmm-ondemand-mobility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 11:21:51 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2814014D909HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi all, This is the initial draft of the response to the Brian Haberman's early rev= iew of draft-dmm-ondemand-mobility. I would like to thank Brian for his review and provide the WG's response. Please see the first draft of the response below and provide comments. I th= ink that the first issue requires most of our attention. Assuming that most= of the people will agree with my opinion that Brian is correct in his comm= ent about the term 'IP session continuity', please help me in using a bette= r term. I have provided some alternatives and am also open to more suggesti= ons. I have copied Brian's comments and provided a response to each one. Thanks, Danny Response to the early review of draft-dmm-ondemand-mobility: Reviewer: Brian Haberman Review result: Not Ready This is an early review request for draft-ietf-dmm-ondemand-mobility. I am having a hard time with the thrust of this document. The following iss= ues really need to be addressed in some form... 1. Where is the concept of an IP session defined? Given that IP is connecti= onless, this term is really about IP address stability and its lifetime. A = new term could/should be coined to reflect what is really needed. Yes, this is a fare comment. Most of the work that has been done in relation with mobility boils down to= the stableness of the mobile node's source IP address (or source IP prefix= ). The implication to applications, is their ability or inability to mainta= in the transfer of packets with the corresponding node - which may be perce= ived this as a 'session'. On the other hand, the term 'session' is overloaded and might not be accura= te enough in this context. I checked other RFCs: RFC5944 uses the text: '...the ability to communicate...' or '... the abili= ty to maintain transport and high-layer connections...'. RFC4830 uses the text (under the definition of 'Global Mobility Management = Protocol'): '...end-to-end routing of packets for the purpose of maintainin= g session continuity when management causes a topology change...'. Since I would like to avoid getting into a debate on a new definition (whic= h could take years and is probably on a wider scope than dmm), I would like= to suggest some alternatives: 1. Maintaining transport and higher-layer connections 2. Continuity of IP connectivity 3. Session continuity 4. Source IP prefix validity 5. Socket operation validity 2. The needs described in this document have a mix of the ID/Location split= issues raised in a variety of other specifications. It would be good to cl= arify what is different here. This document does not describe a need to perform ID/Location split, or def= ines a new way to maintain the validity of an IP prefix. It simply defines = a new ability of applications in a host to influence the type of service pr= ovided by the mobile network. Most current cellular network performs tunneling automatically to all provi= sioned IP prefixes regardless of whether or not this is needed. This docume= nt defines a way for applications to indicate to networks if such service i= s actually needed or not. The benefit of providing this information to the network is saving unnecess= ary network resources (required for maintaining the validity of the source = IP prefix) and enabling more optimized routes to packet transmitted and rec= eived by mobile nodes (as mentioned in the document). 3. The draft only references host-based Mobile IP specifications. What are = the implications when other solutions (e.g., PMIP) are employed? Please clarify this point. I checked once more and did not find any reference in the text to the host-= based Mobile IP. Furthermore, the context of this document is about managem= ent of IP prefixes performed by the network (e.g. proxy...) and the ability= of applications to indicate when such operation are not needed. It does no= t specify specific operations, but clearly, PMIP, GTP, ID/Location separati= on are examples of such operations. The documents provides some pointers to RFC that define these operations, a= mong them: RFC5563 - Proxy Mobile IPv4 and RFC 5213 - Proxy Mobile IPv6. So what exactly is missing? 4. It is problematic that this document explicitly rules out of scope any d= iscussion of how this API interacts with address assignment methods (e.g., = DHCP). Clearly, there will need to be a way for this API to influence each = of the address assignment methods available. Some of the classes of IP addr= esses described in this document require certain lifetime guarantees from t= he address assignment method. That needs to addressed since it will require= changes to every assignment method. There are two other documents in process in DMM that address the way applic= ations convey the required service from the network and for the network to = update the host of the assigned service: - draft-moses-dmm-dhcp-ondemand-mobility - specifying extensions to = DHCPv6, and - draft-feng-dmm-ra-prefixtype - specifying extension to the mobilit= y option in RA messages. 5. The IETF has a very checkered history of success in getting APIs standar= dized within the appropriate group (POSIX/Austin/Open). Has this proposed A= PI been discussed within that community? No. However it has been discussed in 3GPP SA2 WG and the SSC mode feature of re= lease 15 will benefit from this document. Needless to say, once the document becomes an RFC, it would be good to disc= uss implementation in the groups that are mentioned. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC2814014D909HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi all,

 

This is the initial draft of the response to the Bri= an Haberman’s early review of draft-dmm-ondemand-mobility.=

 

I would like to thank Brian for his review and provi= de the WG’s response.

Please see the first draft of the response below and= provide comments. I think that the first issue requires most of our attent= ion. Assuming that most of the people will agree with my opinion that Brian= is correct in his comment about the term ‘IP session continuity’, please help me in using a better= term. I have provided some alternatives and am also open to more suggestio= ns.

 

I have copied Brian’s comments and provided a = response to each one.

 

Thanks,

Danny

 

Response to the early review of  draft-dmm-onde= mand-mobility:

 

Reviewer: Brian Haberman

Review result: Not Ready

 

This is an early review request for draft-ietf-dmm-o= ndemand-mobility.

 

I am having a hard time with the thrust of this docu= ment. The following issues really need to be addressed in some form...=

 

1. Where is the concept of an IP session defined? Gi= ven that IP is connectionless, this term is really about IP address stabili= ty and its lifetime. A new term could/should be coined to reflect what is r= eally needed.

 

Yes, this is a fare comment.

Most of the work that has been done in relation with mobility boils = down to the stableness of the mobile node’s source IP address (or sou= rce IP prefix). The implication to applications, is their ability or inability to maintain the transfer of packets with the= corresponding node – which may be perceived this as a ‘session= ’.

On the other hand, the term ‘session’ is overloaded and = might not be accurate enough in this context.

 

I checked other RFCs:

RFC5944 uses the text: ‘…the ability to communicate̷= 0;’ or ‘… the ability to maintain transport and high-laye= r connections…’.

RFC4830 uses the text (under the definition of ‘Global Mobilit= y Management Protocol’): ‘…end-to-end routing of packets = for the purpose of maintaining session continuity when management causes a topology change…’.

Since I would like to avoid getting into a debate on a new definitio= n (which could take years and is probably on a wider scope than dmm), I wou= ld like to suggest some alternatives:

1. &nbs= p;    Maintaining transport and higher-layer connections

2. &nbs= p;    Continuity of IP connectivity

3. &nbs= p;    Session continuity

4. &nbs= p;    Source IP prefix validity

5. &nbs= p;    Socket operation validity

 

 

 

2. The needs described in this document have a mix o= f the ID/Location split issues raised in a variety of other specifications.= It would be good to clarify what is different here.

 

This document does not describe a need to perform ID/Location split,= or defines a new way to maintain the validity of an IP prefix. It simply d= efines a new ability of applications in a host to influence the type of service provided by the mobile network.

 

Most current cellular network performs tunneling automatically to al= l provisioned IP prefixes regardless of whether or not this is needed. This= document defines a way for applications to indicate to networks if such service is actually needed or not.

The benefit of providing this information to the network is saving u= nnecessary network resources (required for maintaining the validity of the = source IP prefix) and enabling more optimized routes to packet transmitted and received by mobile nodes (as mentioned in= the document).

 

3. The draft only references host-based Mobile IP sp= ecifications. What are the implications when other solutions (e.g., PMIP) a= re employed?

 

Please clarify this point.

I checked once more and did not find any reference in the text to th= e host-based Mobile IP. Furthermore, the context of this document is about = management of IP prefixes performed by the network (e.g. proxy…) and the ability of applications to indicat= e when such operation are not needed. It does not specify specific operatio= ns, but clearly, PMIP, GTP, ID/Location separation are examples of such ope= rations.

The documents provides some pointers to RFC that define these operat= ions, among them: RFC5563 – Proxy Mobile IPv4 and RFC 5213 – Pr= oxy Mobile IPv6.

So what exactly is missing?

 

4. It is problematic that this document explicitly r= ules out of scope any discussion of how this API interacts with address ass= ignment methods (e.g., DHCP). Clearly, there will need to be a way for this= API to influence each of the address assignment methods available. Some of the classes of IP addresses describe= d in this document require certain lifetime guarantees from the address ass= ignment method. That needs to addressed since it will require changes to ev= ery assignment method.

 

There are two other documents in process in DMM that address the way= applications convey the required service from the network and for the netw= ork to update the host of the assigned service:

-  = ;      draft-moses-dmm-dhcp-ondemand-mobility – specifying extens= ions to DHCPv6, and

-  = ;      draft-feng-dmm-ra-prefixtype – specifying extension to the= mobility option in RA messages.

 

 

5. The IETF has a very checkered history of success = in getting APIs standardized within the appropriate group (POSIX/Austin/Ope= n). Has this proposed API been discussed within that community?<= /p>

No.

However it has been discussed in 3GPP SA2 WG and the SSC mode featur= e of release 15 will benefit from this document.

Needless to say, once the document becomes an RFC, it would be good = to discuss implementation in the groups that are mentioned.

 

 

 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC2814014D909HASMSX106gercor_-- From nobody Tue Jun 12 14:10:20 2018 Return-Path: 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 4423E130E97 for ; Tue, 12 Jun 2018 14:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 nH8v6emxNbZE for ; Tue, 12 Jun 2018 14:10:10 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77910130E96 for ; Tue, 12 Jun 2018 14:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33661; q=dns/txt; s=iport; t=1528837810; x=1530047410; h=from:to:cc:subject:date:message-id:mime-version; bh=hFyq55P9tcyThAqnoK4/BBmvvFHwz4GhtTBkO4OrsV8=; b=Z5Bjv5L5a5auptTEqRDjSMqpuuMarbvDLUWlyPpbhfzCvz+chQ5X6dtf L2qSeQFZo0Ph6sxfBkeg/gvNwfyOgUk5qEju4gdxZ+G48VIkOVLvh4l3T xrlETP94dTjQP4uKFypb1J8Qa8YkKHznv1qbsAATQyAhCI27lREVs8ShW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AACzNSBb/5xdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJORy5ifygKi3KMaYF/lFuBeAuEbII0ITQYAQIBAQEBAQE?= =?us-ascii?q?CbSiFKAEGLUUHEgEIEQMBAiEBBjkUCQoEAQkEBRQHgwmBG2SuG4Rag3CBaIc?= =?us-ascii?q?+gQqBVD8laoI8Ii6FE4U2AoVKgWMIGYR0hHSHUAkCizuDPIE/g36HdYdqiSc?= =?us-ascii?q?CERMBgSQdOIFScBWCfoIhF44Xb453gRoBAQ?= X-IronPort-AV: E=Sophos;i="5.51,216,1526342400"; d="scan'208,217";a="128149191" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2018 21:10:09 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w5CLA90k003690 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2018 21:10:09 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Jun 2018 16:10:08 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Tue, 12 Jun 2018 16:10:08 -0500 From: "Sri Gundavelli (sgundave)" To: "Moses, Danny" , "dmm@ietf.org" CC: Brian Haberman Thread-Topic: [DMM] Response to the early review of draft-dmm-ondemand-mobility Thread-Index: AQHUApG+X9Yl48bvGkyLFr4lwzz/9g== Date: Tue, 12 Jun 2018 21:10:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: multipart/alternative; boundary="_000_D745802F2BACE8sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Response to the early review of draft-dmm-ondemand-mobility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 21:10:15 -0000 --_000_D745802F2BACE8sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Danny, You can discuss this with Brian directly (keeping the WG in the loop). You = do not need consensus from the WG. If there is any objection from the WG on= any of the issue resolutions, then it will become a WG issue. Please see inline for additional comments. Sri From: dmm > on behalf of = "Moses, Danny" > Date: Sunday, June 10, 2018 at 4:21 AM To: "dmm@ietf.org" > Subject: [DMM] Response to the early review of draft-dmm-ondemand-mobility Hi all, This is the initial draft of the response to the Brian Haberman=92s early r= eview of draft-dmm-ondemand-mobility. I would like to thank Brian for his review and provide the WG=92s response. Please see the first draft of the response below and provide comments. I th= ink that the first issue requires most of our attention. Assuming that most= of the people will agree with my opinion that Brian is correct in his comm= ent about the term =91IP session continuity=92, please help me in using a b= etter term. I have provided some alternatives and am also open to more sugg= estions. I have copied Brian=92s comments and provided a response to each one. Thanks, Danny Response to the early review of draft-dmm-ondemand-mobility: Reviewer: Brian Haberman Review result: Not Ready This is an early review request for draft-ietf-dmm-ondemand-mobility. I am having a hard time with the thrust of this document. The following iss= ues really need to be addressed in some form... 1. Where is the concept of an IP session defined? Given that IP is connecti= onless, this term is really about IP address stability and its lifetime. A = new term could/should be coined to reflect what is really needed. Yes, this is a fare comment. Most of the work that has been done in relation with mobility boils down to= the stableness of the mobile node=92s source IP address (or source IP pref= ix). The implication to applications, is their ability or inability to main= tain the transfer of packets with the corresponding node =96 which may be p= erceived this as a =91session=92. On the other hand, the term =91session=92 is overloaded and might not be ac= curate enough in this context. I checked other RFCs: RFC5944 uses the text: =91=85the ability to communicate=85=92 or =91=85 the= ability to maintain transport and high-layer connections=85=92. RFC4830 uses the text (under the definition of =91Global Mobility Managemen= t Protocol=92): =91=85end-to-end routing of packets for the purpose of main= taining session continuity when management causes a topology change=85=92. Since I would like to avoid getting into a debate on a new definition (whic= h could take years and is probably on a wider scope than dmm), I would like= to suggest some alternatives: 1. Maintaining transport and higher-layer connections 2. Continuity of IP connectivity 3. Session continuity 4. Source IP prefix validity 5. Socket operation validity We have the term, "Mobility Session=94 defined in MIP specs. But, I do not = believe we have provided any explicit definition for the term "IP Session".= RFC 7847 (Logical Interface Support) uses the =93IP Session=94 term, but w= ith no explicit definition. I think providing some definition will help. I = do not think it will take years to converge on a definition. If you can jus= t state your assumption or technical requirements on what the expectations = or from the stack, application or routing point of view, that should do it.= You may want to propose some text to Brian. 2. The needs described in this document have a mix of the ID/Location split= issues raised in a variety of other specifications. It would be good to cl= arify what is different here. This document does not describe a need to perform ID/Location split, or def= ines a new way to maintain the validity of an IP prefix. It simply defines = a new ability of applications in a host to influence the type of service pr= ovided by the mobile network. Most current cellular network performs tunneling automatically to all provi= sioned IP prefixes regardless of whether or not this is needed. This docume= nt defines a way for applications to indicate to networks if such service i= s actually needed or not. The benefit of providing this information to the network is saving unnecess= ary network resources (required for maintaining the validity of the source = IP prefix) and enabling more optimized routes to packet transmitted and rec= eived by mobile nodes (as mentioned in the document). I would say, when there are mobility management mechanisms in place In the = access network to which a mobile node is attached, the mobile node is unawa= re of the mobility management support that exists for an IP address. The go= al of this spec is to enable the mobile node with such awareness. A given a= ddress may have mobility support, or it may mobility support for a transien= t period of time. The objective here is to extend the socket layer so the m= obile node can obtain this additional meta-data about the address from its = IP stack. 3. The draft only references host-based Mobile IP specifications. What are = the implications when other solutions (e.g., PMIP) are employed? Please clarify this point. I checked once more and did not find any reference in the text to the host-= based Mobile IP. Furthermore, the context of this document is about managem= ent of IP prefixes performed by the network (e.g. proxy=85) and the ability= of applications to indicate when such operation are not needed. It does no= t specify specific operations, but clearly, PMIP, GTP, ID/Location separati= on are examples of such operations. The documents provides some pointers to RFC that define these operations, a= mong them: RFC5563 =96 Proxy Mobile IPv4 and RFC 5213 =96 Proxy Mobile IPv6= . So what exactly is missing? The focus of the spec in the socket layer extensions and these extensions s= hould work with both client and network based mobility management enabled n= etworks. 4. It is problematic that this document explicitly rules out of scope any d= iscussion of how this API interacts with address assignment methods (e.g., = DHCP). Clearly, there will need to be a way for this API to influence each = of the address assignment methods available. Some of the classes of IP addr= esses described in this document require certain lifetime guarantees from t= he address assignment method. That needs to addressed since it will require= changes to every assignment method. There are two other documents in process in DMM that address the way applic= ations convey the required service from the network and for the network to = update the host of the assigned service: - draft-moses-dmm-dhcp-ondemand-mobility =96 specifying extensions t= o DHCPv6, and - draft-feng-dmm-ra-prefixtype =96 specifying extension to the mobil= ity option in RA messages. 5. The IETF has a very checkered history of success in getting APIs standar= dized within the appropriate group (POSIX/Austin/Open). Has this proposed A= PI been discussed within that community? No. However it has been discussed in 3GPP SA2 WG and the SSC mode feature of re= lease 15 will benefit from this document. Needless to say, once the document becomes an RFC, it would be good to disc= uss implementation in the groups that are mentioned. Given that 3GPP is asking for such support, there is good chance this will = make it into host stacks. Sri --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_D745802F2BACE8sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Danny,

You can discuss this with Brian directly (keeping the WG in the loop).= You do not need consensus from the WG. If there is any objection from the = WG on any of the issue resolutions, then it will become a WG issue.

Please see inline for additional comments.

Sri



From: dmm <dmm-bounces@ietf.org> on behalf of "Moses, D= anny" <danny.moses@intel.c= om>
Date: Sunday, June 10, 2018 at 4:21= AM
To: "dmm@ietf.org" <dmm@ietf.= org>
Subject: [DMM] Response to the earl= y review of draft-dmm-ondemand-mobility

Hi all,

 

This is the initial draft of the response to the Bri= an Haberman=92s early review of draft-dmm-ondemand-mobility.

 

I would like to thank Brian for his review and provi= de the WG=92s response.

Please see the first draft of the response below and= provide comments. I think that the first issue requires most of our attent= ion. Assuming that most of the people will agree with my opinion that Brian= is correct in his comment about the term =91IP session continuity=92, please help me in using a better term. I= have provided some alternatives and am also open to more suggestions.=

 

I have copied Brian=92s comments and provided a resp= onse to each one.

 

Thanks,

Danny

 

Response to the early review of  draft-dmm-onde= mand-mobility:

 

Reviewer: Brian Haberman

Review result: Not Ready

 

This is an early review request for draft-ietf-dmm-o= ndemand-mobility.

 

I am having a hard time with the thrust of this docu= ment. The following issues really need to be addressed in some form...=

 

1. Where is the concept of an IP session defined? Gi= ven that IP is connectionless, this term is really about IP address stabili= ty and its lifetime. A new term could/should be coined to reflect what is r= eally needed.

 

Yes, this is a fare comment.

Most of the work that has been done in relation with mobility boils = down to the stableness of the mobile node=92s source IP address (or source = IP prefix). The implication to applications, is their ability or inability to maintain the transfer of packets with the= corresponding node =96 which may be perceived this as a =91session=92.

On the other hand, the term =91session=92 is overloaded and might no= t be accurate enough in this context.

 

I checked other RFCs:

RFC5944 uses the text: =91=85the ability to communicate=85=92 or =91= =85 the ability to maintain transport and high-layer connections=85=92.

RFC4830 uses the text (under the definition of =91Global Mobility Ma= nagement Protocol=92): =91=85end-to-end routing of packets for the purpose = of maintaining session continuity when management causes a topology change=85=92.

Since I would like to avoid getting into a debate on a new definitio= n (which could take years and is probably on a wider scope than dmm), I wou= ld like to suggest some alternatives:

1. =      Maintaining transport and higher-layer connections

2. =      Continuity of IP connectivity

3. =      Session continuity

4. =      Source IP prefix validity

5. =      Socket operation validity

 

 
We have the term, "Mobility Session=94 defined in MIP specs. But,= I do not believe we have provided any explicit definition for the term &qu= ot;IP Session". RFC 7847 (Logical Interface Support) uses the =93IP Se= ssion=94 term, but with no explicit definition. I think providing some definition will help. I do not think it will take years to = converge on a definition. If you can just state your assumption or technica= l requirements on what the expectations or from the stack, application or r= outing point of view, that should do it. You may want to propose some text to Brian. 




 

2. The needs described in this document have a mix o= f the ID/Location split issues raised in a variety of other specifications.= It would be good to clarify what is different here.

 

This document does not describe a need to perform ID/Location split,= or defines a new way to maintain the validity of an IP prefix. It simply d= efines a new ability of applications in a host to influence the type of service provided by the mobile network.

 

Most current cellular network performs tunneling automatically to al= l provisioned IP prefixes regardless of whether or not this is needed. This= document defines a way for applications to indicate to networks if such service is actually needed or not.

The benefit of providing this information to the network is saving u= nnecessary network resources (required for maintaining the validity of the = source IP prefix) and enabling more optimized routes to packet transmitted and received by mobile nodes (as mentioned in= the document).

 
I would say, when there are mobility management mechanisms in place In= the access network to which a mobile node is attached, the mobile node is = unaware of the mobility management support that exists for an IP address. T= he goal of this spec is to enable the mobile node with such awareness. A given address may have mobility sup= port, or it may mobility support for a transient period of time. The object= ive here is to extend the socket layer so the mobile node can obtain this a= dditional meta-data about the address from its IP stack. 




3. The draft only references host-based Mobile IP sp= ecifications. What are the implications when other solutions (e.g., PMIP) a= re employed?

 

Please clarify this point.

I checked once more and did not find any reference in the text to th= e host-based Mobile IP. Furthermore, the context of this document is about = management of IP prefixes performed by the network (e.g. proxy=85) and the ability of applications to indicate wh= en such operation are not needed. It does not specify specific operations, = but clearly, PMIP, GTP, ID/Location separation are examples of such operati= ons.

The documents provides some pointers to RFC that define these operat= ions, among them: RFC5563 =96 Proxy Mobile IPv4 and RFC 5213 =96 Proxy Mobi= le IPv6.

So what exactly is missing?

 
The focus of the spec in the socket layer extensions and these extensi= ons should work with both client and network based mobility management enab= led networks. 




4. It is problematic that this document explicitly r= ules out of scope any discussion of how this API interacts with address ass= ignment methods (e.g., DHCP). Clearly, there will need to be a way for this= API to influence each of the address assignment methods available. Some of the classes of IP addresses describe= d in this document require certain lifetime guarantees from the address ass= ignment method. That needs to addressed since it will require changes to ev= ery assignment method.

 

There are two other documents in process in DMM that address the way= applications convey the required service from the network and for the netw= ork to update the host of the assigned service:

- &= nbsp;      draft-moses-dmm-dhcp-ondemand-mobility =96 specifying extens= ions to DHCPv6, and

- &= nbsp;      draft-feng-dmm-ra-prefixtype =96 specifying extension to the= mobility option in RA messages.

 

 

5. The IETF has a very checkered history of success = in getting APIs standardized within the appropriate group (POSIX/Austin/Ope= n). Has this proposed API been discussed within that community?<= /p>

No.

However it has been discussed in 3GPP SA2 WG and the SSC mode featur= e of release 15 will benefit from this document.

Needless to say, once the document becomes an RFC, it would be good = to discuss implementation in the groups that are mentioned.

 

 
Given that 3GPP is asking for such support, there is good chance this = will make it into host stacks.


Sri

 

--------------------------------------------------------------------- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

 --_000_D745802F2BACE8sgundaveciscocom_-- From nobody Thu Jun 14 10:49:41 2018 Return-Path: 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 9D5D3130E5B for ; Thu, 14 Jun 2018 10:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 7jR9qKpzM197 for ; Thu, 14 Jun 2018 10:49:34 -0700 (PDT) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (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 1A0A1130E39 for ; Thu, 14 Jun 2018 10:49:34 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2018 10:49:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,222,1526367600"; d="scan'208,217";a="232639347" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga005.jf.intel.com with ESMTP; 14 Jun 2018 10:49:32 -0700 Received: from fmsmsx151.amr.corp.intel.com (10.18.125.4) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Jun 2018 10:49:32 -0700 Received: from lcsmsx152.ger.corp.intel.com (10.186.165.231) by FMSMSX151.amr.corp.intel.com (10.18.125.4) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Jun 2018 10:49:31 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.43]) by LCSMSX152.ger.corp.intel.com ([169.254.4.149]) with mapi id 14.03.0319.002; Thu, 14 Jun 2018 20:49:28 +0300 From: "Moses, Danny" To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" CC: Brian Haberman Thread-Topic: [DMM] Response to the early review of draft-dmm-ondemand-mobility Thread-Index: AQHUApG+X9Yl48bvGkyLFr4lwzz/9qRgCf5Q Date: Thu, 14 Jun 2018 17:49:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDAwMzA1ZDUtMDkzYy00Y2Y3LThmNGYtMTk0NWZmYjgyNTEzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoibk5hWm4wTHJobUZEV2ZJSTBJOVwvaTBnUWJ4RWxtRmxySk1aeUs0c1wvb2hWcWt3RG1oNk1ZTFBZaFFZaHkrRlBpIn0= dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.249.88.86] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28140152815HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Response to the early review of draft-dmm-ondemand-mobility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 17:49:38 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28140152815HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Sri, Thanks for the additional comments, they are in line with my views. I will discuss with Brian an update the WG as you recommended. Thanks, Danny From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, June 13, 2018 00:10 To: Moses, Danny ; dmm@ietf.org Cc: Brian Haberman Subject: Re: [DMM] Response to the early review of draft-dmm-ondemand-mobil= ity Hi Danny, You can discuss this with Brian directly (keeping the WG in the loop). You = do not need consensus from the WG. If there is any objection from the WG on= any of the issue resolutions, then it will become a WG issue. Please see inline for additional comments. Sri From: dmm > on behalf of = "Moses, Danny" > Date: Sunday, June 10, 2018 at 4:21 AM To: "dmm@ietf.org" > Subject: [DMM] Response to the early review of draft-dmm-ondemand-mobility Hi all, This is the initial draft of the response to the Brian Haberman's early rev= iew of draft-dmm-ondemand-mobility. I would like to thank Brian for his review and provide the WG's response. Please see the first draft of the response below and provide comments. I th= ink that the first issue requires most of our attention. Assuming that most= of the people will agree with my opinion that Brian is correct in his comm= ent about the term 'IP session continuity', please help me in using a bette= r term. I have provided some alternatives and am also open to more suggesti= ons. I have copied Brian's comments and provided a response to each one. Thanks, Danny Response to the early review of draft-dmm-ondemand-mobility: Reviewer: Brian Haberman Review result: Not Ready This is an early review request for draft-ietf-dmm-ondemand-mobility. I am having a hard time with the thrust of this document. The following iss= ues really need to be addressed in some form... 1. Where is the concept of an IP session defined? Given that IP is connecti= onless, this term is really about IP address stability and its lifetime. A = new term could/should be coined to reflect what is really needed. Yes, this is a fare comment. Most of the work that has been done in relation with mobility boils down to= the stableness of the mobile node's source IP address (or source IP prefix= ). The implication to applications, is their ability or inability to mainta= in the transfer of packets with the corresponding node - which may be perce= ived this as a 'session'. On the other hand, the term 'session' is overloaded and might not be accura= te enough in this context. I checked other RFCs: RFC5944 uses the text: '...the ability to communicate...' or '... the abili= ty to maintain transport and high-layer connections...'. RFC4830 uses the text (under the definition of 'Global Mobility Management = Protocol'): '...end-to-end routing of packets for the purpose of maintainin= g session continuity when management causes a topology change...'. Since I would like to avoid getting into a debate on a new definition (whic= h could take years and is probably on a wider scope than dmm), I would like= to suggest some alternatives: 1. Maintaining transport and higher-layer connections 2. Continuity of IP connectivity 3. Session continuity 4. Source IP prefix validity 5. Socket operation validity We have the term, "Mobility Session" defined in MIP specs. But, I do not be= lieve we have provided any explicit definition for the term "IP Session". R= FC 7847 (Logical Interface Support) uses the "IP Session" term, but with no= explicit definition. I think providing some definition will help. I do not= think it will take years to converge on a definition. If you can just stat= e your assumption or technical requirements on what the expectations or fro= m the stack, application or routing point of view, that should do it. You m= ay want to propose some text to Brian. 2. The needs described in this document have a mix of the ID/Location split= issues raised in a variety of other specifications. It would be good to cl= arify what is different here. This document does not describe a need to perform ID/Location split, or def= ines a new way to maintain the validity of an IP prefix. It simply defines = a new ability of applications in a host to influence the type of service pr= ovided by the mobile network. Most current cellular network performs tunneling automatically to all provi= sioned IP prefixes regardless of whether or not this is needed. This docume= nt defines a way for applications to indicate to networks if such service i= s actually needed or not. The benefit of providing this information to the network is saving unnecess= ary network resources (required for maintaining the validity of the source = IP prefix) and enabling more optimized routes to packet transmitted and rec= eived by mobile nodes (as mentioned in the document). I would say, when there are mobility management mechanisms in place In the = access network to which a mobile node is attached, the mobile node is unawa= re of the mobility management support that exists for an IP address. The go= al of this spec is to enable the mobile node with such awareness. A given a= ddress may have mobility support, or it may mobility support for a transien= t period of time. The objective here is to extend the socket layer so the m= obile node can obtain this additional meta-data about the address from its = IP stack. 3. The draft only references host-based Mobile IP specifications. What are = the implications when other solutions (e.g., PMIP) are employed? Please clarify this point. I checked once more and did not find any reference in the text to the host-= based Mobile IP. Furthermore, the context of this document is about managem= ent of IP prefixes performed by the network (e.g. proxy...) and the ability= of applications to indicate when such operation are not needed. It does no= t specify specific operations, but clearly, PMIP, GTP, ID/Location separati= on are examples of such operations. The documents provides some pointers to RFC that define these operations, a= mong them: RFC5563 - Proxy Mobile IPv4 and RFC 5213 - Proxy Mobile IPv6. So what exactly is missing? The focus of the spec in the socket layer extensions and these extensions s= hould work with both client and network based mobility management enabled n= etworks. 4. It is problematic that this document explicitly rules out of scope any d= iscussion of how this API interacts with address assignment methods (e.g., = DHCP). Clearly, there will need to be a way for this API to influence each = of the address assignment methods available. Some of the classes of IP addr= esses described in this document require certain lifetime guarantees from t= he address assignment method. That needs to addressed since it will require= changes to every assignment method. There are two other documents in process in DMM that address the way applic= ations convey the required service from the network and for the network to = update the host of the assigned service: - draft-moses-dmm-dhcp-ondemand-mobility - specifying extensions to = DHCPv6, and - draft-feng-dmm-ra-prefixtype - specifying extension to the mobilit= y option in RA messages. 5. The IETF has a very checkered history of success in getting APIs standar= dized within the appropriate group (POSIX/Austin/Open). Has this proposed A= PI been discussed within that community? No. However it has been discussed in 3GPP SA2 WG and the SSC mode feature of re= lease 15 will benefit from this document. Needless to say, once the document becomes an RFC, it would be good to disc= uss implementation in the groups that are mentioned. Given that 3GPP is asking for such support, there is good chance this will = make it into host stacks. Sri --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28140152815HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Sri,

 

Thanks for the additio= nal comments, they are in line with my views.

I will discuss with Br= ian an update the WG as you recommended.

 

Thanks,

Danny

 

 

From: Sri= Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, June 13, 2018 00:10
To: Moses, Danny <danny.moses@intel.com>; dmm@ietf.org
Cc: Brian Haberman <brian@innovationslab.net>
Subject: Re: [DMM] Response to the early review of draft-dmm-ondeman= d-mobility

 

Hi Dann= y,

&n= bsp;

You can= discuss this with Brian directly (keeping the WG in the loop). You do not = need consensus from the WG. If there is any objection from the WG on any of= the issue resolutions, then it will become a WG issue.

&n= bsp;

Please = see inline for additional comments.

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

From: dmm <dmm= -bounces@ietf.org> on behalf of "Moses, Danny" <danny.moses@intel.com>
Date: Sunday, June 10, 2018 at 4:21 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] Response to the early review of draft-dmm-ondemand-mo= bility

&n= bsp;

Hi all,

 =

This is the initial draf= t of the response to the Brian Haberman’s early review of draft-dmm-o= ndemand-mobility.

 =

I would like to thank Br= ian for his review and provide the WG’s response.

Please see the first dra= ft of the response below and provide comments. I think that the first issue= requires most of our attention. Assuming that most of the people will agre= e with my opinion that Brian is correct in his comment about the term ‘IP session continuity’, please = help me in using a better term. I have provided some alternatives and am al= so open to more suggestions.

 =

I have copied Brian̵= 7;s comments and provided a response to each one.

 =

Thanks,

Danny<= /p>

 =

Response to the early re= view of  draft-dmm-ondemand-mobility:

 =

Reviewer: Brian Haberman=

Review result: Not Ready=

 =

This is an early review = request for draft-ietf-dmm-ondemand-mobility.

 =

I am having a hard time = with the thrust of this document. The following issues really need to be ad= dressed in some form...

 =

1. Where is the concept = of an IP session defined? Given that IP is connectionless, this term is rea= lly about IP address stability and its lifetime. A new term could/should be= coined to reflect what is really needed.

 =

Yes, this is a fare comment.=

Most of the work that has been done in relation with mobility boils = down to the stableness of the mobile node’s source IP address (or sou= rce IP prefix). The implication to applications, is their ability or inability to maintain the transfer of packets with the= corresponding node – which may be perceived this as a ‘session= ’.

On the other hand, the term ‘session’ is overloaded and = might not be accurate enough in this context.

 

I checked other RFCs:<= /span>

RFC5944 uses the text: ‘…the ability to communicate̷= 0;’ or ‘… the ability to maintain transport and high-laye= r connections…’.<= /span>

RFC4830 uses the text (under the definition of ‘Global Mobilit= y Management Protocol’): ‘…end-to-end routing of packets = for the purpose of maintaining session continuity when management causes a topology change…’.=

Since I would like to avoid getting into a debate on a new definitio= n (which could take years and is probably on a wider scope than dmm), I wou= ld like to suggest some alternatives:

1.  =     Maintaining transport and higher-layer connections

2.  =     Continuity of IP connectivity=

3.  =     Session continuity=

4.  =     Source IP prefix validity

5.  =     Socket operation validity

 

 =

We have= the term, "Mobility Session” defined in MIP specs. But, I do no= t believe we have provided any explicit definition for the term "IP Se= ssion". RFC 7847 (Logical Interface Support) uses the “IP Session” term, but with no explicit definition. I think pr= oviding some definition will help. I do not think it will take years to con= verge on a definition. If you can just state your assumption or technical r= equirements on what the expectations or from the stack, application or routing point of view, that should do it. You ma= y want to propose some text to Brian. 

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

 =

2. The needs described i= n this document have a mix of the ID/Location split issues raised in a vari= ety of other specifications. It would be good to clarify what is different = here.

 =

This document does not describe a need to perform ID/Location split,= or defines a new way to maintain the validity of an IP prefix. It simply d= efines a new ability of applications in a host to influence the type of service provided by the mobile network.

 

Most current cellular network performs tunneling automatically to al= l provisioned IP prefixes regardless of whether or not this is needed. This= document defines a way for applications to indicate to networks if such service is actually needed or not.<= span style=3D"color:black">

The benefit of providing this information to the network is saving u= nnecessary network resources (required for maintaining the validity of the = source IP prefix) and enabling more optimized routes to packet transmitted and received by mobile nodes (as mentioned in= the document).

 =

I would= say, when there are mobility management mechanisms in place In the access = network to which a mobile node is attached, the mobile node is unaware of t= he mobility management support that exists for an IP address. The goal of this spec is to enable the mobile no= de with such awareness. A given address may have mobility support, or it ma= y mobility support for a transient period of time. The objective here is to= extend the socket layer so the mobile node can obtain this additional meta-data about the address from it= s IP stack. 

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

3. The draft only refere= nces host-based Mobile IP specifications. What are the implications when ot= her solutions (e.g., PMIP) are employed?

 =

Please clarify this point.

I checked once more and did not find any reference in the text to th= e host-based Mobile IP. Furthermore, the context of this document is about = management of IP prefixes performed by the network (e.g. proxy…) and the ability of applications to indicat= e when such operation are not needed. It does not specify specific operatio= ns, but clearly, PMIP, GTP, ID/Location separation are examples of such ope= rations.

The documents provides some pointers to RFC that define these operat= ions, among them: RFC5563 – Proxy Mobile IPv4 and RFC 5213 – Pr= oxy Mobile IPv6.

So what exactly is missing?<= /o:p>

 =

The foc= us of the spec in the socket layer extensions and these extensions should w= ork with both client and network based mobility management enabled networks= . 

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

4. It is problematic tha= t this document explicitly rules out of scope any discussion of how this AP= I interacts with address assignment methods (e.g., DHCP). Clearly, there wi= ll need to be a way for this API to influence each of the address assignment methods available. Some of the cl= asses of IP addresses described in this document require certain lifetime g= uarantees from the address assignment method. That needs to addressed since= it will require changes to every assignment method.

 =

There are two other documents in process in DMM that address the way= applications convey the required service from the network and for the netw= ork to update the host of the assigned service:

-  &= nbsp;     draft-moses-dmm-dhcp-ondemand-mobility – specifying extens= ions to DHCPv6, and

-  &= nbsp;     draft-feng-dmm-ra-prefixtype – specifying extension to the= mobility option in RA messages.

 

 =

5. The IETF has a very c= heckered history of success in getting APIs standardized within the appropr= iate group (POSIX/Austin/Open). Has this proposed API been discussed within= that community?

No.

However it has been discussed in 3GPP SA2 WG and the SSC mode featur= e of release 15 will benefit from this document.

Needless to say, once the document becomes an RFC, it would be good = to discuss implementation in the groups that are mentioned.

 

 

Given t= hat 3GPP is asking for such support, there is good chance this will make it= into host stacks.

&n= bsp;

&n= bsp;

Sri

 =

-----------------------------------------------------------= ----------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential ma= terial for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28140152815HASMSX106gercor_-- From nobody Mon Jun 18 07:01:16 2018 Return-Path: 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 3D978130EA6 for ; Mon, 18 Jun 2018 07:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Xx-RSXQFRVMS for ; Mon, 18 Jun 2018 07:00:57 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF386130E07 for ; Mon, 18 Jun 2018 07:00:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BA80610456F; Mon, 18 Jun 2018 16:00:54 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIw46PjAowFe; Mon, 18 Jun 2018 16:00:54 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 8A93B104401; Mon, 18 Jun 2018 16:00:48 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.27]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0319.002; Mon, 18 Jun 2018 16:00:47 +0200 From: Marco Liebsch To: Arashmid Akhavain , Sri Gundavelli , "dmm@ietf.org" Thread-Topic: draft-gundavelli-dmm-mfa Thread-Index: AdPjJkKqeU0dQ2OyRTS8AFGEhuZHtgGEvFwQBU+0qAACI1rgkA== Date: Mon, 18 Jun 2018 14:00:47 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26DE0EEF24F@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26DE03A96EE@DAPHNIS.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.170] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26DE0EEF24FPALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] draft-gundavelli-dmm-mfa X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 14:01:11 -0000 --_000_69756203DDDDE64E987BC4F70B71A26DE0EEF24FPALLENEofficehd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Arashmid, slowly we move ahead ;-) but let's increase the pace to have a good picture= before next meeting and solid material to discuss at IETF102. Inline, please [ml2]. From: Arashmid Akhavain [mailto:arashmid.akhavain@huawei.com] Sent: Donnerstag, 7. Juni 2018 20:19 To: Marco Liebsch; Sri Gundavelli; dmm@ietf.org Subject: RE: draft-gundavelli-dmm-mfa Hi Marco, Sorry about my tardy reply. Please see my comments inline [Arashmid] From: Marco Liebsch [mailto:Marco.Liebsch@neclab.eu] Sent: 11 May 2018 11:47 To: Arashmid Akhavain ; Sri Gundavelli ; dmm@ietf.org Subject: RE: draft-gundavelli-dmm-mfa Hi Arashmid, please find my take inline [ml]. From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Arashmid Akhavain Sent: Donnerstag, 3. Mai 2018 23:38 To: Sri Gundavelli; dmm@ietf.org Subject: [DMM] draft-gundavelli-dmm-mfa Hi Sri, Please find below some questions and comments. Best regards, Arashmid 1- This technique certainly eliminates the need for fixed anchor points fro= m the data plane point of view. However, it is not clear what happens to other functions provided by the ex= isting 3GPP fixed anchor points. It should be possible to program the nodes for these additional functions a= s well. I think a list of existing functions or those required by 5G in 3GP= P would be a good starting point for the discussion. [ml] Good point, if we think about the MN's AG is a traditional data plane = anchor with some extensions that enable it to be changed per the operation described in this draft, all functions may move to the edge where the AG is= deployed. That may work for metering, paging initiation and QoS in case downstream labels are required for compatibility with the RAN. [Arashmid] Do you mean that we move these functions into the AG itself? If = so, then we need a mechanism to move say metering data from one AG to anoth= er as MN moves around. [ml2] Today the mobile gateway has all these functions and if we move that = gateway to the edge and name it AG, yes, then it's all there. Sri's draft assumes a current AG for a mobile node as well as 1..N correspo= ndent data plane nodes, which are in the proximity of the 1..N correspondent services/nodes. If the correspondent node is a mobile, t= hen this may be an AG, too, if it's a service, e.g. in a data center, then it may be a policy router, PE router or something else. It's up to the= control plane to decide which policy to enforce on which of these data pla= ne nodes. Where metering happens depends on the aggregate and probably that needs to = happen on the AG for down and uplink. However, other functions, such as QoS enforcement or chargeable event monitoring, may happen on the c= orrespondent side already for downlink traffic. But then there is no QoS enforcement in a large part of the network in betw= een the CN and the MN's AG. Hence, the approach would benefit from enforcement = of downlink QoS rules on the CN's anchor /CNA. What do you think? [Arashmid] Yes, it allows policies to be enforced right at the edge. I thin= k we should capture this in the draft. But let's discuss what happens to po= licies (both uplink and downlink) as MN moves around. [ml2] sure, we can add more on this. 2- Performance is another issue. How fast can we detect and then program MF= A nodes? This is the issue that applies to all different approaches. I thin= k performance merits a section in the draft. [ml] The draft depicts a reactive approach, which should work and in the wo= rst case it suffers from some packets' re-ordering after enforcing the optimized route. Pro-active extensions should be possible and improve t= hat situation. [Arashmid] If I am not mistaken, while things are settling down, .the old A= G can forward the packets to the new one as well. Yes we might end up with out of order packets due to path latency differentials. But as you = said, proactive measures can ease up the situation. Should this be reflecte= d in the draft? [ml2] we focus on the basic principles right now but appreciate such feedba= ck. So far I can imagine some smartness on the control plane to enable a proactive AG relocation, possible with the help of available ha= ndover support extensions, such as end marker packets, which in this case should work in a control- data plane separated deployment. What d= o you think? 3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document we= ll. Appendix? [ml] Are you asking for details about other data plane protocols that are c= urrently being discussed in the IETF? Since the MFA controller enforces pol= icies in the network edges (MN and CN side), these policies can result also in IL= A or LISP mappings per an ingress node operation for the packets, no? The current draft states at the beginning that it's not dependent on a part= icular data plane but it focuses on SRv6 so far. Which of the alternative d= ata plane protocols you think should be covered in the appendix? [Arashmid] I was just thinking about adding an example for SRv6 since the d= raft singles it out. But a statement regarding ILA and LISP would certainly= help to highlight the versatility of the approach. [ml2] I am sure we'll find a good place in the draft where we can address o= ther data plane protocols. 4- Page 5, end of MFA-MNA paragraph: " Typically, the MFA-MNA function will be collocated with the UPF in the 3G= PP 5G system architecture." Couldn't it be collocated with the gNB as well? Or did you purposely took g= NB out to avoid touching the N3 interface? [ml] The draft is supposed to be independent of a particular access network= . Move the MNA closer to the access network and you may run your last mile protocol on a 1meter patch cable to the NB. = That's loose coupling and keeps the interface between control plane and the MNA decoupled from the interface between NB and contr= ol plane. Of course you may collocate and run the MNA tightly coupled with any access-specific node and even merg= e the interfaces to the control plane. [Arashmid] Yes, I agree. Thank you for clarifying. 5- When correspondent nodes are mobile themselves. e..g. UE-UE communicatio= n, isn't the MFA-CNA is just another MFA-MNA? Some clarification in the dra= ft might come handy. [ml] Sure. To differentiate between policy enforcement points on the data p= lane which are associated with the MN or the CN we chose these abbreviations. They may be of the same type of node. 6- Page 14, figure 5: Need to change MFA-NMA-->MFA-MNA, and MFA-CAN--> MFA-= CNA in the figure. [ml] Thanks for spotting this, we'll correct in the update. 7- How does paging work? Not sure about this one, but is it possible for a = UE to go to be idle (a new inactive state has also been added in the spec) = in one gNB and wake in another that connects to a different first hop route= r? [ml] adopting the IETF DMM terminology of past work ;-), the dormant monito= ring agent could be in the anchor or current MN-AG and detect packets that are addressed to a MN in dormant mode. Different options exist here. [Arashmid] The MN is usually provided with a paging cycle upon its initial = attachment. The MN in dormant mode then wakes up temporarily at each cycle = to check paging. The dormant monitoring agent in AG can detect MN and update t= he system with the new location. No? [ml2] Having the dormant monitoring function in the AG makes sense and it w= ill work. Also, in case of a reactive mode per this version of the draft, the MN's dormant state may be known only to the MFA NC, which initiates paging = instead of updating the CN's AG and the MN's current AG (which is not known as the MN is in dormant mode..). Multiple good or worse approache= s are possible and this initial draft does not focus on them yet as we want to sketch the key principles first and solicit feedback. 8- Page 19 after step 10: It might be useful to talk about how and when MFA= -CN removes the rule for H1::/64 from AG-2. I guess it is something along w= hat described in 4.3. [ml] Definitely, more details need to be covered. Also here, multiple optio= ns are possible, either remove them after the data session terminated, or k= eep them until the MN enters dormant mode. 9- Page 20, section 4.3, step 1: Might be useful to indicate how the syste= m would know when a flow is inactive and hence the rules associated with it= are no longer need. [ml] Yes, I agree. Another question is whether data flow termination should= serve as only indication to remove these states. [Arashmid] Are we talking about some sort of inactive time out period? [ml2] it could be a soft state that expires or gets explicitly removed in c= ase the state is not valid anymore. What that means for the control plane load is to be further looked at. marco In the view of reducing control plane load, other events should be consider= ed to remove states. Best regards, marco --_000_69756203DDDDE64E987BC4F70B71A26DE0EEF24FPALLENEofficehd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Arashmid,

slowly we move ahead ;-) but let’s increase the pace to have a good p= icture before next meeting and solid material to discuss at IETF102.

Inline,= please [ml2].

&n= bsp;

Arash= mid Akhavain [mailto:arashmid.akhavain@huawei.com]
Sent: Donnerstag, 7. Juni 2018 20:19
To: Marco Liebsch; Sri Gundavelli; dmm@ietf.org
Subject: RE: draft-gundavelli-dmm-mfa

 

Hi Marc= o,

Sorry a= bout my tardy reply. Please see my comments inline [Arashmid]

&n= bsp;

&n= bsp;

From: Marco Liebsch [mailto:Marco.Liebsch@neclab.eu]
Sent: 11 May 2018 11:47
To: Arashmid Akhavain <arashmid.akhavain@huawei.com>; Sri Gund= avelli <sgundave@cisco.com>; dmm@ietf.org
Subject: RE: draft-gundavelli-dmm-mfa

 

Hi Aras= hmid,

please find my take inline [ml].

&n= bsp;

&n= bsp;

dmm [= mailto:dmm-bounces@ietf.org] On Behalf Of Arashmid Akhavain
Sent: Donnerstag, 3. Mai 2018 23:38
To: Sri Gundavelli; dmm@ietf.org=
Subject: [DMM] draft-gundavelli-dmm-mfa

 

Hi Sri,

Please find below some question= s and comments.

 

Best regards,=

Arashmid

 

1- This technique certainly eli= minates the need for fixed anchor points from the data plane point of view.=

However, it is not clear what h= appens to other functions provided by the existing 3GPP fixed anchor points= .

It should be possible to progra= m the nodes for these additional functions as well. I think a list of exist= ing functions or those required by 5G in 3GPP would be a good starting poin= t for the discussion.

&n= bsp;

[ml] Go= od point, if we think about the MN’s AG is a traditional data plane a= nchor with some extensions that enable it to be changed per the operation described in this draft, all functions may move to the edge where the AG is= deployed. That may work for metering, paging initiation and QoS
in case downstream labels are required for compatibility with the RAN.

<= o:p> 

[= Arashmid] Do you mean that we move these functions into the AG itself? If s= o, then we need a mechanism to move say metering data from one AG to anothe= r

a= s MN moves around.

<= o:p> 

[ml2] T= oday the mobile gateway has all these functions and if we move that gateway= to the edge and name it AG, yes, then it’s all there.

SriR= 17;s draft assumes a current AG for a mobile node as well as 1..N correspon= dent data plane nodes, which are in the proximity of the
1..N correspondent services/nodes. If the correspondent node is a mobile, t= hen this may be an AG, too, if it’s a service, e.g. in a data center,=
then it may be a policy router, PE router or something else. It’s up = to the control plane to decide which policy to enforce on which of these da= ta plane nodes.
Where metering happens depends on the aggregate and probably that needs to = happen on the AG for down and uplink. However, other functions,
such as QoS enforcement or chargeable event monitoring, may happen on the c= orrespondent side already for downlink traffic.

&n= bsp;

<= o:p> 

But the= n there is no QoS enforcement in a large part of the network in between
the CN and the MN’s AG. Hence, the approach would benefit from enforc= ement of downlink QoS rules on the CN’s anchor /CNA. What do you thin= k?

[= Arashmid] Yes, it allows policies to be enforced right at the edge. I think= we should capture this in the draft. But let’s discuss what happens = to policies

(= both uplink and downlink) as MN moves around.

&n= bsp;

[ml2] s= ure, we can add more on this.

&n= bsp;

2- Performance is another issue= . How fast can we detect and then program MFA nodes? This is the issue that= applies to all different approaches. I think performance merits a section = in the draft.

&n= bsp;

[ml] Th= e draft depicts a reactive approach, which should work and in the worst cas= e it suffers from some packets’ re-ordering after enforcing
the optimized route. Pro-active extensions should be possible and improve t= hat situation.

[= Arashmid] If I am not mistaken, while things are settling down, .the old AG= can forward the packets to the new one as well. Yes we might end

u= p with out of order packets due to path latency differentials. But as you s= aid, proactive measures can ease up the situation. Should this be reflected=

i= n the draft?

&n= bsp;

[ml2] w= e focus on the basic principles right now but appreciate such feedback. So = far I can imagine some smartness on the control plane
to enable a proactive AG relocation, possible with the help of available ha= ndover support extensions, such as end marker packets, which in
this case should work in a control- data plane separated deployment. What d= o you think?

&n= bsp;

&n= bsp;

3- An example with SRv6 and/or = SRv6 with ID-LOC might serve the document well. Appendix?=

&n= bsp;

[ml] Ar= e you asking for details about other data plane protocols that are currentl= y being discussed in the IETF? Since the MFA controller enforces policies in the network edges (MN and CN side), these policies can result also in IL= A or LISP mappings per an ingress node operation for the packets, no?

The cur= rent draft states at the beginning that it’s not dependent on a parti= cular data plane but it focuses on SRv6 so far. Which of the alternative da= ta
plane protocols you think should be covered in the appendix?

[= Arashmid] I was just thinking about adding an example for SRv6 since the dr= aft singles it out. But a statement regarding ILA and LISP would certainly = help to

h= ighlight the versatility of the approach.

&n= bsp;

[ml2] I= am sure we’ll find a good place in the draft where we can address ot= her data plane protocols.

&n= bsp;

&n= bsp;

4- Page 5, end of MFA-MNA parag= raph:

" Typically, the MFA-MNA f= unction will be collocated with the UPF in the 3GPP 5G system architecture.= "

Couldn't it be collocated with = the gNB as well? Or did you purposely took gNB out to avoid touching the N3= interface?

&n= bsp;

[ml] Th= e draft is supposed to be independent of a particular access network. Move = the MNA closer to the access network
and you may run your last mile protocol on a 1meter patch cable to the NB. = That’s loose coupling and keeps the interface between
control plane and the MNA decoupled from the interface between NB and contr= ol plane. Of course you may collocate
and run the MNA tightly coupled with any access-specific node and even merg= e the interfaces to the control plane.

[= Arashmid] Yes, I agree. Thank you for clarifying.

&n= bsp;

&n= bsp;

5- When correspondent nodes are= mobile themselves. e..g. UE-UE communication, isn't the MFA-CNA is just an= other MFA-MNA? Some clarification in the draft might come handy.=

&n= bsp;

[ml] Su= re. To differentiate between policy enforcement points on the data plane wh= ich are associated with the MN or the CN we
chose these abbreviations. They may be of the same type of node.=

&n= bsp;

6- Page 14, figure 5: Need to c= hange MFA-NMA= =E0MFA-MNA, and MFA-CAN=E0 MFA-CNA in the figure.

&n= bsp;

[ml] Th= anks for spotting this, we’ll correct in the update.

&n= bsp;

7- How does paging work? Not su= re about this one, but is it possible for a UE to go to be idle (a new inac= tive state has also been added in the spec) in one gNB and wake in another = that connects to a different first hop router?

&n= bsp;

[ml] ad= opting the IETF DMM terminology of past work ;-), the dormant monitoring ag= ent could be in the anchor or current MN-AG and detect packets that
are addressed to a MN in dormant mode. Different options exist here. <= /o:p>

&n= bsp;

[= Arashmid] The MN is usually provided with a paging cycle upon its initial a= ttachment. The MN in dormant mode then wakes up temporarily at each cycle t= o

c= heck paging. The dormant monitoring agent in AG can detect MN and update th= e system with the new location. No?

<= o:p> 

[ml2] H= aving the dormant monitoring function in the AG makes sense and it will wor= k.

&n= bsp;

<= o:p> 

Also, i= n case of a reactive mode per this version of the draft, the
MN’s dormant state may be known only to the MFA NC, which initiates p= aging instead of updating the CN’s AG and the MN’s current AG (= which is
not known as the MN is in dormant mode..). Multiple good or worse approache= s are possible and this initial draft does not focus on them yet as we
want to sketch the key principles first and solicit feedback.

&n= bsp;

8- Page 19 after step 10: It mi= ght be useful to talk about how and when MFA-CN removes the rule for H1::/6= 4 from AG-2. I guess it is something along what described in 4.3.

&n= bsp;

[ml] De= finitely, more details need to be covered. Also here, multiple options are = possible, either remove them after the data session terminated, or keep the= m until the
MN enters dormant mode.

&n= bsp;

9-  Page 20, section 4.3, = step 1: Might be useful to indicate how the system would know when a flow i= s inactive and hence the rules associated with it are no longer need.<= /o:p>

&n= bsp;

[ml] Ye= s, I agree. Another question is whether data flow termination should serve = as only indication to remove these states.

[= Arashmid] Are we talking about some sort of inactive time out period?<= /o:p>

&n= bsp;

[ml2] i= t could be a soft state that expires or gets explicitly removed in case the= state is not valid anymore.
What that means for the control plane load is to be further looked at.

&n= bsp;

marco <= o:p>

&n= bsp;

&n= bsp;

In the = view of reducing control plane load, other events should be considered to r= emove states.

&n= bsp;

Best re= gards,

marco

&n= bsp;

&n= bsp;

--_000_69756203DDDDE64E987BC4F70B71A26DE0EEF24FPALLENEofficehd_-- From nobody Mon Jun 18 07:07:23 2018 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D692A120049; Mon, 18 Jun 2018 07:07:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152933084180.3094.16435524228853663527@ietfa.amsl.com> Date: Mon, 18 Jun 2018 07:07:21 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-11.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 14:07:22 -0000 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 : Protocol for Forwarding Policy Configuration (FPC) in DMM Authors : Satoru Matsushima Lyle Bertz Marco Liebsch Sri Gundavelli Danny Moses Charles E. Perkins Filename : draft-ietf-dmm-fpc-cpdp-11.txt Pages : 152 Date : 2018-06-18 Abstract: This document describes a way, called Forwarding Policy Configuration (FPC) to manage the separation of data-plane and control-plane. FPC defines a flexible mobility management system using FPC agent and FPC client functions. A FPC agent provides an abstract interface to the data-plane. The FPC client configures data-plane nodes by using the functions and abstractions provided by the FPC agent for the data- plane nodes. The data-plane abstractions presented in this document are extensible in order to support many different types of mobility management systems and data-plane functions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-11 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-fpc-cpdp-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-fpc-cpdp-11 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/ From nobody Mon Jun 18 07:15:23 2018 Return-Path: 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 6F66B130F4F for ; Mon, 18 Jun 2018 07:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 2zhJSmibJQjN for ; Mon, 18 Jun 2018 07:15:13 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730128.outbound.protection.outlook.com [40.107.73.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF45130F29 for ; Mon, 18 Jun 2018 07:15:13 -0700 (PDT) Received: from DM5PR05CA0014.namprd05.prod.outlook.com (10.173.226.24) by BN7PR05MB4449.namprd05.prod.outlook.com (52.135.248.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.6; Mon, 18 Jun 2018 14:15:12 +0000 Received: from SN1NAM01FT016.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::202) by DM5PR05CA0014.outlook.office365.com (2603:10b6:3:d4::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.884.12 via Frontend Transport; Mon, 18 Jun 2018 14:15:11 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com; Received: from preapdm3.corp.sprint.com (144.230.32.82) by SN1NAM01FT016.mail.protection.outlook.com (10.152.64.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.863.11 via Frontend Transport; Mon, 18 Jun 2018 14:15:11 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id w5IDq9ND017407 for ; Mon, 18 Jun 2018 10:15:11 -0400 Received: from plswe13m04.ad.sprint.com (plswe13m04.corp.sprint.com [144.229.214.23]) by preapdm3.corp.sprint.com with ESMTP id 2jmvt7fjjd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 18 Jun 2018 10:15:11 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m04.ad.sprint.com (2002:90e5:d617::90e5:d617) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Jun 2018 09:15:09 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1367.000; Mon, 18 Jun 2018 09:15:09 -0500 From: "Bertz, Lyle T [CTO]" To: "dmm@ietf.org" Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-11.txt Thread-Index: AQHUBw21ozNgxfg7hUeueCZvAACx+KRmDdPA Date: Mon, 18 Jun 2018 14:15:09 +0000 Message-ID: <9bd1459912964d18a9173e31fb176ddd@plswe13m04.ad.sprint.com> References: <152933084180.3094.16435524228853663527@ietfa.amsl.com> In-Reply-To: <152933084180.3094.16435524228853663527@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.82; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39380400002)(39860400002)(2980300002)(438002)(13464003)(189003)(199004)(8746002)(81166006)(7736002)(2501003)(14454004)(356003)(2351001)(8936002)(23726003)(186003)(6116002)(6246003)(53546011)(476003)(59450400001)(5890100001)(126002)(102836004)(2906002)(305945005)(1730700003)(81156014)(8676002)(6306002)(45080400002)(106466001)(486006)(2900100001)(72206003)(5640700003)(5250100002)(336012)(53936002)(478600001)(46406003)(50466002)(3846002)(108616005)(6916009)(68736007)(966005)(229853002)(5660300001)(47776003)(7696005)(86362001)(97736004)(26005)(76176011)(97756001)(11346002)(446003)(106002)(24736004)(575784001)(426003)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4449; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT016; 1:bktzDC4pmD9iEI9PM4v24MNLwt9gEy9t4Kfb/sLXTNE3WDvxXWfpuE7jbq3kVTmUePE8vajyVAdKtzx2pPSFppxyeWbpPutjZ5Gi89iz9xokpf8P94kItHKEJmDt4Zbg X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 195015c2-68da-452a-5710-08d5d525e78c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:BN7PR05MB4449; X-Microsoft-Exchange-Diagnostics: 1; BN7PR05MB4449; 3:qkD5weKBABOMsR/fsXJD1GFOgSSBxX2iepLPLno43Qrwb2InfNbMZJ8PoRo0Z3nx/vZKWOQncbOFfWk58FVq1HKn9/pSGXe+gv69DdH4/sGxJDZCczeVa5O0iFe43AnZApVmcnbvDVwBgjHxG0HGZX4ipSNqg7hB04pv94Y+PVpp0uOAPCzHl0+oe51BqIVAtoDCoOMdsWeu63T8rkDP6va4YSHLKq6s/R2AP1AtvhwYH3LW5WHeLfWiVKHHxoKu1kEMXF1laxfzNZzzhLkUGwVHkJ2qMI6asJyPlmZllhyGra0e+27fUfP/cXOHkxT8N2ZHH8dZ/1xa1pUd3vSj1nwfhCqfD5caG89aZijuFi8=; 25:cVrkMTxA4r+7ExYu5n49yGOmU19/Y5pGaT66MUTx+9yiHX4wQYIo/9IUrzWhzHXldwrcz4gbO2gjXPmvbxGm5DtZGbtHirYpg+wDjYD/K6i797KkZJJDLVBh8VvQHeeUfb1fPr19eJ1kK+gu5yMK5zcCfNYo6S6hRQGtN6zl8LrBinWufz92y0yvdiGC+7IsR/iab580xt6SymahRzBSlGZ52MYIF1MDd8Zl3JGMPx3uBIL3xlrepDEZdG4kyAIMFe4WFNABStLJnW5FqU7tNmyZAhHsUYFS0XCMpzJhJbNiz+jbYW23PngVw3z373ZlUWf7HQIuZ1EDVPLvW/V3aA== X-MS-TrafficTypeDiagnostic: BN7PR05MB4449: X-Microsoft-Exchange-Diagnostics: 1; BN7PR05MB4449; 31:wib15Pb3eIra9iwXeRHfPNyLNMTxIJZ+Y+sVA0fKQ1i+Au7cZzjdViriN1UFy9pxloJ3210alDYT0xSR+bS0oSP8tar+XaBakoX/oPhrS0bOT+IbV9LWtn4MuegWIt7rxkCr+I9NHLDEwfXacAoawA9tcVxUsPD+1GLc/d5gvL5qU1qMZgIsf3tH2Wz3RYY6jUutTsT3PBaChem196Ett+XIsozbnnpcz5GuGvTla34=; 20:IZyTNZgmfqaIgpPb3DJO2H1Hi6ddKsv2BhEZR+FAXNz1Cv20qRQHAnKTqWglnTQniEe6T//xOidWaWCAej9OZe5syvlG5xdESiIqPz9Nbm27nuYsqfbGJ4UeqGtEo2dXXQrMLODrAH+6a1C1z0A94kdHlmX4GlIhrC6sbLKDvQxYlT9C20DqzHlO4w989vXS8w4a1FNWX7/z0HhGQDxmo8HMI9B792m5VNnMCqe8H7u+vu4G13GQM1aVODLlil2yl8LJSe5VG1KoEW43NB/NqzwFZz9eNga5a4TdU6OCOhPSXtHez8qe8THBESgTIjhMe81E1brJWNRmbzn3ezsF9lVViOhYJZB7AyPO/DXtcilzo1b51ygtBj2lBmyLZRUZ50/us584fJYi6uje2sLTM6/Uq8JiK5KrqJ4izKfLGD5Q2L3Yw6OMYVZbj/80je8HebIYQel8cRwyrp2AYodIiuHFKubiZicDO+yCey92DxJ692/6XhSfdykIUOBqtPCw X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(189930954265078)(219752817060721); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231254)(944501410)(52105095)(93006095)(93004095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BN7PR05MB4449; BCL:0; PCL:0; RULEID:; SRVR:BN7PR05MB4449; X-Microsoft-Exchange-Diagnostics: 1; BN7PR05MB4449; 4:+81Ln2YTDKBO4DGjE0ps5BmnqBDSDj/+X5KOardpTJuL5POQHM2NyFB27o7BqdfHqUh8XeO9Tcb1HnhqM+a5rWug+7Y25B8Bd2texHMQwwvceiDpX5a12TiObbOv0KX4hyeXNtuneYWxMi+dxjAgShwdZHPcuTbS8ESoBGNNi5+wuPySccClXCh/4Gm8wH3JtoWhpJvAeOzZFAy8oRUsZTp064EqNCIVdzUvx2zwsFS55nL1AJPv18syu+cjepAKJopx6LymmdYRthIj7lK8U2/pbCa/ul5rYJnMWl8ZGvIP38CFzesNTzTdR9E+tN4oFoswxtTy9y4PALsBcPLeeE0rfIOUF5maIoGjadaS/Io= X-Forefront-PRVS: 0707248B64 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN7PR05MB4449; 23:zt6XoRYDQ3CKOcvDfadASHw/BYi5O5NIpad/32q3i?= =?us-ascii?Q?SFpTmatn5VbFZ6EWjQ2aWJbsAAVt0jK23aayS1GQ5+sgxBFsjNJ9ClzZ15Ow?= =?us-ascii?Q?oflA7dgFVcwW7in5Y2zo1n9VUBEUaVdUMwIok4C6rloOsdETv/RWJg4DvsoY?= =?us-ascii?Q?b46tk3t4ac/oPh+pcOBy+9CS/2EWNX5As326wyDOjbkObL449xyRanWW37Sk?= =?us-ascii?Q?aEOI2uvIPQmoe/7m/QEu7pps4BsfYT4gGeedC8W1Z35UfBSYRgkBDxHUByct?= =?us-ascii?Q?nYAkXYeM46dsNvh3I8BPrQkWzJ4/VuaybPww8Vm1klad38hbCy5BsQ+UHcuH?= =?us-ascii?Q?bJgZFyvKiA3ThN0fWqipVsRX/k1nNCBLJqBd9l92B1W257ZWOV/8lm+Az+G1?= =?us-ascii?Q?KRgfaZomGqZM4YF+BjzqmwW61e+t03COjEvAeaOrF0T2NY3iv1GHeH/DRz9i?= =?us-ascii?Q?PWEzY7WHRJP0Dv/dP6pg2DvsuiqJSonowUi+tJkqG84iFav3xyLjAIF9m/et?= =?us-ascii?Q?pFzPvsiuA/W3SaAlDZVf+2W7x3i5kSkI99mldl7S5typPdbxH4a60h5BldvV?= =?us-ascii?Q?1/Zq8vlOE5IvEPPHPQ0BO6DSyg8rXGdqG/Qa7w18iCcgrnoCoCWh/JBOpMvO?= =?us-ascii?Q?fKOI+UfV5JtD8DMYvjbrT5yqQPvT3WcVjEI+dUm4zI4R8bgdLZaXpGwgY1Io?= =?us-ascii?Q?OmnXmsla+caOMJPOFFuHm/qY2M0hn4INbE0oNKj49UW4WoxezPkYhGvb+LJ2?= =?us-ascii?Q?/dAn6LMgKVe8QBimpvAsDX6zONiP6/xb6pXUBMTAf6AeYJC7JL87urECVJse?= =?us-ascii?Q?mUgcVBN3VfG7PBc3UT90zsPxaR+fu7HqwII9xb5uG47tbz/53nCqnQt6LSaO?= =?us-ascii?Q?QTokC3RTCmKD706aQzeF7AWtQm584EgiX0/GGODZmGcaq1EAARCUbxHUzurL?= =?us-ascii?Q?qWm/pFXyDhvSqJCClE75TsDiN32oHfeHhOA6vSpZwSRpPH+CIv3H3Cyqye1i?= =?us-ascii?Q?fBk+jX2aoi6+NWkZWcTgZd93J5yWT1GxlmuEnoIaLlbC9G14BDNti9sgKD/c?= =?us-ascii?Q?d85kQYcndoCafNdy/DCkB3NWMSwJ6VocZyPX6C9WEhVwubnT3b09rjqoHnsv?= =?us-ascii?Q?Ozc1d1mNbU/2oMicfUp+veBWKnFUNcZ10etgS7fJAzKmT/fiNoux/4r3/nyU?= =?us-ascii?Q?QlEH+jFvySDfDZvYg+7/4PANxAO495M8CxkVIWf88POoOJZaTsSDcw5nDZvb?= =?us-ascii?Q?kKSHLUcNwXjPb0Io1GsHDiGl3SRw9Of/8vxuq5uzldl9+OdHLrmgQRFEAHLp?= =?us-ascii?Q?IPsrJyNRWiA2effPJaXxNyh+3lYCsQ4/yB+W7hQ0cvw9hBxjRBk3PCsy+M1j?= =?us-ascii?Q?ARSOMspFNdaUMikGGyoy0GfzqhALxj1JYdK8EQAMa8JuosynhIx3TqhivxKg?= =?us-ascii?Q?MBhBzeHVAcXIn5/NBUMNY3eaeiIWQZDyB/eu4aMfsyeb39VUISlkxl0Bs8Vu?= =?us-ascii?Q?R3skMz9Mvo5rfGhG/b0Jsuhmcps4rrE+OQ=3D?= X-Microsoft-Antispam-Message-Info: e7BqbOkUmzB3FVPf2EUqqQCdhD7ak0IbdSB0nvS8gdlmU8DJwOCZbsVJWKzDmmyeerfqXfe3UTal/+MsciD4HQXLKqhe/hjr+CutGSDQfxwDvm5OynKoltCOxfzH6Bsaf0YHKwJFIz6CSJT8JOULKWfVfu1aCvnRynHXWfgrESOBVjd/zXLoRKdiwD3vpcj6 X-Microsoft-Exchange-Diagnostics: 1; BN7PR05MB4449; 6:msUmcoOHBQdOIVTJyClPio92zUh58CyCSttzG1vevg5qlVW50R9eB9XzdVLxb5gsvXKXcdDVm1lfgqm5+MtvXeHsIRjDZJhyR7RIsUCT9ZyM3Qu1jtUgCTjuzL5FWfECH2zGR8xIrT2sd/Io8xjLuN7KbqgXHm4L9P1g6P70NSiS/xFRSdA/w4KV6GIQW+Uz6htQdSJMYIwtiF8+w03/q8dItDP7cBcmA1Yy648YARxaPxxFVMmoTGQs55Q10qDpnRhCnea1xeNPxzBYQZl8yn8h91nGFUiCqcD87PfU6hxS4sD+BtYPXs3en5anPCTioY+PWfYuIsi1HiQMUI0EPL9pGsdMAYl3RLQ1fVYQwjIycKuTgcQ4bDlpo9OKy7X+DM7Xoqa0enSvLBlKHtx1EeDRkGmD72wIjjjldEmvTW9EMSrfmWmMjcuC8+ubaU3NRrXCpDRQKUGiY+fXIuBqgQ==; 5:xdg/RSVHOUPP8k0OlznQYayAWWNXBj+XKpl5yQFVp66uhl6rgJgoPVY0ERqby5FzmqFroYOCcCClXB+sfPlEh78B9rVMv/nwW8bnpFBM1bGg/DkoFunY9yKEthcBw2Vv7xQrmVlCAfvVTGLC0y3hyuqjNnjYlkjuHhNxMn3fG4c=; 24:OVrz7g90yU8nMByF2kQ+In1AwWD4ZYLZxDn29JFDPAiup68EDx9dboDq6GFg8eA3TLHk/H5GKLTv8An3Wg9RF5N/klP+Ir2Vb1hdTIU2wdE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN7PR05MB4449; 7:dpzxlYkW7hIqZSki11YjV0XIkBd6iactOL758S2g3pfVW+N2tBWRZJt1Uu6AnRNj2o8Vt5GOJEIwnVbq/fd2Xa+NPsX0TxjB/NC4Ok/gTvQhNledkddvIjWadCPI+ybs8D3gfXOZhEgfoPUH2Er3N37+JkOWZnsiElH58FvLGeYhRCkcSeGm5YqcsYDbltNcnHf8cAvRIuyRc7emAmyK7gKk4YNR5Nfz4TzzcMcFr7GfSIc4PnhMEJyjJ1XOIFlQ X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2018 14:15:11.6002 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 195015c2-68da-452a-5710-08d5d525e78c X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4449 Archived-At: Subject: Re: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-11.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 14:15:20 -0000 All, The following changes have been made since version 10 as noted during IE= TF 101: Service-Endpoints eliminated. Service-Group and DPN interfaces changed to hold information previously held by Service-Endpoint as noted in *ML* during IETF 101. Scrubbed YANG for NMDA compliance and Guidelines (RFC 6087bis). Monitor lifecycle, ServiceGroup, policy and policy installation examp= les added. All examples updated to be consistent with any edits that were made. Other changes Service-Group resides under the Topology-Information-Mode The Domain now has a checkpoint and the Topology Information Model checkpoint was removed to avoid any overlaps in checkpoints. Monitor lifecycle, policy and policy installation examples added. Editing Thanks! Lyle > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, June 18, 2018 9:07 AM > To: i-d-announce@ietf.org > Cc: dmm@ietf.org > Subject: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-11.txt > > CAUTION: This email originated from outside of the organization. Do not c= lick > links or open attachments unless you recognize the sender and know the > content is safe. > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Distributed Mobility Management WG of th= e > IETF. > > Title : Protocol for Forwarding Policy Configuration (F= PC) in DMM > Authors : Satoru Matsushima > Lyle Bertz > Marco Liebsch > Sri Gundavelli > Danny Moses > Charles E. Perkins > Filename : draft-ietf-dmm-fpc-cpdp-11.txt > Pages : 152 > Date : 2018-06-18 > > Abstract: > This document describes a way, called Forwarding Policy Configuration > (FPC) to manage the separation of data-plane and control-plane. FPC > defines a flexible mobility management system using FPC agent and FPC > client functions. A FPC agent provides an abstract interface to the > data-plane. The FPC client configures data-plane nodes by using the > functions and abstractions provided by the FPC agent for the data- > plane nodes. The data-plane abstractions presented in this document > are extensible in order to support many different types of mobility > management systems and data-plane functions. > > > The IETF datatracker status page for this draft is: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr > acker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-fpc- > cpdp%2F&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7C2b411db4bf0a453 > 52d2a08d5d524d4fd%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C6 > 36649276530433038&sdata=3DwySdutjo24ubIZVgc5oHfunUE%2BF%2F%2BDl2h > kH5RVpjUy8%3D&reserved=3D0 > > There are also htmlized versions available at: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.= i > etf.org%2Fhtml%2Fdraft-ietf-dmm-fpc-cpdp- > 11&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7C2b411db4bf0a45352d2a > 08d5d524d4fd%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C636649 > 276530443048&sdata=3D0AqctjYJ09O4hkY97i059PxZb9p5rCcXynEpGY2NiSI%3D > &reserved=3D0 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr > acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-fpc-cpdp- > 11&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7C2b411db4bf0a45352d2a > 08d5d524d4fd%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C636649 > 276530443048&sdata=3DBHYt4WB00qZhor%2F0C2ZixuY0DNBkWjiekLvHcDCxfZo > %3D&reserved=3D0 > > A diff from the previous version is available at: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-dmm-fpc-cpdp- > 11&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7C2b411db4bf0a45352d2a > 08d5d524d4fd%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C636649 > 276530443048&sdata=3DPAg40E2Z8rnDV9QPKzewR0WEIG1OvZrtOgkA60oos2E > %3D&reserved=3D0 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fdmm&data=3D02%7C01%7Clyle.t.bertz%40s > print.com%7C2b411db4bf0a45352d2a08d5d524d4fd%7C4f8bc0acbd784bf5b5 > 5f1b31301d9adf%7C0%7C1%7C636649276530443048&sdata=3Dkub6vt76MbXEX > tBYvpoNvf0MPno2Y7zw6wxofjcLd4o%3D&reserved=3D0 ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Jun 18 09:27:42 2018 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 605A2130DDF; Mon, 18 Jun 2018 09:27:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152933925537.2709.344059573805579258@ietfa.amsl.com> Date: Mon, 18 Jun 2018 09:27:35 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-12.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:27:36 -0000 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 : Protocol for Forwarding Policy Configuration (FPC) in DMM Authors : Satoru Matsushima Lyle Bertz Marco Liebsch Sri Gundavelli Danny Moses Charles E. Perkins Filename : draft-ietf-dmm-fpc-cpdp-12.txt Pages : 152 Date : 2018-06-18 Abstract: This document describes a way, called Forwarding Policy Configuration (FPC) to manage the separation of data-plane and control-plane. FPC defines a flexible mobility management system using FPC agent and FPC client functions. A FPC agent provides an abstract interface to the data-plane. The FPC client configures data-plane nodes by using the functions and abstractions provided by the FPC agent for the data- plane nodes. The data-plane abstractions presented in this document are extensible in order to support many different types of mobility management systems and data-plane functions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-12 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-fpc-cpdp-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-fpc-cpdp-12 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/ From nobody Mon Jun 18 09:30:10 2018 Return-Path: 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 D3531130DDF for ; Mon, 18 Jun 2018 09:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 LyjCRa43lTPJ for ; Mon, 18 Jun 2018 09:29:59 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0094.outbound.protection.outlook.com [104.47.38.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B392130DE0 for ; Mon, 18 Jun 2018 09:29:59 -0700 (PDT) Received: from SN4PR0501CA0099.namprd05.prod.outlook.com (2603:10b6:803:42::16) by BN7PR05MB4196.namprd05.prod.outlook.com (2603:10b6:406:90::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.15; Mon, 18 Jun 2018 16:29:57 +0000 Received: from BY2NAM01FT009.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e42::209) by SN4PR0501CA0099.outlook.office365.com (2603:10b6:803:42::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.884.12 via Frontend Transport; Mon, 18 Jun 2018 16:29:56 +0000 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com; Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BY2NAM01FT009.mail.protection.outlook.com (10.152.68.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.863.11 via Frontend Transport; Mon, 18 Jun 2018 16:29:56 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id w5IFdCsn014212 for ; Mon, 18 Jun 2018 11:29:56 -0500 Received: from prewe13m04.ad.sprint.com (prewe13m04.corp.sprint.com [144.226.128.23]) by plsapdm1.corp.sprint.com with ESMTP id 2jn06xycsj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 18 Jun 2018 11:29:56 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Jun 2018 12:29:54 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1367.000; Mon, 18 Jun 2018 11:29:54 -0500 From: "Bertz, Lyle T [CTO]" To: "dmm@ietf.org" Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-12.txt Thread-Index: AQHUByFphZmEeidty0maMuPGz1ZPs6RmNKhQ Date: Mon, 18 Jun 2018 16:29:53 +0000 Message-ID: <605b69e92ad5488bb6f2e3667c3ca52a@plswe13m04.ad.sprint.com> References: <152933925537.2709.344059573805579258@ietfa.amsl.com> In-Reply-To: <152933925537.2709.344059573805579258@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.36; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(39380400002)(376002)(2980300002)(438002)(69234005)(13464003)(189003)(199004)(106002)(2351001)(102836004)(50466002)(46406003)(2900100001)(97736004)(106466001)(68736007)(5640700003)(229853002)(426003)(486006)(5660300001)(6916009)(26005)(186003)(476003)(126002)(2501003)(316002)(336012)(5250100002)(53936002)(5890100001)(6306002)(446003)(6246003)(47776003)(6346003)(356003)(8936002)(76176011)(14454004)(8746002)(86362001)(45080400002)(23726003)(3846002)(6116002)(11346002)(97756001)(575784001)(59450400001)(53546011)(478600001)(72206003)(1730700003)(2906002)(966005)(7736002)(81166006)(305945005)(108616005)(8676002)(7696005)(24736004)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4196; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM01FT009; 1:/nwcL4Pu/szkrLbJtsCjQtyTTouHnWlxAIfM3GmCqMdboIcrahbbuN7nZ0qa15gxFMYC2HaMksgYAOj49AoyjAQOWGI9renk1YZHuXgnf64srgvSjYfL0FjOFqiUnI3l X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0db7acee-347e-4cc6-e95a-08d5d538ba93 X-Microsoft-Antispam: UriScan:(18430343700868); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:BN7PR05MB4196; X-Microsoft-Exchange-Diagnostics: 1; BN7PR05MB4196; 3:pdlB0snR6aIftHpPo46230503puzQA9rgnj3uh7ieKWwjZLfZ8VD/4JdViYJ3VFwaoTC2rXMDc359IEIIPkzZeVWz071x70J43c1H559Yjc9MIMDHp1TOyv8mT68Fg6W5jBVVWywyeg1YGWqxDTbF3EufMMshUFLWWPaNhaVpnU7DOUAoN1yMgO2nlSY+1mffn8eTioLXnGr7Lmb40/LaBX3SMzEcKB70RofjVk9y/bnvIaOnNHNWNjnsgUf6Wog7V5IeiyGAWTK1o9doEUDuBkS0gKXkgZGSi+BXYAf2zlfaFw3/GtQmVAlFMe1geS6y2T/9FZMG0Q69/f1vyynOF9BAwtVUsAxXXIMNUxKS5tJAiS/S3rZ2olrORkucWpgJzphuzUOFEEwnfcp++9uhg==; 25:XWGdV/JwtTeK5po9U8nX5jbymWJU/5g+wqgLRNs9R0CwIq+ZI/tONYSuYyNSz00feJz72I1DDgFJtUos8AobUHv4ah40gGhLVaFISiJy6GHIFM4FuFvX/337dd5yM7jb5oi+5BB7jUzCU/NDB5cyAhZpJSgnaNMS/CB1u7TBfpQNUrb1qycwXu/DBweP5qqNteSKxKlKHl8PZMcEdmyyO/6QtCw9d4JDsMJ/MO1bx7RY/8vwF8PlPsiomjeMollqZtzhLGc3exzeaEvh5LtFy+X8gf17eQQgxtZIOGwbKtX/EQrRwooSDpe5axK+MXzbdrHoSgKKdEVX87yF70watQ== X-MS-TrafficTypeDiagnostic: BN7PR05MB4196: X-Microsoft-Exchange-Diagnostics: 1; BN7PR05MB4196; 31:Ut99eMEqduqaPOsl1MZcJ1PtKuD5wjc+dtNVnerffAdzaGtHY558lhKoHQYOGShNOmz/D0MTrmeCZZSviFyLy4uYkGEifyDwBLb7QBiNbqIFyCVwIavrDLAmEhHJsqERupBdrj0Z2uHJ5NMR8LxYvFAJxE5iI3arjdkOCazXSyk080NN4hbEjIeAZJ/RlODtRCkT2/KWNfv7hNcBS0mLBunrFkmhcgWWSLMCUpkZof8=; 20:9GkgV0CglKAt3wgw+OhL0pA3VdYEo27vDCAZPbf2we3dlhNmHo9gq9HSKkRzivoa3L9SibjLYBBRPbIA1xs8e6s9H9y6/qq09BebO8zwNb7I76tsBXGqbV5wstOm+CJaPL9Ksova7d8vqrFssiWTBC5k03pSEovQkaN/NP2EJ7UZJob4aaSvk8pQgrADqIEwcHCLIoqpUvi3hsDxIYbvUlyaHf9aW23B+Ez9eyE493qpE+LK7uFOvvhp5LYtQR7xlZkBp8rMz4MNh6id8hF+CLIkpCJoRnY++5QUascfk4hmG2axkERhsl8nLijrENjY6FqNRLaILaMN8vQ0MF9h4gFoptuUAF8l42SA3Y892EYANR+Zc51yEAvroAynkIqNQ+PFquNZG4Ri14Q7RrvawS93gZ360drA3MoXDLLw9z6LZSbUYb6ilU5dtqIB8KCvY7itSbPTDMCX9bAjlg7trt0Mt6xim6uSpUZUVNY4KT3qcaOcICyv6On9npEBik+1 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(18430343700868)(189930954265078)(219752817060721); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93004095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BN7PR05MB4196; BCL:0; PCL:0; RULEID:; SRVR:BN7PR05MB4196; X-Microsoft-Exchange-Diagnostics: 1; BN7PR05MB4196; 4:2f8O4m77Wiv08aTe81JTI2Bm0zHDrzEMTtfJ+ZKhW9hUKAe7YU+aMpj/Cy766bMY+OYHZq2++3oBkyJFwyn9Dr+nR5+vHHAysxfzYjvY/dh+skdx0Rur5YXFLKq0zMT+2S1vEgwwlDKgWTiLoMGzJtOz82WJvs1UxnjP5SxBiS7evdv/4fnCAlwkK7UmtVKDrFb5/i/fLH6qixfKR6+iWO7KDNhsfO2CnMrIou/bWQTW8j9vqFHcqV9jj1a/n3OmviF2y00ZtHY3oyr9b+NglOTVxX+P2x+FU5moUIrFGFeW4HebSdlQWHKP4WN6usJFHKwc6z7Sv6l0W8rdCkXQ53Se5/QhWvMjl6WALR8vqdprZzX/5qyikbvh7H3ZI80D X-Forefront-PRVS: 0707248B64 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN7PR05MB4196; 23:9kGXYp2mQkUlwYBYrpPMVUlcC+K4PmKu3jcKnOtzR?= =?us-ascii?Q?WRfOpbqTWcnp9xCWkxGCL/PJuz5MK43Dq99JEutdAWTLUoKsLLT62m7xQy+L?= =?us-ascii?Q?SY1rQTAUMIIRat+fiEtQRJ9bECtpY0ErZbsr1nGfosImHFk+vzxJoICwKUD8?= =?us-ascii?Q?cqbBrAgLXA0iHH7p1SZafH9OVM00LFbBztfj/klqCCGjXFJe8LBeFJ/O6K0U?= =?us-ascii?Q?cjnXmOB422AA2MTM9AH3FlxhvBwQgpz/W/hxjRsJzFmHWIMszM3MWnKhYkg3?= =?us-ascii?Q?eem8CennrIKXxAIvoIcm73NDGLeAvFY4PSEZlhqzEK90lhTlME4Ob5sntRFO?= =?us-ascii?Q?7+X+pZ1X5zcty6Z6jB2+6LGW3GhN55w8NEkWR6sz/gGrXDJ+mQs7/luymWF4?= =?us-ascii?Q?e3PFCahbbxnLcrW3S/0JQEiL4ufwcu3BB6SE7qAPeVrCvwiGA0fj4rfCVlUr?= =?us-ascii?Q?NDr78LmYSCklH8xZsMcFSbcOWhC+lx0sBwLgdLihBCa6KZBN/NLxJTbdXV9x?= =?us-ascii?Q?c+Dv2+qaupfJrImqZ8pUPQIyGNMgRydXzn4fXVKeiTbDaUiAFgkucY1hlc8U?= =?us-ascii?Q?/Hhye15MBsHqfIaKbOWFrsdNxapnN99NuHET5kR0tuxU8rxrMrpjz+AZVGuC?= =?us-ascii?Q?M1dfydFX1qhrQV/4KXMFnpB0iQRxh8PRWxqtaBhoCzc26VSmPhU11SxZFl3Z?= =?us-ascii?Q?N2mdbTfN4pzEB8aaWgTbGBcO+odwYbFiJoDn0P2/HJ+VhMeUgl35CWoHczJZ?= =?us-ascii?Q?hNkDOZlVOZTT0ZSdFZsTjggm8lBc2s3rD0no9Q3XHgjj1uDxJfBPGr8bftp8?= =?us-ascii?Q?oVT4SnfRPoPZZgyZwDC5JJw23k2QN4AiExqhQ3srS3nHpHIBV++d/ww7crkt?= =?us-ascii?Q?vQ+BaA4+PKYa2eRwqPW54Vg3ZSB6xdV/Nid7oiiTERcI19F/NXvncCKssJom?= =?us-ascii?Q?gBVp6pgHhVdsyC2OPsgMBkhedbk60Vef7wtYEmbeCxGFQ/NkSWf7dgWcoReD?= =?us-ascii?Q?XP/K9hdCRaWnr8WoTE3nDfZqVhisCdoR7RTPtEYAnPYPmvE3G4knkCOiyhQX?= =?us-ascii?Q?niNAAO/+aVBcsJ/fEOeDOW3gICsnlqcPm2GdHwjtb1f3d3OT9mmdB/ZLsbSw?= =?us-ascii?Q?Nth+1F+ES7bRYoNDx4wdDJuRhLUn52vcGmLvEyuweePqVPhjuqOKwsmtSDT+?= =?us-ascii?Q?+TuOZdS3zqtJ/W4CJWZmyZ/xCsPWLoi7Qn/DrNEXrIUz9Eu3JonZEbGLVmwH?= =?us-ascii?Q?/44vIM6BnpRNLfYYi6u+rwgbZ8Du65e+hl6OoJDmPj9gJ7s642H5KF8KEDh4?= =?us-ascii?Q?8SBbw8lnQYbHCilfmkhazy6I/BVL+EoTmW7Ra/x/eEM5T6Ah3gEsT+w1r/bg?= =?us-ascii?Q?dZucNQiWvx8K9nXevZ2TNCDjH0uqVk0sMJ6CwDUd2Ozdsr8l3OFLZAzkiEO8?= =?us-ascii?Q?BO64hL07Xw96rEIJYBB3HoU1Ec7b0sMF3Tdk9f25laDupV86Oe2IEO99XyPJ?= =?us-ascii?Q?odR68ixyLrrsCvt00VUK00tmP5yjQZJCh83MIlQVXSLqq4pdvHN6vvv?= X-Microsoft-Antispam-Message-Info: SRWZF21PpGXWbB4R1b0MNvTup1Vb48GNUjqFjINzaI9/WI8xBjGH6lKdvi19pZVxqlR/XKJstDOSCKQBA4tLRBaCMjNa+tFqRzmckVSWAabQBLLhdzeEwcDi48xjA/qCieG/5z7lp2y0gq7/Bg/2FWiqubtL98a6T5TO6MJugKAvyIp1/Jx/klziLMAqTM1pyqrhZdzrKJ8vbiTylltM+0PvYYBQQpQyN0M8rQYaW7gkN7RyXhkgAQ7XvSjKQVmNKGKC/5sNBosTBj5U7SeQaPBGXp9EMXb9d5LY6dTtHHoUusOLV711r/RH0cShTaYsYRkACjScwZwa2YIlPqa/ug== X-Microsoft-Exchange-Diagnostics: 1; BN7PR05MB4196; 6:cwQdzNILOZ53x7FVUms8Z3s8GjIt9Kehk5pWa3s+13W3Qm4R1O4nLAiNIknNKinmW9hJJRJoaOoxrVYRWaXvQYN5D/EEGurNNFz5d8E0wif2iu9djeOqoOVbpy1oFLhzGMoVrHvXOuwHzE1BJecHqMzoYPEkO4Ug5+Z0+9q4X/gM/PhBZ/Ee6jE6m1gZBWEAgiJ4r7dusw7q9kSf5vKAFtaMjgpH3YU1COhaEcEH/nXtJnFo7jOnNuRKuIJO5TWjptyqWfUnN/8JYThf0hYiouhyye3cuqrcFRmYT4xGNYgZHLcO8JyZnyzTxvNiq8M6BdYV/dYvJssyaXNj3UJlfIPzrg5uYyCRRcp62CzTwdGORTCjfGp6V512kGRY0liOqMSZezFXioJMdp4T46XfE9IQcMRlNdV0Ah54hz/bZIrN1pVOjRxTMOejz20HQvPas/KoIi5q6nKSveaJdm2duw==; 5:+3vHkkp//Fviwt4on3F9BOKES6gbAJ7B6/Fj3kEXfqmCPhnEagC2yOUw4j7g1dddwo+ew4vhlJ0iMQdrm3p2RyPgdGfQ3IZx/pmLl84DxqehEfDmgNPONed/Lvf3SgDaILesTUvAghGT3jJUKiQksg1OBS44rb7xQ3J/NPf4pF0=; 24:Dz/zvBXMEuqQiy+5pZeEs8uirj0VmsiTMW2JrUyB4VC6/tZCDj7aS1HbP326bz5vxt+kb+TnJO9UiNsDwJaQUt3yh4Qtn1wtyIsFjQVOUCA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN7PR05MB4196; 7:QxmBE8z6bPH5i6u46rjbW1DDQAQ0mRfRGLooWJDvVLj7O77f0VDz9BQPwY5l4nMVoioime7VBB5rSeyM0vqFgaRxXimzI8D1SZoMytYGyJRhjmevz2udJQWr2G0ZNQSlgJUAqlEGcVSNcd8V4nU/qxTZiVFCCNsChajKDO+LE3nMPmEl4S2vNOUQhiKwlYZBgTJwQZJ9fTz1mXyhqNqQAy4iRgnpj9Vugt0wG/wrNnelCw4h3ZLD85Twceg5PMHT X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2018 16:29:56.6058 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0db7acee-347e-4cc6-e95a-08d5d538ba93 X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4196 Archived-At: Subject: Re: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-12.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:30:08 -0000 FYI - This is a YANG fix for default config statements to be consistent wit= h NMDA statements made in the Appendix. Apologies for the submission spam. Please look at the version 11 diff for = substantive updates. Lyle > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, June 18, 2018 11:28 AM > To: i-d-announce@ietf.org > Cc: dmm@ietf.org > Subject: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-12.txt > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > > 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 th= e > IETF. > > Title : Protocol for Forwarding Policy Configuration (F= PC) in DMM > Authors : Satoru Matsushima > Lyle Bertz > Marco Liebsch > Sri Gundavelli > Danny Moses > Charles E. Perkins > Filename : draft-ietf-dmm-fpc-cpdp-12.txt > Pages : 152 > Date : 2018-06-18 > > Abstract: > This document describes a way, called Forwarding Policy Configuration > (FPC) to manage the separation of data-plane and control-plane. FPC > defines a flexible mobility management system using FPC agent and FPC > client functions. A FPC agent provides an abstract interface to the > data-plane. The FPC client configures data-plane nodes by using the > functions and abstractions provided by the FPC agent for the data- > plane nodes. The data-plane abstractions presented in this document > are extensible in order to support many different types of mobility > management systems and data-plane functions. > > > The IETF datatracker status page for this draft is: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr > acker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-fpc- > cpdp%2F&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7Cbafa5ea885524c > db9ab808d5d53888c9%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1% > 7C636649361159769899&sdata=3DuqAllFzyY5vSwRqzBeVTuPaNq%2BFUDIEqg > eliqcAYa7Y%3D&reserved=3D0 > > There are also htmlized versions available at: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.= i > etf.org%2Fhtml%2Fdraft-ietf-dmm-fpc-cpdp- > 12&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7Cbafa5ea885524cdb9ab8 > 08d5d53888c9%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C6366 > 49361159769899&sdata=3DOSmW7IzcLUxZomr8EiBhf8%2FbifZWF3LBA1Zlfxru > gOs%3D&reserved=3D0 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr > acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-fpc-cpdp- > 12&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7Cbafa5ea885524cdb9ab8 > 08d5d53888c9%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C6366 > 49361159769899&sdata=3DDxNQ8Z4GXI20s61WdgaogAA1tCQS9Zqi3bXUraYR > 6Xo%3D&reserved=3D0 > > A diff from the previous version is available at: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-dmm-fpc-cpdp- > 12&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7Cbafa5ea885524cdb9ab8 > 08d5d53888c9%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C6366 > 49361159769899&sdata=3DDIC5VjKMh%2BIo%2FnYXtsAZSfxXUhvO053bQOet4 > Dib8xQ%3D&reserved=3D0 > > > 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://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fdmm&data=3D02%7C01%7Clyle.t.bertz%40 > sprint.com%7Cbafa5ea885524cdb9ab808d5d53888c9%7C4f8bc0acbd784bf5 > b55f1b31301d9adf%7C0%7C1%7C636649361159769899&sdata=3DO44%2B2IE > HepRltTBF6qxgF1zqHtzZNvRtmD5AO6MFraM%3D&reserved=3D0 ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Tue Jun 19 02:46:47 2018 Return-Path: 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 3588B1310CA for ; Tue, 19 Jun 2018 02:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Wzi6YHpsMNp3 for ; Tue, 19 Jun 2018 02:46:43 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1BA130DC5 for ; Tue, 19 Jun 2018 02:46:43 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id x6-v6so7045551ybl.12 for ; Tue, 19 Jun 2018 02:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=haNp0w2wRh6ZYqz4nlsq0mq07N5WOzRG954iVoshYPw=; b=GicbzNBlpdE6gf6ptNCMZzWvhRhP6kQIeq4a4Rj93PZPKueXFwP48JkujCcTQUbrYQ uf4G5yhW/S4TpYzXcv3kpyW97TtmLmsbOw1BoLWZHJI+0IZsZvMvsXW27Pu/AHkUChkR fLqFErjja+83NnNhA4ENRRI5m388pNIXBgS22d1CGONdNK9Blrw87H8ycUv0aL6QvfBG w7BqGGISWcsxc9rDrVAZ9XzlQSrVaH8gnH+o/Jo/C1GMNrUTSWoWl2v1fX9Z5lVHHLMr Mc3UAqPC7mRpXfQEf1u15zdUJIt/gGWK+NdqyFIe8RCTZsaivSZ1h7e1ttZI7hTHQGYY w0lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=haNp0w2wRh6ZYqz4nlsq0mq07N5WOzRG954iVoshYPw=; b=pECNd6w6MYP/BrD3LRjUjN2/nmE3c8qeFMLs2imWgiDXFldRkIKpWRNi0wH21X1bVq ZPaCECp48MwEgMEM21P6ESSo2vyGZsG9Gtyc3sqbjz12moafUeMluw8jEM8BDmW80e1s 9UCHBPZ5WVu5fIL9wWeQAffXjskCMdiXVy3LrIIRVuYF51hGfCei1ZKJWz0kk9u4sjkx teq0JS7Q4SqM5TuO1SYosfsyZRZtTZXEl7dDbGZTfjwKaVp0ooVzY8AJdmWm4oS8ZJ+I m0LhWUiZihw35cBmJhWIzqpgUZCqjXjC9muV6TepM4FJFhz1XCmIWwjv/QTqzN58vii0 fwWQ== X-Gm-Message-State: APt69E2olJOhq2hN+B2d6NzFGSgoQbHy35klt0QsISlx9RlaquSaVBAU vC/u5vpnUJsLbAVfrydyGoYJXE8lxAv6y2dHPIgkSg== X-Google-Smtp-Source: ADUXVKIsJYU06ynR7I2kXIVelBJhAleLm+U5CW5Nt9Lgh1nTTWifwkCDUSlyUOsrvbRG3y8aJpBjrb3e9MobFaErB2E= X-Received: by 2002:a25:1a45:: with SMTP id a66-v6mr477182yba.268.1529401602479; Tue, 19 Jun 2018 02:46:42 -0700 (PDT) MIME-Version: 1.0 From: Luca Muscariello Date: Tue, 19 Jun 2018 11:46:31 +0200 Message-ID: To: dmm@ietf.org Cc: Luca Muscariello Content-Type: multipart/alternative; boundary="0000000000003c1c35056efb8f70" Archived-At: Subject: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 09:46:45 -0000 --0000000000003c1c35056efb8f70 Content-Type: text/plain; charset="UTF-8" Hi all, the draft below has been posted and describes deployments options for anchorless mobility management by using the hicn network architecture that implements icn semantics in IPv6 networks. https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ A background document has been posted to the internet area WG and reported here for your convenience. The core principle behind hicn and mobility management is that data sources are named using location independent names encoded in IPv6 addresses. The transport service sitting on top of the hicn architecture is not based on usual TCP/UDP sockets but on a novel consumer/producer transport service that will be described in another draft. The current document and a companion document that will be posted soon describe the different deployment options with special care to the 5G service based architecture. Thanks for the comments already received that helped completing this -00 draft. Luca --0000000000003c1c35056efb8f70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

the draft below has been posted = and describes deployments options for anchorless mobility management=C2=A0 = by using
the hicn network architecture that = implements icn semantics in IPv6 networks.
<= br>
A background document has been posted to the int= ernet area WG and reported here for your convenience.
The core principle behind hicn and mobility management is t= hat data sources are named using location independent names
encoded in IPv6 addresses. The transport service sitt= ing on top of the hicn architecture is not based on usual TCP/UDP sockets= =C2=A0
but on a novel consumer/produce= r transport service that will be described in another draft.=C2=A0
The current document and a companion document = that will be posted soon describe the different deployment options=C2=A0
with special care to the 5G service base= d architecture.
Thanks for the comment= s already received that helped completing this -00 draft.

Luca





--0000000000003c1c35056efb8f70-- From nobody Tue Jun 19 12:26:46 2018 Return-Path: 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 25D80130E1B for ; Tue, 19 Jun 2018 12:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 IOLpxJ9SdaAQ for ; Tue, 19 Jun 2018 12:26:43 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2619F130DCA for ; Tue, 19 Jun 2018 12:26:43 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id l41-v6so786068wre.7 for ; Tue, 19 Jun 2018 12:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NdFvt5DOqlGo4gTKoFg5r+vuXTd1SBLfdfg+KU4PcLE=; b=rHery79ggbq0yabvNQomBktyKBQd4bb1DvvSjFfSD8V/NYcJskEdp8NLvDSf/pJjLG CTv434H7VC1b0c/m+40+83ZzlUE7zWcjO0+PmK8day7cGT7SGCwrgRVCUinF4PszW8Ed d7dKSSo03XFxWBYaNGJMt1K4K0TBWA/UOAT6J7q4ee9mdgMcQsJSZcW15ysiR2qs1X9U s/u5kIWw6vdS1ZSfIsMJPojzamOIPcvAdm50jhF5INHqFp0s6JroczdmfU86ee7cCpwN 2pzRYDMf8oluGbKx29Be3NwM5eIn6p1FjgIT37jfbqwdzUKei6qMfXeIJblBMljOapDE NCSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NdFvt5DOqlGo4gTKoFg5r+vuXTd1SBLfdfg+KU4PcLE=; b=dJcT8S4PKKlc7uHROviy2nG2O289HnGsWh7HcH8X8uuvqvKMxQhCygvt7PR4k3Omqk a0XYKymtVF6CvEJYwWeFFvewhtd5vA/EovGyWg1g4576Pzm34W3RVRpM5y+/Ebh187R+ qAvXqmQ35in+fBtYHh9XiXL/R2kimVunWFUqO8eifnTwFH+tFXuZA9ZiASzHABulMwhW Tf2FvLOR9syxFHAlteappsxfccRAearmakzjpNc25hImf9xMdhCdys4Mw5gkTVIPyZ0+ +oj0QvKKnF/C/UJ6QvT6Kx5JcDih1BDGdvOcWacz4IxJnupwepqWjAVFO9c1U9BU6MZ6 ebRg== X-Gm-Message-State: APt69E0vZnv3BiQwRlvfiHeqAzSc0oTbMqIXMc4SDunf36lzCO4aMIuG yMRtS0ziONC4+t95pWhudfrbRxfgBzfFmpsuLZif+g== X-Google-Smtp-Source: ADUXVKL7Z7hJQ4XGGJ6K20agnz2luVUQJH9dt3l4IAeSjJ6DNTH59Pv7Xoq+Y+sA964/LxqNtrNCo/E8EV5LYwl1OFg= X-Received: by 2002:adf:a20a:: with SMTP id p10-v6mr15153394wra.196.1529436401456; Tue, 19 Jun 2018 12:26:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:f9d2:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 12:26:41 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Tue, 19 Jun 2018 12:26:41 -0700 Message-ID: To: Luca Muscariello Cc: dmm , Luca Muscariello Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 19:26:45 -0000 On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello wrote: > Hi all, > > the draft below has been posted and describes deployments options for > anchorless mobility management by using > the hicn network architecture that implements icn semantics in IPv6 > networks. > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options > > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ > > A background document has been posted to the internet area WG and reported > here for your convenience. > The core principle behind hicn and mobility management is that data sources > are named using location independent names > encoded in IPv6 addresses. The transport service sitting on top of the hicn > architecture is not based on usual TCP/UDP sockets > but on a novel consumer/producer transport service that will be described in > another draft. >From the draft: "The transport end-point offers two kinds of services to applications: a producer and a consumer service. The service is instantiated in the application by opening communication sockets with an API to perform basic transport service operations: allocation, initialization, configuration, data transmission and reception." This seems like a pretty dramatic rethink of the transport layer just for the purposes of mobility management. Will there be a way to use hICN at the network layer with exsiting and unmodified transport protocols (i.e. can this be done without boiling the ocean)? Thanks, Tom > The current document and a companion document that will be posted soon > describe the different deployment options > with special care to the 5G service based architecture. > Thanks for the comments already received that helped completing this -00 > draft. > > Luca > > > > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Tue Jun 19 13:51:00 2018 Return-Path: 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 BE7B5130F2D for ; Tue, 19 Jun 2018 13:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=gmail.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 mftmEcD7d1KE for ; Tue, 19 Jun 2018 13:50:55 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC393130F27 for ; Tue, 19 Jun 2018 13:50:54 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id t198-v6so401178ywc.3 for ; Tue, 19 Jun 2018 13:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m46BvlAklC1FZi3nq1M9oTHm1YtySFU/7wmvO+6I1F8=; b=LIszBfOfHiqAbtkDVjxp9SV+ahi30BexbclTapdhQAPGBDFT+Mtnz8czVx/XCR+17z y3IjWyCm4mym/lhmpoqahoyON+S5qx34gj0IrSQsWng3yV9myO1YzgeAFG8SkoPd1RD4 euDpELYtWLZYMyOz9bzD9Jv0DL/2eflV78r5jUTkd2dyYV4s8JmevP81+iBb1j/ZW/Ge cDm+pylf0AR+CtJMy5Ru4swhtG+WFKCXs4FlFaPjMxEq8IjRr/S0R41+YS/3qXMOMPzO 3Bjoem5y4jNv8xg7WWZXfJVp+XIdGQzpr7QKNZfIhh4eD68oYreXmOkEPSa/i+AOEuL0 /M2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m46BvlAklC1FZi3nq1M9oTHm1YtySFU/7wmvO+6I1F8=; b=sWNfyLXG1zUecoAL1feOQ0DJP1hkOIGuSSqynNVOCYFVbisMg1ESI4VDucDV/R2f/T gtA+dmCABUOCxZcyHmwRv+rfBSy+NOkcZXki/pV0i427bK3UNyMaLE2UOmgRmusYiXzc 3PevXIMFSAOE/t9ESctq9dB2yhwCl8gcN3EFycTqNu694criRvlY+5wRzTetG1lqVYUE BZ+/lVZfIvfMEWizI0BRg0Vjf/LzzdWS0gQSeaVp5Vw5NNW8Wnxl4p8u9kAg5y7eMKWi N11GBvlU6ftzhfKpkNJPZoLAEaDdFaEqWGdmSs2YWaTjnJZ/8CSZ8OApP/95XDRY5vAL oNSA== X-Gm-Message-State: APt69E0klz+W6rBfnH3mauSX/QVit8cjRwDkP8ETV/Wp7ZqAw27Qcfcg 18QbVx1o+vwREosWTmRJduw+LCOuplTxDRY/uxI= X-Google-Smtp-Source: ADUXVKIrGUvRrjgc+4HzC99YiVg3puv47ZfxHZxUyqLqZizFGAqn0AlHkYbX57zLyvEa8Lt2Q711laq41WCRmkBtr/c= X-Received: by 2002:a81:a316:: with SMTP id a22-v6mr7414693ywh.142.1529441454060; Tue, 19 Jun 2018 13:50:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Luca Muscariello Date: Tue, 19 Jun 2018 22:50:42 +0200 Message-ID: To: tom@quantonium.net Cc: dmm@ietf.org, Luca Muscariello Content-Type: multipart/alternative; boundary="00000000000092fa15056f04d694" Archived-At: Subject: Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:50:58 -0000 --00000000000092fa15056f04d694 Content-Type: text/plain; charset="UTF-8" The paragraph you reported is from the draft that describes hICN to enable several use cases. Mobility is one of those, not the only one. To clarify, the draft on hICN mobility deployment options focuses on the 5G service based architecture. You may be asking 1) is it possible to get all the features provided by hICN w/o updates to the transport layer? 2) is changing the transport protocol unnecessary difficult to enable all the use cases mentioned in the draft? IMO, the answers are no for both. Luca On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert wrote: > On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello > wrote: > > Hi all, > > > > the draft below has been posted and describes deployments options for > > anchorless mobility management by using > > the hicn network architecture that implements icn semantics in IPv6 > > networks. > > > > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options > > > > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ > > > > A background document has been posted to the internet area WG and > reported > > here for your convenience. > > The core principle behind hicn and mobility management is that data > sources > > are named using location independent names > > encoded in IPv6 addresses. The transport service sitting on top of the > hicn > > architecture is not based on usual TCP/UDP sockets > > but on a novel consumer/producer transport service that will be > described in > > another draft. > > From the draft: "The transport end-point offers two kinds of services > to applications: a producer and a consumer service. The service is > instantiated in the application by opening communication sockets with > an API to perform basic transport service operations: allocation, > initialization, configuration, data transmission and reception." > > This seems like a pretty dramatic rethink of the transport layer just > for the purposes of mobility management. Will there be a way to use > hICN at the network layer with exsiting and unmodified transport > protocols (i.e. can this be done without boiling the ocean)? > > Thanks, > Tom > > > > > The current document and a companion document that will be posted soon > > describe the different deployment options > > with special care to the 5G service based architecture. > > Thanks for the comments already received that helped completing this -00 > > draft. > > > > Luca > > > > > > > > > > > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > --00000000000092fa15056f04d694 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The paragraph you reported is from the draft that des= cribes hICN to enable several use cases.
Mobility is one of those= , not the only one.=C2=A0
To clarify, the draft on hICN mobility = deployment options focuses on the 5G service based architecture.=C2=A0

You may be asking=C2=A0
1) is it possible to= get all the features provided by hICN w/o updates to the transport layer?<= /div>
2) is changing the transport protocol unnecessary difficult to en= able all the use cases mentioned in the draft?

IMO= , the answers are no for both.

Luca

=
On Tue, Jun 19, 2018 at 9:26 PM= Tom Herbert <tom@quantonium.net> wrote:
On Tue, Jun 19, 2018 = at 2:46 AM, Luca Muscariello
<luca.mu= scariello@gmail.com> wrote:
> Hi all,
>
> the draft below has been posted and describes deployments options for<= br> > anchorless mobility management=C2=A0 by using
> the hicn network architecture that implements icn semantics in IPv6 > networks.
>
> https://datatra= cker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options
>
> https://datatracker.ietf.org/do= c/draft-muscariello-intarea-hicn/
>
> A background document has been posted to the internet area WG and repo= rted
> here for your convenience.
> The core principle behind hicn and mobility management is that data so= urces
> are named using location independent names
> encoded in IPv6 addresses. The transport service sitting on top of the= hicn
> architecture is not based on usual TCP/UDP sockets
> but on a novel consumer/producer transport service that will be descri= bed in
> another draft.

>From the draft: "The transport end-point offers two kinds of services<= br> to applications: a producer and a consumer service. The service is
instantiated in the application by opening communication sockets with
an API to perform basic transport service operations: allocation,
initialization, configuration, data transmission and reception."

This seems like a pretty dramatic rethink of the transport layer just
for the purposes of mobility management. Will there be a way to use
hICN at the network layer with exsiting and unmodified transport
protocols (i.e. can this be done without boiling the ocean)?

Thanks,
Tom



> The current document and a companion document that will be posted soon=
> describe the different deployment options
> with special care to the 5G service based architecture.
> Thanks for the comments already received that helped completing this -= 00
> draft.
>
> Luca
>
>
>
>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
--00000000000092fa15056f04d694-- From nobody Tue Jun 19 15:30:28 2018 Return-Path: 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 B3E7E130F7E for ; Tue, 19 Jun 2018 15:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 5E23pmfPIdE0 for ; Tue, 19 Jun 2018 15:30:24 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8068A130E4A for ; Tue, 19 Jun 2018 15:30:24 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id p11-v6so3217927wmc.4 for ; Tue, 19 Jun 2018 15:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9SZ9beec/0XTGdAJpwR9vvosiGvhwDN/5lbK+1enhJw=; b=czvTyQcgV8Xyb5AsnOAM/yObke5S368JocmOEtGFzIBKb9f0BO3JEyjOBfuSAwEd43 0JfaH6ZUA7OeLU/Ynj+YYieXHVIfSgaxbvvQXsxRvCumZ9nw/i8rVTJOyf8pPRdBVdit 3e+FVrw18KvvrLOy48aXw7oG3I4k+WmtaCLtY8ZkFGsyXh6H4orTLY867CFyuFQiv8o0 h85wQMtBbIwut645IdUqGwtVedjnI59KmOm5WT7OfIo7hu8B104P4S1KgMGBuGj7Tqi/ PoCs7GiUL+u31UKOryDmmJ5Oj2fqouuhIB2YQqJqF5i9uRg9f0wMZPneSTURKmcZNomn cEng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9SZ9beec/0XTGdAJpwR9vvosiGvhwDN/5lbK+1enhJw=; b=cR8VbkWXDJT+XsJHIIhHV7oDlHPytbftEq5nuNKPRmE5c6t4shS7Zml/Fr85t3wKqC CI2sSWyzhJjEnJOtrwpnyymaAEa9jeqeIVOkWiPiMEhzxOaPoxvRkV8OfamMH6Sj3PAb mppR6MVjE+pUhHbpjsQooC7JiGhsmIcSEEzCxam/hmqIO7K4j2IqjOZrwNJYkc4H3PW7 BVzoeh2WvqddzdSmr4DFJoTYuHNFIOEMouW/3QALL05IVo+xyHv8b3AjDp3Tv0MAik1Y wnnleATUsD+aRgxab4S0UPWu6Dq1L2an45rvGio6EjOhZYvq8/FHkQPXXv824gu7CAxw jcdA== X-Gm-Message-State: APt69E2wdmbVMVOnJg49hELqBR+aZ+RHRrYCPj8t5cckUMKiGo/04SHl dfR/o2upgsGUTnQL6crwghKVosWDJWhJxY8tdSHRRQ== X-Google-Smtp-Source: ADUXVKLzVhZEoHxbmg6WJ1V01q6nnDJTL+cNUMbytXCpw/16O02TXAaNp8mo3v1ZKk70F69r7uRaYIeC8tz0V6bPgEU= X-Received: by 2002:a1c:6dd3:: with SMTP id b80-v6mr12550859wmi.32.1529447422976; Tue, 19 Jun 2018 15:30:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:f9d2:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 15:30:22 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Tue, 19 Jun 2018 15:30:22 -0700 Message-ID: To: Luca Muscariello Cc: dmm , Luca Muscariello Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 22:30:27 -0000 On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello wrote: > The paragraph you reported is from the draft that describes hICN to enable > several use cases. > Mobility is one of those, not the only one. > To clarify, the draft on hICN mobility deployment options focuses on the 5G > service based architecture. > > You may be asking > 1) is it possible to get all the features provided by hICN w/o updates to > the transport layer? > 2) is changing the transport protocol unnecessary difficult to enable all > the use cases mentioned in the draft? > Sorry, but I'm still missing something fundamental here. AFAICT, the idea of hICN is to put routes in the local routing table and use existing forwarding and routing to forward packets to mobile nodes. So if a node changes location, then the routing tables need to be updated. Effectively this is a bunch of host routes that need to be maintained. At least this is what I gather from the draft: "hICN network layer is about using the IPv6 FIB to determine a next hop router to forward requests or using a local packet cache to determine if an incoming request can be satisfied locally." Is this correct? If it is, then I sort of understand how hICN could be used for mobility or virtualization without network overlays, but then I'm completely lost as to why this would require any changes in the transport layer. Tom > IMO, the answers are no for both. > > Luca > > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert wrote: >> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >> wrote: >> > Hi all, >> > >> > the draft below has been posted and describes deployments options for >> > anchorless mobility management by using >> > the hicn network architecture that implements icn semantics in IPv6 >> > networks. >> > >> > >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options >> > >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >> > >> > A background document has been posted to the internet area WG and >> > reported >> > here for your convenience. >> > The core principle behind hicn and mobility management is that data >> > sources >> > are named using location independent names >> > encoded in IPv6 addresses. The transport service sitting on top of the >> > hicn >> > architecture is not based on usual TCP/UDP sockets >> > but on a novel consumer/producer transport service that will be >> > described in >> > another draft. >> >> From the draft: "The transport end-point offers two kinds of services >> to applications: a producer and a consumer service. The service is >> instantiated in the application by opening communication sockets with >> an API to perform basic transport service operations: allocation, >> initialization, configuration, data transmission and reception." >> >> This seems like a pretty dramatic rethink of the transport layer just >> for the purposes of mobility management. Will there be a way to use >> hICN at the network layer with exsiting and unmodified transport >> protocols (i.e. can this be done without boiling the ocean)? >> >> Thanks, >> Tom >> >> >> >> > The current document and a companion document that will be posted soon >> > describe the different deployment options >> > with special care to the 5G service based architecture. >> > Thanks for the comments already received that helped completing this -00 >> > draft. >> > >> > Luca >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > dmm mailing list >> > dmm@ietf.org >> > https://www.ietf.org/mailman/listinfo/dmm >> > From nobody Tue Jun 19 16:05:49 2018 Return-Path: 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 3EFB41311C7 for ; Tue, 19 Jun 2018 16:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 o4HcjT6YSRi4 for ; Tue, 19 Jun 2018 16:05:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EA21311D4 for ; Tue, 19 Jun 2018 16:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6615; q=dns/txt; s=iport; t=1529449537; x=1530659137; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IUN4Su9I8mFVI52wCgMumnoUoVUMOpbh38du+SZl8ww=; b=TLYln2wa3gwCg4PZpI3ISu+KV1+bWqJcJGrsMipQbB7vC2sRanddjGuP OEfoSFldVZwP4TFwwkDR6y4KN62MPf+TIy/sh/unf3OrNrKAatdAh2lms 8jZhznLXW4Mn3oDNZZt8/O+nDMc2PtoNuj1bde6LSUSHAvtgSRCk7t8kl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsAAAriylb/5pdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNJYn8oCotzjFOCAIQ3g2uMWRSBZAsYDYRHAoJuITQYAQI?= =?us-ascii?q?BAQEBAQECbRwMhSgBAQEBAgEBAWwLBQsCAQgRAQMBAQEJGgsPEgYLFwYIAgQ?= =?us-ascii?q?BDQWDJoFnAw0ID60shxENgSxoBYIthieBVD+EG4FUfUIBAQIBAYEgPIVWAow?= =?us-ascii?q?+Oot7LAkChXuGCYMJjT2KFU2GSgIREwGBJB04gVJwFTuCQ4JJiEiFPm+LM4E?= =?us-ascii?q?aAQE?= X-IronPort-AV: E=Sophos;i="5.51,245,1526342400"; d="scan'208";a="412698921" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2018 23:05:36 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w5JN5aWv027859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2018 23:05:36 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 19 Jun 2018 18:05:36 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Tue, 19 Jun 2018 18:05:36 -0500 From: "Giovanna Carofiglio (gcarofig)" To: Tom Herbert , Luca Muscariello CC: "Luca Muscariello (lumuscar)" , dmm Thread-Topic: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options Thread-Index: AQHUB7J1ia0nsa1DZU6+Bs7zHD1LjqRoS1OAgAAXeQCAABvZAP//rP8m Date: Tue, 19 Jun 2018 23:05:36 +0000 Message-ID: <1529449536100.38092@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.84.43] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:05:44 -0000 =0A= ________________________________________=0A= From: dmm on behalf of Tom Herbert =0A= Sent: Wednesday, June 20, 2018 12:30 AM=0A= To: Luca Muscariello=0A= Cc: Luca Muscariello (lumuscar); dmm=0A= Subject: Re: [DMM] New draft posted: Anchorless mobility management through= hICN (hICN-AMM): Deployment options=0A= =0A= On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello=0A= wrote:=0A= > The paragraph you reported is from the draft that describes hICN to enabl= e=0A= > several use cases.=0A= > Mobility is one of those, not the only one.=0A= > To clarify, the draft on hICN mobility deployment options focuses on the = 5G=0A= > service based architecture.=0A= >=0A= > You may be asking=0A= > 1) is it possible to get all the features provided by hICN w/o updates to= =0A= > the transport layer?=0A= > 2) is changing the transport protocol unnecessary difficult to enable all= =0A= > the use cases mentioned in the draft?=0A= >=0A= Sorry, but I'm still missing something fundamental here. AFAICT, the=0A= idea of hICN is to put routes in the local routing table and use=0A= existing forwarding and routing to forward packets to mobile nodes. So=0A= if a node changes location, then the routing tables need to be=0A= updated. Effectively this is a bunch of host routes that need to be=0A= maintained. =0A= =0A= =0A= GC/ That is a misunderstanding here, hICN mobility management is not based = on routing updates/host routes to be maintained. There is no routing of dat= a back to the users, rather data packets follow reverse path of requests. = Hopefully the publication of the yet-to-be-published hICN mobility draft wi= ll clarify that, but just to summarize here, the basic idea of hICN is=0A= =0A= 1) routing/forwarding based on location-independent identifiers (ICN's idea= ) encoded into IP addresses (the h in hICN)=0A= 2) connectionless request/reply transport model : only known end-point is t= he receiver, source(s) is(are) dynamically discovered, path is a priori unk= nown =0A= 3) richer forwarding exploiting lookup-by-name features in buffer (for cach= ing, request aggregation,/multicast, in network congestion control etc) and= dynamic hop-by-hop decisions based on name-based forwarding strategies =0A= =0A= Mobility advantages come from all three points above: consumer mobility is = handled by design (no change to host routes, data flow back on the reverse = path of requests), producer mobility can be handled through localized forwa= rding updates (MapMe protocol described in hICN drafts is one possibility) = at a much faster timescale than that of routing updates and without requiri= ng any UP/CP anchor. =0A= =0A= Since it does not rely on routing updates such approach can minimize latenc= y and track producer (while cached copies are not enough) in realtime at ne= twork latency but also support infrastructure-less communication when neede= d.=0A= =0A= Name/location binding, route re-computation, tunneling, anchoring are not d= one here.=0A= =0A= Coexistance with existing CP and transparent interconnection with the rest= of infrastructure is accounted by design in the h of hICN (described in th= e hICN draft), benefits/costs wrt hICN deployment penetration is discussed = in the deployment options draft, but in all cases we assume 1)-2)-3) in hIC= N-enabled endpoints. =0A= Of course you could think about partial integration of ICN into IP that kee= p pieces of it (eg naming/forwarding) neglecting others (transport as you s= ay): as explained in the draft that comes at the cost of losing many advant= ages as showed by previous work, so we do not recommend it. =0A= =0A= Hope it help clarify your doubts.=0A= =0A= Giovanna =0A= =0A= =0A= =0A= =0A= =0A= =0A= > IMO, the answers are no for both.=0A= >=0A= > Luca=0A= >=0A= > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert wrote:= =0A= >>=0A= >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello=0A= >> wrote:=0A= >> > Hi all,=0A= >> >=0A= >> > the draft below has been posted and describes deployments options for= =0A= >> > anchorless mobility management by using=0A= >> > the hicn network architecture that implements icn semantics in IPv6=0A= >> > networks.=0A= >> >=0A= >> >=0A= >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployme= nt-options=0A= >> >=0A= >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/=0A= >> >=0A= >> > A background document has been posted to the internet area WG and=0A= >> > reported=0A= >> > here for your convenience.=0A= >> > The core principle behind hicn and mobility management is that data=0A= >> > sources=0A= >> > are named using location independent names=0A= >> > encoded in IPv6 addresses. The transport service sitting on top of the= =0A= >> > hicn=0A= >> > architecture is not based on usual TCP/UDP sockets=0A= >> > but on a novel consumer/producer transport service that will be=0A= >> > described in=0A= >> > another draft.=0A= >>=0A= >> From the draft: "The transport end-point offers two kinds of services=0A= >> to applications: a producer and a consumer service. The service is=0A= >> instantiated in the application by opening communication sockets with=0A= >> an API to perform basic transport service operations: allocation,=0A= >> initialization, configuration, data transmission and reception."=0A= >>=0A= >> This seems like a pretty dramatic rethink of the transport layer just=0A= >> for the purposes of mobility management. Will there be a way to use=0A= >> hICN at the network layer with exsiting and unmodified transport=0A= >> protocols (i.e. can this be done without boiling the ocean)?=0A= >>=0A= >> Thanks,=0A= >> Tom=0A= >>=0A= >>=0A= >>=0A= >> > The current document and a companion document that will be posted soon= =0A= >> > describe the different deployment options=0A= >> > with special care to the 5G service based architecture.=0A= >> > Thanks for the comments already received that helped completing this -= 00=0A= >> > draft.=0A= >> >=0A= >> > Luca=0A= >> >=0A= >> >=0A= >> >=0A= >> >=0A= >> >=0A= >> >=0A= >> > _______________________________________________=0A= >> > dmm mailing list=0A= >> > dmm@ietf.org=0A= >> > https://www.ietf.org/mailman/listinfo/dmm=0A= >> >=0A= =0A= _______________________________________________=0A= dmm mailing list=0A= dmm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dmm=0A= From nobody Tue Jun 19 16:21:20 2018 Return-Path: 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 565AF131001; Tue, 19 Jun 2018 16:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=gmail.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 ciNpMYBaPYQI; Tue, 19 Jun 2018 16:21:16 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353591311F4; Tue, 19 Jun 2018 16:21:16 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id e84-v6so564213ybb.0; Tue, 19 Jun 2018 16:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H6dXYQpxHohKqEVeK4ymVmAYhgIoKQF2we9TPWUYS8M=; b=BN5i+YM3ILK7kkEfKVmQ+4KbI6IT43vZbRAN9xEII2bJxclu7dApevt6G5YaUB+jVk pcFXCj9nX97rgmcA5RUxjEyhiAcVdMmB1JmHtLspWacUnquZYz+bp0QWtKNfyroGKUKh PPlj5+hD44VmWMwoZ7WUY47LeeK6v5T6kCmtogAwScmOgL25SoKMiiic+W1ofjBCFQo/ W9iVJHZUgjJA29598wtlGAM/N8bhXAS5li08ExiiK1xXe7eHAPpArcXKHni0On3DjuzF NZjKYWLd2flwnqHhTqq8X385Ln03PIfZIRs5BGcp1rYho7CaTRBrWdMOEnSqpSZvuRZo unNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H6dXYQpxHohKqEVeK4ymVmAYhgIoKQF2we9TPWUYS8M=; b=li22JJ2kXxiM8a56sKTZGGtGSdPIbQ9HJUyjpmPn/WZPsvRAiubTYOp7KcdkKy6Cz2 1EkVAV1ZnZm52E98KgbjB5PwNj7mInNQeoML1hJ1TpdssNwp2z8/5wOxkLp0merFr32C cXytbaaEaJ8AuwokcBO3GtohziEO6L60ugV2x7LHDMvDoAEsUz9nfm7kyzs2ixmWNQmX ABJAKSvyCmgXRmNdCm6QedrXveEy9X3+1e+Lw8pj2A/NM/LQ7blMW6annytD1O5SY6tT iI+7IdiBSTi+p0cRcK7Gsqf1aXSAzejsun2mZJMCkR4QNQG2u1DL7KHyiYymVtCFOD/J xK9g== X-Gm-Message-State: APt69E1Jm88ErgfD3/UD5zWYJYXAgWySkzBJfCxpz1dKgxdbef+b/Eu+ MpuclEhxbOdSCcm8RH4+l05l3OXz1f47+ORXkGU= X-Google-Smtp-Source: ADUXVKJzu2BucWI1vXUv+TEm7H8FJEgRBJyKTyxWhytqeEsfdp7cG4SGGz36N0DUXJR0yrcO3DILnom42mrFjbZnf0Y= X-Received: by 2002:a25:ba4c:: with SMTP id z12-v6mr9559996ybj.427.1529450475319; Tue, 19 Jun 2018 16:21:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Luca Muscariello Date: Wed, 20 Jun 2018 01:21:03 +0200 Message-ID: To: tom@quantonium.net, int-area@ietf.org Cc: dmm@ietf.org, Luca Muscariello Content-Type: multipart/alternative; boundary="0000000000004879ec056f06f07d" Archived-At: Subject: Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:21:20 -0000 --0000000000004879ec056f06f07d Content-Type: text/plain; charset="UTF-8" I wonder whether this conversation should happen in the intarea wg mailing list as the main draft was posted there in the first place. I don't know if cross posting is welcome but I take the risk. Going back to the question, the transport changes are related to the request/reply semantic of the architecture. The two distinct forwarding paths described in the draft take care of forwarding requests or replies.This ends up in the transport layer as a unidirectional channel to recv data or snd data. The replies carry data originating from a transport end-point (snd buffer) that binds to an identifier which is location independent, an IPv6 number which is not a locator. The forwarding path of the requests is very close to unmodified IPv6 with the DST address carrying the identifier. If you check in the draft an hICN node does one additional lookup in a local cache though. But you can ignore that for now for sake of clarity. What is important is the address rewrite operation made on the SRC address of the request. A copy of the request is stored in the local cache and the locator of the output interface is written in the SRC address before transmission. This is used by an upstream hICN or the final end-point to know the locator that will be used to reply. Replies coming from the snd end-point are label swapped but not like MPLS. The label is the identifier itself that is stored in the SRC address of the reply, whereas the DST address is a locator. In this forwarding path a lookup is made in the local cache to find a request (one or many) and the associated locator (one or many) that matches the identifier. The DST addr field of the replies is rewritten with the locator(s) just obtained from the lookup. This is how the reply is forwarded to the end-points that issued requests for this identifier. For the replies there is no FIB lookup on the identifier (as it is in the SRC addr field). There can be a lookup in the FIB on the locator stored in the DST of the reply to reach back the previous hICN node or eventually the original end-point. On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: > On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello > wrote: > > The paragraph you reported is from the draft that describes hICN to > enable > > several use cases. > > Mobility is one of those, not the only one. > > To clarify, the draft on hICN mobility deployment options focuses on the > 5G > > service based architecture. > > > > You may be asking > > 1) is it possible to get all the features provided by hICN w/o updates to > > the transport layer? > > 2) is changing the transport protocol unnecessary difficult to enable all > > the use cases mentioned in the draft? > > > Sorry, but I'm still missing something fundamental here. AFAICT, the > idea of hICN is to put routes in the local routing table and use > existing forwarding and routing to forward packets to mobile nodes. So > if a node changes location, then the routing tables need to be > updated. Effectively this is a bunch of host routes that need to be > maintained. At least this is what I gather from the draft: > > "hICN network layer is about using the IPv6 FIB to determine a next > hop router to forward requests or using a local packet cache to > determine if an incoming request can be satisfied locally." > > Is this correct? If it is, then I sort of understand how hICN could be > used for mobility or virtualization without network overlays, but then > I'm completely lost as to why this would require any changes in the > transport layer. > > Tom > > > > > > > IMO, the answers are no for both. > > > > Luca > > > > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert wrote: > >> > >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello > >> wrote: > >> > Hi all, > >> > > >> > the draft below has been posted and describes deployments options for > >> > anchorless mobility management by using > >> > the hicn network architecture that implements icn semantics in IPv6 > >> > networks. > >> > > >> > > >> > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options > >> > > >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ > >> > > >> > A background document has been posted to the internet area WG and > >> > reported > >> > here for your convenience. > >> > The core principle behind hicn and mobility management is that data > >> > sources > >> > are named using location independent names > >> > encoded in IPv6 addresses. The transport service sitting on top of the > >> > hicn > >> > architecture is not based on usual TCP/UDP sockets > >> > but on a novel consumer/producer transport service that will be > >> > described in > >> > another draft. > >> > >> From the draft: "The transport end-point offers two kinds of services > >> to applications: a producer and a consumer service. The service is > >> instantiated in the application by opening communication sockets with > >> an API to perform basic transport service operations: allocation, > >> initialization, configuration, data transmission and reception." > >> > >> This seems like a pretty dramatic rethink of the transport layer just > >> for the purposes of mobility management. Will there be a way to use > >> hICN at the network layer with exsiting and unmodified transport > >> protocols (i.e. can this be done without boiling the ocean)? > >> > >> Thanks, > >> Tom > >> > >> > >> > >> > The current document and a companion document that will be posted soon > >> > describe the different deployment options > >> > with special care to the 5G service based architecture. > >> > Thanks for the comments already received that helped completing this > -00 > >> > draft. > >> > > >> > Luca > >> > > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > dmm mailing list > >> > dmm@ietf.org > >> > https://www.ietf.org/mailman/listinfo/dmm > >> > > --0000000000004879ec056f06f07d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wonder whether this conversation should happen in the in= tarea wg mailing list=C2=A0
as the main draft was posted there in the f= irst place. I don't know if cross posting is welcome
but I ta= ke the risk.

Going back to the question, the trans= port changes are related to the request/reply semantic=C2=A0
of t= he architecture. The two distinct forwarding paths described in the draft t= ake care
of forwarding requests or replies.This ends up in the tr= ansport layer as a unidirectional=C2=A0
channel to recv data or s= nd data. The replies carry data originating from a=C2=A0 transport end-poin= t (snd buffer)
that binds to an identifier which is location inde= pendent, an IPv6 number which is not a locator.

Th= e forwarding path of the requests is very close to unmodified IPv6 with the= DST address carrying the identifier.
If you check in the draft a= n hICN node does one additional lookup in a local cache though. But you can= ignore that
for now for sake of clarity. What is important is th= e address rewrite operation made on the SRC address
of the reques= t. A copy of the request is stored in the local cache and the locator of th= e output interface is written in the=C2=A0
SRC address before tra= nsmission. This is used by an upstream hICN or the final end-point to know = the locator that
will be used to reply.

= Replies coming from the snd end-point are label swapped but not like MPLS.= =C2=A0
The label is the identifier itself that is stored in the S= RC address of the reply,=C2=A0
whereas the DST address is a locat= or. In this forwarding path a lookup is made in the local cache to
find a request (one or many) and the associated locator (one or many) tha= t matches the identifier.
The DST addr field of the replies is re= written with the locator(s) just obtained from the lookup.
This i= s how the reply is forwarded to the end-points that issued requests for thi= s identifier.=C2=A0

For the replies there is no FI= B lookup on the identifier (as it is in the SRC addr field).=C2=A0
There can be a lookup in the FIB on the locator stored in the DST of the = reply to=C2=A0
reach back the previous hICN node or eventually th= e original end-point.

=C2=A0
=C2=A0




On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <<= a href=3D"mailto:tom@quantonium.net">tom@quantonium.net> wrote:
<= /div>
On Tue, Jun 19, 2018 at 1:50 PM, Luca M= uscariello
<luca.mu= scariello@gmail.com> wrote:
> The paragraph you reported is from the draft that describes hICN to en= able
> several use cases.
> Mobility is one of those, not the only one.
> To clarify, the draft on hICN mobility deployment options focuses on t= he 5G
> service based architecture.
>
> You may be asking
> 1) is it possible to get all the features provided by hICN w/o updates= to
> the transport layer?
> 2) is changing the transport protocol unnecessary difficult to enable = all
> the use cases mentioned in the draft?
>
Sorry, but I'm still missing something fundamental here. AFAICT, the idea of hICN is to put routes in the local routing table and use
existing forwarding and routing to forward packets to mobile nodes. So
if a node changes location, then the routing tables need to be
updated. Effectively this is a bunch of host routes that need to be
maintained. At least this is what I gather from the draft:

"hICN network layer is about using the IPv6 FIB to determine a next hop router to forward requests or using a local packet cache to
determine if an incoming request can be satisfied locally."

Is this correct? If it is, then I sort of understand how hICN could be
used for mobility or virtualization without network overlays, but then
I'm completely lost as to why this would require any changes in the
transport layer.

Tom





> IMO, the answers are no for both.
>
> Luca
>
> On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <tom@quantonium.net> wrote:
>>
>> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
>> <luca.muscariello@gmail.com> wrote:
>> > Hi all,
>> >
>> > the draft below has been posted and describes deployments opt= ions for
>> > anchorless mobility management=C2=A0 by using
>> > the hicn network architecture that implements icn semantics i= n IPv6
>> > networks.
>> >
>> >
>> > https:= //datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options<= /a>
>> >
>> > https://datatracker.ie= tf.org/doc/draft-muscariello-intarea-hicn/
>> >
>> > A background document has been posted to the internet area WG= and
>> > reported
>> > here for your convenience.
>> > The core principle behind hicn and mobility management is tha= t data
>> > sources
>> > are named using location independent names
>> > encoded in IPv6 addresses. The transport service sitting on t= op of the
>> > hicn
>> > architecture is not based on usual TCP/UDP sockets
>> > but on a novel consumer/producer transport service that will = be
>> > described in
>> > another draft.
>>
>> From the draft: "The transport end-point offers two kinds of = services
>> to applications: a producer and a consumer service. The service is=
>> instantiated in the application by opening communication sockets w= ith
>> an API to perform basic transport service operations: allocation,<= br> >> initialization, configuration, data transmission and reception.&qu= ot;
>>
>> This seems like a pretty dramatic rethink of the transport layer j= ust
>> for the purposes of mobility management. Will there be a way to us= e
>> hICN at the network layer with exsiting and unmodified transport >> protocols (i.e. can this be done without boiling the ocean)?
>>
>> Thanks,
>> Tom
>>
>>
>>
>> > The current document and a companion document that will be po= sted soon
>> > describe the different deployment options
>> > with special care to the 5G service based architecture.
>> > Thanks for the comments already received that helped completi= ng this -00
>> > draft.
>> >
>> > Luca
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > dmm mailing list
>> > dmm@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/dmm=
>> >
--0000000000004879ec056f06f07d-- From nobody Wed Jun 20 07:19:07 2018 Return-Path: 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 E54A11310CC; Wed, 20 Jun 2018 07:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9GCOzg7fBTcW; Wed, 20 Jun 2018 07:18:49 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87D21310D4; Wed, 20 Jun 2018 07:18:48 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id g18-v6so953180wro.7; Wed, 20 Jun 2018 07:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+Rn3JhaNP/wNHlxnh8rFZ1TBwD10lVowa5bzoJ56hbk=; b=sw3cjvy4D0sx7aPQvcIWkLvK9NUWgZXxoSBLYxkgBNZ9bfKEvgw0iwx2rPz2/KheiO +NFcVh9yFZ1lqQRV8nZpwBYPCL2LH4yGbXyBUxtNcJ2E3FIXaFBiyG+59f+/dTmc2Njo T5rQXsYi9vrSSrv7Myg1l6fFR3eJdW01XnzlaD+UxkcX5idsE9tr7ppMW+/4Yts9HtxM wDqzoDM5HWccqSEE4IX0ansazViPYN+tjqCd+i1zC8//CykwI5Y5jc7m85O5nRa+gsKv +ktnCC/UHWoaRwfWNo7bY0bTYmKE5+4p7HSPssE9lQFto6xGhrH6h4TyUj6c8E8USTF/ F7jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=+Rn3JhaNP/wNHlxnh8rFZ1TBwD10lVowa5bzoJ56hbk=; b=AOLVOA/zYW5ZkXLh75BLKEJllLJK4syUgyyKV4Vsoqg9YhFfCMaCSmAxHsv4SANyhu ZKOBlGv0Ky+ZGKDam7TVFn0O5SRvBPRpckwlmuRkwvrJgUCYtUuPCXI9+LcnkNc1msbO /dTQGdoghZ7fsfQPN8AGy4P1q0vyEJO4cpB3TSwxwg+3jC9bg+x9qChhJU1+xfb5/qNN Qes6F3uMAvYtRKx9yIkXDVpzLdGPmZdGz2dTwAycd0ro0Va/x1/v4tV4XzQm6QF9AVrs OG3RbyuGYsTQoGGH6yqjP2fMSVNMMIZlCEGfGnC070q7bQnra0KDNO7qvMqHXKcmSaaL wY6A== X-Gm-Message-State: APt69E1qsWupl18gzygNQzbAK9E1b3FO7j0z3fgom6in5MlyDFqCEYM3 P7InipkNJgr8HImVqxllsarAVpJ8xQO9Me9FHd0= X-Google-Smtp-Source: ADUXVKK5dGUuGIH1sNesmcc6A8j4gcoWkJtQPhMgvqpmewGhyOvrE4Vnn1A8u/6nu/WFyXwxz7tR+XRFBvsolWxm3tY= X-Received: by 2002:adf:fd88:: with SMTP id d8-v6mr16986672wrr.276.1529504327271; Wed, 20 Jun 2018 07:18:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:fc84:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 07:18:46 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: References: From: Behcet Sarikaya Date: Wed, 20 Jun 2018 09:18:46 -0500 Message-ID: To: Luca Muscariello Cc: Tom Herbert , Internet Area , Luca Muscariello , dmm Content-Type: multipart/alternative; boundary="0000000000001c0956056f137abd" Archived-At: Subject: Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 14:19:01 -0000 --0000000000001c0956056f137abd Content-Type: text/plain; charset="UTF-8" On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello < luca.muscariello@gmail.com> wrote: > I wonder whether this conversation should happen in the intarea wg mailing > list > as the main draft was posted there in the first place. I don't know if > cross posting is welcome > but I take the risk. > > Going back to the question, the transport changes are related to the > request/reply semantic > of the architecture. The two distinct forwarding paths described in the > draft take care > of forwarding requests or replies.This ends up in the transport layer as a > unidirectional > channel to recv data or snd data. The replies carry data originating from > a transport end-point (snd buffer) > that binds to an identifier which is location independent, an IPv6 number > which is not a locator. > > The forwarding path of the requests is very close to unmodified IPv6 with > the DST address carrying the identifier. > If you check in the draft an hICN node does one additional lookup in a > local cache though. But you can ignore that > for now for sake of clarity. What is important is the address rewrite > operation made on the SRC address > of the request. A copy of the request is stored in the local cache and the > locator of the output interface is written in the > SRC address before transmission. This is used by an upstream hICN or the > final end-point to know the locator that > will be used to reply. > > Replies coming from the snd end-point are label swapped but not like MPLS. > The label is the identifier itself that is stored in the SRC address of > the reply, > whereas the DST address is a locator. In this forwarding path a lookup is > made in the local cache to > find a request (one or many) and the associated locator (one or many) that > matches the identifier. > The DST addr field of the replies is rewritten with the locator(s) just > obtained from the lookup. > This is how the reply is forwarded to the end-points that issued requests > for this identifier. > > For the replies there is no FIB lookup on the identifier (as it is in the > SRC addr field). > There can be a lookup in the FIB on the locator stored in the DST of the > reply to > reach back the previous hICN node or eventually the original end-point. > > > > Hi, My humble question is: are you supporting SRv6 or hICN? Regards Behcet > > > > > On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: > >> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >> wrote: >> > The paragraph you reported is from the draft that describes hICN to >> enable >> > several use cases. >> > Mobility is one of those, not the only one. >> > To clarify, the draft on hICN mobility deployment options focuses on >> the 5G >> > service based architecture. >> > >> > You may be asking >> > 1) is it possible to get all the features provided by hICN w/o updates >> to >> > the transport layer? >> > 2) is changing the transport protocol unnecessary difficult to enable >> all >> > the use cases mentioned in the draft? >> > >> Sorry, but I'm still missing something fundamental here. AFAICT, the >> idea of hICN is to put routes in the local routing table and use >> existing forwarding and routing to forward packets to mobile nodes. So >> if a node changes location, then the routing tables need to be >> updated. Effectively this is a bunch of host routes that need to be >> maintained. At least this is what I gather from the draft: >> >> "hICN network layer is about using the IPv6 FIB to determine a next >> hop router to forward requests or using a local packet cache to >> determine if an incoming request can be satisfied locally." >> >> Is this correct? If it is, then I sort of understand how hICN could be >> used for mobility or virtualization without network overlays, but then >> I'm completely lost as to why this would require any changes in the >> transport layer. >> >> Tom >> >> >> >> >> >> > IMO, the answers are no for both. >> > >> > Luca >> > >> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert wrote: >> >> >> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >> >> wrote: >> >> > Hi all, >> >> > >> >> > the draft below has been posted and describes deployments options for >> >> > anchorless mobility management by using >> >> > the hicn network architecture that implements icn semantics in IPv6 >> >> > networks. >> >> > >> >> > >> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn- >> mobility-deployment-options >> >> > >> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >> >> > >> >> > A background document has been posted to the internet area WG and >> >> > reported >> >> > here for your convenience. >> >> > The core principle behind hicn and mobility management is that data >> >> > sources >> >> > are named using location independent names >> >> > encoded in IPv6 addresses. The transport service sitting on top of >> the >> >> > hicn >> >> > architecture is not based on usual TCP/UDP sockets >> >> > but on a novel consumer/producer transport service that will be >> >> > described in >> >> > another draft. >> >> >> >> From the draft: "The transport end-point offers two kinds of services >> >> to applications: a producer and a consumer service. The service is >> >> instantiated in the application by opening communication sockets with >> >> an API to perform basic transport service operations: allocation, >> >> initialization, configuration, data transmission and reception." >> >> >> >> This seems like a pretty dramatic rethink of the transport layer just >> >> for the purposes of mobility management. Will there be a way to use >> >> hICN at the network layer with exsiting and unmodified transport >> >> protocols (i.e. can this be done without boiling the ocean)? >> >> >> >> Thanks, >> >> Tom >> >> >> >> >> >> >> >> > The current document and a companion document that will be posted >> soon >> >> > describe the different deployment options >> >> > with special care to the 5G service based architecture. >> >> > Thanks for the comments already received that helped completing this >> -00 >> >> > draft. >> >> > >> >> > Luca >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > dmm mailing list >> >> > dmm@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/dmm >> >> > >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > --0000000000001c0956056f137abd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello <= ;luca.musca= riello@gmail.com> wrote:
I wonder whether this conversation should happen in the inta= rea wg mailing list=C2=A0
as the main draft was posted there in the fir= st place. I don't know if cross posting is welcome
but I take= the risk.

Going back to the question, the transpo= rt changes are related to the request/reply semantic=C2=A0
of the= architecture. The two distinct forwarding paths described in the draft tak= e care
of forwarding requests or replies.This ends up in the tran= sport layer as a unidirectional=C2=A0
channel to recv data or snd= data. The replies carry data originating from a=C2=A0 transport end-point = (snd buffer)
that binds to an identifier which is location indepe= ndent, an IPv6 number which is not a locator.

The = forwarding path of the requests is very close to unmodified IPv6 with the D= ST address carrying the identifier.
If you check in the draft an = hICN node does one additional lookup in a local cache though. But you can i= gnore that
for now for sake of clarity. What is important is the = address rewrite operation made on the SRC address
of the request.= A copy of the request is stored in the local cache and the locator of the = output interface is written in the=C2=A0
SRC address before trans= mission. This is used by an upstream hICN or the final end-point to know th= e locator that
will be used to reply.

Re= plies coming from the snd end-point are label swapped but not like MPLS.=C2= =A0
The label is the identifier itself that is stored in the SRC = address of the reply,=C2=A0
whereas the DST address is a locator.= In this forwarding path a lookup is made in the local cache to
f= ind a request (one or many) and the associated locator (one or many) that m= atches the identifier.
The DST addr field of the replies is rewri= tten with the locator(s) just obtained from the lookup.
This is h= ow the reply is forwarded to the end-points that issued requests for this i= dentifier.=C2=A0

For the replies there is no FIB l= ookup on the identifier (as it is in the SRC addr field).=C2=A0
T= here can be a lookup in the FIB on the locator stored in the DST of the rep= ly to=C2=A0
reach back the previous hICN node or eventually the o= riginal end-point.

=C2=A0
=C2=A0

Hi,

My humble= question is: are you supporting SRv6 or hICN?

Reg= ards
Behcet
=C2=A0
=




On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <tom@quantonium.net> wrote:
On Tue, Jun 19, 2018 at 1:50 PM, Luca Mu= scariello
<luca.mu= scariello@gmail.com> wrote:
> The paragraph you reported is from the draft that describes hICN to en= able
> several use cases.
> Mobility is one of those, not the only one.
> To clarify, the draft on hICN mobility deployment options focuses on t= he 5G
> service based architecture.
>
> You may be asking
> 1) is it possible to get all the features provided by hICN w/o updates= to
> the transport layer?
> 2) is changing the transport protocol unnecessary difficult to enable = all
> the use cases mentioned in the draft?
>
Sorry, but I'm still missing something fundamental here. AFAICT, the idea of hICN is to put routes in the local routing table and use
existing forwarding and routing to forward packets to mobile nodes. So
if a node changes location, then the routing tables need to be
updated. Effectively this is a bunch of host routes that need to be
maintained. At least this is what I gather from the draft:

"hICN network layer is about using the IPv6 FIB to determine a next hop router to forward requests or using a local packet cache to
determine if an incoming request can be satisfied locally."

Is this correct? If it is, then I sort of understand how hICN could be
used for mobility or virtualization without network overlays, but then
I'm completely lost as to why this would require any changes in the
transport layer.

Tom





> IMO, the answers are no for both.
>
> Luca
>
> On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <tom@quantonium.net> wrote:
>>
>> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
>> <luca.muscariello@gmail.com> wrote:
>> > Hi all,
>> >
>> > the draft below has been posted and describes deployments opt= ions for
>> > anchorless mobility management=C2=A0 by using
>> > the hicn network architecture that implements icn semantics i= n IPv6
>> > networks.
>> >
>> >
>> > https:= //datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deploymen= t-options
>> >
>> > https://datatracker.ie= tf.org/doc/draft-muscariello-intarea-hicn/
>> >
>> > A background document has been posted to the internet area WG= and
>> > reported
>> > here for your convenience.
>> > The core principle behind hicn and mobility management is tha= t data
>> > sources
>> > are named using location independent names
>> > encoded in IPv6 addresses. The transport service sitting on t= op of the
>> > hicn
>> > architecture is not based on usual TCP/UDP sockets
>> > but on a novel consumer/producer transport service that will = be
>> > described in
>> > another draft.
>>
>> From the draft: "The transport end-point offers two kinds of = services
>> to applications: a producer and a consumer service. The service is=
>> instantiated in the application by opening communication sockets w= ith
>> an API to perform basic transport service operations: allocation,<= br> >> initialization, configuration, data transmission and reception.&qu= ot;
>>
>> This seems like a pretty dramatic rethink of the transport layer j= ust
>> for the purposes of mobility management. Will there be a way to us= e
>> hICN at the network layer with exsiting and unmodified transport >> protocols (i.e. can this be done without boiling the ocean)?
>>
>> Thanks,
>> Tom
>>
>>
>>
>> > The current document and a companion document that will be po= sted soon
>> > describe the different deployment options
>> > with special care to the 5G service based architecture.
>> > Thanks for the comments already received that helped completi= ng this -00
>> > draft.
>> >
>> > Luca
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > dmm mailing list
>> > dmm@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/dm= m
>> >

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


--0000000000001c0956056f137abd-- From nobody Wed Jun 20 07:34:00 2018 Return-Path: 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 47DB21294D7; Wed, 20 Jun 2018 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 K1DuUILt-SO4; Wed, 20 Jun 2018 07:33:43 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA59130EBD; Wed, 20 Jun 2018 07:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19134; q=dns/txt; s=iport; t=1529505223; x=1530714823; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=haVlhaPa6LO+zPT6hXkAyFW2YTg8KIw9zBPXIuEVPwA=; b=gPEQ+YMuETKdmX8B35H+i2m7EQSuqRRGO6Tfo6TA+9nNNI0GCmTwWTya Cc4mqlAbr0Ax4h+F/CDSAPmmrJpvIj4J4E1QOjI6CjtpkvcOCtgRLTP/l wshPEY16gzlrIYU3VcEFZDGXSgu1ngn7SlG6OSb3gpi5E8P+M4spZc3+R k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQDmZCpb/4sNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTAUcuYn8oCotzjD+CAoQ6g2uHWIUDFA6BVwsYAQyERwK?= =?us-ascii?q?CdyE0GAECAQEBAQEBAm0cDIUoAQEBAwEBAWwLBQsCAQgRAQMBAQEJGgQHDxI?= =?us-ascii?q?GCxQDBggCBAENBYMmgRtMAw0ID618hw8NgSxoBYIthieBVD+BD4MMgVSBAkI?= =?us-ascii?q?BAQIBAYEgcoUgAosNgW2EUYctLAkChXuGCoMJjUGKHU2GTgIREwGBJB04JoE?= =?us-ascii?q?scBU7gkgfgXFYiEiFPm+OT4EaAQE?= X-IronPort-AV: E=Sophos;i="5.51,247,1526342400"; d="scan'208,217";a="132289285" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2018 14:33:42 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w5KEXg8N020788 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jun 2018 14:33:42 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 20 Jun 2018 09:33:41 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Wed, 20 Jun 2018 09:33:41 -0500 From: "Giovanna Carofiglio (gcarofig)" To: Luca Muscariello , "sarikaya@ieee.org" CC: Internet Area , "Luca Muscariello (lumuscar)" , Tom Herbert , dmm Thread-Topic: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options Thread-Index: AQHUB7J1ia0nsa1DZU6+Bs7zHD1LjqRoS1OAgAAXeQCAABvZAIAADimAgAD60QD//61t8A== Date: Wed, 20 Jun 2018 14:33:41 +0000 Message-ID: <1529505221125.58728@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.212.143] Content-Type: multipart/alternative; boundary="_000_152950522112558728ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 14:33:47 -0000 --_000_152950522112558728ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This draft is about hICN and discusses various deployment options with asso= ciated pros and cons, without supporting one specifically. Clearly, dependi= ng on application requirements, on network constraints, on phase of deploy= ment/transition etc. one option may be preferrable over another one (and d= ifferent ones may coexist). One of the described deployment options also discusses combination of hICN = and SRv6, without opposing one approach to the other, rather exploiting in = the combination the advantages of both ones. Giovanna ________________________________ From: Int-area on behalf of Behcet Sarikaya Sent: Wednesday, June 20, 2018 4:18 PM To: Luca Muscariello Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility managem= ent through hICN (hICN-AMM): Deployment options On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello > wrote: I wonder whether this conversation should happen in the intarea wg mailing = list as the main draft was posted there in the first place. I don't know if cros= s posting is welcome but I take the risk. Going back to the question, the transport changes are related to the reques= t/reply semantic of the architecture. The two distinct forwarding paths described in the dra= ft take care of forwarding requests or replies.This ends up in the transport layer as a = unidirectional channel to recv data or snd data. The replies carry data originating from a= transport end-point (snd buffer) that binds to an identifier which is location independent, an IPv6 number w= hich is not a locator. The forwarding path of the requests is very close to unmodified IPv6 with t= he DST address carrying the identifier. If you check in the draft an hICN node does one additional lookup in a loca= l cache though. But you can ignore that for now for sake of clarity. What is important is the address rewrite opera= tion made on the SRC address of the request. A copy of the request is stored in the local cache and the = locator of the output interface is written in the SRC address before transmission. This is used by an upstream hICN or the fi= nal end-point to know the locator that will be used to reply. Replies coming from the snd end-point are label swapped but not like MPLS. The label is the identifier itself that is stored in the SRC address of the= reply, whereas the DST address is a locator. In this forwarding path a lookup is m= ade in the local cache to find a request (one or many) and the associated locator (one or many) that = matches the identifier. The DST addr field of the replies is rewritten with the locator(s) just obt= ained from the lookup. This is how the reply is forwarded to the end-points that issued requests f= or this identifier. For the replies there is no FIB lookup on the identifier (as it is in the S= RC addr field). There can be a lookup in the FIB on the locator stored in the DST of the re= ply to reach back the previous hICN node or eventually the original end-point. Hi, My humble question is: are you supporting SRv6 or hICN? Regards Behcet On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert > wrote: On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello > wrote: > The paragraph you reported is from the draft that describes hICN to enabl= e > several use cases. > Mobility is one of those, not the only one. > To clarify, the draft on hICN mobility deployment options focuses on the = 5G > service based architecture. > > You may be asking > 1) is it possible to get all the features provided by hICN w/o updates to > the transport layer? > 2) is changing the transport protocol unnecessary difficult to enable all > the use cases mentioned in the draft? > Sorry, but I'm still missing something fundamental here. AFAICT, the idea of hICN is to put routes in the local routing table and use existing forwarding and routing to forward packets to mobile nodes. So if a node changes location, then the routing tables need to be updated. Effectively this is a bunch of host routes that need to be maintained. At least this is what I gather from the draft: "hICN network layer is about using the IPv6 FIB to determine a next hop router to forward requests or using a local packet cache to determine if an incoming request can be satisfied locally." Is this correct? If it is, then I sort of understand how hICN could be used for mobility or virtualization without network overlays, but then I'm completely lost as to why this would require any changes in the transport layer. Tom > IMO, the answers are no for both. > > Luca > > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert > wrote: >> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >> > wrote: >> > Hi all, >> > >> > the draft below has been posted and describes deployments options for >> > anchorless mobility management by using >> > the hicn network architecture that implements icn semantics in IPv6 >> > networks. >> > >> > >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployme= nt-options >> > >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >> > >> > A background document has been posted to the internet area WG and >> > reported >> > here for your convenience. >> > The core principle behind hicn and mobility management is that data >> > sources >> > are named using location independent names >> > encoded in IPv6 addresses. The transport service sitting on top of the >> > hicn >> > architecture is not based on usual TCP/UDP sockets >> > but on a novel consumer/producer transport service that will be >> > described in >> > another draft. >> >> From the draft: "The transport end-point offers two kinds of services >> to applications: a producer and a consumer service. The service is >> instantiated in the application by opening communication sockets with >> an API to perform basic transport service operations: allocation, >> initialization, configuration, data transmission and reception." >> >> This seems like a pretty dramatic rethink of the transport layer just >> for the purposes of mobility management. Will there be a way to use >> hICN at the network layer with exsiting and unmodified transport >> protocols (i.e. can this be done without boiling the ocean)? >> >> Thanks, >> Tom >> >> >> >> > The current document and a companion document that will be posted soon >> > describe the different deployment options >> > with special care to the 5G service based architecture. >> > Thanks for the comments already received that helped completing this -= 00 >> > draft. >> > >> > Luca >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > dmm mailing list >> > dmm@ietf.org >> > https://www.ietf.org/mailman/listinfo/dmm >> > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_152950522112558728ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This draft is about hICN and discusses various deployment options with a= ssociated pros and cons, without supporting one specifically. Clearly, depe= nding on  application requirements, on network constraints, on phase o= f deployment/transition  etc. one option may be preferrable over another one (and different ones may coexist).


One of the described deployment options also discusses combination of hI= CN and SRv6, without opposing one approach to the other, rather exploi= ting in the combination the advantages of both ones.


Giovanna

From: Int-area <int-ar= ea-bounces@ietf.org> on behalf of Behcet Sarikaya <sarikaya2012@gmail= .com>
Sent: Wednesday, June 20, 2018 4:18 PM
To: Luca Muscariello
Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm
Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility = management through hICN (hICN-AMM): Deployment options
 


On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariell= o <luca.mu= scariello@gmail.com> wrote:
I wonder whether this conversation should happen in the in= tarea wg mailing list 
as the main draft was posted there in the first place. I don't know if= cross posting is welcome
but I take the risk.

Going back to the question, the transport changes are related to the r= equest/reply semantic 
of the architecture. The two distinct forwarding paths described in th= e draft take care
of forwarding requests or replies.This ends up in the transport layer = as a unidirectional 
channel to recv data or snd data. The replies carry data originating f= rom a  transport end-point (snd buffer)
that binds to an identifier which is location independent, an IPv6 num= ber which is not a locator.

The forwarding path of the requests is very close to unmodified IPv6 w= ith the DST address carrying the identifier.
If you check in the draft an hICN node does one additional lookup in a= local cache though. But you can ignore that
for now for sake of clarity. What is important is the address rewrite = operation made on the SRC address
of the request. A copy of the request is stored in the local cache and= the locator of the output interface is written in the 
SRC address before transmission. This is used by an upstream hICN or t= he final end-point to know the locator that
will be used to reply.

Replies coming from the snd end-point are label swapped but not like M= PLS. 
The label is the identifier itself that is stored in the SRC address o= f the reply, 
whereas the DST address is a locator. In this forwarding path a lookup= is made in the local cache to
find a request (one or many) and the associated locator (one or many) = that matches the identifier.
The DST addr field of the replies is rewritten with the locator(s) jus= t obtained from the lookup.
This is how the reply is forwarded to the end-points that issued reque= sts for this identifier. 

For the replies there is no FIB lookup on the identifier (as it is in = the SRC addr field). 
There can be a lookup in the FIB on the locator stored in the DST of t= he reply to 
reach back the previous hICN node or eventually the original end-point= .

 
 

Hi,

My humble question is: are you supporting SRv6 or hICN?

Regards
Behcet
 




On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <tom@quantonium.net>= wrote:
On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello
<luca.mu= scariello@gmail.com> wrote:
> The paragraph you reported is from the draft that describes hICN to en= able
> several use cases.
> Mobility is one of those, not the only one.
> To clarify, the draft on hICN mobility deployment options focuses on t= he 5G
> service based architecture.
>
> You may be asking
> 1) is it possible to get all the features provided by hICN w/o updates= to
> the transport layer?
> 2) is changing the transport protocol unnecessary difficult to enable = all
> the use cases mentioned in the draft?
>
Sorry, but I'm still missing something fundamental here. AFAICT, the
idea of hICN is to put routes in the local routing table and use
existing forwarding and routing to forward packets to mobile nodes. So
if a node changes location, then the routing tables need to be
updated. Effectively this is a bunch of host routes that need to be
maintained. At least this is what I gather from the draft:

"hICN network layer is about using the IPv6 FIB to determine a next hop router to forward requests or using a local packet cache to
determine if an incoming request can be satisfied locally."

Is this correct? If it is, then I sort of understand how hICN could be
used for mobility or virtualization without network overlays, but then
I'm completely lost as to why this would require any changes in the
transport layer.

Tom





> IMO, the answers are no for both.
>
> Luca
>
> On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <tom@quantonium.net> wrote:
>>
>> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
>> <luca.muscariello@gmail.com> wrote:
>> > Hi all,
>> >
>> > the draft below has been posted and describes deployments opt= ions for
>> > anchorless mobility management  by using
>> > the hicn network architecture that implements icn semantics i= n IPv6
>> > networks.
>> >
>> >
>> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-dep= loyment-options
>> >
>> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/<= /a>
>> >
>> > A background document has been posted to the internet area WG= and
>> > reported
>> > here for your convenience.
>> > The core principle behind hicn and mobility management is tha= t data
>> > sources
>> > are named using location independent names
>> > encoded in IPv6 addresses. The transport service sitting on t= op of the
>> > hicn
>> > architecture is not based on usual TCP/UDP sockets
>> > but on a novel consumer/producer transport service that will = be
>> > described in
>> > another draft.
>>
>> From the draft: "The transport end-point offers two kinds of = services
>> to applications: a producer and a consumer service. The service is=
>> instantiated in the application by opening communication sockets w= ith
>> an API to perform basic transport service operations: allocation,<= br> >> initialization, configuration, data transmission and reception.&qu= ot;
>>
>> This seems like a pretty dramatic rethink of the transport layer j= ust
>> for the purposes of mobility management. Will there be a way to us= e
>> hICN at the network layer with exsiting and unmodified transport >> protocols (i.e. can this be done without boiling the ocean)?
>>
>> Thanks,
>> Tom
>>
>>
>>
>> > The current document and a companion document that will be po= sted soon
>> > describe the different deployment options
>> > with special care to the 5G service based architecture.
>> > Thanks for the comments already received that helped completi= ng this -00
>> > draft.
>> >
>> > Luca
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > dmm mailing list
>> > dmm@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/dmm
>> >

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


--_000_152950522112558728ciscocom_-- From nobody Wed Jun 20 07:49:08 2018 Return-Path: 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 77649130F13; Wed, 20 Jun 2018 07:49:05 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 IRJ1NXC5teTD; Wed, 20 Jun 2018 07:49:02 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B18130EBD; Wed, 20 Jun 2018 07:49:01 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id s201-v6so1245301ywg.8; Wed, 20 Jun 2018 07:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=plQLoe3EEOsrlK68hERKEptHy+tYaUamKBEQg4WVJWc=; b=G7oKMC3n5qSX7UW6Npi78kXnYsApxrrubVF6Olj0SaqXM4LoYdnhZmn277QQKSMhyU ApUo/6AG328KjBGikWYuB2tQ5YLKcKC/Qur1v+9432X4NKnk+Mo8iCGvTCUc84YabFqt 0mX9FUwbCD/aIK7acRBVDTEjp0PjVFjPwduYTfDJsKYQVd2yjBOOQkchmtY/H8zoieJp 2Pg8ZbIzJHLkMUuiWOqQL7C+XeiSu9/gr5WI0n4Dw1JeqsGDym+aE43VL2rALx0djkDU lwNuq5Ys5FGHJnP+A1M63M2xDWIH5WwbCywHa6MzTSUsamIh0UKcPzmv3CeQsj5nj5sz pBIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=plQLoe3EEOsrlK68hERKEptHy+tYaUamKBEQg4WVJWc=; b=kLN1UQre1TdiXxALmQ2n38NFN94D+TcbHgb+G9GiZlsGfl+B0MBs7jijILaO/9/5cE PwzhmJQY92741n0xPmVnprieTb6CNufMB88zD8VcaSlNzyYX/XcJIMgsih2cmc/Q6gjF AtbuUjzDFRcZWz7xNK3fwN/VmBPGFGTvwoiOU43qj1tXbHb5e/JqCpg871Tapse2NA3p bgeZj4BouR2Gd57DN5tni/Dj8K4jlsV4ihN97czFuoNehgqkGnY04j9hz+wuLjyIaNQx zHXiqCINhx9hzSbrB/S060MX7XnKT0ehWBOuLRBfA5ei8OUPlL+VNuxpx4PZ6MLU+5qU gO7Q== X-Gm-Message-State: APt69E1p9XculbPMAxcfOo1xdCkPeTYZZP3CArWLo7U+wYDdg8s6xH9u KImh1fGrO1ksNWWxj8NyGSd7upsr2UbN0Ds5Hgw2v+M+ X-Google-Smtp-Source: ADUXVKKkq/a6JpNsWNnvkEwlyFZWPJc5dxkMtlkT2C6wylOh5GS+yBIyZ8iHIhc1kQvuzEY4YPv7irB62x0p7XdvU3I= X-Received: by 2002:a81:4684:: with SMTP id t126-v6mr10243887ywa.225.1529506141002; Wed, 20 Jun 2018 07:49:01 -0700 (PDT) MIME-Version: 1.0 References: <1529505221125.58728@cisco.com> In-Reply-To: <1529505221125.58728@cisco.com> From: Luca Muscariello Date: Wed, 20 Jun 2018 16:48:49 +0200 Message-ID: To: Giovanna Carofiglio Cc: sarikaya@ieee.org, int-area@ietf.org, Luca Muscariello , tom@quantonium.net, dmm@ietf.org Content-Type: multipart/alternative; boundary="0000000000003762c9056f13e6b6" Archived-At: Subject: Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 14:49:06 -0000 --0000000000003762c9056f13e6b6 Content-Type: text/plain; charset="UTF-8" More on the mobility use case which also makes deployment options easier to digest https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) < gcarofig@cisco.com> wrote: > This draft is about hICN and discusses various deployment options with > associated pros and cons, without supporting one specifically. Clearly, > depending on application requirements, on network constraints, on phase of > deployment/transition etc. one option may be preferrable over another one > (and different ones may coexist). > > > One of the described deployment options also discusses combination of hICN > and SRv6, without opposing one approach to the other, rather exploiting in > the combination the advantages of both ones. > > > Giovanna > ------------------------------ > *From:* Int-area on behalf of Behcet Sarikaya > > *Sent:* Wednesday, June 20, 2018 4:18 PM > *To:* Luca Muscariello > *Cc:* Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm > *Subject:* Re: [Int-area] [DMM] New draft posted: Anchorless mobility > management through hICN (hICN-AMM): Deployment options > > > > On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello < > luca.muscariello@gmail.com> wrote: > >> I wonder whether this conversation should happen in the intarea wg >> mailing list >> as the main draft was posted there in the first place. I don't know if >> cross posting is welcome >> but I take the risk. >> >> Going back to the question, the transport changes are related to the >> request/reply semantic >> of the architecture. The two distinct forwarding paths described in the >> draft take care >> of forwarding requests or replies.This ends up in the transport layer as >> a unidirectional >> channel to recv data or snd data. The replies carry data originating from >> a transport end-point (snd buffer) >> that binds to an identifier which is location independent, an IPv6 number >> which is not a locator. >> >> The forwarding path of the requests is very close to unmodified IPv6 with >> the DST address carrying the identifier. >> If you check in the draft an hICN node does one additional lookup in a >> local cache though. But you can ignore that >> for now for sake of clarity. What is important is the address rewrite >> operation made on the SRC address >> of the request. A copy of the request is stored in the local cache and >> the locator of the output interface is written in the >> SRC address before transmission. This is used by an upstream hICN or the >> final end-point to know the locator that >> will be used to reply. >> >> Replies coming from the snd end-point are label swapped but not like >> MPLS. >> The label is the identifier itself that is stored in the SRC address of >> the reply, >> whereas the DST address is a locator. In this forwarding path a lookup is >> made in the local cache to >> find a request (one or many) and the associated locator (one or many) >> that matches the identifier. >> The DST addr field of the replies is rewritten with the locator(s) just >> obtained from the lookup. >> This is how the reply is forwarded to the end-points that issued requests >> for this identifier. >> >> For the replies there is no FIB lookup on the identifier (as it is in the >> SRC addr field). >> There can be a lookup in the FIB on the locator stored in the DST of the >> reply to >> reach back the previous hICN node or eventually the original end-point. >> >> >> >> > > Hi, > > My humble question is: are you supporting SRv6 or hICN? > > Regards > Behcet > > >> >> >> >> >> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: >> >>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >>> wrote: >>> > The paragraph you reported is from the draft that describes hICN to >>> enable >>> > several use cases. >>> > Mobility is one of those, not the only one. >>> > To clarify, the draft on hICN mobility deployment options focuses on >>> the 5G >>> > service based architecture. >>> > >>> > You may be asking >>> > 1) is it possible to get all the features provided by hICN w/o updates >>> to >>> > the transport layer? >>> > 2) is changing the transport protocol unnecessary difficult to enable >>> all >>> > the use cases mentioned in the draft? >>> > >>> Sorry, but I'm still missing something fundamental here. AFAICT, the >>> idea of hICN is to put routes in the local routing table and use >>> existing forwarding and routing to forward packets to mobile nodes. So >>> if a node changes location, then the routing tables need to be >>> updated. Effectively this is a bunch of host routes that need to be >>> maintained. At least this is what I gather from the draft: >>> >>> "hICN network layer is about using the IPv6 FIB to determine a next >>> hop router to forward requests or using a local packet cache to >>> determine if an incoming request can be satisfied locally." >>> >>> Is this correct? If it is, then I sort of understand how hICN could be >>> used for mobility or virtualization without network overlays, but then >>> I'm completely lost as to why this would require any changes in the >>> transport layer. >>> >>> Tom >>> >>> >>> >>> >>> >>> > IMO, the answers are no for both. >>> > >>> > Luca >>> > >>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert >>> wrote: >>> >> >>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >>> >> wrote: >>> >> > Hi all, >>> >> > >>> >> > the draft below has been posted and describes deployments options >>> for >>> >> > anchorless mobility management by using >>> >> > the hicn network architecture that implements icn semantics in IPv6 >>> >> > networks. >>> >> > >>> >> > >>> >> > >>> https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options >>> >> > >>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >>> >> > >>> >> > A background document has been posted to the internet area WG and >>> >> > reported >>> >> > here for your convenience. >>> >> > The core principle behind hicn and mobility management is that data >>> >> > sources >>> >> > are named using location independent names >>> >> > encoded in IPv6 addresses. The transport service sitting on top of >>> the >>> >> > hicn >>> >> > architecture is not based on usual TCP/UDP sockets >>> >> > but on a novel consumer/producer transport service that will be >>> >> > described in >>> >> > another draft. >>> >> >>> >> From the draft: "The transport end-point offers two kinds of services >>> >> to applications: a producer and a consumer service. The service is >>> >> instantiated in the application by opening communication sockets with >>> >> an API to perform basic transport service operations: allocation, >>> >> initialization, configuration, data transmission and reception." >>> >> >>> >> This seems like a pretty dramatic rethink of the transport layer just >>> >> for the purposes of mobility management. Will there be a way to use >>> >> hICN at the network layer with exsiting and unmodified transport >>> >> protocols (i.e. can this be done without boiling the ocean)? >>> >> >>> >> Thanks, >>> >> Tom >>> >> >>> >> >>> >> >>> >> > The current document and a companion document that will be posted >>> soon >>> >> > describe the different deployment options >>> >> > with special care to the 5G service based architecture. >>> >> > Thanks for the comments already received that helped completing >>> this -00 >>> >> > draft. >>> >> > >>> >> > Luca >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > dmm mailing list >>> >> > dmm@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/dmm >>> >> > >>> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> > --0000000000003762c9056f13e6b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
More on the mobility use case which also makes deployment = options easier to digest



On Wed, Jun 20, 2018 at 4:33 PM Giov= anna Carofiglio (gcarofig) <gcarof= ig@cisco.com> wrote:

This draft is about hICN and discusses various deployment options with a= ssociated pros and cons, without supporting one specifically. Clearly, depe= nding on=C2=A0 application requirements, on network constraints, on phase o= f deployment/transition=C2=A0 etc. one option may be preferrable over another one (and different ones may coexist).


One of the described deployment options also discusses combination of hI= CN and SRv6, without opposing one=C2=A0approach to the other, rather exploi= ting in the combination=C2=A0the advantages of both=C2=A0ones.


Giovanna

From: = Int-area <int-area-bounces@ietf.org> on behalf of Behcet Sarikaya <sarikaya2012@gmail.com= >
Sent: Wednesday, June 20, 2018 4:18 PM
To: Luca Muscariello
Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm
Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility = management through hICN (hICN-AMM): Deployment options
=C2=A0


On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariell= o <luca.mu= scariello@gmail.com> wrote:
I wonder whether this conversation should happen in the in= tarea wg mailing list=C2=A0
as the main draft was posted there in the first place. I don't kno= w if cross posting is welcome
but I take the risk.

Going back to the question, the transport changes are related to the r= equest/reply semantic=C2=A0
of the architecture. The two distinct forwarding paths described in th= e draft take care
of forwarding requests or replies.This ends up in the transport layer = as a unidirectional=C2=A0
channel to recv data or snd data. The replies carry data originating f= rom a=C2=A0 transport end-point (snd buffer)
that binds to an identifier which is location independent, an IPv6 num= ber which is not a locator.

The forwarding path of the requests is very close to unmodified IPv6 w= ith the DST address carrying the identifier.
If you check in the draft an hICN node does one additional lookup in a= local cache though. But you can ignore that
for now for sake of clarity. What is important is the address rewrite = operation made on the SRC address
of the request. A copy of the request is stored in the local cache and= the locator of the output interface is written in the=C2=A0
SRC address before transmission. This is used by an upstream hICN or t= he final end-point to know the locator that
will be used to reply.

Replies coming from the snd end-point are label swapped but not like M= PLS.=C2=A0
The label is the identifier itself that is stored in the SRC address o= f the reply,=C2=A0
whereas the DST address is a locator. In this forwarding path a lookup= is made in the local cache to
find a request (one or many) and the associated locator (one or many) = that matches the identifier.
The DST addr field of the replies is rewritten with the locator(s) jus= t obtained from the lookup.
This is how the reply is forwarded to the end-points that issued reque= sts for this identifier.=C2=A0

For the replies there is no FIB lookup on the identifier (as it is in = the SRC addr field).=C2=A0
There can be a lookup in the FIB on the locator stored in the DST of t= he reply to=C2=A0
reach back the previous hICN node or eventually the original end-point= .

=C2=A0
=C2=A0

Hi,

My humble question is: are you supporting SRv6 or hICN?

Regards
Behcet
=C2=A0




On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <tom@quantonium.net>= wrote:
On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello
<luca.mu= scariello@gmail.com> wrote:
> The paragraph you reported is from the draft that describes hICN to en= able
> several use cases.
> Mobility is one of those, not the only one.
> To clarify, the draft on hICN mobility deployment options focuses on t= he 5G
> service based architecture.
>
> You may be asking
> 1) is it possible to get all the features provided by hICN w/o updates= to
> the transport layer?
> 2) is changing the transport protocol unnecessary difficult to enable = all
> the use cases mentioned in the draft?
>
Sorry, but I'm still missing something fundamental here. AFAICT, the idea of hICN is to put routes in the local routing table and use
existing forwarding and routing to forward packets to mobile nodes. So
if a node changes location, then the routing tables need to be
updated. Effectively this is a bunch of host routes that need to be
maintained. At least this is what I gather from the draft:

"hICN network layer is about using the IPv6 FIB to determine a next hop router to forward requests or using a local packet cache to
determine if an incoming request can be satisfied locally."

Is this correct? If it is, then I sort of understand how hICN could be
used for mobility or virtualization without network overlays, but then
I'm completely lost as to why this would require any changes in the
transport layer.

Tom





> IMO, the answers are no for both.
>
> Luca
>
> On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <tom@quantonium.net> wrote:
>>
>> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
>> <luca.muscariello@gmail.com> wrote:
>> > Hi all,
>> >
>> > the draft below has been posted and describes deployments opt= ions for
>> > anchorless mobility management=C2=A0 by using
>> > the hicn network architecture that implements icn semantics i= n IPv6
>> > networks.
>> >
>> >
>> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-op= tions
>> >
>> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/
>> >
>> > A background document has been posted to the internet area WG= and
>> > reported
>> > here for your convenience.
>> > The core principle behind hicn and mobility management is tha= t data
>> > sources
>> > are named using location independent names
>> > encoded in IPv6 addresses. The transport service sitting on t= op of the
>> > hicn
>> > architecture is not based on usual TCP/UDP sockets
>> > but on a novel consumer/producer transport service that will = be
>> > described in
>> > another draft.
>>
>> From the draft: "The transport end-point offers two kinds of = services
>> to applications: a producer and a consumer service. The service is=
>> instantiated in the application by opening communication sockets w= ith
>> an API to perform basic transport service operations: allocation,<= br> >> initialization, configuration, data transmission and reception.&qu= ot;
>>
>> This seems like a pretty dramatic rethink of the transport layer j= ust
>> for the purposes of mobility management. Will there be a way to us= e
>> hICN at the network layer with exsiting and unmodified transport >> protocols (i.e. can this be done without boiling the ocean)?
>>
>> Thanks,
>> Tom
>>
>>
>>
>> > The current document and a companion document that will be po= sted soon
>> > describe the different deployment options
>> > with special care to the 5G service based architecture.
>> > Thanks for the comments already received that helped completi= ng this -00
>> > draft.
>> >
>> > Luca
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > dmm mailing list
>> > dmm@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/dmm
>> >

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


--0000000000003762c9056f13e6b6-- From nobody Wed Jun 20 07:54:07 2018 Return-Path: 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 991E0130F08; Wed, 20 Jun 2018 07:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oDmhI7BR9h_3; Wed, 20 Jun 2018 07:54:02 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAC0130ED6; Wed, 20 Jun 2018 07:54:01 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id v131-v6so47333wma.1; Wed, 20 Jun 2018 07:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZJI+MEM1pooQK9gGB1/f0S1sXYrlUPzNA/mMZ7PFl20=; b=krMLzysEOCDMZIdVpjby60XspQLikY+miJJ2dCS1NfHWLR5MQcQEhntWHuwB7ZdvgE RN1JqSUJ+IZinyRN3PLdF4RxlyjMmom6F/EdCOh8l/Qh5Z9/tMqBt5wvL07QiS98z60s eeCIzsrXijceuqp/PZMFuk+nokw9s9ewUcyWAnZdLJ67X6mWY3ca0u6dVXuwGsIb6tpq Onb67NpVw8KvjnMKOdseG6Yyco+lXyeVAWvlQ6u/hSSHCyDKRijiCsJdGnQRgevUckuR MoTmGJyyYqzYDBFZ647mT2EFA4jyckMmbFhK/LCX6+3bfInJL8IygkrR1SdTQkdgSAq+ 23Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=ZJI+MEM1pooQK9gGB1/f0S1sXYrlUPzNA/mMZ7PFl20=; b=fMDm7JMBYecog60Ui3SJ7owAXuai9FbWZBiqqkrJpxUJW9fSU/7ZG2mgJ+YfEGTRNX /rJ+IaeUZaSU7wXCLVOavQIXrpEAOQJzkDZQkofoizBswiCCjw8DMqspTK4lXcr3H+1C JSOcV1D/mjaxjesR7uZZoWMS9DTMMrkhpUgJl7GpTTh22lVLRSMm34UKchy0oEGBrqQ2 ijEIjb35L4qddtBTox8bkd2z7nS3nnHFwdntNN7UNF12WeK2JvBIA0D+3hX604WdF9bh PGgWb4KUoSsqBV6x4QcK0+MBYD8QylYL3vTjwVsxMRpD5h27WzNjlh8zd51hyi81gDok 1Gpg== X-Gm-Message-State: APt69E2sD/4NOQr1izzTDjqTkaTbEqkzJyKaViCMay05FwSL4gfqiNbG 3qspctI2TqX0FBgD5rZFY0//aKEHoV9X+DQAn/o= X-Google-Smtp-Source: ADUXVKJYvFXPg1Z234Lqqda8V/BRb1aG//cJ73MsNZqqBkxoU8aXQ+0OqhjHmkca+zw+3NiyZ60v8hzs3Gk8Io3yhdk= X-Received: by 2002:a1c:9c0b:: with SMTP id f11-v6mr1992187wme.148.1529506440271; Wed, 20 Jun 2018 07:54:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:fc84:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 07:53:59 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: <1529505221125.58728@cisco.com> References: <1529505221125.58728@cisco.com> From: Behcet Sarikaya Date: Wed, 20 Jun 2018 09:53:59 -0500 Message-ID: To: "Giovanna Carofiglio (gcarofig)" Cc: Luca Muscariello , Internet Area , "Luca Muscariello (lumuscar)" , Tom Herbert , dmm Content-Type: multipart/alternative; boundary="0000000000000de08b056f13f8cb" Archived-At: Subject: Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 14:54:05 -0000 --0000000000000de08b056f13f8cb Content-Type: text/plain; charset="UTF-8" On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) < gcarofig@cisco.com> wrote: > This draft is about hICN and discusses various deployment options with > associated pros and cons, without supporting one specifically. Clearly, > depending on application requirements, on network constraints, on phase of > deployment/transition etc. one option may be preferrable over another one > (and different ones may coexist). > > > One of the described deployment options also discusses combination of hICN > and SRv6, without opposing one approach to the other, rather exploiting in > the combination the advantages of both ones. > > > I don't understand. SRv6 is tunneling technique while hICN is talking about anchoress mobility. Did I get something wrong? Behcet > Giovanna > ------------------------------ > *From:* Int-area on behalf of Behcet Sarikaya > > *Sent:* Wednesday, June 20, 2018 4:18 PM > *To:* Luca Muscariello > *Cc:* Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm > *Subject:* Re: [Int-area] [DMM] New draft posted: Anchorless mobility > management through hICN (hICN-AMM): Deployment options > > > > On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello < > luca.muscariello@gmail.com> wrote: > >> I wonder whether this conversation should happen in the intarea wg >> mailing list >> as the main draft was posted there in the first place. I don't know if >> cross posting is welcome >> but I take the risk. >> >> Going back to the question, the transport changes are related to the >> request/reply semantic >> of the architecture. The two distinct forwarding paths described in the >> draft take care >> of forwarding requests or replies.This ends up in the transport layer as >> a unidirectional >> channel to recv data or snd data. The replies carry data originating from >> a transport end-point (snd buffer) >> that binds to an identifier which is location independent, an IPv6 number >> which is not a locator. >> >> The forwarding path of the requests is very close to unmodified IPv6 with >> the DST address carrying the identifier. >> If you check in the draft an hICN node does one additional lookup in a >> local cache though. But you can ignore that >> for now for sake of clarity. What is important is the address rewrite >> operation made on the SRC address >> of the request. A copy of the request is stored in the local cache and >> the locator of the output interface is written in the >> SRC address before transmission. This is used by an upstream hICN or the >> final end-point to know the locator that >> will be used to reply. >> >> Replies coming from the snd end-point are label swapped but not like >> MPLS. >> The label is the identifier itself that is stored in the SRC address of >> the reply, >> whereas the DST address is a locator. In this forwarding path a lookup is >> made in the local cache to >> find a request (one or many) and the associated locator (one or many) >> that matches the identifier. >> The DST addr field of the replies is rewritten with the locator(s) just >> obtained from the lookup. >> This is how the reply is forwarded to the end-points that issued requests >> for this identifier. >> >> For the replies there is no FIB lookup on the identifier (as it is in the >> SRC addr field). >> There can be a lookup in the FIB on the locator stored in the DST of the >> reply to >> reach back the previous hICN node or eventually the original end-point. >> >> >> >> > > Hi, > > My humble question is: are you supporting SRv6 or hICN? > > Regards > Behcet > > >> >> >> >> >> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: >> >>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >>> wrote: >>> > The paragraph you reported is from the draft that describes hICN to >>> enable >>> > several use cases. >>> > Mobility is one of those, not the only one. >>> > To clarify, the draft on hICN mobility deployment options focuses on >>> the 5G >>> > service based architecture. >>> > >>> > You may be asking >>> > 1) is it possible to get all the features provided by hICN w/o updates >>> to >>> > the transport layer? >>> > 2) is changing the transport protocol unnecessary difficult to enable >>> all >>> > the use cases mentioned in the draft? >>> > >>> Sorry, but I'm still missing something fundamental here. AFAICT, the >>> idea of hICN is to put routes in the local routing table and use >>> existing forwarding and routing to forward packets to mobile nodes. So >>> if a node changes location, then the routing tables need to be >>> updated. Effectively this is a bunch of host routes that need to be >>> maintained. At least this is what I gather from the draft: >>> >>> "hICN network layer is about using the IPv6 FIB to determine a next >>> hop router to forward requests or using a local packet cache to >>> determine if an incoming request can be satisfied locally." >>> >>> Is this correct? If it is, then I sort of understand how hICN could be >>> used for mobility or virtualization without network overlays, but then >>> I'm completely lost as to why this would require any changes in the >>> transport layer. >>> >>> Tom >>> >>> >>> >>> >>> >>> > IMO, the answers are no for both. >>> > >>> > Luca >>> > >>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert >>> wrote: >>> >> >>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >>> >> wrote: >>> >> > Hi all, >>> >> > >>> >> > the draft below has been posted and describes deployments options >>> for >>> >> > anchorless mobility management by using >>> >> > the hicn network architecture that implements icn semantics in IPv6 >>> >> > networks. >>> >> > >>> >> > >>> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobilit >>> y-deployment-options >>> >> > >>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >>> >> > >>> >> > A background document has been posted to the internet area WG and >>> >> > reported >>> >> > here for your convenience. >>> >> > The core principle behind hicn and mobility management is that data >>> >> > sources >>> >> > are named using location independent names >>> >> > encoded in IPv6 addresses. The transport service sitting on top of >>> the >>> >> > hicn >>> >> > architecture is not based on usual TCP/UDP sockets >>> >> > but on a novel consumer/producer transport service that will be >>> >> > described in >>> >> > another draft. >>> >> >>> >> From the draft: "The transport end-point offers two kinds of services >>> >> to applications: a producer and a consumer service. The service is >>> >> instantiated in the application by opening communication sockets with >>> >> an API to perform basic transport service operations: allocation, >>> >> initialization, configuration, data transmission and reception." >>> >> >>> >> This seems like a pretty dramatic rethink of the transport layer just >>> >> for the purposes of mobility management. Will there be a way to use >>> >> hICN at the network layer with exsiting and unmodified transport >>> >> protocols (i.e. can this be done without boiling the ocean)? >>> >> >>> >> Thanks, >>> >> Tom >>> >> >>> >> >>> >> >>> >> > The current document and a companion document that will be posted >>> soon >>> >> > describe the different deployment options >>> >> > with special care to the 5G service based architecture. >>> >> > Thanks for the comments already received that helped completing >>> this -00 >>> >> > draft. >>> >> > >>> >> > Luca >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > dmm mailing list >>> >> > dmm@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/dmm >>> >> > >>> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> > --0000000000000de08b056f13f8cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) <gcar= ofig@cisco.com> wrote:

This draft is about hICN and discusses various deployment options with a= ssociated pros and cons, without supporting one specifically. Clearly, depe= nding on=C2=A0 application requirements, on network constraints, on phase o= f deployment/transition=C2=A0 etc. one option may be preferrable over another one (and different ones may coexist).


One of the described deployment options also discusses combination of hI= CN and SRv6, without opposing one=C2=A0approach to the other, rather exploi= ting in the combination=C2=A0the advantages of both=C2=A0ones.



I don't understand.
SRv6 is tunneling technique while hICN is talking about anchoress = mobility.
Did I get something wrong?

Beh= cet=C2=A0

Giovanna

From: = Int-area <int-area-bounces@ietf.org> on behalf of Behcet Sarikaya <sarikaya2012@gmail.com= >
Sent: Wednesday, June 20, 2018 4:18 PM
To: Luca Muscariello
Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm
Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility = management through hICN (hICN-AMM): Deployment options
=C2=A0


On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariell= o <luca.mu= scariello@gmail.com> wrote:
I wonder whether this conversation should happen in the in= tarea wg mailing list=C2=A0
as the main draft was posted there in the first place. I don't kno= w if cross posting is welcome
but I take the risk.

Going back to the question, the transport changes are related to the r= equest/reply semantic=C2=A0
of the architecture. The two distinct forwarding paths described in th= e draft take care
of forwarding requests or replies.This ends up in the transport layer = as a unidirectional=C2=A0
channel to recv data or snd data. The replies carry data originating f= rom a=C2=A0 transport end-point (snd buffer)
that binds to an identifier which is location independent, an IPv6 num= ber which is not a locator.

The forwarding path of the requests is very close to unmodified IPv6 w= ith the DST address carrying the identifier.
If you check in the draft an hICN node does one additional lookup in a= local cache though. But you can ignore that
for now for sake of clarity. What is important is the address rewrite = operation made on the SRC address
of the request. A copy of the request is stored in the local cache and= the locator of the output interface is written in the=C2=A0
SRC address before transmission. This is used by an upstream hICN or t= he final end-point to know the locator that
will be used to reply.

Replies coming from the snd end-point are label swapped but not like M= PLS.=C2=A0
The label is the identifier itself that is stored in the SRC address o= f the reply,=C2=A0
whereas the DST address is a locator. In this forwarding path a lookup= is made in the local cache to
find a request (one or many) and the associated locator (one or many) = that matches the identifier.
The DST addr field of the replies is rewritten with the locator(s) jus= t obtained from the lookup.
This is how the reply is forwarded to the end-points that issued reque= sts for this identifier.=C2=A0

For the replies there is no FIB lookup on the identifier (as it is in = the SRC addr field).=C2=A0
There can be a lookup in the FIB on the locator stored in the DST of t= he reply to=C2=A0
reach back the previous hICN node or eventually the original end-point= .

=C2=A0
=C2=A0

Hi,

My humble question is: are you supporting SRv6 or hICN?

Regards
Behcet
=C2=A0




On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <tom@quantonium.net>= wrote:
On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello
<luca.mu= scariello@gmail.com> wrote:
> The paragraph you reported is from the draft that describes hICN to en= able
> several use cases.
> Mobility is one of those, not the only one.
> To clarify, the draft on hICN mobility deployment options focuses on t= he 5G
> service based architecture.
>
> You may be asking
> 1) is it possible to get all the features provided by hICN w/o updates= to
> the transport layer?
> 2) is changing the transport protocol unnecessary difficult to enable = all
> the use cases mentioned in the draft?
>
Sorry, but I'm still missing something fundamental here. AFAICT, the idea of hICN is to put routes in the local routing table and use
existing forwarding and routing to forward packets to mobile nodes. So
if a node changes location, then the routing tables need to be
updated. Effectively this is a bunch of host routes that need to be
maintained. At least this is what I gather from the draft:

"hICN network layer is about using the IPv6 FIB to determine a next hop router to forward requests or using a local packet cache to
determine if an incoming request can be satisfied locally."

Is this correct? If it is, then I sort of understand how hICN could be
used for mobility or virtualization without network overlays, but then
I'm completely lost as to why this would require any changes in the
transport layer.

Tom





> IMO, the answers are no for both.
>
> Luca
>
> On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <tom@quantonium.net> wrote:
>>
>> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
>> <luca.muscariello@gmail.com> wrote:
>> > Hi all,
>> >
>> > the draft below has been posted and describes deployments opt= ions for
>> > anchorless mobility management=C2=A0 by using
>> > the hicn network architecture that implements icn semantics i= n IPv6
>> > networks.
>> >
>> >
>> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-dep= loyment-options
>> >
>> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/<= /a>
>> >
>> > A background document has been posted to the internet area WG= and
>> > reported
>> > here for your convenience.
>> > The core principle behind hicn and mobility management is tha= t data
>> > sources
>> > are named using location independent names
>> > encoded in IPv6 addresses. The transport service sitting on t= op of the
>> > hicn
>> > architecture is not based on usual TCP/UDP sockets
>> > but on a novel consumer/producer transport service that will = be
>> > described in
>> > another draft.
>>
>> From the draft: "The transport end-point offers two kinds of = services
>> to applications: a producer and a consumer service. The service is=
>> instantiated in the application by opening communication sockets w= ith
>> an API to perform basic transport service operations: allocation,<= br> >> initialization, configuration, data transmission and reception.&qu= ot;
>>
>> This seems like a pretty dramatic rethink of the transport layer j= ust
>> for the purposes of mobility management. Will there be a way to us= e
>> hICN at the network layer with exsiting and unmodified transport >> protocols (i.e. can this be done without boiling the ocean)?
>>
>> Thanks,
>> Tom
>>
>>
>>
>> > The current document and a companion document that will be po= sted soon
>> > describe the different deployment options
>> > with special care to the 5G service based architecture.
>> > Thanks for the comments already received that helped completi= ng this -00
>> > draft.
>> >
>> > Luca
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > dmm mailing list
>> > dmm@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/dmm
>> >

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



--0000000000000de08b056f13f8cb-- From nobody Wed Jun 20 08:13:18 2018 Return-Path: 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 AF07F130F3A for ; Wed, 20 Jun 2018 08:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 P3YVwu4IyEdI for ; Wed, 20 Jun 2018 08:13:14 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F81130F34 for ; Wed, 20 Jun 2018 08:13:13 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id e18-v6so3696800wrs.5 for ; Wed, 20 Jun 2018 08:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IAGkE6m96CRQ0t09jCLipOXhc6Uoe7OO/6ta9+OZke4=; b=SNg1SIHZ5oauiUSyWxr6Qihtpx8nhVxCxSlJRCvUDEPg9kyRPSeAu+0r6296Sk5sPd I3Fg5SsDPjeJFhytVxiV9GtUgO/JgLpsjSm2q9uQQJPk3YxuswIVUBggrY7H0dmuUTTd kgwf7EX7zWYfQ78GQ20i8P48sni6x12mlJjSraoND8CRTNTqD4hRlVWeaUaRHErqrKeZ QxEWvWacaGpVmJwIwqvWcgifgHDBAs9wKgfQtyozWZR1F2nMPmp94yJQZhZhS3kwtVaR Pli2ovm15OLp0Dr7tLGPxTWJPruQPdlpzFHwVMRPBDo6FcEpmxMC1DH62eZ41RCvaW0n M9Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IAGkE6m96CRQ0t09jCLipOXhc6Uoe7OO/6ta9+OZke4=; b=kDW9za0S8pTLPc+TE1YQEwIOm4qczZQTwIMiLBA5W0kY4rxNfHwDCYsUjtiffjP7FC i2IyTCjaeampmzMtIT94bh8wYemvwasrSY4uqNxTJkNyhyMZl4Mr6t0O28OVwBI4QWmx 3hBIqZAjAHm2BkcMOsdaKv6hBXu1kr50jAV8zCuRZF6NPZrNYsuoQRcDpoldvx1kcB+P gfp2SajG0xR9uLkDZmpa4zgwo4W8zoBezBQAWY0yJWuXfve9jFsUuxJZhFQt9bDXbXkI tFO/U256NDkGkdzPu2oQDKplG9UsqbeABVja23NE8aRcyFjuThGiCL3iJOSwImjZoC2r RzpQ== X-Gm-Message-State: APt69E3kpOqJQWrnrDpcMeEsRC2X6w+sk4kZcHNhsTyRPBKEHp3FAuKz /uU9TjRfNtywtHBmqJoLG1fjOG5IZXt/zMu2zXDALA== X-Google-Smtp-Source: ADUXVKL5GTx2kQpEBfYIU8tG3UuNhkurArTlIt/mUipWoVs++aqVqc+vR3oJXDenH+1mk5rJsQEfho/BWjyElbuTx+c= X-Received: by 2002:adf:e542:: with SMTP id z2-v6mr18768564wrm.111.1529507591904; Wed, 20 Jun 2018 08:13:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:f9d2:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 08:13:11 -0700 (PDT) In-Reply-To: References: <1529505221125.58728@cisco.com> From: Tom Herbert Date: Wed, 20 Jun 2018 08:13:11 -0700 Message-ID: To: Luca Muscariello Cc: Giovanna Carofiglio , Behcet Sarikaya , int-area@ietf.org, Luca Muscariello , dmm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 15:13:17 -0000 On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello wrote: > More on the mobility use case which also makes deployment options easier to > digest > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ > >From the draft: "The goal of hICN is to ease ICN insertion in existing IP infrastructure by: ... 3. minor modification to existing IP routers/endpoints;" Can you elaborate on this "minor modification"? Especially for endpoints, which I assume means hosts, what is the scope, the necessary modifications, and deployment model. Also, will applications have to change or use a new API for hICN? If the implication of hICN is that all Internet hosts need to change to support a new consumer/producer communications model, a new transport protocol, and a new application API-- there's nothing minor about that! Tom > > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) > wrote: >> >> This draft is about hICN and discusses various deployment options with >> associated pros and cons, without supporting one specifically. Clearly, >> depending on application requirements, on network constraints, on phase of >> deployment/transition etc. one option may be preferrable over another one >> (and different ones may coexist). >> >> >> One of the described deployment options also discusses combination of hICN >> and SRv6, without opposing one approach to the other, rather exploiting in >> the combination the advantages of both ones. >> >> >> Giovanna >> >> ________________________________ >> From: Int-area on behalf of Behcet Sarikaya >> >> Sent: Wednesday, June 20, 2018 4:18 PM >> To: Luca Muscariello >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility >> management through hICN (hICN-AMM): Deployment options >> >> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello >> wrote: >>> >>> I wonder whether this conversation should happen in the intarea wg >>> mailing list >>> as the main draft was posted there in the first place. I don't know if >>> cross posting is welcome >>> but I take the risk. >>> >>> Going back to the question, the transport changes are related to the >>> request/reply semantic >>> of the architecture. The two distinct forwarding paths described in the >>> draft take care >>> of forwarding requests or replies.This ends up in the transport layer as >>> a unidirectional >>> channel to recv data or snd data. The replies carry data originating from >>> a transport end-point (snd buffer) >>> that binds to an identifier which is location independent, an IPv6 number >>> which is not a locator. >>> >>> The forwarding path of the requests is very close to unmodified IPv6 with >>> the DST address carrying the identifier. >>> If you check in the draft an hICN node does one additional lookup in a >>> local cache though. But you can ignore that >>> for now for sake of clarity. What is important is the address rewrite >>> operation made on the SRC address >>> of the request. A copy of the request is stored in the local cache and >>> the locator of the output interface is written in the >>> SRC address before transmission. This is used by an upstream hICN or the >>> final end-point to know the locator that >>> will be used to reply. >>> >>> Replies coming from the snd end-point are label swapped but not like >>> MPLS. >>> The label is the identifier itself that is stored in the SRC address of >>> the reply, >>> whereas the DST address is a locator. In this forwarding path a lookup is >>> made in the local cache to >>> find a request (one or many) and the associated locator (one or many) >>> that matches the identifier. >>> The DST addr field of the replies is rewritten with the locator(s) just >>> obtained from the lookup. >>> This is how the reply is forwarded to the end-points that issued requests >>> for this identifier. >>> >>> For the replies there is no FIB lookup on the identifier (as it is in the >>> SRC addr field). >>> There can be a lookup in the FIB on the locator stored in the DST of the >>> reply to >>> reach back the previous hICN node or eventually the original end-point. >>> >>> >>> >> >> >> Hi, >> >> My humble question is: are you supporting SRv6 or hICN? >> >> Regards >> Behcet >> >>> >>> >>> >>> >>> >>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: >>>> >>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >>>> wrote: >>>> > The paragraph you reported is from the draft that describes hICN to >>>> > enable >>>> > several use cases. >>>> > Mobility is one of those, not the only one. >>>> > To clarify, the draft on hICN mobility deployment options focuses on >>>> > the 5G >>>> > service based architecture. >>>> > >>>> > You may be asking >>>> > 1) is it possible to get all the features provided by hICN w/o updates >>>> > to >>>> > the transport layer? >>>> > 2) is changing the transport protocol unnecessary difficult to enable >>>> > all >>>> > the use cases mentioned in the draft? >>>> > >>>> Sorry, but I'm still missing something fundamental here. AFAICT, the >>>> idea of hICN is to put routes in the local routing table and use >>>> existing forwarding and routing to forward packets to mobile nodes. So >>>> if a node changes location, then the routing tables need to be >>>> updated. Effectively this is a bunch of host routes that need to be >>>> maintained. At least this is what I gather from the draft: >>>> >>>> "hICN network layer is about using the IPv6 FIB to determine a next >>>> hop router to forward requests or using a local packet cache to >>>> determine if an incoming request can be satisfied locally." >>>> >>>> Is this correct? If it is, then I sort of understand how hICN could be >>>> used for mobility or virtualization without network overlays, but then >>>> I'm completely lost as to why this would require any changes in the >>>> transport layer. >>>> >>>> Tom >>>> >>>> >>>> >>>> >>>> >>>> > IMO, the answers are no for both. >>>> > >>>> > Luca >>>> > >>>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert >>>> > wrote: >>>> >> >>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >>>> >> wrote: >>>> >> > Hi all, >>>> >> > >>>> >> > the draft below has been posted and describes deployments options >>>> >> > for >>>> >> > anchorless mobility management by using >>>> >> > the hicn network architecture that implements icn semantics in IPv6 >>>> >> > networks. >>>> >> > >>>> >> > >>>> >> > >>>> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options >>>> >> > >>>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >>>> >> > >>>> >> > A background document has been posted to the internet area WG and >>>> >> > reported >>>> >> > here for your convenience. >>>> >> > The core principle behind hicn and mobility management is that data >>>> >> > sources >>>> >> > are named using location independent names >>>> >> > encoded in IPv6 addresses. The transport service sitting on top of >>>> >> > the >>>> >> > hicn >>>> >> > architecture is not based on usual TCP/UDP sockets >>>> >> > but on a novel consumer/producer transport service that will be >>>> >> > described in >>>> >> > another draft. >>>> >> >>>> >> From the draft: "The transport end-point offers two kinds of services >>>> >> to applications: a producer and a consumer service. The service is >>>> >> instantiated in the application by opening communication sockets with >>>> >> an API to perform basic transport service operations: allocation, >>>> >> initialization, configuration, data transmission and reception." >>>> >> >>>> >> This seems like a pretty dramatic rethink of the transport layer just >>>> >> for the purposes of mobility management. Will there be a way to use >>>> >> hICN at the network layer with exsiting and unmodified transport >>>> >> protocols (i.e. can this be done without boiling the ocean)? >>>> >> >>>> >> Thanks, >>>> >> Tom >>>> >> >>>> >> >>>> >> >>>> >> > The current document and a companion document that will be posted >>>> >> > soon >>>> >> > describe the different deployment options >>>> >> > with special care to the 5G service based architecture. >>>> >> > Thanks for the comments already received that helped completing >>>> >> > this -00 >>>> >> > draft. >>>> >> > >>>> >> > Luca >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > _______________________________________________ >>>> >> > dmm mailing list >>>> >> > dmm@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/dmm >>>> >> > >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >> > From nobody Wed Jun 20 09:06:51 2018 Return-Path: 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 8966D131118; Wed, 20 Jun 2018 09:06:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 c3E3OfRz7fXX; Wed, 20 Jun 2018 09:06:29 -0700 (PDT) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D7B130E19; Wed, 20 Jun 2018 09:06:28 -0700 (PDT) Received: by mail-yw0-x242.google.com with SMTP id v131-v6so36791ywg.2; Wed, 20 Jun 2018 09:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zg33u4qDs9wcSixo+oY4ntx7sdLpjkSGGn4/psgi6PE=; b=saaLPfBJFs51vo+mnJRtn4bKKOjiYy1YU5CM9UK89o91GcWNguZSY2rs0yZJiJYORA RVxnSEbrSwTl7/Q1SPI3eZo8qUIeQgAe8pbBOoPzE/HskEH/B/rr/QZYNzyEr6Vewmb4 EQGeOcgWpe+/mBgSZp/+S7oAHiY/LDdEGxZqbUqGwQldEaDLOQ9ijUWC40l86HweLlmE 8IcaQwtlTADEMPOHj7mIbEoLoiEmxab/ka0ze0fo0WKmaEm5GCTUwcBGsBAjstZHxnHo Jiy2sxl55M3rxlUF68S5oJOynwNCrb0R6fJluH6oZ1WLbyFra5gAhMWGb9+DRGAvSLav cRuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zg33u4qDs9wcSixo+oY4ntx7sdLpjkSGGn4/psgi6PE=; b=jR/AOHuEXaGBNvybJE1rE3t7hwNmHPJNQ/1Cn7m59bABga6Oerzm2RF2Mm56k9fpPN RSLxGnfUrMJO21rDGxAzLJY1l1/gNTP1ls7AdW+7NyYkGuwZju7I4VLKHhs8EehZ7YB/ TlznCKw5jja7JkibryFIDdPU95vCt6x1mIx9hw8bUZFIqFW91zkMw2mxxfsz2EFb44zG DqZsLxniLf44xz2K9hJQGPvTN/5rMImG1ro7SfJ8nYjQyBN75bgSGx79KsgVmYpURnCR YWNmzwbF3pz95L0ApnMOEfLKXrIBmds8JTYD1gdN8Qwetwc5nqBQKwZ9zJfmBJkCpCK/ AQZw== X-Gm-Message-State: APt69E1+K+VagW3i/3e6kUmdYvcoV+42l93E6aQCqzr1DyiX/pbj5FRk m1ur1oA9047562fSjTd65U7sI/LRDlCx2v3FLBk= X-Google-Smtp-Source: ADUXVKJlwHWvih6kHbL8EGo2ciesOrGXLKubLImfmq2fLtCZmaM3P+WNZu2iD1rAqYKnO1CzUOdghZqwOsgDAjLmOX8= X-Received: by 2002:a81:a316:: with SMTP id a22-v6mr8938670ywh.142.1529510787808; Wed, 20 Jun 2018 09:06:27 -0700 (PDT) MIME-Version: 1.0 References: <1529505221125.58728@cisco.com> In-Reply-To: From: Luca Muscariello Date: Wed, 20 Jun 2018 18:06:16 +0200 Message-ID: To: tom@quantonium.net Cc: Giovanna Carofiglio , sarikaya@ieee.org, int-area@ietf.org, Luca Muscariello , dmm@ietf.org Content-Type: multipart/alternative; boundary="000000000000300304056f14fb46" Archived-At: Subject: Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 16:06:42 -0000 --000000000000300304056f14fb46 Content-Type: text/plain; charset="UTF-8" The adjective minor is used in a comparative way. At least I intended that way. hICN allows to implement ICN features with less changes than using ICN as an overlay. On an absolute scale, I don't think that hICN requires negligible changes. So I haven't used the adjective minor as a synonym of negligible. I do think that having those changes are worthy for many apps. Back to your questions that I understand this way: 1) What is the hICN socket API? 2) Does hICN imply that all hosts have to change transport stack? 3) Does hICN disrupt the TCP/IP stack in an end host? 1) The answer to the first question is something that I wanted to discuss in the transport area but repeating does good. In the current implementation we support two different APIs. The first one is a BSD socket API, the second one is a post-socket API that is currently under development in the TAPS WG with a first integration in iOS 12 beta. I'm not contributing to TAPS but I think it is worthy to keep our implementation updated with TAPS. I haven't finished to write a draft but I have a technical report that I could share right before next IETF. 2) An application developer may or may not want to change to use this API. But I would turn the question around to ask, is it worthy to change the application to exploit this new transport service and the underlying network service to get a certain number of benefits? IMO, yes. Is it worthy to implement a new transport service in user-space such as LEDBAT, QUIC or the variety of transport services running for RTC apps? The answer is up to the application. It is the app that decides. So, no, there is no need to change all hosts. IMO the answer is it depends. 3) when you enable hICN in an end host the local network configuration manages two distinct namespaces, one for locators and one for identifiers (intended as location independent names). An end-host can manage several locators because might be multi-homed and can manage several identifiers because it has been assigned identifiers to name data sources at the host: mic, camera, an app etc. This host continues to be able to open TCP or UDP sockets (but also SCTP or others) with the usual socket bindings. Just to give an example: We are using our hICN transport library for WebRTC, MPEG-DASH among other things. An MPEG-DASH segment can be retrieved by a video client using TCP, QUIC or the consumer/producer socket. The video player can sequentially switch protocol to retrieve the segment. Not that it make any sense but it's just to explain that they live in the same end-host. If the app considers that one transport service can provide features that are advantageous it can optionally switch to it. There is no intent to replace TCP, UDP, LEDBAT, QUIC, SCTP or any other transport protocol with the consumer/producer sockets. Luca On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert wrote: > On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello > wrote: > > More on the mobility use case which also makes deployment options easier > to > > digest > > > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ > > > > From the draft: > > "The goal of hICN is to ease ICN insertion in existing IP infrastructure > by: > ... > 3. minor modification to existing IP routers/endpoints;" > > Can you elaborate on this "minor modification"? Especially for > endpoints, which I assume means hosts, what is the scope, the > necessary modifications, and deployment model. Also, will applications > have to change or use a new API for hICN? > > If the implication of hICN is that all Internet hosts need to change > to support a new consumer/producer communications model, a new > transport protocol, and a new application API-- there's nothing minor > about that! > > Tom > > > > > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) > > wrote: > >> > >> This draft is about hICN and discusses various deployment options with > >> associated pros and cons, without supporting one specifically. Clearly, > >> depending on application requirements, on network constraints, on > phase of > >> deployment/transition etc. one option may be preferrable over another > one > >> (and different ones may coexist). > >> > >> > >> One of the described deployment options also discusses combination of > hICN > >> and SRv6, without opposing one approach to the other, rather exploiting > in > >> the combination the advantages of both ones. > >> > >> > >> Giovanna > >> > >> ________________________________ > >> From: Int-area on behalf of Behcet Sarikaya > >> > >> Sent: Wednesday, June 20, 2018 4:18 PM > >> To: Luca Muscariello > >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm > >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility > >> management through hICN (hICN-AMM): Deployment options > >> > >> > >> > >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello > >> wrote: > >>> > >>> I wonder whether this conversation should happen in the intarea wg > >>> mailing list > >>> as the main draft was posted there in the first place. I don't know if > >>> cross posting is welcome > >>> but I take the risk. > >>> > >>> Going back to the question, the transport changes are related to the > >>> request/reply semantic > >>> of the architecture. The two distinct forwarding paths described in the > >>> draft take care > >>> of forwarding requests or replies.This ends up in the transport layer > as > >>> a unidirectional > >>> channel to recv data or snd data. The replies carry data originating > from > >>> a transport end-point (snd buffer) > >>> that binds to an identifier which is location independent, an IPv6 > number > >>> which is not a locator. > >>> > >>> The forwarding path of the requests is very close to unmodified IPv6 > with > >>> the DST address carrying the identifier. > >>> If you check in the draft an hICN node does one additional lookup in a > >>> local cache though. But you can ignore that > >>> for now for sake of clarity. What is important is the address rewrite > >>> operation made on the SRC address > >>> of the request. A copy of the request is stored in the local cache and > >>> the locator of the output interface is written in the > >>> SRC address before transmission. This is used by an upstream hICN or > the > >>> final end-point to know the locator that > >>> will be used to reply. > >>> > >>> Replies coming from the snd end-point are label swapped but not like > >>> MPLS. > >>> The label is the identifier itself that is stored in the SRC address of > >>> the reply, > >>> whereas the DST address is a locator. In this forwarding path a lookup > is > >>> made in the local cache to > >>> find a request (one or many) and the associated locator (one or many) > >>> that matches the identifier. > >>> The DST addr field of the replies is rewritten with the locator(s) just > >>> obtained from the lookup. > >>> This is how the reply is forwarded to the end-points that issued > requests > >>> for this identifier. > >>> > >>> For the replies there is no FIB lookup on the identifier (as it is in > the > >>> SRC addr field). > >>> There can be a lookup in the FIB on the locator stored in the DST of > the > >>> reply to > >>> reach back the previous hICN node or eventually the original end-point. > >>> > >>> > >>> > >> > >> > >> Hi, > >> > >> My humble question is: are you supporting SRv6 or hICN? > >> > >> Regards > >> Behcet > >> > >>> > >>> > >>> > >>> > >>> > >>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert > wrote: > >>>> > >>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello > >>>> wrote: > >>>> > The paragraph you reported is from the draft that describes hICN to > >>>> > enable > >>>> > several use cases. > >>>> > Mobility is one of those, not the only one. > >>>> > To clarify, the draft on hICN mobility deployment options focuses on > >>>> > the 5G > >>>> > service based architecture. > >>>> > > >>>> > You may be asking > >>>> > 1) is it possible to get all the features provided by hICN w/o > updates > >>>> > to > >>>> > the transport layer? > >>>> > 2) is changing the transport protocol unnecessary difficult to > enable > >>>> > all > >>>> > the use cases mentioned in the draft? > >>>> > > >>>> Sorry, but I'm still missing something fundamental here. AFAICT, the > >>>> idea of hICN is to put routes in the local routing table and use > >>>> existing forwarding and routing to forward packets to mobile nodes. So > >>>> if a node changes location, then the routing tables need to be > >>>> updated. Effectively this is a bunch of host routes that need to be > >>>> maintained. At least this is what I gather from the draft: > >>>> > >>>> "hICN network layer is about using the IPv6 FIB to determine a next > >>>> hop router to forward requests or using a local packet cache to > >>>> determine if an incoming request can be satisfied locally." > >>>> > >>>> Is this correct? If it is, then I sort of understand how hICN could be > >>>> used for mobility or virtualization without network overlays, but then > >>>> I'm completely lost as to why this would require any changes in the > >>>> transport layer. > >>>> > >>>> Tom > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > IMO, the answers are no for both. > >>>> > > >>>> > Luca > >>>> > > >>>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert > >>>> > wrote: > >>>> >> > >>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello > >>>> >> wrote: > >>>> >> > Hi all, > >>>> >> > > >>>> >> > the draft below has been posted and describes deployments options > >>>> >> > for > >>>> >> > anchorless mobility management by using > >>>> >> > the hicn network architecture that implements icn semantics in > IPv6 > >>>> >> > networks. > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options > >>>> >> > > >>>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ > >>>> >> > > >>>> >> > A background document has been posted to the internet area WG and > >>>> >> > reported > >>>> >> > here for your convenience. > >>>> >> > The core principle behind hicn and mobility management is that > data > >>>> >> > sources > >>>> >> > are named using location independent names > >>>> >> > encoded in IPv6 addresses. The transport service sitting on top > of > >>>> >> > the > >>>> >> > hicn > >>>> >> > architecture is not based on usual TCP/UDP sockets > >>>> >> > but on a novel consumer/producer transport service that will be > >>>> >> > described in > >>>> >> > another draft. > >>>> >> > >>>> >> From the draft: "The transport end-point offers two kinds of > services > >>>> >> to applications: a producer and a consumer service. The service is > >>>> >> instantiated in the application by opening communication sockets > with > >>>> >> an API to perform basic transport service operations: allocation, > >>>> >> initialization, configuration, data transmission and reception." > >>>> >> > >>>> >> This seems like a pretty dramatic rethink of the transport layer > just > >>>> >> for the purposes of mobility management. Will there be a way to use > >>>> >> hICN at the network layer with exsiting and unmodified transport > >>>> >> protocols (i.e. can this be done without boiling the ocean)? > >>>> >> > >>>> >> Thanks, > >>>> >> Tom > >>>> >> > >>>> >> > >>>> >> > >>>> >> > The current document and a companion document that will be posted > >>>> >> > soon > >>>> >> > describe the different deployment options > >>>> >> > with special care to the 5G service based architecture. > >>>> >> > Thanks for the comments already received that helped completing > >>>> >> > this -00 > >>>> >> > draft. > >>>> >> > > >>>> >> > Luca > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > _______________________________________________ > >>>> >> > dmm mailing list > >>>> >> > dmm@ietf.org > >>>> >> > https://www.ietf.org/mailman/listinfo/dmm > >>>> >> > > >>> > >>> > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >>> > >> > > > --000000000000300304056f14fb46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The adjective minor is used in a comparative way. At = least I intended that way.
hICN allows to implement ICN features = with less changes than using ICN as an overlay.
On an absolute sc= ale, I don't think that hICN requires negligible changes.
So I haven't used the adjective minor as a synonym of negligible.=C2= =A0
I do think that having those changes are worthy for many apps= .

Back to your questions that I understand this wa= y:
1) What is the hICN socket API?=C2=A0
2) Does hICN i= mply that all hosts have to change transport stack?
3) Does hICN = disrupt the TCP/IP stack in an end host?


1) The answer to the first question is something that I wanted to dis= cuss in the transport area=C2=A0
but repeating does good. In the = current implementation we support two different APIs.
The first o= ne is a BSD socket API, the second one is a post-socket API that is current= ly
under development in the TAPS WG with a first integration in i= OS 12 beta. I'm not
contributing to TAPS but I think it is wo= rthy to keep our implementation updated with TAPS.
I haven't = finished to write a draft but I have a technical report that I could share = right before next IETF.

2) An application develope= r may or may not want to change to use this API.
But I would turn= the question around to ask, is it worthy to change the application to expl= oit
this new transport service and the underlying network service= to get a certain number of benefits?
IMO, yes.

Is it worthy to implement a new transport service in user-space suc= h as LEDBAT, QUIC or the variety of transport
services running fo= r RTC apps? The answer is up to the application. It is the app that decides= .
So, no, there is no need to change all hosts. IMO the answer is= it depends.

3) when you enable hICN in an end hos= t the local network configuration manages two distinct namespaces,
one for locators and one for identifiers (intended as location independen= t names).=C2=A0 An end-host can manage several
locators because m= ight be multi-homed and can manage several identifiers because it has been = assigned identifiers
to name data sources at the host: mic, camer= a, an app etc.
This host continues to be able to open TCP or UDP = sockets (but also SCTP or others) with the usual socket bindings.

Just to give an example: We are using our hICN=C2=A0 transp= ort library for WebRTC, MPEG-DASH among other things.
An MPEG-DAS= H segment can be retrieved by a video client using TCP, QUIC or the consume= r/producer socket.=C2=A0
The video player can sequentially switch= protocol to retrieve the segment. Not that it make any sense but it's = just
to explain that they live in the same end-host.=C2=A0 If the= app considers that one transport service can provide
features th= at are advantageous it can optionally switch to it.=C2=A0
There i= s no intent to replace TCP, UDP, LEDBAT, QUIC, SCTP or any other transport = protocol with the consumer/producer
sockets.

=
Luca

=C2=A0

On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert <tom@quantonium.net> wrote:
On Wed, Jun 20, 2018 at 7:48 AM, Luca Mu= scariello
<luca.mu= scariello@gmail.com> wrote:
> More on the mobility use case which also makes deployment options easi= er to
> digest
>
> https://datatracker.ietf.org/doc/= draft-auge-dmm-hicn-mobility/
>

>From the draft:

"The goal of hICN is to ease ICN insertion in existing IP infrastructu= re by:
...
=C2=A03.=C2=A0 minor modification to existing IP routers/endpoints;"
Can you elaborate on this "minor modification"? Especially for endpoints, which I assume means hosts, what is the scope, the
necessary modifications, and deployment model. Also, will applications
have to change or use a new API for hICN?

If the implication of hICN is that all Internet hosts need to change
to support a new consumer/producer communications model, a new
transport protocol, and a new application API-- there's nothing minor about that!

Tom

>
> On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig)
> <gcarofig@c= isco.com> wrote:
>>
>> This draft is about hICN and discusses various deployment options = with
>> associated pros and cons, without supporting one specifically. Cle= arly,
>> depending on=C2=A0 application requirements, on network constraint= s, on phase of
>> deployment/transition=C2=A0 etc. one option may be preferrable ove= r another one
>> (and different ones may coexist).
>>
>>
>> One of the described deployment options also discusses combination= of hICN
>> and SRv6, without opposing one approach to the other, rather explo= iting in
>> the combination the advantages of both ones.
>>
>>
>> Giovanna
>>
>> ________________________________
>> From: Int-area <int-area-bounces@ietf.org> on behalf of Behcet Sarik= aya
>> <sa= rikaya2012@gmail.com>
>> Sent: Wednesday, June 20, 2018 4:18 PM
>> To: Luca Muscariello
>> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobilit= y
>> management through hICN (hICN-AMM): Deployment options
>>
>>
>>
>> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello
>> <luca.muscariello@gmail.com> wrote:
>>>
>>> I wonder whether this conversation should happen in the intare= a wg
>>> mailing list
>>> as the main draft was posted there in the first place. I don&#= 39;t know if
>>> cross posting is welcome
>>> but I take the risk.
>>>
>>> Going back to the question, the transport changes are related = to the
>>> request/reply semantic
>>> of the architecture. The two distinct forwarding paths describ= ed in the
>>> draft take care
>>> of forwarding requests or replies.This ends up in the transpor= t layer as
>>> a unidirectional
>>> channel to recv data or snd data. The replies carry data origi= nating from
>>> a=C2=A0 transport end-point (snd buffer)
>>> that binds to an identifier which is location independent, an = IPv6 number
>>> which is not a locator.
>>>
>>> The forwarding path of the requests is very close to unmodifie= d IPv6 with
>>> the DST address carrying the identifier.
>>> If you check in the draft an hICN node does one additional loo= kup in a
>>> local cache though. But you can ignore that
>>> for now for sake of clarity. What is important is the address = rewrite
>>> operation made on the SRC address
>>> of the request. A copy of the request is stored in the local c= ache and
>>> the locator of the output interface is written in the
>>> SRC address before transmission. This is used by an upstream h= ICN or the
>>> final end-point to know the locator that
>>> will be used to reply.
>>>
>>> Replies coming from the snd end-point are label swapped but no= t like
>>> MPLS.
>>> The label is the identifier itself that is stored in the SRC a= ddress of
>>> the reply,
>>> whereas the DST address is a locator. In this forwarding path = a lookup is
>>> made in the local cache to
>>> find a request (one or many) and the associated locator (one o= r many)
>>> that matches the identifier.
>>> The DST addr field of the replies is rewritten with the locato= r(s) just
>>> obtained from the lookup.
>>> This is how the reply is forwarded to the end-points that issu= ed requests
>>> for this identifier.
>>>
>>> For the replies there is no FIB lookup on the identifier (as i= t is in the
>>> SRC addr field).
>>> There can be a lookup in the FIB on the locator stored in the = DST of the
>>> reply to
>>> reach back the previous hICN node or eventually the original e= nd-point.
>>>
>>>
>>>
>>
>>
>> Hi,
>>
>> My humble question is: are you supporting SRv6 or hICN?
>>
>> Regards
>> Behcet
>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <tom@quantonium.net> wrote= :
>>>>
>>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello
>>>> <luca.muscariello@gmail.com> wrote:
>>>> > The paragraph you reported is from the draft that des= cribes hICN to
>>>> > enable
>>>> > several use cases.
>>>> > Mobility is one of those, not the only one.
>>>> > To clarify, the draft on hICN mobility deployment opt= ions focuses on
>>>> > the 5G
>>>> > service based architecture.
>>>> >
>>>> > You may be asking
>>>> > 1) is it possible to get all the features provided by= hICN w/o updates
>>>> > to
>>>> > the transport layer?
>>>> > 2) is changing the transport protocol unnecessary dif= ficult to enable
>>>> > all
>>>> > the use cases mentioned in the draft?
>>>> >
>>>> Sorry, but I'm still missing something fundamental her= e. AFAICT, the
>>>> idea of hICN is to put routes in the local routing table a= nd use
>>>> existing forwarding and routing to forward packets to mobi= le nodes. So
>>>> if a node changes location, then the routing tables need t= o be
>>>> updated. Effectively this is a bunch of host routes that n= eed to be
>>>> maintained. At least this is what I gather from the draft:=
>>>>
>>>> "hICN network layer is about using the IPv6 FIB to de= termine a next
>>>> hop router to forward requests or using a local packet cac= he to
>>>> determine if an incoming request can be satisfied locally.= "
>>>>
>>>> Is this correct? If it is, then I sort of understand how h= ICN could be
>>>> used for mobility or virtualization without network overla= ys, but then
>>>> I'm completely lost as to why this would require any c= hanges in the
>>>> transport layer.
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > IMO, the answers are no for both.
>>>> >
>>>> > Luca
>>>> >
>>>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <tom@quantonium.net&g= t;
>>>> > wrote:
>>>> >>
>>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello=
>>>> >> <luca.muscariello@gmail.com> wrote:
>>>> >> > Hi all,
>>>> >> >
>>>> >> > the draft below has been posted and describe= s deployments options
>>>> >> > for
>>>> >> > anchorless mobility management=C2=A0 by usin= g
>>>> >> > the hicn network architecture that implement= s icn semantics in IPv6
>>>> >> > networks.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-d= eployment-options
>>>> >> >
>>>> >> > https= ://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/
>>>> >> >
>>>> >> > A background document has been posted to the= internet area WG and
>>>> >> > reported
>>>> >> > here for your convenience.
>>>> >> > The core principle behind hicn and mobility = management is that data
>>>> >> > sources
>>>> >> > are named using location independent names >>>> >> > encoded in IPv6 addresses. The transport ser= vice sitting on top of
>>>> >> > the
>>>> >> > hicn
>>>> >> > architecture is not based on usual TCP/UDP s= ockets
>>>> >> > but on a novel consumer/producer transport s= ervice that will be
>>>> >> > described in
>>>> >> > another draft.
>>>> >>
>>>> >> From the draft: "The transport end-point off= ers two kinds of services
>>>> >> to applications: a producer and a consumer servic= e. The service is
>>>> >> instantiated in the application by opening commun= ication sockets with
>>>> >> an API to perform basic transport service operati= ons: allocation,
>>>> >> initialization, configuration, data transmission = and reception."
>>>> >>
>>>> >> This seems like a pretty dramatic rethink of the = transport layer just
>>>> >> for the purposes of mobility management. Will the= re be a way to use
>>>> >> hICN at the network layer with exsiting and unmod= ified transport
>>>> >> protocols (i.e. can this be done without boiling = the ocean)?
>>>> >>
>>>> >> Thanks,
>>>> >> Tom
>>>> >>
>>>> >>
>>>> >>
>>>> >> > The current document and a companion documen= t that will be posted
>>>> >> > soon
>>>> >> > describe the different deployment options >>>> >> > with special care to the 5G service based ar= chitecture.
>>>> >> > Thanks for the comments already received tha= t helped completing
>>>> >> > this -00
>>>> >> > draft.
>>>> >> >
>>>> >> > Luca
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > ____________________________________________= ___
>>>> >> > dmm mailing list
>>>> >> > dmm@ietf.org
>>>> >> > https://www.ietf.org/mailman= /listinfo/dmm
>>>> >> >
>>>
>>>
>>> _______________________________________________
>>> dmm mailing list
>>> dmm@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/dmm<= br> >>>
>>
>
--000000000000300304056f14fb46-- From nobody Wed Jun 20 09:39:19 2018 Return-Path: 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 B04CB129C6B; Wed, 20 Jun 2018 09:39:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 1Go4dsVDUcsB; Wed, 20 Jun 2018 09:39:09 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40647131059; Wed, 20 Jun 2018 09:39:04 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id w3-v6so69027ybq.10; Wed, 20 Jun 2018 09:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mI641FhI5YKjWvsMb2UVfizdHcPvr+SXmGlwcz/Dtho=; b=BGFnLMZ982oRHdQz44VdUJ2aRAAIHZtQDemOTk55FK2S1ttPIvib9+7m7cM4i9e5Pu EVoBdTTsHbCZ+Ak3fG7wh13lBx7LuPTLMNLtf1VrP7NCBpNz6gtipep19oRWy6QW/Aba bM1XRNDKHuKt4xSofJ1afZpN229QpgEUEpf/hmzpcPJLXD+SeSCtaRLTwsQZrXOOem4m t4NwaYsXhyc8Hp/KLlOYW/HKWUeiU6aG+GXSetK0kn0CzPcmOjhEiOfVd3gQ2/kdgQAA UYCn99MuYPlXpao/pa9jUZbKK/BLLdwZKwtaOgSNQ44gD5792vQml3ZI24DsLUipm51n n9dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mI641FhI5YKjWvsMb2UVfizdHcPvr+SXmGlwcz/Dtho=; b=mhUvC0LZZ0XgG+X9qKNjsEWLv4ujWwzTqDpd9lk4x/HwqIdSmSbE5DbXyh8NBfZ6qr MFrMiLv5bE+37K1NtwEvRD5j0Z/mzRGh5HLRyr7s6QimmJYZYsitlr1oW4SPcUBVfw3c JXxg7Z+UPpqu11VxDKGpdBe7wuKNSeEERov/Xt4C7nWu1GbTfe8RQphBj81XhzmlANpM ITksg9BGgYm55laGa9lj3ap8qjqVCBVa2/9/lpPYO19Vem//3wjgR7vS8IFhQk4/iCVM L86uAcWiRPDJprcgeCaY+8ul6Gc1QjJK3XI80WpkVctWkTpS3MGxVk0RRWt0x9ppPI+k xRkQ== X-Gm-Message-State: APt69E23PfN6F8L937wY3an59aEz19gMAxj+5ko1Phsq/VaMYqLezIfG MWJaEIQopX9f/QRzC1CNB5ftJADuFIrGGrSt0fU= X-Google-Smtp-Source: ADUXVKL/JcxUqQtzPljZlctYd4s7IffHsycWeCq+mFEallmpj1RNNDCqB8FnQUcC1PLA2upUbGDSl3j/o5EgFGC0Bkc= X-Received: by 2002:a25:683:: with SMTP id 125-v6mr10563523ybg.232.1529512738546; Wed, 20 Jun 2018 09:38:58 -0700 (PDT) MIME-Version: 1.0 References: <1529505221125.58728@cisco.com> In-Reply-To: From: Luca Muscariello Date: Wed, 20 Jun 2018 18:38:47 +0200 Message-ID: To: sarikaya@ieee.org Cc: Giovanna Carofiglio , int-area@ietf.org, Luca Muscariello , tom@quantonium.net, dmm@ietf.org Content-Type: multipart/alternative; boundary="00000000000075fdde056f156f74" Archived-At: Subject: Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 16:39:13 -0000 --00000000000075fdde056f156f74 Content-Type: text/plain; charset="UTF-8" I am sorry but I'm not sure I get your question right. I am not sure SRv6 is just a tunnelling technique but I am not right person to talk about that. We do mention SRv6 in the draft to show how hICN can use it to steer the next-hop path for the request carrying the ID in the DST addr field and for the reply to steer the next-hop path carrying the locator in the DST addr field. In the first place hICN makes use of the IPv6 FIB. This is the default. But there are several interoperable protocols that might be included in the next-hop pipeline processing. Does it clarify your doubts? Luca On Wed, Jun 20, 2018 at 4:54 PM Behcet Sarikaya wrote: > > > On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) < > gcarofig@cisco.com> wrote: > >> This draft is about hICN and discusses various deployment options with >> associated pros and cons, without supporting one specifically. Clearly, >> depending on application requirements, on network constraints, on phase of >> deployment/transition etc. one option may be preferrable over another one >> (and different ones may coexist). >> >> >> One of the described deployment options also discusses combination of >> hICN and SRv6, without opposing one approach to the other, rather >> exploiting in the combination the advantages of both ones. >> >> >> > I don't understand. > SRv6 is tunneling technique while hICN is talking about anchoress mobility. > Did I get something wrong? > > Behcet > >> Giovanna >> ------------------------------ >> *From:* Int-area on behalf of Behcet >> Sarikaya >> *Sent:* Wednesday, June 20, 2018 4:18 PM >> *To:* Luca Muscariello >> *Cc:* Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> *Subject:* Re: [Int-area] [DMM] New draft posted: Anchorless mobility >> management through hICN (hICN-AMM): Deployment options >> >> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello < >> luca.muscariello@gmail.com> wrote: >> >>> I wonder whether this conversation should happen in the intarea wg >>> mailing list >>> as the main draft was posted there in the first place. I don't know if >>> cross posting is welcome >>> but I take the risk. >>> >>> Going back to the question, the transport changes are related to the >>> request/reply semantic >>> of the architecture. The two distinct forwarding paths described in the >>> draft take care >>> of forwarding requests or replies.This ends up in the transport layer as >>> a unidirectional >>> channel to recv data or snd data. The replies carry data originating >>> from a transport end-point (snd buffer) >>> that binds to an identifier which is location independent, an IPv6 >>> number which is not a locator. >>> >>> The forwarding path of the requests is very close to unmodified IPv6 >>> with the DST address carrying the identifier. >>> If you check in the draft an hICN node does one additional lookup in a >>> local cache though. But you can ignore that >>> for now for sake of clarity. What is important is the address rewrite >>> operation made on the SRC address >>> of the request. A copy of the request is stored in the local cache and >>> the locator of the output interface is written in the >>> SRC address before transmission. This is used by an upstream hICN or the >>> final end-point to know the locator that >>> will be used to reply. >>> >>> Replies coming from the snd end-point are label swapped but not like >>> MPLS. >>> The label is the identifier itself that is stored in the SRC address of >>> the reply, >>> whereas the DST address is a locator. In this forwarding path a lookup >>> is made in the local cache to >>> find a request (one or many) and the associated locator (one or many) >>> that matches the identifier. >>> The DST addr field of the replies is rewritten with the locator(s) just >>> obtained from the lookup. >>> This is how the reply is forwarded to the end-points that issued >>> requests for this identifier. >>> >>> For the replies there is no FIB lookup on the identifier (as it is in >>> the SRC addr field). >>> There can be a lookup in the FIB on the locator stored in the DST of the >>> reply to >>> reach back the previous hICN node or eventually the original end-point. >>> >>> >>> >>> >> >> Hi, >> >> My humble question is: are you supporting SRv6 or hICN? >> >> Regards >> Behcet >> >> >>> >>> >>> >>> >>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: >>> >>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >>>> wrote: >>>> > The paragraph you reported is from the draft that describes hICN to >>>> enable >>>> > several use cases. >>>> > Mobility is one of those, not the only one. >>>> > To clarify, the draft on hICN mobility deployment options focuses on >>>> the 5G >>>> > service based architecture. >>>> > >>>> > You may be asking >>>> > 1) is it possible to get all the features provided by hICN w/o >>>> updates to >>>> > the transport layer? >>>> > 2) is changing the transport protocol unnecessary difficult to enable >>>> all >>>> > the use cases mentioned in the draft? >>>> > >>>> Sorry, but I'm still missing something fundamental here. AFAICT, the >>>> idea of hICN is to put routes in the local routing table and use >>>> existing forwarding and routing to forward packets to mobile nodes. So >>>> if a node changes location, then the routing tables need to be >>>> updated. Effectively this is a bunch of host routes that need to be >>>> maintained. At least this is what I gather from the draft: >>>> >>>> "hICN network layer is about using the IPv6 FIB to determine a next >>>> hop router to forward requests or using a local packet cache to >>>> determine if an incoming request can be satisfied locally." >>>> >>>> Is this correct? If it is, then I sort of understand how hICN could be >>>> used for mobility or virtualization without network overlays, but then >>>> I'm completely lost as to why this would require any changes in the >>>> transport layer. >>>> >>>> Tom >>>> >>>> >>>> >>>> >>>> >>>> > IMO, the answers are no for both. >>>> > >>>> > Luca >>>> > >>>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert >>>> wrote: >>>> >> >>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >>>> >> wrote: >>>> >> > Hi all, >>>> >> > >>>> >> > the draft below has been posted and describes deployments options >>>> for >>>> >> > anchorless mobility management by using >>>> >> > the hicn network architecture that implements icn semantics in IPv6 >>>> >> > networks. >>>> >> > >>>> >> > >>>> >> > >>>> https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options >>>> >> > >>>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >>>> >> > >>>> >> > A background document has been posted to the internet area WG and >>>> >> > reported >>>> >> > here for your convenience. >>>> >> > The core principle behind hicn and mobility management is that data >>>> >> > sources >>>> >> > are named using location independent names >>>> >> > encoded in IPv6 addresses. The transport service sitting on top of >>>> the >>>> >> > hicn >>>> >> > architecture is not based on usual TCP/UDP sockets >>>> >> > but on a novel consumer/producer transport service that will be >>>> >> > described in >>>> >> > another draft. >>>> >> >>>> >> From the draft: "The transport end-point offers two kinds of services >>>> >> to applications: a producer and a consumer service. The service is >>>> >> instantiated in the application by opening communication sockets with >>>> >> an API to perform basic transport service operations: allocation, >>>> >> initialization, configuration, data transmission and reception." >>>> >> >>>> >> This seems like a pretty dramatic rethink of the transport layer just >>>> >> for the purposes of mobility management. Will there be a way to use >>>> >> hICN at the network layer with exsiting and unmodified transport >>>> >> protocols (i.e. can this be done without boiling the ocean)? >>>> >> >>>> >> Thanks, >>>> >> Tom >>>> >> >>>> >> >>>> >> >>>> >> > The current document and a companion document that will be posted >>>> soon >>>> >> > describe the different deployment options >>>> >> > with special care to the 5G service based architecture. >>>> >> > Thanks for the comments already received that helped completing >>>> this -00 >>>> >> > draft. >>>> >> > >>>> >> > Luca >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > _______________________________________________ >>>> >> > dmm mailing list >>>> >> > dmm@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/dmm >>>> >> > >>>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> >> > --00000000000075fdde056f156f74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am sorry but I'm not sure I get your question right.=
I am not sure SRv6 is just a tunnelling technique but I am not right p= erson to talk about that.

We do mention SRv6 i= n the draft to show how hICN can use it to steer the next-hop path for the = request
carrying the ID in the DST addr field and=C2=A0 for the r= eply to steer the next-hop path carrying the locator
in the DST a= ddr field.=C2=A0

In the first place hICN makes use= of the IPv6 FIB. This is the default. But there are several=C2=A0
interoperable protocols that might be included in the next-hop pipeline p= rocessing.=C2=A0=C2=A0

Does it clarify your doubts= ?

Luca



On Wed, Jun 20, 2018 at 4:54 PM Behc= et Sarikaya <sarikaya2012@gmai= l.com> wrote:


On Wed, Ju= n 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) <= ;gcarofig@cisco.com= > wrote:

This draft is about hICN and discusses various deployment options with a= ssociated pros and cons, without supporting one specifically. Clearly, depe= nding on=C2=A0 application requirements, on network constraints, on phase o= f deployment/transition=C2=A0 etc. one option may be preferrable over another one (and different ones may coexist).


One of the described deployment options also discusses combination of hI= CN and SRv6, without opposing one=C2=A0approach to the other, rather exploi= ting in the combination=C2=A0the advantages of both=C2=A0ones.



I don't understand.
SRv6 is tunneling technique while hICN is talking about anchoress = mobility.
Did I get something wrong?

Beh= cet=C2=A0

Giovanna

From: Int-area <int-area-bounces@ietf.org> on behalf of Behcet= Sarikaya <s= arikaya2012@gmail.com>
Sent: Wednesday, June 20, 2018 4:18 PM
To: Luca Muscariello
Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm
Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility = management through hICN (hICN-AMM): Deployment options
=C2=A0


On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariell= o <luca.mu= scariello@gmail.com> wrote:
I wonder whether this conversation should happen in the in= tarea wg mailing list=C2=A0
as the main draft was posted there in the first place. I don't kno= w if cross posting is welcome
but I take the risk.

Going back to the question, the transport changes are related to the r= equest/reply semantic=C2=A0
of the architecture. The two distinct forwarding paths described in th= e draft take care
of forwarding requests or replies.This ends up in the transport layer = as a unidirectional=C2=A0
channel to recv data or snd data. The replies carry data originating f= rom a=C2=A0 transport end-point (snd buffer)
that binds to an identifier which is location independent, an IPv6 num= ber which is not a locator.

The forwarding path of the requests is very close to unmodified IPv6 w= ith the DST address carrying the identifier.
If you check in the draft an hICN node does one additional lookup in a= local cache though. But you can ignore that
for now for sake of clarity. What is important is the address rewrite = operation made on the SRC address
of the request. A copy of the request is stored in the local cache and= the locator of the output interface is written in the=C2=A0
SRC address before transmission. This is used by an upstream hICN or t= he final end-point to know the locator that
will be used to reply.

Replies coming from the snd end-point are label swapped but not like M= PLS.=C2=A0
The label is the identifier itself that is stored in the SRC address o= f the reply,=C2=A0
whereas the DST address is a locator. In this forwarding path a lookup= is made in the local cache to
find a request (one or many) and the associated locator (one or many) = that matches the identifier.
The DST addr field of the replies is rewritten with the locator(s) jus= t obtained from the lookup.
This is how the reply is forwarded to the end-points that issued reque= sts for this identifier.=C2=A0

For the replies there is no FIB lookup on the identifier (as it is in = the SRC addr field).=C2=A0
There can be a lookup in the FIB on the locator stored in the DST of t= he reply to=C2=A0
reach back the previous hICN node or eventually the original end-point= .

=C2=A0
=C2=A0

Hi,

My humble question is: are you supporting SRv6 or hICN?

Regards
Behcet
=C2=A0




On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <tom@quantonium.net>= wrote:
On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello
<luca.mu= scariello@gmail.com> wrote:
> The paragraph you reported is from the draft that describes hICN to en= able
> several use cases.
> Mobility is one of those, not the only one.
> To clarify, the draft on hICN mobility deployment options focuses on t= he 5G
> service based architecture.
>
> You may be asking
> 1) is it possible to get all the features provided by hICN w/o updates= to
> the transport layer?
> 2) is changing the transport protocol unnecessary difficult to enable = all
> the use cases mentioned in the draft?
>
Sorry, but I'm still missing something fundamental here. AFAICT, the idea of hICN is to put routes in the local routing table and use
existing forwarding and routing to forward packets to mobile nodes. So
if a node changes location, then the routing tables need to be
updated. Effectively this is a bunch of host routes that need to be
maintained. At least this is what I gather from the draft:

"hICN network layer is about using the IPv6 FIB to determine a next hop router to forward requests or using a local packet cache to
determine if an incoming request can be satisfied locally."

Is this correct? If it is, then I sort of understand how hICN could be
used for mobility or virtualization without network overlays, but then
I'm completely lost as to why this would require any changes in the
transport layer.

Tom





> IMO, the answers are no for both.
>
> Luca
>
> On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <tom@quantonium.net> wrote:
>>
>> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
>> <luca.muscariello@gmail.com> wrote:
>> > Hi all,
>> >
>> > the draft below has been posted and describes deployments opt= ions for
>> > anchorless mobility management=C2=A0 by using
>> > the hicn network architecture that implements icn semantics i= n IPv6
>> > networks.
>> >
>> >
>> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-op= tions
>> >
>> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/
>> >
>> > A background document has been posted to the internet area WG= and
>> > reported
>> > here for your convenience.
>> > The core principle behind hicn and mobility management is tha= t data
>> > sources
>> > are named using location independent names
>> > encoded in IPv6 addresses. The transport service sitting on t= op of the
>> > hicn
>> > architecture is not based on usual TCP/UDP sockets
>> > but on a novel consumer/producer transport service that will = be
>> > described in
>> > another draft.
>>
>> From the draft: "The transport end-point offers two kinds of = services
>> to applications: a producer and a consumer service. The service is=
>> instantiated in the application by opening communication sockets w= ith
>> an API to perform basic transport service operations: allocation,<= br> >> initialization, configuration, data transmission and reception.&qu= ot;
>>
>> This seems like a pretty dramatic rethink of the transport layer j= ust
>> for the purposes of mobility management. Will there be a way to us= e
>> hICN at the network layer with exsiting and unmodified transport >> protocols (i.e. can this be done without boiling the ocean)?
>>
>> Thanks,
>> Tom
>>
>>
>>
>> > The current document and a companion document that will be po= sted soon
>> > describe the different deployment options
>> > with special care to the 5G service based architecture.
>> > Thanks for the comments already received that helped completi= ng this -00
>> > draft.
>> >
>> > Luca
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > dmm mailing list
>> > dmm@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/dmm
>> >

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



--00000000000075fdde056f156f74-- From nobody Wed Jun 20 10:18:35 2018 Return-Path: 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 9E14A129C6B for ; Wed, 20 Jun 2018 10:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 1rcObocL4pv9 for ; Wed, 20 Jun 2018 10:18:23 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20728130DF4 for ; Wed, 20 Jun 2018 10:18:23 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id e18-v6so306826wrs.5 for ; Wed, 20 Jun 2018 10:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=drnLhx4Qldl3u9s9OkcSdfh1SuYhfcqwNoLQyJz+mbw=; b=F3MkgIDfcnkUdtKSZBRWy0ROGtZdFPL8oxHTzWkNfudligFZu/7ueRibzehR5q3kP8 dyb7Xtl3qG1YY5cTyUuGHGNDltVQBTbsqCEAJjBmNm2fCneCJF/cxgp2kDzIWbHf6T/A G6/iwD6i0KFn99huGbgBDhxkRS3hLwhdEmkBU3n87eOiuojlOF8hgGFvSqeGoqdXjc46 /0CSDtGdNuNdBm1OgN1i7+P9ahs2jEPNk4vZMwqr4v0+bDmZPXf3JTqcj5g7MrtsbVSl nGTdsO4wwn8soB5/uUtWnOKtsFp8Lncq1RnbAr5ggpM1knV5px5oJqbx1IKNv/hxWqQO 4rsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=drnLhx4Qldl3u9s9OkcSdfh1SuYhfcqwNoLQyJz+mbw=; b=bGq7Q/MkhLWKH6800/LnhhwpKA+/t3mUyxhBxFVCK1bxTwWklJBW7Rv3UJcjkf/w8g 9xwS/+2XQXgfLPO2vo7NyfKW/Y1NwSz7ozfZ3V26ZUQ4RRxxoMDUy2zcij2QVg4ER2lh JbNRg3EhQsJkuAMXOlCeT4lcTcwhsX1dBHWdwhmNC1H3u7QrGd0dYGVoBdFVr1f1WTH4 4lJqCUZt5PKfGE+A6QSNRcGjJ89BbqTItxGHPDIGLwcaCxe9CeBIN/ikWXI36Ck2KtsS XpyXmsZ/8Fdui66EfkCzAfa1VNwZGZ7h6rHYP2Y0XidPFu7FthIpmhoNssQivVeJc4wq o6JQ== X-Gm-Message-State: APt69E0no0crg8YIgEhWcXytkPlalmLDfOgWL06PSSG9pC2R2Nd63Jbk Q/6RvItmac+fBC2ahvMt/s6NjJghZnI+ks4vFszfdw== X-Google-Smtp-Source: ADUXVKJzPkU0bSHJQdBxzUocFzSAk/7nnhE4UTdH6ng0WQYsd8k57K86JW+qEkZ6knhobCMh8ZO17RYQVR8ix3w/hiU= X-Received: by 2002:adf:e542:: with SMTP id z2-v6mr19170333wrm.111.1529515101459; Wed, 20 Jun 2018 10:18:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:f9d2:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 10:18:20 -0700 (PDT) In-Reply-To: References: <1529505221125.58728@cisco.com> From: Tom Herbert Date: Wed, 20 Jun 2018 10:18:20 -0700 Message-ID: To: Luca Muscariello Cc: Giovanna Carofiglio , Behcet Sarikaya , int-area@ietf.org, Luca Muscariello , dmm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 17:18:28 -0000 On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello wrote: > The adjective minor is used in a comparative way. At least I intended that > way. > hICN allows to implement ICN features with less changes than using ICN as an > overlay. > On an absolute scale, I don't think that hICN requires negligible changes. > So I haven't used the adjective minor as a synonym of negligible. > I do think that having those changes are worthy for many apps. > > Back to your questions that I understand this way: > 1) What is the hICN socket API? > 2) Does hICN imply that all hosts have to change transport stack? > 3) Does hICN disrupt the TCP/IP stack in an end host? > > > 1) The answer to the first question is something that I wanted to discuss in > the transport area > but repeating does good. In the current implementation we support two > different APIs. > The first one is a BSD socket API, the second one is a post-socket API that > is currently > under development in the TAPS WG with a first integration in iOS 12 beta. > I'm not > contributing to TAPS but I think it is worthy to keep our implementation > updated with TAPS. > I haven't finished to write a draft but I have a technical report that I > could share right before next IETF. > > 2) An application developer may or may not want to change to use this API. > But I would turn the question around to ask, is it worthy to change the > application to exploit > this new transport service and the underlying network service to get a > certain number of benefits? Luca, I would say the answer is no, unless you can prove beyond doubt that violating the protocol layering archictecure of the Internet and the E2E model is necessary to get those benefits. I don't believe that proof has yet been provided (for this proposal or any other similar ones and there have been several). The Internet is architectured such that any transport protocol can run over a common network layer. Mobility is a network layer concern and so should be part of the network layer. Therefore, a network mobility solution should work transparently with any transport layer (TCP, UCP, QUIC, SCTP, and new ones we may come up with). The network/transport separation is not maintained when we we see intermediate devices trying to participate the transport layer which entails DPI and inevitably leads to protocol ossification in the Internet. So we want middelboxes be less invasive in the transport layer, not more invasive! You may want to look at early PLUS/SPUD efforts that were attempting to turn UDP into a sort of of network layer protocol to carry path information read by the network (they choose UDP because of compatibility with existing HW instead of defining a new transport protocol). This even included encoding flow semantics for network to track (like the request/response tracking in hICN). These efforts got pushback in part because it violates protocol layer and encouraged DPI. In hindsight the answer now seems pretty simple: network layer information belongs in network layer headers. If you want to signal the network then just put information extension headers like HBH options. EH also permits data modification by intermediate devices which is useful for things like OAM. > IMO, yes. > > Is it worthy to implement a new transport service in user-space such as > LEDBAT, QUIC or the variety of transport > services running for RTC apps? The answer is up to the application. It is > the app that decides. It's not just up to the application. It's up the network operators, hardware vendors, as well as the OS vendors. The OS is a big problem. There is simply no concept of instantaneously changing all OS deployments to a support a new feature like this. It takes years to get significant traction. Look at a protocol like MPTCP: it's good protocol and shows a lot of value to many users, but deployment has been stymied by lack of OS support. We are trying to fix the situation, but it's not easy. > So, no, there is no need to change all hosts. IMO the answer is it depends. > > 3) when you enable hICN in an end host the local network configuration > manages two distinct namespaces, > one for locators and one for identifiers (intended as location independent > names). An end-host can manage several > locators because might be multi-homed and can manage several identifiers > because it has been assigned identifiers > to name data sources at the host: mic, camera, an app etc. > This host continues to be able to open TCP or UDP sockets (but also SCTP or > others) with the usual socket bindings. > > Just to give an example: We are using our hICN transport library for > WebRTC, MPEG-DASH among other things. > An MPEG-DASH segment can be retrieved by a video client using TCP, QUIC or > the consumer/producer socket. > The video player can sequentially switch protocol to retrieve the segment. > Not that it make any sense but it's just > to explain that they live in the same end-host. If the app considers that > one transport service can provide > features that are advantageous it can optionally switch to it. > There is no intent to replace TCP, UDP, LEDBAT, QUIC, SCTP or any other > transport protocol with the consumer/producer > sockets. Okay, but these protocols still need to work in mobile networks, which means in hICN enabled network you still need a mobile infrastructure to handle these "legacy" protocols. That means there are two distinct mobility models needed-- hICN is not simplifying matters in this regard. To me, the hICN story would be a lot more compelling if the transport and network layer are decoupled so there was one solution that provided seamless mobility for everyone in the network regardless of type of transport protocol they use or application that they wish to run. Beyond that, there might be opportunities to improve communications by some coordinated interaction with the network (like we propose in FAST), but these are strictly optimization and not requirements to make basic communications work. Tom > > Luca > > > > On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert wrote: >> >> On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello >> wrote: >> > More on the mobility use case which also makes deployment options easier >> > to >> > digest >> > >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ >> > >> >> From the draft: >> >> "The goal of hICN is to ease ICN insertion in existing IP infrastructure >> by: >> ... >> 3. minor modification to existing IP routers/endpoints;" >> >> Can you elaborate on this "minor modification"? Especially for >> endpoints, which I assume means hosts, what is the scope, the >> necessary modifications, and deployment model. Also, will applications >> have to change or use a new API for hICN? >> >> If the implication of hICN is that all Internet hosts need to change >> to support a new consumer/producer communications model, a new >> transport protocol, and a new application API-- there's nothing minor >> about that! >> >> Tom >> >> > >> > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) >> > wrote: >> >> >> >> This draft is about hICN and discusses various deployment options with >> >> associated pros and cons, without supporting one specifically. Clearly, >> >> depending on application requirements, on network constraints, on >> >> phase of >> >> deployment/transition etc. one option may be preferrable over another >> >> one >> >> (and different ones may coexist). >> >> >> >> >> >> One of the described deployment options also discusses combination of >> >> hICN >> >> and SRv6, without opposing one approach to the other, rather exploiting >> >> in >> >> the combination the advantages of both ones. >> >> >> >> >> >> Giovanna >> >> >> >> ________________________________ >> >> From: Int-area on behalf of Behcet Sarikaya >> >> >> >> Sent: Wednesday, June 20, 2018 4:18 PM >> >> To: Luca Muscariello >> >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility >> >> management through hICN (hICN-AMM): Deployment options >> >> >> >> >> >> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello >> >> wrote: >> >>> >> >>> I wonder whether this conversation should happen in the intarea wg >> >>> mailing list >> >>> as the main draft was posted there in the first place. I don't know if >> >>> cross posting is welcome >> >>> but I take the risk. >> >>> >> >>> Going back to the question, the transport changes are related to the >> >>> request/reply semantic >> >>> of the architecture. The two distinct forwarding paths described in >> >>> the >> >>> draft take care >> >>> of forwarding requests or replies.This ends up in the transport layer >> >>> as >> >>> a unidirectional >> >>> channel to recv data or snd data. The replies carry data originating >> >>> from >> >>> a transport end-point (snd buffer) >> >>> that binds to an identifier which is location independent, an IPv6 >> >>> number >> >>> which is not a locator. >> >>> >> >>> The forwarding path of the requests is very close to unmodified IPv6 >> >>> with >> >>> the DST address carrying the identifier. >> >>> If you check in the draft an hICN node does one additional lookup in a >> >>> local cache though. But you can ignore that >> >>> for now for sake of clarity. What is important is the address rewrite >> >>> operation made on the SRC address >> >>> of the request. A copy of the request is stored in the local cache and >> >>> the locator of the output interface is written in the >> >>> SRC address before transmission. This is used by an upstream hICN or >> >>> the >> >>> final end-point to know the locator that >> >>> will be used to reply. >> >>> >> >>> Replies coming from the snd end-point are label swapped but not like >> >>> MPLS. >> >>> The label is the identifier itself that is stored in the SRC address >> >>> of >> >>> the reply, >> >>> whereas the DST address is a locator. In this forwarding path a lookup >> >>> is >> >>> made in the local cache to >> >>> find a request (one or many) and the associated locator (one or many) >> >>> that matches the identifier. >> >>> The DST addr field of the replies is rewritten with the locator(s) >> >>> just >> >>> obtained from the lookup. >> >>> This is how the reply is forwarded to the end-points that issued >> >>> requests >> >>> for this identifier. >> >>> >> >>> For the replies there is no FIB lookup on the identifier (as it is in >> >>> the >> >>> SRC addr field). >> >>> There can be a lookup in the FIB on the locator stored in the DST of >> >>> the >> >>> reply to >> >>> reach back the previous hICN node or eventually the original >> >>> end-point. >> >>> >> >>> >> >>> >> >> >> >> >> >> Hi, >> >> >> >> My humble question is: are you supporting SRv6 or hICN? >> >> >> >> Regards >> >> Behcet >> >> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert >> >>> wrote: >> >>>> >> >>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >> >>>> wrote: >> >>>> > The paragraph you reported is from the draft that describes hICN to >> >>>> > enable >> >>>> > several use cases. >> >>>> > Mobility is one of those, not the only one. >> >>>> > To clarify, the draft on hICN mobility deployment options focuses >> >>>> > on >> >>>> > the 5G >> >>>> > service based architecture. >> >>>> > >> >>>> > You may be asking >> >>>> > 1) is it possible to get all the features provided by hICN w/o >> >>>> > updates >> >>>> > to >> >>>> > the transport layer? >> >>>> > 2) is changing the transport protocol unnecessary difficult to >> >>>> > enable >> >>>> > all >> >>>> > the use cases mentioned in the draft? >> >>>> > >> >>>> Sorry, but I'm still missing something fundamental here. AFAICT, the >> >>>> idea of hICN is to put routes in the local routing table and use >> >>>> existing forwarding and routing to forward packets to mobile nodes. >> >>>> So >> >>>> if a node changes location, then the routing tables need to be >> >>>> updated. Effectively this is a bunch of host routes that need to be >> >>>> maintained. At least this is what I gather from the draft: >> >>>> >> >>>> "hICN network layer is about using the IPv6 FIB to determine a next >> >>>> hop router to forward requests or using a local packet cache to >> >>>> determine if an incoming request can be satisfied locally." >> >>>> >> >>>> Is this correct? If it is, then I sort of understand how hICN could >> >>>> be >> >>>> used for mobility or virtualization without network overlays, but >> >>>> then >> >>>> I'm completely lost as to why this would require any changes in the >> >>>> transport layer. >> >>>> >> >>>> Tom >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> > IMO, the answers are no for both. >> >>>> > >> >>>> > Luca >> >>>> > >> >>>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert >> >>>> > wrote: >> >>>> >> >> >>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >> >>>> >> wrote: >> >>>> >> > Hi all, >> >>>> >> > >> >>>> >> > the draft below has been posted and describes deployments >> >>>> >> > options >> >>>> >> > for >> >>>> >> > anchorless mobility management by using >> >>>> >> > the hicn network architecture that implements icn semantics in >> >>>> >> > IPv6 >> >>>> >> > networks. >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options >> >>>> >> > >> >>>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >> >>>> >> > >> >>>> >> > A background document has been posted to the internet area WG >> >>>> >> > and >> >>>> >> > reported >> >>>> >> > here for your convenience. >> >>>> >> > The core principle behind hicn and mobility management is that >> >>>> >> > data >> >>>> >> > sources >> >>>> >> > are named using location independent names >> >>>> >> > encoded in IPv6 addresses. The transport service sitting on top >> >>>> >> > of >> >>>> >> > the >> >>>> >> > hicn >> >>>> >> > architecture is not based on usual TCP/UDP sockets >> >>>> >> > but on a novel consumer/producer transport service that will be >> >>>> >> > described in >> >>>> >> > another draft. >> >>>> >> >> >>>> >> From the draft: "The transport end-point offers two kinds of >> >>>> >> services >> >>>> >> to applications: a producer and a consumer service. The service is >> >>>> >> instantiated in the application by opening communication sockets >> >>>> >> with >> >>>> >> an API to perform basic transport service operations: allocation, >> >>>> >> initialization, configuration, data transmission and reception." >> >>>> >> >> >>>> >> This seems like a pretty dramatic rethink of the transport layer >> >>>> >> just >> >>>> >> for the purposes of mobility management. Will there be a way to >> >>>> >> use >> >>>> >> hICN at the network layer with exsiting and unmodified transport >> >>>> >> protocols (i.e. can this be done without boiling the ocean)? >> >>>> >> >> >>>> >> Thanks, >> >>>> >> Tom >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> > The current document and a companion document that will be >> >>>> >> > posted >> >>>> >> > soon >> >>>> >> > describe the different deployment options >> >>>> >> > with special care to the 5G service based architecture. >> >>>> >> > Thanks for the comments already received that helped completing >> >>>> >> > this -00 >> >>>> >> > draft. >> >>>> >> > >> >>>> >> > Luca >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > _______________________________________________ >> >>>> >> > dmm mailing list >> >>>> >> > dmm@ietf.org >> >>>> >> > https://www.ietf.org/mailman/listinfo/dmm >> >>>> >> > >> >>> >> >>> >> >>> _______________________________________________ >> >>> dmm mailing list >> >>> dmm@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/dmm >> >>> >> >> >> > From nobody Thu Jun 21 03:29:54 2018 Return-Path: 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 D54C2131200; Thu, 21 Jun 2018 03:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=gmail.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 Gjlw9XTV0AXR; Thu, 21 Jun 2018 03:29:45 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160BD131065; Thu, 21 Jun 2018 03:29:45 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id k18-v6so953790ywm.11; Thu, 21 Jun 2018 03:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yZJK3cNvLF1FTVJuXAiys40yIFdw8cvcoZdJMbYOXQU=; b=YPwrXO6NXuonPmjoMFxqLEjtRzYHf3jGPIByKQ031B2ROjdVaT81/ff3w0036Yh1Z3 NrgelXHfPn1xMM5KFFY5oGHHgeAGfVhIRYfm/0h4ycDr0OoHQVU/0NmI3VTbkyiW7IRe bmka9826jiZaXp3oIemOCvVDd2c1v3SpRnJgUW6i/jaVNC6/OYok+RLPCmUaA2Y4iY9E 0ALlz3TZ/wSgGx/T3TpWR5QzpwtmydJ4Iy2nUkY+Il5HawnkgsTylWQLAJOLbRDvKlo2 euOZArf/gADzWCuTxgAr7jKkw3j6zAtqwvvudbBf/t0Y/LM992cPbAODkI+bGXcgRQY4 gMqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yZJK3cNvLF1FTVJuXAiys40yIFdw8cvcoZdJMbYOXQU=; b=lHHQcCP10F0+0vL9Wh8ODHIBJMa76QCQSPwZwzpD0Qnu/613tvsl5J1tIanamMoVQu 9CSUwt9MxOallpEdRnhfQxgOzlkWCdcqZps2pqLMgK6BY82FKAxDJbEqUe7QIY1iVFPU xhX967TTmUPHKkAYODRtp8dNkWMxazxCMFUFQhLYqcUTS3co6OLwarkZa3zaYkzj0YL5 U5kWB/KPU3IAxuXeV9fg58d3Q7MY5pEAwZO+mwGcRZj7Ln40tVs6DGg737no+5yk1yI5 nVTjS7/CUOEQRJjNwyvOEsT3iUU+yoyaWzUhtu4sVIgKlfDnuc7xd/Pdm412VRfdM2SQ g92Q== X-Gm-Message-State: APt69E0jI1W8wZFhH8SDeTWpfk602wQfdnXrvq+xcYEuFFGCZaYPy4ul PUkvFu7cwTFBAqIZ2XewHTStCL9vwRjBjoJb/3E= X-Google-Smtp-Source: ADUXVKJoBurv68vDwFBrgmDvK8cOcENZw/YTCFu0mZiFRe8JaaDwOWzu8YR6PU8C3umwIORbmRzEXVsmMZ/BROmgJYY= X-Received: by 2002:a81:5988:: with SMTP id n130-v6mr11899410ywb.30.1529576983865; Thu, 21 Jun 2018 03:29:43 -0700 (PDT) MIME-Version: 1.0 References: <1529505221125.58728@cisco.com> In-Reply-To: From: Luca Muscariello Date: Thu, 21 Jun 2018 12:29:32 +0200 Message-ID: To: tom@quantonium.net Cc: Giovanna Carofiglio , sarikaya@ieee.org, int-area@ietf.org, Luca Muscariello , dmm@ietf.org Content-Type: multipart/alternative; boundary="000000000000c7ad1c056f246482" Archived-At: Subject: Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 10:29:50 -0000 --000000000000c7ad1c056f246482 Content-Type: text/plain; charset="UTF-8" There are several points raised here: 1) Alleged protocol layering violations and the e2e principle. 2) Relationship between the OS and transport services. 1) Many see the e2e principle as another instance of Occam's razor applied to communication protocols function placement, I think it is even written in the first paper that talks about it (Reed, Clark...). It's all about design patters for the development of distributed applications. Placement of function vertically in a layered architecture and horizontally in the network path between end-points. In this respect, hICN, but I should say CCN and NDN realise that principle with a new way to look at networking. Essentially naming data sources with location-independent identifiers. I am far from going to claim credits to the design principles behind CCN/NDN as it is Van Jacobson and team who fundamentally designed that system. hICN is a convenient implementation of CCN into IPv6 to make that design available in IPv6 now. Other attempts have introduced networking of location-independent identifiers in the Internet and the most notable one is LISP even if it is still the host to be identified. I would avoid to quote in full Brian Carpenter about this topic so I just report a reference. It's all in there. Brian E. Carpenter. 2014. IP addresses considered harmful. *SIGCOMM Comput. Commun. Rev.* 44, 2 (April 2014), 65-69. DOI: http://dx.doi.org/10.1145/2602204.2602215 If we look at LISP for instance, the placement of protocol functions requires to have a mapping system. It is not exactly an instance of the Occam's razor though. But it is probably the best solution to a very specific problem formulation. The fact that the network has to support all transport protocols is clearly false. The Internet is also IP multicast, among other things, and the transport protocols being cited (TCP/LEDBAT/QUIC etc) not only will never work over IP multicast but have never been meant to at design time. hICN mobility for the 5G service based architecture is supposed to run in a slice for the development of advanced applications (IoT, AR/VR, MEC etc) but also to rethink current applications with these new transport services. This means that alternative solutions for mobility management in 5G, such as GTP, LISP or derivations of it, are required to exist. In the current 5G standardisation effort there might be several mobility models co-existing and slicing has been designed in order to enable that. 2) This should probably be a whole new email thread and also other mailing lists might be a better forum. It is true that applications make use of a communication API provided by the OS. But that's quite generic. Those functions can be place in different parts of the OS. Our choice is to move communication functions, essentially the entire stack, out of the kernel and use a server stack based on VPP https://git.fd.io and install network functions just like any application in an application store. The client stack would also de deployed as a portable app. iOS 12 is the first mobile OS to adopt this kind of philosophy and we continue to adopt that approach for the time being. The fact that MPTCP encounters difficulties to be fully integrated in a specific OS component is an implementation issue that belongs to that particular component. The consequence of that might be that multiple culturally different implementations and deployment options of network functions should exist in the future. Not less. On Wed, Jun 20, 2018 at 7:18 PM Tom Herbert wrote: > On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello > wrote: > > The adjective minor is used in a comparative way. At least I intended > that > > way. > > hICN allows to implement ICN features with less changes than using ICN > as an > > overlay. > > On an absolute scale, I don't think that hICN requires negligible > changes. > > So I haven't used the adjective minor as a synonym of negligible. > > I do think that having those changes are worthy for many apps. > > > > Back to your questions that I understand this way: > > 1) What is the hICN socket API? > > 2) Does hICN imply that all hosts have to change transport stack? > > 3) Does hICN disrupt the TCP/IP stack in an end host? > > > > > > 1) The answer to the first question is something that I wanted to > discuss in > > the transport area > > but repeating does good. In the current implementation we support two > > different APIs. > > The first one is a BSD socket API, the second one is a post-socket API > that > > is currently > > under development in the TAPS WG with a first integration in iOS 12 beta. > > I'm not > > contributing to TAPS but I think it is worthy to keep our implementation > > updated with TAPS. > > I haven't finished to write a draft but I have a technical report that I > > could share right before next IETF. > > > > 2) An application developer may or may not want to change to use this > API. > > But I would turn the question around to ask, is it worthy to change the > > application to exploit > > this new transport service and the underlying network service to get a > > certain number of benefits? > > Luca, > > I would say the answer is no, unless you can prove beyond doubt that > violating the protocol layering archictecure of the Internet and the > E2E model is necessary to get those benefits. I don't believe that > proof has yet been provided (for this proposal or any other similar > ones and there have been several). The Internet is architectured such > that any transport protocol can run over a common network layer. > Mobility is a network layer concern and so should be part of the > network layer. Therefore, a network mobility solution should work > transparently with any transport layer (TCP, UCP, QUIC, SCTP, and new > ones we may come up with). The network/transport separation is not > maintained when we we see intermediate devices trying to participate > the transport layer which entails DPI and inevitably leads to protocol > ossification in the Internet. > > So we want middelboxes be less invasive in the transport layer, not > more invasive! You may want to look at early PLUS/SPUD efforts that > were attempting to turn UDP into a sort of of network layer protocol > to carry path information read by the network (they choose UDP because > of compatibility with existing HW instead of defining a new transport > protocol). This even included encoding flow semantics for network to > track (like the request/response tracking in hICN). These efforts got > pushback in part because it violates protocol layer and encouraged > DPI. In hindsight the answer now seems pretty simple: network layer > information belongs in network layer headers. If you want to signal > the network then just put information extension headers like HBH > options. EH also permits data modification by intermediate devices > which is useful for things like OAM. > > > IMO, yes. > > > > Is it worthy to implement a new transport service in user-space such as > > LEDBAT, QUIC or the variety of transport > > services running for RTC apps? The answer is up to the application. It is > > the app that decides. > > It's not just up to the application. It's up the network operators, > hardware vendors, as well as the OS vendors. The OS is a big problem. > There is simply no concept of instantaneously changing all OS > deployments to a support a new feature like this. It takes years to > get significant traction. Look at a protocol like MPTCP: it's good > protocol and shows a lot of value to many users, but deployment has > been stymied by lack of OS support. We are trying to fix the > situation, but it's not easy. > > > So, no, there is no need to change all hosts. IMO the answer is it > depends. > > > > 3) when you enable hICN in an end host the local network configuration > > manages two distinct namespaces, > > one for locators and one for identifiers (intended as location > independent > > names). An end-host can manage several > > locators because might be multi-homed and can manage several identifiers > > because it has been assigned identifiers > > to name data sources at the host: mic, camera, an app etc. > > This host continues to be able to open TCP or UDP sockets (but also SCTP > or > > others) with the usual socket bindings. > > > > Just to give an example: We are using our hICN transport library for > > WebRTC, MPEG-DASH among other things. > > An MPEG-DASH segment can be retrieved by a video client using TCP, QUIC > or > > the consumer/producer socket. > > The video player can sequentially switch protocol to retrieve the > segment. > > Not that it make any sense but it's just > > to explain that they live in the same end-host. If the app considers > that > > one transport service can provide > > features that are advantageous it can optionally switch to it. > > There is no intent to replace TCP, UDP, LEDBAT, QUIC, SCTP or any other > > transport protocol with the consumer/producer > > sockets. > > Okay, but these protocols still need to work in mobile networks, which > means in hICN enabled network you still need a mobile infrastructure > to handle these "legacy" protocols. That means there are two distinct > mobility models needed-- hICN is not simplifying matters in this > regard. > > To me, the hICN story would be a lot more compelling if the transport > and network layer are decoupled so there was one solution that > provided seamless mobility for everyone in the network regardless of > type of transport protocol they use or application that they wish to > run. Beyond that, there might be opportunities to improve > communications by some coordinated interaction with the network (like > we propose in FAST), but these are strictly optimization and not > requirements to make basic communications work. > > Tom > > > > > Luca > > > > > > > > On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert wrote: > >> > >> On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello > >> wrote: > >> > More on the mobility use case which also makes deployment options > easier > >> > to > >> > digest > >> > > >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ > >> > > >> > >> From the draft: > >> > >> "The goal of hICN is to ease ICN insertion in existing IP infrastructure > >> by: > >> ... > >> 3. minor modification to existing IP routers/endpoints;" > >> > >> Can you elaborate on this "minor modification"? Especially for > >> endpoints, which I assume means hosts, what is the scope, the > >> necessary modifications, and deployment model. Also, will applications > >> have to change or use a new API for hICN? > >> > >> If the implication of hICN is that all Internet hosts need to change > >> to support a new consumer/producer communications model, a new > >> transport protocol, and a new application API-- there's nothing minor > >> about that! > >> > >> Tom > >> > >> > > >> > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) > >> > wrote: > >> >> > >> >> This draft is about hICN and discusses various deployment options > with > >> >> associated pros and cons, without supporting one specifically. > Clearly, > >> >> depending on application requirements, on network constraints, on > >> >> phase of > >> >> deployment/transition etc. one option may be preferrable over > another > >> >> one > >> >> (and different ones may coexist). > >> >> > >> >> > >> >> One of the described deployment options also discusses combination of > >> >> hICN > >> >> and SRv6, without opposing one approach to the other, rather > exploiting > >> >> in > >> >> the combination the advantages of both ones. > >> >> > >> >> > >> >> Giovanna > >> >> > >> >> ________________________________ > >> >> From: Int-area on behalf of Behcet > Sarikaya > >> >> > >> >> Sent: Wednesday, June 20, 2018 4:18 PM > >> >> To: Luca Muscariello > >> >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm > >> >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility > >> >> management through hICN (hICN-AMM): Deployment options > >> >> > >> >> > >> >> > >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello > >> >> wrote: > >> >>> > >> >>> I wonder whether this conversation should happen in the intarea wg > >> >>> mailing list > >> >>> as the main draft was posted there in the first place. I don't know > if > >> >>> cross posting is welcome > >> >>> but I take the risk. > >> >>> > >> >>> Going back to the question, the transport changes are related to the > >> >>> request/reply semantic > >> >>> of the architecture. The two distinct forwarding paths described in > >> >>> the > >> >>> draft take care > >> >>> of forwarding requests or replies.This ends up in the transport > layer > >> >>> as > >> >>> a unidirectional > >> >>> channel to recv data or snd data. The replies carry data originating > >> >>> from > >> >>> a transport end-point (snd buffer) > >> >>> that binds to an identifier which is location independent, an IPv6 > >> >>> number > >> >>> which is not a locator. > >> >>> > >> >>> The forwarding path of the requests is very close to unmodified IPv6 > >> >>> with > >> >>> the DST address carrying the identifier. > >> >>> If you check in the draft an hICN node does one additional lookup > in a > >> >>> local cache though. But you can ignore that > >> >>> for now for sake of clarity. What is important is the address > rewrite > >> >>> operation made on the SRC address > >> >>> of the request. A copy of the request is stored in the local cache > and > >> >>> the locator of the output interface is written in the > >> >>> SRC address before transmission. This is used by an upstream hICN or > >> >>> the > >> >>> final end-point to know the locator that > >> >>> will be used to reply. > >> >>> > >> >>> Replies coming from the snd end-point are label swapped but not like > >> >>> MPLS. > >> >>> The label is the identifier itself that is stored in the SRC address > >> >>> of > >> >>> the reply, > >> >>> whereas the DST address is a locator. In this forwarding path a > lookup > >> >>> is > >> >>> made in the local cache to > >> >>> find a request (one or many) and the associated locator (one or > many) > >> >>> that matches the identifier. > >> >>> The DST addr field of the replies is rewritten with the locator(s) > >> >>> just > >> >>> obtained from the lookup. > >> >>> This is how the reply is forwarded to the end-points that issued > >> >>> requests > >> >>> for this identifier. > >> >>> > >> >>> For the replies there is no FIB lookup on the identifier (as it is > in > >> >>> the > >> >>> SRC addr field). > >> >>> There can be a lookup in the FIB on the locator stored in the DST of > >> >>> the > >> >>> reply to > >> >>> reach back the previous hICN node or eventually the original > >> >>> end-point. > >> >>> > >> >>> > >> >>> > >> >> > >> >> > >> >> Hi, > >> >> > >> >> My humble question is: are you supporting SRv6 or hICN? > >> >> > >> >> Regards > >> >> Behcet > >> >> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert > >> >>> wrote: > >> >>>> > >> >>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello > >> >>>> wrote: > >> >>>> > The paragraph you reported is from the draft that describes hICN > to > >> >>>> > enable > >> >>>> > several use cases. > >> >>>> > Mobility is one of those, not the only one. > >> >>>> > To clarify, the draft on hICN mobility deployment options focuses > >> >>>> > on > >> >>>> > the 5G > >> >>>> > service based architecture. > >> >>>> > > >> >>>> > You may be asking > >> >>>> > 1) is it possible to get all the features provided by hICN w/o > >> >>>> > updates > >> >>>> > to > >> >>>> > the transport layer? > >> >>>> > 2) is changing the transport protocol unnecessary difficult to > >> >>>> > enable > >> >>>> > all > >> >>>> > the use cases mentioned in the draft? > >> >>>> > > >> >>>> Sorry, but I'm still missing something fundamental here. AFAICT, > the > >> >>>> idea of hICN is to put routes in the local routing table and use > >> >>>> existing forwarding and routing to forward packets to mobile nodes. > >> >>>> So > >> >>>> if a node changes location, then the routing tables need to be > >> >>>> updated. Effectively this is a bunch of host routes that need to be > >> >>>> maintained. At least this is what I gather from the draft: > >> >>>> > >> >>>> "hICN network layer is about using the IPv6 FIB to determine a next > >> >>>> hop router to forward requests or using a local packet cache to > >> >>>> determine if an incoming request can be satisfied locally." > >> >>>> > >> >>>> Is this correct? If it is, then I sort of understand how hICN could > >> >>>> be > >> >>>> used for mobility or virtualization without network overlays, but > >> >>>> then > >> >>>> I'm completely lost as to why this would require any changes in the > >> >>>> transport layer. > >> >>>> > >> >>>> Tom > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > IMO, the answers are no for both. > >> >>>> > > >> >>>> > Luca > >> >>>> > > >> >>>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert > >> >>>> > wrote: > >> >>>> >> > >> >>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello > >> >>>> >> wrote: > >> >>>> >> > Hi all, > >> >>>> >> > > >> >>>> >> > the draft below has been posted and describes deployments > >> >>>> >> > options > >> >>>> >> > for > >> >>>> >> > anchorless mobility management by using > >> >>>> >> > the hicn network architecture that implements icn semantics in > >> >>>> >> > IPv6 > >> >>>> >> > networks. > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options > >> >>>> >> > > >> >>>> >> > > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ > >> >>>> >> > > >> >>>> >> > A background document has been posted to the internet area WG > >> >>>> >> > and > >> >>>> >> > reported > >> >>>> >> > here for your convenience. > >> >>>> >> > The core principle behind hicn and mobility management is that > >> >>>> >> > data > >> >>>> >> > sources > >> >>>> >> > are named using location independent names > >> >>>> >> > encoded in IPv6 addresses. The transport service sitting on > top > >> >>>> >> > of > >> >>>> >> > the > >> >>>> >> > hicn > >> >>>> >> > architecture is not based on usual TCP/UDP sockets > >> >>>> >> > but on a novel consumer/producer transport service that will > be > >> >>>> >> > described in > >> >>>> >> > another draft. > >> >>>> >> > >> >>>> >> From the draft: "The transport end-point offers two kinds of > >> >>>> >> services > >> >>>> >> to applications: a producer and a consumer service. The service > is > >> >>>> >> instantiated in the application by opening communication sockets > >> >>>> >> with > >> >>>> >> an API to perform basic transport service operations: > allocation, > >> >>>> >> initialization, configuration, data transmission and reception." > >> >>>> >> > >> >>>> >> This seems like a pretty dramatic rethink of the transport layer > >> >>>> >> just > >> >>>> >> for the purposes of mobility management. Will there be a way to > >> >>>> >> use > >> >>>> >> hICN at the network layer with exsiting and unmodified transport > >> >>>> >> protocols (i.e. can this be done without boiling the ocean)? > >> >>>> >> > >> >>>> >> Thanks, > >> >>>> >> Tom > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > The current document and a companion document that will be > >> >>>> >> > posted > >> >>>> >> > soon > >> >>>> >> > describe the different deployment options > >> >>>> >> > with special care to the 5G service based architecture. > >> >>>> >> > Thanks for the comments already received that helped > completing > >> >>>> >> > this -00 > >> >>>> >> > draft. > >> >>>> >> > > >> >>>> >> > Luca > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > _______________________________________________ > >> >>>> >> > dmm mailing list > >> >>>> >> > dmm@ietf.org > >> >>>> >> > https://www.ietf.org/mailman/listinfo/dmm > >> >>>> >> > > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> dmm mailing list > >> >>> dmm@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/dmm > >> >>> > >> >> > >> > > --000000000000c7ad1c056f246482 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are several points raised here:
1) Alleged proto= col layering violations and the e2e principle.
2) Relationship be= tween the OS and transport services.


1) Many see the e2e principle as another instance of Occam's razor ap= plied to communication=C2=A0
protocols function placement, I thin= k it is even written in the first paper that talks about it (Reed, Clark...= ).=C2=A0
It's all about design patters for the development of= distributed applications.=C2=A0
Placement of function vertically= in a layered architecture and horizontally in the network path between end= -points.

In this respect, hICN, but I should say C= CN and NDN realise that principle with a new way to look at networking.=C2= =A0
Essentially naming data sources with location-independent ide= ntifiers.
I am far from going to claim credits to the design prin= ciples behind CCN/NDN as it is Van Jacobson and team=C2=A0
who fu= ndamentally designed that system. hICN is a convenient implementation of CC= N into IPv6 to make that=C2=A0
design available in IPv6 now.

Other attempts have introduced networking of location-= independent identifiers in the Internet and the most notable=C2=A0
one is LISP even if it is still the host to be identified.
I wo= uld avoid to quote in full Brian Carpenter about this topic so I just repor= t a reference. It's all in there.

Brian E.= Carpenter. 2014. IP addresses considered harmful.=C2=A0SI= GCOMM Comput. Commun. Rev.=C2=A044, 2 (April 2014), 65= -69. DOI: http://dx.d= oi.org/10.1145/2602204.2602215

If w= e look at LISP for instance, the placement of protocol functions requires t= o have a mapping system.=C2=A0
It is not exactly an instance of t= he Occam's razor though. But it is probably the best solution to a very= =C2=A0
specific problem formulation.

The= fact that the network has to support all transport protocols is clearly fa= lse. The Internet is also IP multicast,=C2=A0
among other things,=
and the transport protocols being cited (TCP/LEDBAT/QUIC etc) no= t only will never work over IP multicast but=C2=A0
have never bee= n meant to at design time.

hICN mobility for the 5= G service based architecture is supposed to run in a slice for the developm= ent of advanced=C2=A0
applications (IoT, AR/VR, MEC etc) but also= to rethink current applications with these new transport services.=C2=A0
This means that alternative solutions for mobility management in 5= G, such as GTP, LISP or derivations of it, are=C2=A0
required to = exist.
In the current 5G standardisation effort there might be se= veral mobility models co-existing and slicing has been
designed i= n order to enable that.

2) This should probably be= a whole new email thread and also other mailing lists might be a better fo= rum.

It is true that applications make use of a co= mmunication API provided by the OS. But=C2=A0 that's quite generic.
Those functions can be place in different parts of the OS.=C2=A0
Our choice is to move communication functions, essentially the entir= e stack, out of the kernel
and use a server stack based on VPP=C2= =A0https://git.fd.io and install network = functions just like any application in an application store.
The = client stack would also de deployed as a portable app.=C2=A0 iOS 12 is the = first mobile OS to adopt this kind of philosophy and we continue to adopt t= hat approach for the time being.=C2=A0

The fact th= at MPTCP encounters difficulties to be fully integrated in a specific OS co= mponent is an implementation issue
that belongs to that particula= r component. The consequence of=C2=A0 that might be that multiple=C2=A0 cul= turally different implementations
and deployment options of netwo= rk functions=C2=A0 should exist in the future. Not less.



On W= ed, Jun 20, 2018 at 7:18 PM Tom Herbert <tom@quantonium.net> wrote:
On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello
<luca.mu= scariello@gmail.com> wrote:
> The adjective minor is used in a comparative way. At least I intended = that
> way.
> hICN allows to implement ICN features with less changes than using ICN= as an
> overlay.
> On an absolute scale, I don't think that hICN requires negligible = changes.
> So I haven't used the adjective minor as a synonym of negligible.<= br> > I do think that having those changes are worthy for many apps.
>
> Back to your questions that I understand this way:
> 1) What is the hICN socket API?
> 2) Does hICN imply that all hosts have to change transport stack?
> 3) Does hICN disrupt the TCP/IP stack in an end host?
>
>
> 1) The answer to the first question is something that I wanted to disc= uss in
> the transport area
> but repeating does good. In the current implementation we support two<= br> > different APIs.
> The first one is a BSD socket API, the second one is a post-socket API= that
> is currently
> under development in the TAPS WG with a first integration in iOS 12 be= ta.
> I'm not
> contributing to TAPS but I think it is worthy to keep our implementati= on
> updated with TAPS.
> I haven't finished to write a draft but I have a technical report = that I
> could share right before next IETF.
>
> 2) An application developer may or may not want to change to use this = API.
> But I would turn the question around to ask, is it worthy to change th= e
> application to exploit
> this new transport service and the underlying network service to get a=
> certain number of benefits?

Luca,

I would say the answer is no, unless you can prove beyond doubt that
violating the protocol layering archictecure of the Internet and the
E2E model is necessary to get those benefits. I don't believe that
proof has yet been provided (for this proposal or any other similar
ones and there have been several). The Internet is architectured such
that any transport protocol can run over a common network layer.
Mobility is a network layer concern and so should be part of the
network layer. Therefore, a network mobility solution should work
transparently with any transport layer (TCP, UCP, QUIC, SCTP, and new
ones we may come up with). The network/transport separation is not
maintained when we we see intermediate devices trying to participate
the transport layer which entails DPI and inevitably leads to protocol
ossification in the Internet.

So we want middelboxes be less invasive in the transport layer, not
more invasive! You may want to look at early PLUS/SPUD efforts that
were attempting to turn UDP into a sort of of network layer protocol
to carry path information read by the network (they choose UDP because
of compatibility with existing HW instead of defining a new transport
protocol). This even included encoding flow semantics for network to
track (like the request/response tracking in hICN). These efforts got
pushback in part because it violates protocol layer and encouraged
DPI. In hindsight the answer now seems pretty simple: network layer
information belongs in network layer headers. If you want to signal
the network then just put information extension headers like HBH
options. EH also permits data modification by intermediate devices
which is useful for things like OAM.

> IMO, yes.
>
> Is it worthy to implement a new transport service in user-space such a= s
> LEDBAT, QUIC or the variety of transport
> services running for RTC apps? The answer is up to the application. It= is
> the app that decides.

It's not just up to the application. It's up the network operators,=
hardware vendors, as well as the OS vendors. The OS is a big problem.
There is simply no concept of instantaneously changing all OS
deployments to a support a new feature like this. It takes years to
get significant traction. Look at a protocol like MPTCP: it's good
protocol and shows a lot of value to many users, but deployment has
been stymied by lack of OS support. We are trying to fix the
situation, but it's not easy.

> So, no, there is no need to change all hosts. IMO the answer is it dep= ends.
>
> 3) when you enable hICN in an end host the local network configuration=
> manages two distinct namespaces,
> one for locators and one for identifiers (intended as location indepen= dent
> names).=C2=A0 An end-host can manage several
> locators because might be multi-homed and can manage several identifie= rs
> because it has been assigned identifiers
> to name data sources at the host: mic, camera, an app etc.
> This host continues to be able to open TCP or UDP sockets (but also SC= TP or
> others) with the usual socket bindings.
>
> Just to give an example: We are using our hICN=C2=A0 transport library= for
> WebRTC, MPEG-DASH among other things.
> An MPEG-DASH segment can be retrieved by a video client using TCP, QUI= C or
> the consumer/producer socket.
> The video player can sequentially switch protocol to retrieve the segm= ent.
> Not that it make any sense but it's just
> to explain that they live in the same end-host.=C2=A0 If the app consi= ders that
> one transport service can provide
> features that are advantageous it can optionally switch to it.
> There is no intent to replace TCP, UDP, LEDBAT, QUIC, SCTP or any othe= r
> transport protocol with the consumer/producer
> sockets.

Okay, but these protocols still need to work in mobile networks, which
means in hICN enabled network you still need a mobile infrastructure
to handle these "legacy" protocols. That means there are two dist= inct
mobility models needed-- hICN is not simplifying matters in this
regard.

To me, the hICN story would be a lot more compelling if the transport
and network layer are decoupled so there was one solution that
provided seamless mobility for everyone in the network regardless of
type of transport protocol they use or application that they wish to
run. Beyond that, there might be opportunities to improve
communications by some coordinated interaction with the network (like
we propose in FAST), but these are strictly optimization and not
requirements to make basic communications work.

Tom

>
> Luca
>
>
>
> On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert <tom@quantonium.net> wrote:
>>
>> On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello
>> <luca.muscariello@gmail.com> wrote:
>> > More on the mobility use case which also makes deployment opt= ions easier
>> > to
>> > digest
>> >
>> > https://datatracker.ietf= .org/doc/draft-auge-dmm-hicn-mobility/
>> >
>>
>> From the draft:
>>
>> "The goal of hICN is to ease ICN insertion in existing IP inf= rastructure
>> by:
>> ...
>>=C2=A0 3.=C2=A0 minor modification to existing IP routers/endpoints= ;"
>>
>> Can you elaborate on this "minor modification"? Especial= ly for
>> endpoints, which I assume means hosts, what is the scope, the
>> necessary modifications, and deployment model. Also, will applicat= ions
>> have to change or use a new API for hICN?
>>
>> If the implication of hICN is that all Internet hosts need to chan= ge
>> to support a new consumer/producer communications model, a new
>> transport protocol, and a new application API-- there's nothin= g minor
>> about that!
>>
>> Tom
>>
>> >
>> > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig= )
>> > <g= carofig@cisco.com> wrote:
>> >>
>> >> This draft is about hICN and discusses various deployment= options with
>> >> associated pros and cons, without supporting one specific= ally. Clearly,
>> >> depending on=C2=A0 application requirements, on network c= onstraints, on
>> >> phase of
>> >> deployment/transition=C2=A0 etc. one option may be prefer= rable over another
>> >> one
>> >> (and different ones may coexist).
>> >>
>> >>
>> >> One of the described deployment options also discusses co= mbination of
>> >> hICN
>> >> and SRv6, without opposing one approach to the other, rat= her exploiting
>> >> in
>> >> the combination the advantages of both ones.
>> >>
>> >>
>> >> Giovanna
>> >>
>> >> ________________________________
>> >> From: Int-area <int-area-bounces@ietf.org> on behalf of Beh= cet Sarikaya
>> >> <sarikaya2012@gmail.com>
>> >> Sent: Wednesday, June 20, 2018 4:18 PM
>> >> To: Luca Muscariello
>> >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbe= rt; dmm
>> >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorles= s mobility
>> >> management through hICN (hICN-AMM): Deployment options >> >>
>> >>
>> >>
>> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello
>> >> <luca.muscariello@gmail.com> wrote:
>> >>>
>> >>> I wonder whether this conversation should happen in t= he intarea wg
>> >>> mailing list
>> >>> as the main draft was posted there in the first place= . I don't know if
>> >>> cross posting is welcome
>> >>> but I take the risk.
>> >>>
>> >>> Going back to the question, the transport changes are= related to the
>> >>> request/reply semantic
>> >>> of the architecture. The two distinct forwarding path= s described in
>> >>> the
>> >>> draft take care
>> >>> of forwarding requests or replies.This ends up in the= transport layer
>> >>> as
>> >>> a unidirectional
>> >>> channel to recv data or snd data. The replies carry d= ata originating
>> >>> from
>> >>> a=C2=A0 transport end-point (snd buffer)
>> >>> that binds to an identifier which is location indepen= dent, an IPv6
>> >>> number
>> >>> which is not a locator.
>> >>>
>> >>> The forwarding path of the requests is very close to = unmodified IPv6
>> >>> with
>> >>> the DST address carrying the identifier.
>> >>> If you check in the draft an hICN node does one addit= ional lookup in a
>> >>> local cache though. But you can ignore that
>> >>> for now for sake of clarity. What is important is the= address rewrite
>> >>> operation made on the SRC address
>> >>> of the request. A copy of the request is stored in th= e local cache and
>> >>> the locator of the output interface is written in the=
>> >>> SRC address before transmission. This is used by an u= pstream hICN or
>> >>> the
>> >>> final end-point to know the locator that
>> >>> will be used to reply.
>> >>>
>> >>> Replies coming from the snd end-point are label swapp= ed but not like
>> >>> MPLS.
>> >>> The label is the identifier itself that is stored in = the SRC address
>> >>> of
>> >>> the reply,
>> >>> whereas the DST address is a locator. In this forward= ing path a lookup
>> >>> is
>> >>> made in the local cache to
>> >>> find a request (one or many) and the associated locat= or (one or many)
>> >>> that matches the identifier.
>> >>> The DST addr field of the replies is rewritten with t= he locator(s)
>> >>> just
>> >>> obtained from the lookup.
>> >>> This is how the reply is forwarded to the end-points = that issued
>> >>> requests
>> >>> for this identifier.
>> >>>
>> >>> For the replies there is no FIB lookup on the identif= ier (as it is in
>> >>> the
>> >>> SRC addr field).
>> >>> There can be a lookup in the FIB on the locator store= d in the DST of
>> >>> the
>> >>> reply to
>> >>> reach back the previous hICN node or eventually the o= riginal
>> >>> end-point.
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >> Hi,
>> >>
>> >> My humble question is: are you supporting SRv6 or hICN? >> >>
>> >> Regards
>> >> Behcet
>> >>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <tom@quantonium.net&= gt;
>> >>> wrote:
>> >>>>
>> >>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello=
>> >>>> <luca.muscariello@gmail.com> wrote:
>> >>>> > The paragraph you reported is from the draft= that describes hICN to
>> >>>> > enable
>> >>>> > several use cases.
>> >>>> > Mobility is one of those, not the only one.<= br> >> >>>> > To clarify, the draft on hICN mobility deplo= yment options focuses
>> >>>> > on
>> >>>> > the 5G
>> >>>> > service based architecture.
>> >>>> >
>> >>>> > You may be asking
>> >>>> > 1) is it possible to get all the features pr= ovided by hICN w/o
>> >>>> > updates
>> >>>> > to
>> >>>> > the transport layer?
>> >>>> > 2) is changing the transport protocol unnece= ssary difficult to
>> >>>> > enable
>> >>>> > all
>> >>>> > the use cases mentioned in the draft?
>> >>>> >
>> >>>> Sorry, but I'm still missing something fundam= ental here. AFAICT, the
>> >>>> idea of hICN is to put routes in the local routin= g table and use
>> >>>> existing forwarding and routing to forward packet= s to mobile nodes.
>> >>>> So
>> >>>> if a node changes location, then the routing tabl= es need to be
>> >>>> updated. Effectively this is a bunch of host rout= es that need to be
>> >>>> maintained. At least this is what I gather from t= he draft:
>> >>>>
>> >>>> "hICN network layer is about using the IPv6 = FIB to determine a next
>> >>>> hop router to forward requests or using a local p= acket cache to
>> >>>> determine if an incoming request can be satisfied= locally."
>> >>>>
>> >>>> Is this correct? If it is, then I sort of underst= and how hICN could
>> >>>> be
>> >>>> used for mobility or virtualization without netwo= rk overlays, but
>> >>>> then
>> >>>> I'm completely lost as to why this would requ= ire any changes in the
>> >>>> transport layer.
>> >>>>
>> >>>> Tom
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> > IMO, the answers are no for both.
>> >>>> >
>> >>>> > Luca
>> >>>> >
>> >>>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert = <tom@quantonium.= net>
>> >>>> > wrote:
>> >>>> >>
>> >>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Mu= scariello
>> >>>> >> <luca.muscariello@gmail.com> wrote:
>> >>>> >> > Hi all,
>> >>>> >> >
>> >>>> >> > the draft below has been posted and= describes deployments
>> >>>> >> > options
>> >>>> >> > for
>> >>>> >> > anchorless mobility management=C2= =A0 by using
>> >>>> >> > the hicn network architecture that = implements icn semantics in
>> >>>> >> > IPv6
>> >>>> >> > networks.
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mo= bility-deployment-options
>> >>>> >> >
>> >>>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >> >>>> >> >
>> >>>> >> > A background document has been post= ed to the internet area WG
>> >>>> >> > and
>> >>>> >> > reported
>> >>>> >> > here for your convenience.
>> >>>> >> > The core principle behind hicn and = mobility management is that
>> >>>> >> > data
>> >>>> >> > sources
>> >>>> >> > are named using location independen= t names
>> >>>> >> > encoded in IPv6 addresses. The tran= sport service sitting on top
>> >>>> >> > of
>> >>>> >> > the
>> >>>> >> > hicn
>> >>>> >> > architecture is not based on usual = TCP/UDP sockets
>> >>>> >> > but on a novel consumer/producer tr= ansport service that will be
>> >>>> >> > described in
>> >>>> >> > another draft.
>> >>>> >>
>> >>>> >> From the draft: "The transport end-= point offers two kinds of
>> >>>> >> services
>> >>>> >> to applications: a producer and a consum= er service. The service is
>> >>>> >> instantiated in the application by openi= ng communication sockets
>> >>>> >> with
>> >>>> >> an API to perform basic transport servic= e operations: allocation,
>> >>>> >> initialization, configuration, data tran= smission and reception."
>> >>>> >>
>> >>>> >> This seems like a pretty dramatic rethin= k of the transport layer
>> >>>> >> just
>> >>>> >> for the purposes of mobility management.= Will there be a way to
>> >>>> >> use
>> >>>> >> hICN at the network layer with exsiting = and unmodified transport
>> >>>> >> protocols (i.e. can this be done without= boiling the ocean)?
>> >>>> >>
>> >>>> >> Thanks,
>> >>>> >> Tom
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> > The current document and a companio= n document that will be
>> >>>> >> > posted
>> >>>> >> > soon
>> >>>> >> > describe the different deployment o= ptions
>> >>>> >> > with special care to the 5G service= based architecture.
>> >>>> >> > Thanks for the comments already rec= eived that helped completing
>> >>>> >> > this -00
>> >>>> >> > draft.
>> >>>> >> >
>> >>>> >> > Luca
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > ___________________________________= ____________
>> >>>> >> > dmm mailing list
>> >>>> >> > dmm@ietf.org
>> >>>> >> > https://www.ietf.or= g/mailman/listinfo/dmm
>> >>>> >> >
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> dmm mailing list
>> >>> dmm= @ietf.org
>> >>> https://www.ietf.org/mailman/listinfo= /dmm
>> >>>
>> >>
>> >
--000000000000c7ad1c056f246482-- From nobody Thu Jun 21 11:47:10 2018 Return-Path: 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 46FC71310A8 for ; Thu, 21 Jun 2018 11:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 NRN_bHpRGarQ for ; Thu, 21 Jun 2018 11:47:03 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F271130E05 for ; Thu, 21 Jun 2018 11:47:03 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id v13-v6so4196690wrp.13 for ; Thu, 21 Jun 2018 11:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zpTmzIezZx5mQu1gS7t5MC/hbh/8xR67Oum6gzRwPeY=; b=p1ZM5FJqqN7wPmsXKzXxXG80AMrQEqvfxKK75nIWMoJiKRLrDTx2c/RjmpWVqK9ydb xcs2zqcoqOZo4uahUdD1VIybXhryM3kvCzxf6MHJDit+udnugc2Z1LvsvS8puhSuh+RP 3Ic+CyW7Wpa+4kOEBv9pkONcPnOkfvPRiNA9BFUx6IIRdyBUb4OeDT3W4ZpgRv6Ss+tV OWh5mizK0DA46OWZ7FcMnA2XK77cmNRRpDy24IL5LlubwvGa2GPRdCHDfQhi/G4BWwDD SyZXw4RIxSAazssdONQ6Jw8IUKYiUfQbih5JI1dr7+mi1AXJJxRLXKEkLnAkQ3K1NUb/ EAMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zpTmzIezZx5mQu1gS7t5MC/hbh/8xR67Oum6gzRwPeY=; b=WCpwfVMeo6+Khwbc+Tm1zIyhE+OQZ55ZZoK0BjO5CBd/QDANeg9sa9Lc89yTFHRXZI G6ja7xHki55A7WbGY6C0YcrMS+5K8ftvdQJp0PsbOBjqC42gBBwT6QcnKrcZot18Dif/ VhLnONDQjMRUIoVBlC2lElAP4tOKEVD/cLIovwILlWf4+TMOHY2tDw++brMOiLWKIlkC 2SI8/rSsfVb3SucWEMgOp9w0aaybHMbShzpKmuRmIHQ4YfrnizzX9AM3XaxwyK8d8wAe nmDZ2uy78kw35lDUx+9yFhzapAdaDkp7tLWdGgH8IC9eckdZ3JCxib0D17PeitZPJzoT lZCw== X-Gm-Message-State: APt69E0lkKXgTf73Eba7GvCvYwtEh/K+C8dBgXLzd8q3QDJ2CafBrT6P 3Os95FL1ssl5HxIxgI5o72kTk8jX4+jrWOM4Enpwew== X-Google-Smtp-Source: AAOMgpc1/D4d/ssQfhOgvh1Jkfo+n+piFE5uS0rT/MNOKrPjz1btsbq/gUqyWCTNNVmlNODfaKQaoizxuCKyr2HyQcg= X-Received: by 2002:adf:e505:: with SMTP id j5-v6mr844050wrm.111.1529606821408; Thu, 21 Jun 2018 11:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:f9d2:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 11:47:00 -0700 (PDT) In-Reply-To: References: <1529505221125.58728@cisco.com> From: Tom Herbert Date: Thu, 21 Jun 2018 11:47:00 -0700 Message-ID: To: Luca Muscariello Cc: Giovanna Carofiglio , Behcet Sarikaya , Luca Muscariello , dmm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 18:47:08 -0000 On Thu, Jun 21, 2018 at 3:29 AM, Luca Muscariello wrote: > There are several points raised here: > 1) Alleged protocol layering violations and the e2e principle. > 2) Relationship between the OS and transport services. > > > 1) Many see the e2e principle as another instance of Occam's razor applied > to communication > protocols function placement, I think it is even written in the first paper > that talks about it (Reed, Clark...). > It's all about design patters for the development of distributed > applications. > Placement of function vertically in a layered architecture and horizontally > in the network path between end-points. > > In this respect, hICN, but I should say CCN and NDN realise that principle > with a new way to look at networking. > Essentially naming data sources with location-independent identifiers. LISP, ILA, SRv6, and ILNP also do this. It's a core concept in identifier locator separation protocols. ILNP requires changes to the transport layer and endhosts to work, however ILA, SRv6, and LISP don't-- these protocols operate strictly at the network layer as does GTP. All of these have the goal to provide anchorless communication (that could also be done in GTP as well given right changes to the control plane). ILA and ILNP have they advantage that they don't have any incur additional packet overhead, although I believe that ILNP does use some extension headers which might be a convolution to use over the Internet. Tom > I am far from going to claim credits to the design principles behind CCN/NDN > as it is Van Jacobson and team > who fundamentally designed that system. hICN is a convenient implementation > of CCN into IPv6 to make that > design available in IPv6 now. > > Other attempts have introduced networking of location-independent > identifiers in the Internet and the most notable > one is LISP even if it is still the host to be identified. > I would avoid to quote in full Brian Carpenter about this topic so I just > report a reference. It's all in there. > > Brian E. Carpenter. 2014. IP addresses considered harmful. SIGCOMM Comput. > Commun. Rev. 44, 2 (April 2014), 65-69. DOI: > http://dx.doi.org/10.1145/2602204.2602215 > > If we look at LISP for instance, the placement of protocol functions > requires to have a mapping system. > It is not exactly an instance of the Occam's razor though. But it is > probably the best solution to a very > specific problem formulation. > > The fact that the network has to support all transport protocols is clearly > false. The Internet is also IP multicast, > among other things, > and the transport protocols being cited (TCP/LEDBAT/QUIC etc) not only will > never work over IP multicast but > have never been meant to at design time. > > hICN mobility for the 5G service based architecture is supposed to run in a > slice for the development of advanced > applications (IoT, AR/VR, MEC etc) but also to rethink current applications > with these new transport services. > This means that alternative solutions for mobility management in 5G, such as > GTP, LISP or derivations of it, are > required to exist. > In the current 5G standardisation effort there might be several mobility > models co-existing and slicing has been > designed in order to enable that. > > 2) This should probably be a whole new email thread and also other mailing > lists might be a better forum. > > It is true that applications make use of a communication API provided by the > OS. But that's quite generic. > Those functions can be place in different parts of the OS. > Our choice is to move communication functions, essentially the entire stack, > out of the kernel > and use a server stack based on VPP https://git.fd.io and install network > functions just like any application in an application store. > The client stack would also de deployed as a portable app. iOS 12 is the > first mobile OS to adopt this kind of philosophy and we continue to adopt > that approach for the time being. > > The fact that MPTCP encounters difficulties to be fully integrated in a > specific OS component is an implementation issue > that belongs to that particular component. The consequence of that might be > that multiple culturally different implementations > and deployment options of network functions should exist in the future. Not > less. > > > > On Wed, Jun 20, 2018 at 7:18 PM Tom Herbert wrote: >> >> On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello >> wrote: >> > The adjective minor is used in a comparative way. At least I intended >> > that >> > way. >> > hICN allows to implement ICN features with less changes than using ICN >> > as an >> > overlay. >> > On an absolute scale, I don't think that hICN requires negligible >> > changes. >> > So I haven't used the adjective minor as a synonym of negligible. >> > I do think that having those changes are worthy for many apps. >> > >> > Back to your questions that I understand this way: >> > 1) What is the hICN socket API? >> > 2) Does hICN imply that all hosts have to change transport stack? >> > 3) Does hICN disrupt the TCP/IP stack in an end host? >> > >> > >> > 1) The answer to the first question is something that I wanted to >> > discuss in >> > the transport area >> > but repeating does good. In the current implementation we support two >> > different APIs. >> > The first one is a BSD socket API, the second one is a post-socket API >> > that >> > is currently >> > under development in the TAPS WG with a first integration in iOS 12 >> > beta. >> > I'm not >> > contributing to TAPS but I think it is worthy to keep our implementation >> > updated with TAPS. >> > I haven't finished to write a draft but I have a technical report that I >> > could share right before next IETF. >> > >> > 2) An application developer may or may not want to change to use this >> > API. >> > But I would turn the question around to ask, is it worthy to change the >> > application to exploit >> > this new transport service and the underlying network service to get a >> > certain number of benefits? >> >> Luca, >> >> I would say the answer is no, unless you can prove beyond doubt that >> violating the protocol layering archictecure of the Internet and the >> E2E model is necessary to get those benefits. I don't believe that >> proof has yet been provided (for this proposal or any other similar >> ones and there have been several). The Internet is architectured such >> that any transport protocol can run over a common network layer. >> Mobility is a network layer concern and so should be part of the >> network layer. Therefore, a network mobility solution should work >> transparently with any transport layer (TCP, UCP, QUIC, SCTP, and new >> ones we may come up with). The network/transport separation is not >> maintained when we we see intermediate devices trying to participate >> the transport layer which entails DPI and inevitably leads to protocol >> ossification in the Internet. >> >> So we want middelboxes be less invasive in the transport layer, not >> more invasive! You may want to look at early PLUS/SPUD efforts that >> were attempting to turn UDP into a sort of of network layer protocol >> to carry path information read by the network (they choose UDP because >> of compatibility with existing HW instead of defining a new transport >> protocol). This even included encoding flow semantics for network to >> track (like the request/response tracking in hICN). These efforts got >> pushback in part because it violates protocol layer and encouraged >> DPI. In hindsight the answer now seems pretty simple: network layer >> information belongs in network layer headers. If you want to signal >> the network then just put information extension headers like HBH >> options. EH also permits data modification by intermediate devices >> which is useful for things like OAM. >> >> > IMO, yes. >> > >> > Is it worthy to implement a new transport service in user-space such as >> > LEDBAT, QUIC or the variety of transport >> > services running for RTC apps? The answer is up to the application. It >> > is >> > the app that decides. >> >> It's not just up to the application. It's up the network operators, >> hardware vendors, as well as the OS vendors. The OS is a big problem. >> There is simply no concept of instantaneously changing all OS >> deployments to a support a new feature like this. It takes years to >> get significant traction. Look at a protocol like MPTCP: it's good >> protocol and shows a lot of value to many users, but deployment has >> been stymied by lack of OS support. We are trying to fix the >> situation, but it's not easy. >> >> > So, no, there is no need to change all hosts. IMO the answer is it >> > depends. >> > >> > 3) when you enable hICN in an end host the local network configuration >> > manages two distinct namespaces, >> > one for locators and one for identifiers (intended as location >> > independent >> > names). An end-host can manage several >> > locators because might be multi-homed and can manage several identifiers >> > because it has been assigned identifiers >> > to name data sources at the host: mic, camera, an app etc. >> > This host continues to be able to open TCP or UDP sockets (but also SCTP >> > or >> > others) with the usual socket bindings. >> > >> > Just to give an example: We are using our hICN transport library for >> > WebRTC, MPEG-DASH among other things. >> > An MPEG-DASH segment can be retrieved by a video client using TCP, QUIC >> > or >> > the consumer/producer socket. >> > The video player can sequentially switch protocol to retrieve the >> > segment. >> > Not that it make any sense but it's just >> > to explain that they live in the same end-host. If the app considers >> > that >> > one transport service can provide >> > features that are advantageous it can optionally switch to it. >> > There is no intent to replace TCP, UDP, LEDBAT, QUIC, SCTP or any other >> > transport protocol with the consumer/producer >> > sockets. >> >> Okay, but these protocols still need to work in mobile networks, which >> means in hICN enabled network you still need a mobile infrastructure >> to handle these "legacy" protocols. That means there are two distinct >> mobility models needed-- hICN is not simplifying matters in this >> regard. >> >> To me, the hICN story would be a lot more compelling if the transport >> and network layer are decoupled so there was one solution that >> provided seamless mobility for everyone in the network regardless of >> type of transport protocol they use or application that they wish to >> run. Beyond that, there might be opportunities to improve >> communications by some coordinated interaction with the network (like >> we propose in FAST), but these are strictly optimization and not >> requirements to make basic communications work. >> >> Tom >> >> > >> > Luca >> > >> > >> > >> > On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert wrote: >> >> >> >> On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello >> >> wrote: >> >> > More on the mobility use case which also makes deployment options >> >> > easier >> >> > to >> >> > digest >> >> > >> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ >> >> > >> >> >> >> From the draft: >> >> >> >> "The goal of hICN is to ease ICN insertion in existing IP >> >> infrastructure >> >> by: >> >> ... >> >> 3. minor modification to existing IP routers/endpoints;" >> >> >> >> Can you elaborate on this "minor modification"? Especially for >> >> endpoints, which I assume means hosts, what is the scope, the >> >> necessary modifications, and deployment model. Also, will applications >> >> have to change or use a new API for hICN? >> >> >> >> If the implication of hICN is that all Internet hosts need to change >> >> to support a new consumer/producer communications model, a new >> >> transport protocol, and a new application API-- there's nothing minor >> >> about that! >> >> >> >> Tom >> >> >> >> > >> >> > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) >> >> > wrote: >> >> >> >> >> >> This draft is about hICN and discusses various deployment options >> >> >> with >> >> >> associated pros and cons, without supporting one specifically. >> >> >> Clearly, >> >> >> depending on application requirements, on network constraints, on >> >> >> phase of >> >> >> deployment/transition etc. one option may be preferrable over >> >> >> another >> >> >> one >> >> >> (and different ones may coexist). >> >> >> >> >> >> >> >> >> One of the described deployment options also discusses combination >> >> >> of >> >> >> hICN >> >> >> and SRv6, without opposing one approach to the other, rather >> >> >> exploiting >> >> >> in >> >> >> the combination the advantages of both ones. >> >> >> >> >> >> >> >> >> Giovanna >> >> >> >> >> >> ________________________________ >> >> >> From: Int-area on behalf of Behcet >> >> >> Sarikaya >> >> >> >> >> >> Sent: Wednesday, June 20, 2018 4:18 PM >> >> >> To: Luca Muscariello >> >> >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> >> >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility >> >> >> management through hICN (hICN-AMM): Deployment options >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello >> >> >> wrote: >> >> >>> >> >> >>> I wonder whether this conversation should happen in the intarea wg >> >> >>> mailing list >> >> >>> as the main draft was posted there in the first place. I don't know >> >> >>> if >> >> >>> cross posting is welcome >> >> >>> but I take the risk. >> >> >>> >> >> >>> Going back to the question, the transport changes are related to >> >> >>> the >> >> >>> request/reply semantic >> >> >>> of the architecture. The two distinct forwarding paths described in >> >> >>> the >> >> >>> draft take care >> >> >>> of forwarding requests or replies.This ends up in the transport >> >> >>> layer >> >> >>> as >> >> >>> a unidirectional >> >> >>> channel to recv data or snd data. The replies carry data >> >> >>> originating >> >> >>> from >> >> >>> a transport end-point (snd buffer) >> >> >>> that binds to an identifier which is location independent, an IPv6 >> >> >>> number >> >> >>> which is not a locator. >> >> >>> >> >> >>> The forwarding path of the requests is very close to unmodified >> >> >>> IPv6 >> >> >>> with >> >> >>> the DST address carrying the identifier. >> >> >>> If you check in the draft an hICN node does one additional lookup >> >> >>> in a >> >> >>> local cache though. But you can ignore that >> >> >>> for now for sake of clarity. What is important is the address >> >> >>> rewrite >> >> >>> operation made on the SRC address >> >> >>> of the request. A copy of the request is stored in the local cache >> >> >>> and >> >> >>> the locator of the output interface is written in the >> >> >>> SRC address before transmission. This is used by an upstream hICN >> >> >>> or >> >> >>> the >> >> >>> final end-point to know the locator that >> >> >>> will be used to reply. >> >> >>> >> >> >>> Replies coming from the snd end-point are label swapped but not >> >> >>> like >> >> >>> MPLS. >> >> >>> The label is the identifier itself that is stored in the SRC >> >> >>> address >> >> >>> of >> >> >>> the reply, >> >> >>> whereas the DST address is a locator. In this forwarding path a >> >> >>> lookup >> >> >>> is >> >> >>> made in the local cache to >> >> >>> find a request (one or many) and the associated locator (one or >> >> >>> many) >> >> >>> that matches the identifier. >> >> >>> The DST addr field of the replies is rewritten with the locator(s) >> >> >>> just >> >> >>> obtained from the lookup. >> >> >>> This is how the reply is forwarded to the end-points that issued >> >> >>> requests >> >> >>> for this identifier. >> >> >>> >> >> >>> For the replies there is no FIB lookup on the identifier (as it is >> >> >>> in >> >> >>> the >> >> >>> SRC addr field). >> >> >>> There can be a lookup in the FIB on the locator stored in the DST >> >> >>> of >> >> >>> the >> >> >>> reply to >> >> >>> reach back the previous hICN node or eventually the original >> >> >>> end-point. >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> My humble question is: are you supporting SRv6 or hICN? >> >> >> >> >> >> Regards >> >> >> Behcet >> >> >> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert >> >> >>> wrote: >> >> >>>> >> >> >>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >> >> >>>> wrote: >> >> >>>> > The paragraph you reported is from the draft that describes hICN >> >> >>>> > to >> >> >>>> > enable >> >> >>>> > several use cases. >> >> >>>> > Mobility is one of those, not the only one. >> >> >>>> > To clarify, the draft on hICN mobility deployment options >> >> >>>> > focuses >> >> >>>> > on >> >> >>>> > the 5G >> >> >>>> > service based architecture. >> >> >>>> > >> >> >>>> > You may be asking >> >> >>>> > 1) is it possible to get all the features provided by hICN w/o >> >> >>>> > updates >> >> >>>> > to >> >> >>>> > the transport layer? >> >> >>>> > 2) is changing the transport protocol unnecessary difficult to >> >> >>>> > enable >> >> >>>> > all >> >> >>>> > the use cases mentioned in the draft? >> >> >>>> > >> >> >>>> Sorry, but I'm still missing something fundamental here. AFAICT, >> >> >>>> the >> >> >>>> idea of hICN is to put routes in the local routing table and use >> >> >>>> existing forwarding and routing to forward packets to mobile >> >> >>>> nodes. >> >> >>>> So >> >> >>>> if a node changes location, then the routing tables need to be >> >> >>>> updated. Effectively this is a bunch of host routes that need to >> >> >>>> be >> >> >>>> maintained. At least this is what I gather from the draft: >> >> >>>> >> >> >>>> "hICN network layer is about using the IPv6 FIB to determine a >> >> >>>> next >> >> >>>> hop router to forward requests or using a local packet cache to >> >> >>>> determine if an incoming request can be satisfied locally." >> >> >>>> >> >> >>>> Is this correct? If it is, then I sort of understand how hICN >> >> >>>> could >> >> >>>> be >> >> >>>> used for mobility or virtualization without network overlays, but >> >> >>>> then >> >> >>>> I'm completely lost as to why this would require any changes in >> >> >>>> the >> >> >>>> transport layer. >> >> >>>> >> >> >>>> Tom >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> > IMO, the answers are no for both. >> >> >>>> > >> >> >>>> > Luca >> >> >>>> > >> >> >>>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert >> >> >>>> > wrote: >> >> >>>> >> >> >> >>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >> >> >>>> >> wrote: >> >> >>>> >> > Hi all, >> >> >>>> >> > >> >> >>>> >> > the draft below has been posted and describes deployments >> >> >>>> >> > options >> >> >>>> >> > for >> >> >>>> >> > anchorless mobility management by using >> >> >>>> >> > the hicn network architecture that implements icn semantics >> >> >>>> >> > in >> >> >>>> >> > IPv6 >> >> >>>> >> > networks. >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >> >> >>>> >> > >> >> >>>> >> > A background document has been posted to the internet area WG >> >> >>>> >> > and >> >> >>>> >> > reported >> >> >>>> >> > here for your convenience. >> >> >>>> >> > The core principle behind hicn and mobility management is >> >> >>>> >> > that >> >> >>>> >> > data >> >> >>>> >> > sources >> >> >>>> >> > are named using location independent names >> >> >>>> >> > encoded in IPv6 addresses. The transport service sitting on >> >> >>>> >> > top >> >> >>>> >> > of >> >> >>>> >> > the >> >> >>>> >> > hicn >> >> >>>> >> > architecture is not based on usual TCP/UDP sockets >> >> >>>> >> > but on a novel consumer/producer transport service that will >> >> >>>> >> > be >> >> >>>> >> > described in >> >> >>>> >> > another draft. >> >> >>>> >> >> >> >>>> >> From the draft: "The transport end-point offers two kinds of >> >> >>>> >> services >> >> >>>> >> to applications: a producer and a consumer service. The service >> >> >>>> >> is >> >> >>>> >> instantiated in the application by opening communication >> >> >>>> >> sockets >> >> >>>> >> with >> >> >>>> >> an API to perform basic transport service operations: >> >> >>>> >> allocation, >> >> >>>> >> initialization, configuration, data transmission and >> >> >>>> >> reception." >> >> >>>> >> >> >> >>>> >> This seems like a pretty dramatic rethink of the transport >> >> >>>> >> layer >> >> >>>> >> just >> >> >>>> >> for the purposes of mobility management. Will there be a way to >> >> >>>> >> use >> >> >>>> >> hICN at the network layer with exsiting and unmodified >> >> >>>> >> transport >> >> >>>> >> protocols (i.e. can this be done without boiling the ocean)? >> >> >>>> >> >> >> >>>> >> Thanks, >> >> >>>> >> Tom >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> > The current document and a companion document that will be >> >> >>>> >> > posted >> >> >>>> >> > soon >> >> >>>> >> > describe the different deployment options >> >> >>>> >> > with special care to the 5G service based architecture. >> >> >>>> >> > Thanks for the comments already received that helped >> >> >>>> >> > completing >> >> >>>> >> > this -00 >> >> >>>> >> > draft. >> >> >>>> >> > >> >> >>>> >> > Luca >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > _______________________________________________ >> >> >>>> >> > dmm mailing list >> >> >>>> >> > dmm@ietf.org >> >> >>>> >> > https://www.ietf.org/mailman/listinfo/dmm >> >> >>>> >> > >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> dmm mailing list >> >> >>> dmm@ietf.org >> >> >>> https://www.ietf.org/mailman/listinfo/dmm >> >> >>> >> >> >> >> >> > From nobody Fri Jun 22 01:46:50 2018 Return-Path: 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 72ECA130E04; Fri, 22 Jun 2018 01:46:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 mpukn4oaXBkg; Fri, 22 Jun 2018 01:46:39 -0700 (PDT) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A298130E01; Fri, 22 Jun 2018 01:46:39 -0700 (PDT) Received: by mail-yw0-x242.google.com with SMTP id p129-v6so2143176ywg.7; Fri, 22 Jun 2018 01:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mpekYGCKVjrcFfsvB77wrpgjXi+1iwogyk9ABKooa58=; b=Ns0VN4lHShA83e+/dYVu0n80Cyb2j1crIDGxglUGr3WCUKvLe0ipIJm2cpQuCrQb8/ HSrrxKoZyMlIuuD2hbIinzXg5fpUeSp5eosCc+w0E6tb4MJIDQxK1H9+xgnL23C6UR9w P8KBh1sPaJBl7pgYSarSdtBaEBB8OlxFSNhTBxax0+7qsIT89tIUi2Z6TklvNz1MlJkG fdhTvkgFAPTjFMkD1cn1VyyEJLM2WOXDxETOpXhtLKGUkcPg2WpmgPo4RstnOxXzp9rz egRIS4cTPTT8ngAbxxZcjghTU+KOLMwHab5/UdhCfe894xKCalqw+STVh0vYFqY3CBFA ZSFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mpekYGCKVjrcFfsvB77wrpgjXi+1iwogyk9ABKooa58=; b=AVVa8CIGyE+NN+FZA+BPxwiWvSsBo5YrMX8iaCLBX+Y4dc0ONCyqfpzhNBrSBMBqLQ yYcyrH2zAT02wGhLATbKP8WJIlGTOiHWOGdZJasEVzSp8m5FwEDP4V/FEawIpNz+iBbk hx2RCOh6JHqYqs9HAWTQKzQ7Mxornao12U2PZC5wr1pyzjT1j+86ZlTAnbKColgu/DeC P8Tq5tx2JHBsacogGB/BGuWfiS0DcW5xD+0J/oI5xpCBPQfGrSMWwXlF2jAodEEPu9SQ GU9/MvDM/Xk/DlRoxwFXdTQPdiWrtuTWfwpcWagQF47EAAWk32JLl8nuC9DjegnZgXPO MqSQ== X-Gm-Message-State: APt69E27Y9BTADMTn4+DTdDEMoSbkROSIrO6sKIQie0tVTlRJ27POysp m2612/0OvM7Mx5IhiV8d0pKwPvH9+GrOtAxrGZQ= X-Google-Smtp-Source: ADUXVKIwe6pfkuPw6KIFqL9ynxUXXmtN+BLDsPqMVjs6VLoNWLW6pAHPTlKFRgPHo4W+8WxQiBzBeorkXgL8HF7kKAI= X-Received: by 2002:a81:5988:: with SMTP id n130-v6mr300568ywb.30.1529657198217; Fri, 22 Jun 2018 01:46:38 -0700 (PDT) MIME-Version: 1.0 References: <1529505221125.58728@cisco.com> In-Reply-To: From: Luca Muscariello Date: Fri, 22 Jun 2018 10:46:26 +0200 Message-ID: To: tom@quantonium.net, int-area@ietf.org Cc: Giovanna Carofiglio , sarikaya@ieee.org, Luca Muscariello , dmm@ietf.org Content-Type: multipart/alternative; boundary="000000000000ed91ae056f371143" Archived-At: Subject: Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 08:46:43 -0000 --000000000000ed91ae056f371143 Content-Type: text/plain; charset="UTF-8" These solutions are not all isomorphic and comparison requires some careful taxonomy first. The -01 version of the draft Kalyani is taking care of will include that and will definitely help to compare things. https://datatracker.ietf.org/doc/draft-bogineni-dmm-optimized-mobile-user-plane Let's wait for that work to be available to the list first, probably next week. Luca On Thu, Jun 21, 2018 at 8:47 PM Tom Herbert wrote: > On Thu, Jun 21, 2018 at 3:29 AM, Luca Muscariello > wrote: > > There are several points raised here: > > 1) Alleged protocol layering violations and the e2e principle. > > 2) Relationship between the OS and transport services. > > > > > > 1) Many see the e2e principle as another instance of Occam's razor > applied > > to communication > > protocols function placement, I think it is even written in the first > paper > > that talks about it (Reed, Clark...). > > It's all about design patters for the development of distributed > > applications. > > Placement of function vertically in a layered architecture and > horizontally > > in the network path between end-points. > > > > In this respect, hICN, but I should say CCN and NDN realise that > principle > > with a new way to look at networking. > > Essentially naming data sources with location-independent identifiers. > > LISP, ILA, SRv6, and ILNP also do this. It's a core concept in > identifier locator separation protocols. ILNP requires changes to the > transport layer and endhosts to work, however ILA, SRv6, and LISP > don't-- these protocols operate strictly at the network layer as does > GTP. All of these have the goal to provide anchorless communication > (that could also be done in GTP as well given right changes to the > control plane). ILA and ILNP have they advantage that they don't have > any incur additional packet overhead, although I believe that ILNP > does use some extension headers which might be a convolution to use > over the Internet. > > Tom > > > > I am far from going to claim credits to the design principles behind > CCN/NDN > > as it is Van Jacobson and team > > who fundamentally designed that system. hICN is a convenient > implementation > > of CCN into IPv6 to make that > > design available in IPv6 now. > > > > Other attempts have introduced networking of location-independent > > identifiers in the Internet and the most notable > > one is LISP even if it is still the host to be identified. > > I would avoid to quote in full Brian Carpenter about this topic so I just > > report a reference. It's all in there. > > > > Brian E. Carpenter. 2014. IP addresses considered harmful. SIGCOMM > Comput. > > Commun. Rev. 44, 2 (April 2014), 65-69. DOI: > > http://dx.doi.org/10.1145/2602204.2602215 > > > > If we look at LISP for instance, the placement of protocol functions > > requires to have a mapping system. > > It is not exactly an instance of the Occam's razor though. But it is > > probably the best solution to a very > > specific problem formulation. > > > > The fact that the network has to support all transport protocols is > clearly > > false. The Internet is also IP multicast, > > among other things, > > and the transport protocols being cited (TCP/LEDBAT/QUIC etc) not only > will > > never work over IP multicast but > > have never been meant to at design time. > > > > hICN mobility for the 5G service based architecture is supposed to run > in a > > slice for the development of advanced > > applications (IoT, AR/VR, MEC etc) but also to rethink current > applications > > with these new transport services. > > This means that alternative solutions for mobility management in 5G, > such as > > GTP, LISP or derivations of it, are > > required to exist. > > In the current 5G standardisation effort there might be several mobility > > models co-existing and slicing has been > > designed in order to enable that. > > > > 2) This should probably be a whole new email thread and also other > mailing > > lists might be a better forum. > > > > It is true that applications make use of a communication API provided by > the > > OS. But that's quite generic. > > Those functions can be place in different parts of the OS. > > Our choice is to move communication functions, essentially the entire > stack, > > out of the kernel > > and use a server stack based on VPP https://git.fd.io and install > network > > functions just like any application in an application store. > > The client stack would also de deployed as a portable app. iOS 12 is the > > first mobile OS to adopt this kind of philosophy and we continue to adopt > > that approach for the time being. > > > > The fact that MPTCP encounters difficulties to be fully integrated in a > > specific OS component is an implementation issue > > that belongs to that particular component. The consequence of that > might be > > that multiple culturally different implementations > > and deployment options of network functions should exist in the future. > Not > > less. > > > > > > > > On Wed, Jun 20, 2018 at 7:18 PM Tom Herbert wrote: > >> > >> On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello > >> wrote: > >> > The adjective minor is used in a comparative way. At least I intended > >> > that > >> > way. > >> > hICN allows to implement ICN features with less changes than using ICN > >> > as an > >> > overlay. > >> > On an absolute scale, I don't think that hICN requires negligible > >> > changes. > >> > So I haven't used the adjective minor as a synonym of negligible. > >> > I do think that having those changes are worthy for many apps. > >> > > >> > Back to your questions that I understand this way: > >> > 1) What is the hICN socket API? > >> > 2) Does hICN imply that all hosts have to change transport stack? > >> > 3) Does hICN disrupt the TCP/IP stack in an end host? > >> > > >> > > >> > 1) The answer to the first question is something that I wanted to > >> > discuss in > >> > the transport area > >> > but repeating does good. In the current implementation we support two > >> > different APIs. > >> > The first one is a BSD socket API, the second one is a post-socket API > >> > that > >> > is currently > >> > under development in the TAPS WG with a first integration in iOS 12 > >> > beta. > >> > I'm not > >> > contributing to TAPS but I think it is worthy to keep our > implementation > >> > updated with TAPS. > >> > I haven't finished to write a draft but I have a technical report > that I > >> > could share right before next IETF. > >> > > >> > 2) An application developer may or may not want to change to use this > >> > API. > >> > But I would turn the question around to ask, is it worthy to change > the > >> > application to exploit > >> > this new transport service and the underlying network service to get a > >> > certain number of benefits? > >> > >> Luca, > >> > --000000000000ed91ae056f371143 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
These solutions are not all isomorphic and comparison= requires some careful taxonomy first.
The -01 version of the dra= ft Kalyani is taking care of will include that and will definitely help to= =C2=A0
compare things.
https://datatra= cker.ietf.org/doc/draft-bogineni-dmm-optimized-mobile-user-plane

Let's wait for that work to be available to the = list first, probably next week.

Luca

On Thu, Jun 21, 2018 at 8:47 PM Tom Herbe= rt <tom@quantonium.net> wro= te:
On Thu, Jun = 21, 2018 at 3:29 AM, Luca Muscariello
<luca.mu= scariello@gmail.com> wrote:
> There are several points raised here:
> 1) Alleged protocol layering violations and the e2e principle.
> 2) Relationship between the OS and transport services.
>
>
> 1) Many see the e2e principle as another instance of Occam's razor= applied
> to communication
> protocols function placement, I think it is even written in the first = paper
> that talks about it (Reed, Clark...).
> It's all about design patters for the development of distributed > applications.
> Placement of function vertically in a layered architecture and horizon= tally
> in the network path between end-points.
>
> In this respect, hICN, but I should say CCN and NDN realise that princ= iple
> with a new way to look at networking.
> Essentially naming data sources with location-independent identifiers.=

LISP, ILA, SRv6, and ILNP also do this. It's a core concept in
identifier locator separation protocols. ILNP requires changes to the
transport layer and endhosts to work, however ILA, SRv6, and LISP
don't-- these protocols operate strictly at the network layer as does GTP. All of these have the goal to provide anchorless communication
(that could also be done in GTP as well given right changes to the
control plane). ILA and ILNP have they advantage that they don't have any incur additional packet overhead, although I believe that ILNP
does use some extension headers which might be a convolution to use
over the Internet.

Tom


> I am far from going to claim credits to the design principles behind C= CN/NDN
> as it is Van Jacobson and team
> who fundamentally designed that system. hICN is a convenient implement= ation
> of CCN into IPv6 to make that
> design available in IPv6 now.
>
> Other attempts have introduced networking of location-independent
> identifiers in the Internet and the most notable
> one is LISP even if it is still the host to be identified.
> I would avoid to quote in full Brian Carpenter about this topic so I j= ust
> report a reference. It's all in there.
>
> Brian E. Carpenter. 2014. IP addresses considered harmful. SIGCOMM Com= put.
> Commun. Rev. 44, 2 (April 2014), 65-69. DOI:
> http://dx.doi.org/10.1145/2602204.2602215
>
> If we look at LISP for instance, the placement of protocol functions > requires to have a mapping system.
> It is not exactly an instance of the Occam's razor though. But it = is
> probably the best solution to a very
> specific problem formulation.
>
> The fact that the network has to support all transport protocols is cl= early
> false. The Internet is also IP multicast,
> among other things,
> and the transport protocols being cited (TCP/LEDBAT/QUIC etc) not only= will
> never work over IP multicast but
> have never been meant to at design time.
>
> hICN mobility for the 5G service based architecture is supposed to run= in a
> slice for the development of advanced
> applications (IoT, AR/VR, MEC etc) but also to rethink current applica= tions
> with these new transport services.
> This means that alternative solutions for mobility management in 5G, s= uch as
> GTP, LISP or derivations of it, are
> required to exist.
> In the current 5G standardisation effort there might be several mobili= ty
> models co-existing and slicing has been
> designed in order to enable that.
>
> 2) This should probably be a whole new email thread and also other mai= ling
> lists might be a better forum.
>
> It is true that applications make use of a communication API provided = by the
> OS. But=C2=A0 that's quite generic.
> Those functions can be place in different parts of the OS.
> Our choice is to move communication functions, essentially the entire = stack,
> out of the kernel
> and use a server stack based on VPP https://git.fd.io and install network=
> functions just like any application in an application store.
> The client stack would also de deployed as a portable app.=C2=A0 iOS 1= 2 is the
> first mobile OS to adopt this kind of philosophy and we continue to ad= opt
> that approach for the time being.
>
> The fact that MPTCP encounters difficulties to be fully integrated in = a
> specific OS component is an implementation issue
> that belongs to that particular component. The consequence of=C2=A0 th= at might be
> that multiple=C2=A0 culturally different implementations
> and deployment options of network functions=C2=A0 should exist in the = future. Not
> less.
>
>
>
> On Wed, Jun 20, 2018 at 7:18 PM Tom Herbert <tom@quantonium.net> wrote:
>>
>> On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello
>> <luca.muscariello@gmail.com> wrote:
>> > The adjective minor is used in a comparative way. At least I = intended
>> > that
>> > way.
>> > hICN allows to implement ICN features with less changes than = using ICN
>> > as an
>> > overlay.
>> > On an absolute scale, I don't think that hICN requires ne= gligible
>> > changes.
>> > So I haven't used the adjective minor as a synonym of neg= ligible.
>> > I do think that having those changes are worthy for many apps= .
>> >
>> > Back to your questions that I understand this way:
>> > 1) What is the hICN socket API?
>> > 2) Does hICN imply that all hosts have to change transport st= ack?
>> > 3) Does hICN disrupt the TCP/IP stack in an end host?
>> >
>> >
>> > 1) The answer to the first question is something that I wante= d to
>> > discuss in
>> > the transport area
>> > but repeating does good. In the current implementation we sup= port two
>> > different APIs.
>> > The first one is a BSD socket API, the second one is a post-s= ocket API
>> > that
>> > is currently
>> > under development in the TAPS WG with a first integration in = iOS 12
>> > beta.
>> > I'm not
>> > contributing to TAPS but I think it is worthy to keep our imp= lementation
>> > updated with TAPS.
>> > I haven't finished to write a draft but I have a technica= l report that I
>> > could share right before next IETF.
>> >
>> > 2) An application developer may or may not want to change to = use this
>> > API.
>> > But I would turn the question around to ask, is it worthy to = change the
>> > application to exploit
>> > this new transport service and the underlying network service= to get a
>> > certain number of benefits?
>>
>> Luca,
>>
--000000000000ed91ae056f371143-- From nobody Fri Jun 22 09:24:05 2018 Return-Path: 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 A9FB5130EA6 for ; Fri, 22 Jun 2018 09:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GcwBIGhn5WCU for ; Fri, 22 Jun 2018 09:23:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE53130EA2 for ; Fri, 22 Jun 2018 09:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19176; q=dns/txt; s=iport; t=1529684638; x=1530894238; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Lp1aMG4DyvBpXWsPKvPngQwsI94+E/TnnueKaF4j7+A=; b=Q/7lwjGB/cCzyZtNpzqWlhKI9uV/YzfTykq5FQDAKcrd1tfK2PKUXm7P 6l22d5LRcW6GY0y6TfU0N7wQMAIa2o/qekh56j8hZxER6LXPmkQ0o+AtP o1ehNxYDWE1hlsqpuJMfontKSW884q+Lw7xFl/DPUPoHnjigN68mqPI3S k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAACUIS1b/5FdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNJYn8oCoNviASMP4IFiCiMXxSBZQsYC4RJAheCbCE0GAE?= =?us-ascii?q?CAQEBAQEBAm0cAQuFKAEBBAEBASEROgQCEQYBCBEBAgEBAQECAiMDAgQfBgs?= =?us-ascii?q?UAQIGCgQTFAeDC4FnAw0ID6w+ghyEW4IuDYEsgQAFgQuHXYFWP4EOAYMPgUG?= =?us-ascii?q?BFUIBAQIYgRMBEgEfFw8GglWCVQKHPJFALAkChXtzhRdtghyBP4QFhmuBFod?= =?us-ascii?q?0gixNhlQCERMBgSQdOGFxcBUaIYJngi8cgzSFFIU+bwGMcQcIF4EIgRoBAQ?= X-IronPort-AV: E=Sophos;i="5.51,257,1526342400"; d="scan'208";a="413981765" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2018 16:23:57 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w5MGNupI027671 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Jun 2018 16:23:57 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 22 Jun 2018 11:23:56 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Fri, 22 Jun 2018 11:23:56 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: [DMM] New Liaison Statement, "CP-173160: New Study Item on User Plane Protocol in 5GC" Thread-Index: AQHUCkVqpr0X0I4hEU2E4wqxMx49Ww== Date: Fri, 22 Jun 2018 16:23:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: text/plain; charset="utf-8" Content-ID: <0F052CC20EF9FB4AA54632E0CD829B89@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on User Plane Protocol in 5GC" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:24:03 -0000 Rm9sa3MgLSBCYWNrIHRvIHRoaXMuDQoNCkFueSBmZWVkYmFjayBvbiB0aGlzPyBOb3cgdGhhdCB3 ZSBoYXZlIHdhaXRlZCBmb3Igc29tZSB0aW1lLCBJIGhvcGUgd2Ugbm93DQpoYXZlIGEgdmlldyBv biB0aGlzIExTLiBJIHRlbmQgdG8gdGhpbmsgd2Ugc2hvdWxkIHNlbmQgYSByZXNwb25zZSBzb29u DQpiZWZvcmUgdGhlIEp1bHkgZGVhZGxpbmUuDQoNClNyaQ0KDQoNCg0KDQoNCg0KDQpPbiA0LzE2 LzE4LCA5OjQ3IEFNLCAiZG1tIG9uIGJlaGFsZiBvZiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUp Ig0KPGRtbS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzZ3VuZGF2ZUBjaXNjby5jb20+ IHdyb3RlOg0KDQo+SGkgQXJhc2htaWQsDQo+DQo+SSB3YXMgbm90IGxvb2tpbmcgYXQgdGhlaXIg SnVseSBkYXRlLCBidXQgbW9yZSBhYm91dCBleGNoYW5naW5nIHN0YXR1cyBvZg0KPnRoZSB3b3Jr IGFuZCBzZWVrIGZlZWRiYWNrLg0KPg0KPkkgdGhpbmssIHdlIG5vdyBhcmUgb24gdGhlIHNhbWUg cGFnZSBub3cuDQo+DQo+U3JpDQo+DQo+DQo+DQo+DQo+T24gNC8xNi8xOCwgODozNyBBTSwgIkFy YXNobWlkIEFraGF2YWluIiA8YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbT4NCj53cm90ZToN Cj4NCj4+VGhhbmtzIEthbHlhbmksDQo+PlRoYXQgbWFrZXMgc2Vuc2UuIFRoZSB3b3JkaW5nIG9m IHRoZSBhY3Rpb24gaXRlbSB0aG91Z2ggc291bmRlZCBsaWtlIDNHUFANCj4+d2FzIHRyeWluZyB0 byBpbXBvc2UgYSBkZWFkbGluZS4NCj4+SSBqdXN0IHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgd2Fz bid0IHRoZSBjYXNlIGNhdXNlIHRoZXJlIGlzIHN0aWxsIGEgbG90DQo+Pm9mIHdvcmsgdG8gYmUg ZG9uZS4NCj4+DQo+PkFyYXNobWlkDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4gRnJvbTogQm9naW5lbmksIEthbHlhbmkgW21haWx0bzpLYWx5YW5pLkJvZ2luZW5pQFZl cml6b25XaXJlbGVzcy5jb21dDQo+Pj4gU2VudDogMTYgQXByaWwgMjAxOCAxMToyNg0KPj4+IFRv OiBBcmFzaG1pZCBBa2hhdmFpbiA8YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbT47IFNyaSBH dW5kYXZlbGxpDQo+Pj4gKHNndW5kYXZlKSA8c2d1bmRhdmVAY2lzY28uY29tPjsgZG1tQGlldGYu b3JnDQo+Pj4gU3ViamVjdDogUkU6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIkNQLTE3MzE2MDog TmV3IFN0dWR5IEl0ZW0gb24gVXNlcg0KPj4+IFBsYW5lIFByb3RvY29sIGluIDVHQyINCj4+PiAN Cj4+PiBBcmFzaG1pZCAtIENUNCB3aWxsIHN0YXJ0IHRoZWlyIHN0dWR5IGluIEp1bHkgMjAxOC4g U28gd29yayBmcm9tIElFVEYNCj4+PmNhbg0KPj4+IHByb3ZpZGUgaW5wdXQgaW50byB0aGF0IHN0 dWR5Lg0KPj4+IEthbHlhbmkNCj4+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+IEZyb206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QXJhc2htaWQgQWtoYXZhaW4NCj4+PiBTZW50OiBNb25kYXksIEFwcmlsIDE2LCAyMDE4IDExOjIx IEFNDQo+Pj4gVG86IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgPHNndW5kYXZlQGNpc2NvLmNv bT47IGRtbUBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFtFXSBSZTogW0RNTV0gTmV3IExpYWlzb24g U3RhdGVtZW50LCAiQ1AtMTczMTYwOiBOZXcgU3R1ZHkNCj4+Pkl0ZW0NCj4+PiBvbiBVc2VyIFBs YW5lIFByb3RvY29sIGluIDVHQyINCj4+PiANCj4+PiBIaSBTcmksDQo+Pj4gDQo+Pj4gVGhhbmsg eW91IGZvciBjbGFyaWZpY2F0aW9uLiBJIG5ldmVyIHN1Z2dlc3RlZCB0aGF0IElFVEYgc2hvdWxk IHNpbmdsZQ0KPj4+b3V0IGENCj4+PiBwYXJ0aWN1bGFyIHByb3Bvc2FsLiBPbiB0aGUgY29udHJh cnksIEkgYmVsaWV2ZSBETU0gc2hvdWxkIHNpbXBseQ0KPj4+Y29uZHVjdA0KPj4+IHRoZSBzdHVk eSBhbmQgcHJvdmlkZSAzR1BQIHdpdGggYWxsIGRpZmZlcmVudCBvcHRpb25zLiAzR1BQIHdpbGwg ZGVjaWRlDQo+Pj53aGF0DQo+Pj4gdG8gZG8gd2l0aCB0aGUgcHJvcG9zYWxzIGZyb20gdGhhdCBw b2ludCBvbi4gQXMgeW91IG1lbnRpb25lZCB0aGVyZQ0KPj4+Y291bGQNCj4+PiBiZSBzZXZlcmFs IGJhY2sgYW5kIGZvcnRoIGJldHdlZW4gdGhlIHR3byBTRE9zLg0KPj4+IA0KPj4+IA0KPj4+IA0K Pj4+IFNvLCB3aGlsZSBJIGFncmVlIHdpdGggYWxsIHBvaW50cywgSSBhbSBzdGlsbCBwdXp6bGVk IGJ5IHRoZSBmb2xsb3dpbmcNCj4+PnN0YXRlbWVudA0KPj4+IGluIDNHUFAgZW1haWwuDQo+Pj4g DQo+Pj4gV2hhdCBpcyB0aGUgc2lnbmlmaWNhbmNlIG9mIHRoZSBKdWx5IDIwMTggZGF0ZT8NCj4+ PiANCj4+PiANCj4+PiANCj4+PiBBQ1RJT046DQo+Pj4gDQo+Pj4gQ1Q0IHJlc3BlY3RmdWxseSBh c2tzIElFVEYgRE1NIHRvIHByb3ZpZGUgYW55IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlDQo+Pj4g cmVsZXZhbnQgdG8gdGhlIGFib3ZlIENUNA0KPj4+IA0KPj4+IHdvcmsgYnkgSnVseSAyMDE4Lg0K Pj4+IA0KPj4+IA0KPj4+IA0KPj4+IEFyYXNobWlkDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IA0KPj4+ID4gRnJvbTogU3JpIEd1bmRhdmVs bGkgKHNndW5kYXZlKSBbbWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbV0NCj4+PiANCj4+PiA+IFNl bnQ6IDEzIEFwcmlsIDIwMTggMTk6MDYNCj4+PiANCj4+PiA+IFRvOiBBcmFzaG1pZCBBa2hhdmFp biA8YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbT47IGRtbUBpZXRmLm9yZw0KPj4+IA0KPj4+ ID4gU3ViamVjdDogUmU6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIkNQLTE3MzE2MDogTmV3IFN0 dWR5IEl0ZW0gb24NCj4+PlVzZXINCj4+PiANCj4+PiA+IFBsYW5lIFByb3RvY29sIGluIDVHQyIN Cj4+PiANCj4+PiA+DQo+Pj4gDQo+Pj4gPiBIaSBBcmFzaG1pZCwNCj4+PiANCj4+PiA+DQo+Pj4g DQo+Pj4gPg0KPj4+IA0KPj4+ID4gSSBhbSBub3Qgc2VlaW5nIGEgcmVsYXRpb24gdG8gdGhlIExT IFJlc3BvbnNlIGFuZCB0aGUgSnVseSAyMDE4DQo+Pj5kZWFkbGluZQ0KPj4+IHRoYXQNCj4+PiAN Cj4+PiA+IHlvdSBhcmUgcmVmZXJyaW5nIHRvLiBJIHRoaW5rIHRoZXJlIGlzIHNvbWUgZGlzY29u bmVjdCBoZXJlLiBMZXRzDQo+Pj5yZXZpZXcgd2hhdA0KPj4+IA0KPj4+ID4gd2UgdGhlIGNoYWly cyBhcmUgdGhpbmtpbmcuDQo+Pj4gDQo+Pj4gPg0KPj4+IA0KPj4+ID4NCj4+PiANCj4+PiA+IDEu IFRoZSB3b3JrIGluIElFVEYgcmVsYXRlZCB0byBVc2VyLVBsYW5lIG9wdGltaXphdGlvbnMgd2ls bCBjb250aW51ZQ0KPj4+Zm9yDQo+Pj4gbWFueQ0KPj4+IA0KPj4+ID4gbW9udGhzLiBXaGVuIHRo ZXJlIGlzIGEgTFMgUmVxdWVzdCwgd2Ugd2lsbCBzZW5kIGEgTFMgcmVzcG9uc2UuIFdlDQo+Pj53 aWxsIHVzZQ0KPj4+IA0KPj4+ID4gTFMgcXVlcnkvcmVzcG9uc2UgYXMgYSBtZWFucyB0byBnYXRo ZXIgZmVlZGJhY2sgZnJvbSB0aGUgU0RPDQo+Pj5jb21tdW5pdHksDQo+Pj4gDQo+Pj4gPiBhbmQg cHJvdmlkZSBhbiB1cGRhdGUgb24gdGhlIHN0YXR1cyBvZiBhbGwgdGhlIGRvY3VtZW50cyBpbiBE TU0gYXQNCj4+PnRoaXMNCj4+PiANCj4+PiA+IHRpbWUuIFRoZSBzdGF0dXMgaW5jbHVkZXMgdXBk YXRlIG9uIFdHIGRvY3VtZW50cyBhbmQgaW5kaXZpZHVhbCBJLUTigJlzDQo+Pj4gdW5kZXINCj4+ PiANCj4+PiA+IGRpc2N1c3Npb25zLg0KPj4+IA0KPj4+ID4NCj4+PiANCj4+PiA+IDIuIFdlIGFy ZSBub3QgZ29pbmcgd2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZXJlIHdpbGwgb25seSBiZSBh DQo+Pj5zaW5nbGUgTFMNCj4+PiANCj4+PiA+IHJlcXVlc3QvcmVzcG9uc2UgZm9yIHRoaXMgZW50 aXJlIFVQIFN0dWR5LCBidXQgd2Ugd2lsbCBrZWVwDQo+Pj5leGNoYW5naW5nDQo+Pj4gDQo+Pj4g PiBpbmZvcm1hdGlvbiBiYXNlZCBvbiB0aGUgcHJvZ3Jlc3MsIGFuZCB3aGVuZXZlciB3ZSBuZWVk IGFkZGl0aW9uYWwNCj4+PiANCj4+PiA+IGNsYXJpZmljYXRpb25zLg0KPj4+IA0KPj4+ID4NCj4+ PiANCj4+PiA+IDMuIFRoZXJlIGFyZSBtdWx0aXBsZSBwcm9wb3NhbHMgaW4gSUVURi4gQXMgd2Ug aGF2ZSBpbmRpY2F0ZWQgaW4gdGhlDQo+Pj5wYXN0LCB3ZQ0KPj4+IA0KPj4+ID4gYXJlIG5vdCBn b2luZyB0byByZWNvbW1lbmQgVEhFIHNpbmdsZSBzb2x1dGlvbiBhbmQgcHV0IGl0IG9uIGENCj4+ PnBsYXR0ZXIgZm9yDQo+Pj4gDQo+Pj4gPiAzR1BQIGNvbnN1bXB0aW9uLCBidXQgcmF0aGVyIHRo ZSBmb2N1cyB3aWxsIGJlIG9uIGNoYXJhY3Rlcml6YXRpb24gb2YNCj4+PmVhY2gNCj4+PiANCj4+ PiA+IGFwcHJvYWNoIHRoYXQgd2UgdGFrZSB1cCBpbiBETU0gV0cuDQo+Pj4gDQo+Pj4gPg0KPj4+ IA0KPj4+ID4gTm93LCBrZWVwaW5nIHRoaXMgaW4gbWluZCwgaWYgdGhlcmUgaXMgYSBnb29kIHJl YXNvbiBub3QgdG8gc2VuZCB0aGUNCj4+PkxTDQo+Pj4gDQo+Pj4gPiBSZXNwb25zZSBub3csIGRl bGF5IGl0IGJ5IHNvbWUgdGltZSwgb3IgaWYgd2UgYmVsaWV2ZSB0aGVyZSBpcw0KPj4+bm90aGlu ZyB0bw0KPj4+IA0KPj4+ID4gcmVzcG9uZCwgd2UgY2FuIGRpc2N1c3MgYW5kIGRlY2lkZSB0byBk byBqdXN0IHRoYXQuIEhvcGUgdGhpcyBtYWtlcw0KPj4+c2Vuc2UuDQo+Pj4gDQo+Pj4gPg0KPj4+ IA0KPj4+ID4gQm90dG9tbGluZSwgYWxsIGZlZWRiYWNrIGlzIHdlbGNvbWUhDQo+Pj4gDQo+Pj4g Pg0KPj4+IA0KPj4+ID4NCj4+PiANCj4+PiA+IFNyaQ0KPj4+IA0KPj4+ID4NCj4+PiANCj4+PiA+ DQo+Pj4gDQo+Pj4gPg0KPj4+IA0KPj4+ID4NCj4+PiANCj4+PiA+IE9uIDQvMTMvMTgsIDE6MzUg UE0sICJBcmFzaG1pZCBBa2hhdmFpbiINCj4+PiANCj4+PiA+IDxhcmFzaG1pZC5ha2hhdmFpbkBo dWF3ZWkuY29tPg0KPj4+IA0KPj4+ID4gd3JvdGU6DQo+Pj4gDQo+Pj4gPg0KPj4+IA0KPj4+ID4g PkhpIFNyaSwNCj4+PiANCj4+PiA+ID5UaGFuayB5b3UgZm9yIGdldHRpbmcgYmFjayB0byB1cy4g VGhleSBsaXN0ZWQgYSBmZXcgZGF0ZXMgdGhlcmUuIFRoZQ0KPj4+IA0KPj4+ID4gPmZpbmFsIGRl YWRsaW5lIGlzIEkgZ3Vlc3MgSnVseSAyMDE4Lg0KPj4+IA0KPj4+ID4gPkFyZSB3ZSB0YXJnZXRp bmcgYW55dGhpbmcgZWFybGllcj8NCj4+PiANCj4+PiA+ID4NCj4+PiANCj4+PiA+ID5BcmFzaG1p ZA0KPj4+IA0KPj4+ID4gPg0KPj4+IA0KPj4+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+PiANCj4+PiA+ID4+IEZyb206IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgW21haWx0 bzpzZ3VuZGF2ZUBjaXNjby5jb21dDQo+Pj4gDQo+Pj4gPiA+PiBTZW50OiAxMyBBcHJpbCAyMDE4 IDEyOjQ3DQo+Pj4gDQo+Pj4gPiA+PiBUbzogQXJhc2htaWQgQWtoYXZhaW4gPGFyYXNobWlkLmFr aGF2YWluQGh1YXdlaS5jb20+Ow0KPj4+IGRtbUBpZXRmLm9yZw0KPj4+IA0KPj4+ID4gPj4gU3Vi amVjdDogUmU6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIkNQLTE3MzE2MDogTmV3IFN0dWR5IEl0 ZW0gb24NCj4+PiANCj4+PiA+ID4+IFVzZXIgUGxhbmUgUHJvdG9jb2wgaW4gNUdDIg0KPj4+IA0K Pj4+ID4gPj4NCj4+PiANCj4+PiA+ID4+IEhpIEFyYXNobWlkLA0KPj4+IA0KPj4+ID4gPj4NCj4+ PiANCj4+PiA+ID4+IFdlIHByb3ZpZGUgdGhlIHN0YXR1cyBvZiB0aGUgcmVsYXRlZCB3b3JrIGl0 ZW1zIGluIERNTSwgYW5kIHNlZWsNCj4+PmFueQ0KPj4+IA0KPj4+ID4gPj5jbGFyaWZpY2F0aW9u cyBvbiB0aGVpciBDVDQgd29yay4gS2V5IHRoaW5nIGZyb20gb3VyIHBvaW50IG9mIHZpZXcNCj4+ PmlzDQo+Pj4gDQo+Pj4gPiA+PnRvIGdldCAgdGhlaXIgZmVlZGJhY2sgb24gdGhlIHdvcmsgd2Ug YXJlIGRvaW5nIGFuZCB0cnkgdG8gbWVldA0KPj4+dGhlaXINCj4+PiANCj4+PiA+ID4+dGltZWxp bmVzLg0KPj4+IA0KPj4+ID4gPj4NCj4+PiANCj4+PiA+ID4+IFNyaQ0KPj4+IA0KPj4+ID4gPj4N Cj4+PiANCj4+PiA+ID4+DQo+Pj4gDQo+Pj4gPiA+PiBPbiA0LzEyLzE4LCAxMDo1MyBBTSwgIkFy YXNobWlkIEFraGF2YWluIg0KPj4+IA0KPj4+ID4gPj4gPGFyYXNobWlkLmFraGF2YWluQGh1YXdl aS5jb20+DQo+Pj4gDQo+Pj4gPiA+PiB3cm90ZToNCj4+PiANCj4+PiA+ID4+DQo+Pj4gDQo+Pj4g PiA+PiA+SGkgU3JpLA0KPj4+IA0KPj4+ID4gPj4gPg0KPj4+IA0KPj4+ID4gPj4gPkFueSBpZGVh IHdoYXQgdGhlIHBsYW4gaXMgb25jZSB3ZSBwYXNzIHRoaXMgaW5mb3JtYXRpb24gdG8gQ1Q0Pw0K Pj4+IA0KPj4+ID4gPj4gPg0KPj4+IA0KPj4+ID4gPj4gPkFyYXNobWlkDQo+Pj4gDQo+Pj4gPiA+ PiA+DQo+Pj4gDQo+Pj4gPiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IA0K Pj4+ID4gPj4gPj4gRnJvbTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBTcmkNCj4+PiANCj4+PiA+ID4+ID4+IEd1bmRhdmVsbGkNCj4+PiANCj4+PiA+ID4+ ID4+IChzZ3VuZGF2ZSkNCj4+PiANCj4+PiA+ID4+ID4+IFNlbnQ6IDEyIEFwcmlsIDIwMTggMTI6 NDcNCj4+PiANCj4+PiA+ID4+ID4+IFRvOiBkbW1AaWV0Zi5vcmcNCj4+PiANCj4+PiA+ID4+ID4+ IFN1YmplY3Q6IFJlOiBbRE1NXSBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJDUC0xNzMxNjA6IE5l dyBTdHVkeQ0KPj4+IA0KPj4+ID4gPj4gPj4gSXRlbSBvbiBVc2VyIFBsYW5lIFByb3RvY29sIGlu IDVHQyINCj4+PiANCj4+PiA+ID4+ID4+DQo+Pj4gDQo+Pj4gPiA+PiA+PiBQbGVhc2UgcmV2aWV3 IGFuZCBwb3N0IHlvdXIgY29tbWVudHMuIENoYWlycyB3aWxsIGRyYWZ0IGENCj4+PnJlc3BvbnNl DQo+Pj4gDQo+Pj4gPiA+PiA+PmZvciBXRyAgcmV2aWV3Lg0KPj4+IA0KPj4+ID4gPj4gPj4NCj4+ PiANCj4+PiA+ID4+ID4+IFNyaQ0KPj4+IA0KPj4+ID4gPj4gPj4NCj4+PiANCj4+PiA+ID4+ID4+ DQo+Pj4gDQo+Pj4gPiA+PiA+PiBPbiA0LzExLzE4LCAxMToxNiBBTSwgIkxpYWlzb24gU3RhdGVt ZW50IE1hbmFnZW1lbnQgVG9vbCINCj4+PiANCj4+PiA+ID4+ID4+IDxsc210QGlldGYub3JnPg0K Pj4+IA0KPj4+ID4gPj4gPj4gd3JvdGU6DQo+Pj4gDQo+Pj4gPiA+PiA+Pg0KPj4+IA0KPj4+ID4g Pj4gPj4gPlRpdGxlOiBDUC0xNzMxNjA6IE5ldyBTdHVkeSBJdGVtIG9uIFVzZXIgUGxhbmUgUHJv dG9jb2wgaW4gNUdDDQo+Pj4gDQo+Pj4gPiA+PiA+PiA+U3VibWlzc2lvbiBEYXRlOiAyMDE4LTA0 LTExIFVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZToNCj4+PiANCj4+PiA+ID4+ID4+ID5odHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+Pj4gM0FfX2RhdGF0 cmFja2VyLmlldGYub3JnX2xpYWlzb25fMTU3Ml8mZD1Ed0lHYVEmYz11ZEJUUnZGdlhDNURocWc3 VUgNCj4+PiBwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJnI9SWRpU09EaDhhRFJqZENlR2dkOU16 bkxITVlLZ0tjc19ZU3cNCj4+PiBYQkRpYW9maDQ3b2lsemFYWVJZRVRjQnluVWRwVCZtPTZfZ0JR TlNKSHN3Y29LMmxndmE5QVY3azg0ZUhzZUQ0UQ0KPj4+IHpOcUs1dU92dG8mcz14WFJ0VFRvVTh2 S1RPTEVGekFDdHd6LXlQRi11OHhEMFN3RUtHcldMelIwJmU9DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+ UGxlYXNlIHJlcGx5IGJ5IDIwMTgtMDctMjANCj4+PiANCj4+PiA+ID4+ID4+ID5Gcm9tOiBTYXRv cnUgTWF0c3VzaGltYSA8c2F0b3J1Lm1hdHN1c2hpbWFAZy5zb2Z0YmFuay5jby5qcD4NCj4+PiAN Cj4+PiA+ID4+ID4+ID5UbzogU3JpIEd1bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbT4sRGFw ZW5nIExpdQ0KPj4+IA0KPj4+ID4gPj4gPj4gPjxtYXhwYXNzaW9uQGdtYWlsLmNvbT4NCj4+PiAN Cj4+PiA+ID4+ID4+ID5DYzogRGFwZW5nIExpdSA8bWF4cGFzc2lvbkBnbWFpbC5jb20+LFRlcnJ5 IE1hbmRlcnNvbg0KPj4+IA0KPj4+ID4gPj4gPj4gPjx0ZXJyeS5tYW5kZXJzb25AaWNhbm4ub3Jn PixEaXN0cmlidXRlZCBNb2JpbGl0eSBNYW5hZ2VtZW50DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+RGlz Y3Vzc2lvbiBMaXN0IDxkbW1AaWV0Zi5vcmc+LFNyaSBHdW5kYXZlbGxpDQo+Pj4gDQo+Pj4gPiA+ PiA+PiA+PHNndW5kYXZlQGNpc2NvLmNvbT4sU3VyZXNoIEtyaXNobmFuIDxzdXJlc2hAa2Fsb29t LmNvbT4NCj4+PiANCj4+PiA+IFJlc3BvbnNlDQo+Pj4gDQo+Pj4gPiA+PiBDb250YWN0czoNCj4+ PiANCj4+PiA+ID4+ID4+ID5nZW9yZy5tYXllci5odWF3ZWlAZ214LmNvbSwzR1BQTGlhaXNvbkBl dHNpLm9yZw0KPj4+IA0KPj4+ID4gPj4gPj4gPlRlY2huaWNhbCBDb250YWN0czoNCj4+PiANCj4+ PiA+ID4+ID4+ID5QdXJwb3NlOiBGb3IgYWN0aW9uDQo+Pj4gDQo+Pj4gPiA+PiA+PiA+DQo+Pj4g DQo+Pj4gPiA+PiA+PiA+Qm9keTogMS4gT3ZlcmFsbCBEZXNjcmlwdGlvbjoNCj4+PiANCj4+PiA+ ID4+ID4+ID4zR1BQIHdvcmtpbmcgZ3JvdXAgb2YgQ1Q0IChDb3JlIGFuZCBUZXJtaW5hbCkgd291 bGQgbGlrZSB0bw0KPj4+IA0KPj4+ID4gPj4gPj4gPmluZm9ybSB0aGUgSUVURiB0aGF0IENUNCBo YXMgaW5pdGlhdGVkIGEgc3R1ZHkgaXRlbSBvbiB1c2VyDQo+Pj5wbGFuZQ0KPj4+IA0KPj4+ID4g Pj4gPj4gPnByb3RvY29sIGluIDVHQyBmb3IgUmVsZWFzZS0xNiBvZiA1RyBwaGFzZSAyIChzZWUg Q1AtMTczMTYwKS4NCj4+PiANCj4+PiA+ID4+ID4+ID4NCj4+PiANCj4+PiA+ID4+ID4+ID5CYXNl ZCBvbiB0aGUgb3V0Y29tZSBmcm9tIHRoZSBJRVRGIC8gM0dQUCBDb29yZGluYXRpb24gbWVldGlu Zw0KPj4+YXQNCj4+PiANCj4+PiA+ID4+ID4+ID5JRVRGIzEwMCwgM0dQUCBDVDQgZ290IGF3YXJl IHRoYXQgSUVURiBETU0gV0cgaXMgY3VycmVudGx5DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+d29ya2lu ZyBvbiBhIHBvc3NpYmxlIGNhbmRpZGF0ZSBwcm90b2NvbCBmb3IgdGhlIDNHUFAgNUcgdXNlcg0K Pj4+IA0KPj4+ID4gPj4gPj4gPnBsYW5lDQo+Pj4gDQo+Pj4gPiA+PnByb3RvY29sLg0KPj4+IA0K Pj4+ID4gPj4gPj4gPg0KPj4+IA0KPj4+ID4gPj4gPj4gPjNHUFAgQ1Q0IHdhbnRzIHRvIGVtcGhh c2l6ZSB0aGF0IGN1cnJlbnRseSB0aGVyZSBpcyBubyByZWxhdGVkDQo+Pj4gDQo+Pj4gPiA+PiA+ PiA+ZXZhbHVhdGlvbiBvbmdvaW5nIGluIDNHUFAuIE5ldmVydGhlbGVzcywgYSBzdHVkeSBpdGVt IHdhcw0KPj4+IA0KPj4+ID4gPj4gPj4gPmFwcHJvdmVkIGZvciBzdWNoIGEgc3R1ZHkgdG8gc3Rh cnQgaW4gdGhlIHNlY29uZCBoYWxmIG9mIDIwMTguDQo+Pj4gDQo+Pj4gPiA+PiA+PiA+VGhlIHN0 dWR5IHdpbGwgZXZhbHVhdGUgYmV0d2VlbiBleGlzdGluZyBzb2x1dGlvbnMgd2l0aGluIDNHUFAN Cj4+PiANCj4+PiA+ID4+ID4+ID5hbmQgb3RoZXIgcHJvdG9jb2xzLCBiYXNlZCBvbiB0aGUgUmVs ZWFzZQ0KPj4+IA0KPj4+ID4gPj4gPj4gPjE2IHN0YWdlIDIgKHN5c3RlbSBhcmNoaXRlY3R1cmUp IHJlcXVpcmVtZW50cy4NCj4+PiANCj4+PiA+ID4+ID4+ID4NCj4+PiANCj4+PiA+ID4+ID4+ID4z R1BQIENUNCB3b3VsZCBsaWtlIHRvIHBvaW50IElFVEYgRE1NIHRvIHRoZSBmb2xsb3dpbmcNCj4+ PiANCj4+PiA+ID4+ID4+ID5zcGVjaWZpY2F0aW9ucyBvbiBHVFAtVS4gVGhlIFJlbGVhc2UgMTYg c3RhZ2UgMiByZXF1aXJlbWVudHMNCj4+PmFyZQ0KPj4+IA0KPj4+ID4gPj4gPj4gPm5vdCB5ZXQg a25vd24gYnV0IGl0IGlzIHdvcnRoIGxvb2tpbmcgYXQgbGF0ZXN0IEdUUC1VIHNwZWMNCj4+Pndo aWNoDQo+Pj4gDQo+Pj4gPiA+PiA+PiA+d2lsbCBiZSBldmFsdWF0ZWQgdGhyb3VnaCB0aGUgc3R1 ZHkgYXMgdGhlIGV4aXN0aW5nIHByb3RvY29sLg0KPj4+IA0KPj4+ID4gPj4gPj4gPg0KPj4+IA0K Pj4+ID4gPj4gPj4gPuKCrAlbMV0gM0dQUCBUUyAyOS4yODEgKFYxNS4xLjApOiBHUFJTIFR1bm5l bGxpbmcgUHJvdG9jb2wgVXNlcg0KPj4+IA0KPj4+ID4gUGxhbmUNCj4+PiANCj4+PiA+ID4+ID4+ ID4oR1RQdjEtVSkNCj4+PiANCj4+PiA+ID4+ID4+ID4NCj4+PiANCj4+PiA+ID4+ID4+ID4NCj4+ PiANCj4+PiA+ID4+ID4+ID5Gb2xsb3dpbmcgdGVjaG5pY2FsIHJlcG9ydCBwcm92aWRlcyBpbmZv cm1hdGlvbiBvZiBob3cgM0dQUA0KPj4+IA0KPj4+ID4gPj4gPj4gPmNvbnNpZGVyZWQgR1RQLVUg YXBwbHkgdG8gdXNlciBwbGFuZSBvZiA1R19waDE6DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+DQo+Pj4g DQo+Pj4gPiA+PiA+PiA+4oKsCVsyXSAzR1BQIFRSIDI5Ljg5MSAoVjE1LjAuMCk6IDVHIFN5c3Rl bSDCrSBQaGFzZSAxOyBDVDQNCj4+PkFzcGVjdHMNCj4+PiANCj4+PiA+ID4+ID4+ID4NCj4+PiAN Cj4+PiA+ID4+ID4+ID4NCj4+PiANCj4+PiA+ID4+ID4+ID5GdXJ0aGVybW9yZSwgM0dQUCB3b3Vs ZCBsaWtlIHRvIGdpdmUgdGhlIGZvbGxvd2luZyBnZW5lcmFsDQo+Pj4gDQo+Pj4gPiA+PiA+PiA+ Z3VpZGFuY2UgdG8gSUVURiBETU0sIHJlZ2FyZGluZyB1c2VyIHBsYW5lIHRyYW5zcG9ydCB3aXRo aW4NCj4+PjNHUFANCj4+PiANCj4+PiA+IG5ldHdvcmtzLg0KPj4+IA0KPj4+ID4gPj4gPj4gPlRo ZXNlIGFyZSB0ZWNobmljYWwgc3BlY2lmaWNhdGlvbnMgdGhhdCBpbmNsdWRlIGFsc28gdGhlDQo+ Pj4gDQo+Pj4gPiA+PiA+PiA+bmVjZXNzYXJ5IGluZm9ybWF0aW9uIHRvIHVuZGVyc3RhbmQgd2hp Y2ggYXJjaGl0ZWN0dXJhbCwgUW9TLA0KPj4+IA0KPj4+ID4gPj4gPj4gPnNlY3VyaXR5LXJlbGF0 ZWQgYW5kIGhpZ2gtbGV2ZWwgcmVxdWlyZW1lbnRzIEdUUC1VIGN1cnJlbnRseQ0KPj4+IA0KPj4+ ID4gPj4gPj4gPmNvbXBsaWVzIHRvIHdpdGhpbg0KPj4+IA0KPj4+ID4gPj41R19waDEuDQo+Pj4g DQo+Pj4gPiA+PiA+PiA+DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+4oKsCVszXSAzR1BQIFRTIDIzLjUw MSAoVjE1LjAuMCk6IFN5c3RlbSBBcmNoaXRlY3R1cmUgZm9yIHRoZSA1Rw0KPj4+IA0KPj4+ID4g Pj5TeXN0ZW0NCj4+PiANCj4+PiA+ID4+ID4+ID7igqwJWzRdIDNHUFAgVFMgMjMuNTAyIChWMTUu MC4wKTogUHJvY2VkdXJlcyBmb3IgdGhlIDVHIFN5c3RlbQ0KPj4+IA0KPj4+ID4gPj4gPj4gPuKC rAlbNV0gM0dQUCBUUyAyMy41MDMgKFYxNS4wLjApOiBQb2xpY3kgYW5kIENoYXJnaW5nIEZyYW1l d29yaw0KPj4+IA0KPj4+ID4gZm9yDQo+Pj4gDQo+Pj4gPiA+PnRoZQ0KPj4+IA0KPj4+ID4gPj4g Pj4gNUcNCj4+PiANCj4+PiA+ID4+ID4+ID5TeXN0ZW0NCj4+PiANCj4+PiA+ID4+ID4+ID7igqwJ WzZdIDNHUFAgVFMgMzMuNTAxIChWMC42LjApOiBTZWN1cml0eSBBcmNoaXRlY3R1cmUgKHdvcmsg aW4NCj4+PiANCj4+PiA+ID4+cHJvZ3Jlc3MpDQo+Pj4gDQo+Pj4gPiA+PiA+PiA+DQo+Pj4gDQo+ Pj4gPiA+PiA+PiA+Mi4gQWN0aW9uczoNCj4+PiANCj4+PiA+ID4+ID4+ID5UbyBJRVRGIERNTToN Cj4+PiANCj4+PiA+ID4+ID4+ID5BQ1RJT046IAlDVDQgcmVzcGVjdGZ1bGx5IGFza3MgSUVURiBE TU0gdG8gcHJvdmlkZSBhbnkNCj4+PiANCj4+PiA+IGluZm9ybWF0aW9uDQo+Pj4gDQo+Pj4gPiA+ PiA+PiB0aGF0DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+bWF5IGJlIHJlbGV2YW50IHRvIHRoZSBhYm92 ZSBDVDQgd29yayBieSBKdWx5IDIwMTguDQo+Pj4gDQo+Pj4gPiA+PiA+PiA+DQo+Pj4gDQo+Pj4g PiA+PiA+PiA+DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+My4gRGF0ZSBvZiBOZXh0IENUIGFuZCBDVDQg TWVldGluZ3M6DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+Q1Q0IzgzCTI2dGggRmViIMKtIDJuZCBNYXIg MjAxOAlNb250cmVhbCwgQ0FODQo+Pj4gDQo+Pj4gPiA+PiA+PiA+Q1QjNzkJMTl0aCDCrSAyMHRo IE1hciAyMDE4CUNoZW5uYWksIEluZGlhDQo+Pj4gDQo+Pj4gPiA+PiA+PiA+Q1Q0Izg0CTE2dGgg wq0gMjB0aCBBcHJpbCAyMDE4CUt1bm1pbmcsIENoaW5hDQo+Pj4gDQo+Pj4gPiA+PiA+PiA+Q1Q0 Izg1CTIxc3Qgwq0gMjV0aCBNYXkgMjAxOAlPc2FrYSwgSmFwYW4NCj4+PiANCj4+PiA+ID4+ID4+ ID5DVCM4MAkxMXRoIMKtIDEydGggSnVuZSAyMDE4CUxhIEpvbGxhLCBVU0ENCj4+PiANCj4+PiA+ ID4+ID4+ID5DVDQjODUtYmlzCSAgOXRoIMKtMTN0aCBKdWx5IDIwMTgJVEJELCBGcmFuY2UNCj4+ PiANCj4+PiA+ID4+ID4+ID5DVDQjODYJMjBzdCDCrSAyNHRoIEF1ZyAyMDE4CVRCRCwgVVNBDQo+ Pj4gDQo+Pj4gPiA+PiA+PiA+QXR0YWNobWVudHM6DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+DQo+Pj4g DQo+Pj4gPiA+PiA+PiA+ICAgIENQLTE4MDExNg0KPj4+IA0KPj4+ID4gPj4gPj4gPg0KPj4+IA0K Pj4+ID4gPj4gPj4gPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0NCj4+PiAzQV9fd3d3LmlldGYub3JnX2xpYl9kdF9kb2N1bWVudHNfTElBSVNPTl9saWFp c29uLTJEMjAxOC0yRDA0LTJEMTEtDQo+Pj4gMkQmZD1Ed0lHYVEmYz11ZEJUUnZGdlhDNURocWc3 VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJnI9SWRpDQo+Pj4gU09EaDhhRFJqZENlR2dkOU16 bkxITVlLZ0tjc19ZU3dYQkRpYW9maDQ3b2lsemFYWVJZRVRjQnluVWRwVCZtDQo+Pj4gPTZfZ0JR TlNKSHN3Y29LMmxndmE5QVY3azg0ZUhzZUQ0UXpOcUs1dU92dG8mcz1jemtTb3l0VkZnYnEtDQo+ Pj4gZlNpTGtwM2FfQlpmby03N3REZ1E3Ql9SdHotT1M4JmU9DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+ M2dwDQo+Pj4gDQo+Pj4gPiA+PiA+PiA+cC10DQo+Pj4gDQo+Pj4gPiA+PiA+PiA+c2djDQo+Pj4g DQo+Pj4gPiA+PiA+PiANCj4+Pj50LWN0NC1kbW0tY3AtMTczMTYwLW5ldy1zdHVkeS1pdGVtLW9u LXVzZXItcGxhbmUtcHJvdG9jb2wtaW4tNWdjLQ0KPj4+IA0KPj4+ID4gPj4gPj4gPmF0dA0KPj4+ IA0KPj4+ID4gPj4gPj4gPmFjaA0KPj4+IA0KPj4+ID4gPj4gPj4gPm1lbg0KPj4+IA0KPj4+ID4g Pj4gPj4gPnQtMS5kb2MNCj4+PiANCj4+PiA+ID4+ID4+ID4NCj4+PiANCj4+PiA+ID4+ID4+DQo+ Pj4gDQo+Pj4gPiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IA0KPj4+ID4gPj4gPj4gZG1tIG1haWxpbmcgbGlzdA0KPj4+IA0KPj4+ID4g Pj4gPj4gZG1tQGlldGYub3JnDQo+Pj4gDQo+Pj4gPiA+PiA+PiBodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+Pj4gM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2RtbSZkPUR3SUdhUSZjPXVkQlRSdkZ2WEM1RGhxZzcNCj4+PiBVSHBKbFBw czNtWjNMUnhwYjZfXzBQb21CVFEmcj1JZGlTT0RoOGFEUmpkQ2VHZ2Q5TXpuTEhNWUtnS2NzX1kN Cj4+PiBTd1hCRGlhb2ZoNDdvaWx6YVhZUllFVGNCeW5VZHBUJm09Nl9nQlFOU0pIc3djb0sybGd2 YTlBVjdrODRlSHNlRA0KPj4+IDRRek5xSzV1T3Z0byZzPVdweHJ3SFdDQmZNNDhKRkhSNGMzV1V2 M1VSVm81OWlpSzJ3NGdJbnAzQTQmZT0NCj4+PiANCj4+PiA+ID4NCj4+PiANCj4+PiANCj4+PiAN Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IGRtbSBtYWlsaW5nIGxpc3QNCj4+PiBkbW1AaWV0Zi5vcmcNCj4+PiBodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+Pj4gM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX2RtbSZkPUR3SUdhUSZjPXVkQlRSdkZ2WEM1RGhxZzcNCj4+PiBVSHBK bFBwczNtWjNMUnhwYjZfXzBQb21CVFEmcj1JZGlTT0RoOGFEUmpkQ2VHZ2Q5TXpuTEhNWUtnS2Nz X1kNCj4+PiBTd1hCRGlhb2ZoNDdvaWx6YVhZUllFVGNCeW5VZHBUJm09Nl9nQlFOU0pIc3djb0sy bGd2YTlBVjdrODRlSHNlRA0KPj4+IDRRek5xSzV1T3Z0byZzPVdweHJ3SFdDQmZNNDhKRkhSNGMz V1V2M1VSVm81OWlpSzJ3NGdJbnAzQTQmZT0NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPmRtbSBtYWlsaW5nIGxpc3QNCj5kbW1AaWV0Zi5vcmcN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQo= From nobody Tue Jun 26 02:07:14 2018 Return-Path: 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 66890130EC4 for ; Tue, 26 Jun 2018 02:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcn-ssu-ac-kr.20150623.gappssmtp.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 dg51T3oJRImK for ; Tue, 26 Jun 2018 02:07:10 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB4F130934 for ; Tue, 26 Jun 2018 02:07:10 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id n96-v6so4668524lfi.1 for ; Tue, 26 Jun 2018 02:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dcn-ssu-ac-kr.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IvQLcQQbx06qlJ1i6aSwjXYbeiKvbsKUtB8K0NnXZgg=; b=pHF0yZJ1x6+Hl5sJKNWkUH+IX6lLACGTcqidE7mENfqlH+1PspjsbnXOoyAlDZN0aY 45J0mViz8S6cU3gIYGdSgiPutJY1VDxbJ+fREb6xEZfYWuJYDA8CULr78y0f/4NsQiym /yiURUabxgZtoocJvX/aywoww4Nu6QNQSLGDQhbQ6WcZQVuDvIUIMCOPK4a7YZfjm+ux JjdCBlsGZsWfH2QdLUN551chD27Qnx5GAPmSWM67panSdUGYEoU68U6C5wsytO+i10VA sz0PgSpYEnSMX5PaftijzU8G/x0fQha/7pJ05bfAuBJozvwiogYSUm0J8pG5wQAwsEEQ w7Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IvQLcQQbx06qlJ1i6aSwjXYbeiKvbsKUtB8K0NnXZgg=; b=aCW85LtAewnz28gusB5p76KsL91AbPEjLvjsYHG/jkiZuxOmGUUJYOEmTtly+wf5lt CrQgd5C1mtq6O+JhHVQlDdpEzpw9NCKruB6bebOrbCVtHMjNSX2oflZIBlL0/B3UVtD6 ojv7QbWFTr2Mdl9/FDrS/Gr0KcUG5cRU9ue+oYl2M7nZQ4ssI2sA6nZCB8xw8KvQO20i QHGzana/3xpAsgu6lQX/JpLM+gWFcCax2YgBBjEqos/6sbrR6cTcnUKEQbZorMdveUVo C33OSIK9Vab2UJcDYpNDgjB5beBgiZeBfJRmvt1X6sUnj2kF01EXFbWmuwmjz6NyX0Bo 74bQ== X-Gm-Message-State: APt69E0gmPa40OirWGtjQIVfBBefkcTAXTMJKDXELfhfmN8Qs5MNV4Eo 0huxJRrGhB6ScIcBsB8CiyjvqPl9XgG1TOJhzCmMGA== X-Google-Smtp-Source: AAOMgpf1mLwRKQuBObFZKZ/GRHlHsTpJSzp6FOD64Iq+deM8zuHep3PjxIZVqda6qf1wZBnkYgedW2MhaxJzKqYqbRE= X-Received: by 2002:a19:169f:: with SMTP id 31-v6mr627889lfw.72.1530004028447; Tue, 26 Jun 2018 02:07:08 -0700 (PDT) MIME-Version: 1.0 References: <153000350834.1181.1295435230161977542.idtracker@ietfa.amsl.com> In-Reply-To: <153000350834.1181.1295435230161977542.idtracker@ietfa.amsl.com> From: =?UTF-8?B?7ISg6rK97J6s?= Date: Tue, 26 Jun 2018 18:06:56 +0900 Message-ID: To: dmm@ietf.org Content-Type: multipart/alternative; boundary="0000000000009eec8f056f87d232" Archived-At: Subject: [DMM] Fwd: New Version Notification for draft-sun-dmm-ondemand-cp-orchestration-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 09:07:12 -0000 --0000000000009eec8f056f87d232 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, here is a new draft for on-demand DMM control plane orchestration. Main focus in this document is to specify functionalities of Mobility Controller for on-demand CP orchestration model defined in [dmm-deployment-models]. I hope you to read this draft and review its direction for validity. Any comments and feedbacks are welcome. Thanks, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D *=EC=84=A0=EA=B2=BD=EC=9E=AC / Kyoungjae Sun* =EB=B0=95=EC=82=AC=EA=B3=BC=EC=A0=95 / =EC=88=AD=EC=8B=A4=EB=8C=80=ED=95=99= =EA=B5=90 =EB=B6=84=EC=82=B0 =EC=BB=B4=ED=93=A8=ED=8C=85/=EB=84=A4=ED=8A=B8= =EC=9B=8C=ED=82=B9 =EC=97=B0=EA=B5=AC=EC=8B=A4 Ph.D Student in Distributed Computing and Networking Laboratory / Soongsil University Office : +82-2-820-0841 Phone : +82-10-3643-5627 Email : gomjae@dcn.ssu.ac.kr =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------- Forwarded message --------- From: Date: 2018=EB=85=84 6=EC=9B=94 26=EC=9D=BC (=ED=99=94) =EC=98=A4=ED=9B=84 5= :58 Subject: New Version Notification for draft-sun-dmm-ondemand-cp-orchestration-00.txt To: gomjae@dcn.ssu.ac.kr , Seil Jeon < sijeon@dcn.ssu.ac.kr>, Young-Han Kim A new version of I-D, draft-sun-dmm-ondemand-cp-orchestration-00.txt has been successfully submitted by Kyoungjae Sun and posted to the IETF repository. Name: draft-sun-dmm-ondemand-cp-orchestration Revision: 00 Title: On-demand DMM control plane orchestration Document date: 2018-06-26 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-sun-dmm-ondemand-cp-orchestratio= n-00.txt Status: https://datatracker.ietf.org/doc/draft-sun-dmm-ondemand-cp-orchestration/ Htmlized: https://tools.ietf.org/html/draft-sun-dmm-ondemand-cp-orchestration-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-sun-dmm-ondemand-cp-orchestrati= on Abstract: This document describes the required functionalities of mobility controller in the management and orchestration perspective for the on-demand DMM service. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000009eec8f056f87d232 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, here is a new draft for on-demand DMM control plane or= chestration.

Main focus in this document is to specify f= unctionalities of Mobility Controller for on-demand CP orchestration model = defined in [dmm-deployment-models].

I hope you to = read this draft and review its direction for validity.

=
Any comments and feedbacks are welcome.

Thank= s,

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

=EC=84=A0=EA=B2=BD=EC=9E=AC / Kyoungjae Sun


=EB=B0=95=EC=82=AC=EA= =B3=BC=EC=A0=95 / =EC=88=AD=EC=8B=A4=EB=8C=80=ED=95=99=EA=B5=90 =EB=B6=84= =EC=82=B0 =EC=BB=B4=ED=93=A8=ED=8C=85/=EB=84=A4= =ED=8A=B8=EC=9B=8C=ED=82=B9 =EC=97=B0=EA=B5=AC=EC=8B=A4

Ph= .D Student in Distributed Computing and Networking Laboratory / Soongsil University

Of= fice : +82-2-820-0841=C2=A0=C2=A0=C2=A0 Phone : +82-10-3643-5627

Em= ail : gomjae@dcn.= ssu.ac.kr

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D



---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: 2018=EB=85=84 6=EC=9B= =94 26=EC=9D=BC (=ED=99=94) =EC=98=A4=ED=9B=84 5:58
Subject: New Version= Notification for draft-sun-dmm-ondemand-cp-orchestration-00.txt
To: gomjae@dcn.ssu.ac.kr= <gomjae@d= cn.ssu.ac.kr>, Seil Jeon <sijeon@dcn.ssu.ac.kr>, Young-Han Kim <younghak@ssu.ac.kr>=



A new version of I-D, draft-sun-dmm-ondemand-cp-orchestration-00.txt
has been successfully submitted by Kyoungjae Sun and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sun-dmm-ondemand-cp-orc= hestration
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On-demand DMM control plane orches= tration
Document date:=C2=A0 2018-06-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-sun= -dmm-ondemand-cp-orchestration-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-sun-dmm-ondemand-cp-or= chestration/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-sun-dmm-ondemand-cp-orchestration-0= 0
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-sun-dmm-ondemand-c= p-orchestration


Abstract:
=C2=A0 =C2=A0This document describes the required functionalities of mobili= ty
=C2=A0 =C2=A0controller in the management and orchestration perspective for= the
=C2=A0 =C2=A0on-demand DMM service.




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

The IETF Secretariat

--0000000000009eec8f056f87d232-- From nobody Tue Jun 26 10:28:48 2018 Return-Path: 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 CDC0C1310E7 for ; Tue, 26 Jun 2018 10:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 i1CjT4a9YcXw for ; Tue, 26 Jun 2018 10:28:43 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7C11310E4 for ; Tue, 26 Jun 2018 10:28:43 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id x6-v6so2842124wmc.3 for ; Tue, 26 Jun 2018 10:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OKNZhSvny2vr4uRZ5c6kaMXWanjpZeS3KTKIMhNbk0s=; b=bFiozt1cfdu7Zjg2DyVLUOFZ2EXhQ83OmmYF8JP3OENYxvfgFp5EEkiWMuEbML64Zs 5gLpEbPoqu0ZkFYbbqU/sgYgZjoOn4oVsPB0NCyTISIZSORuwvq4STed6oCPlS+HWi+z PvFbrAX2zJmeoVFczcgzMCVSbpMjHy+z1+2cjYpQUyn9gpKyio7zuxaSBe0THdvSbkM3 kUdoNFjZo19QL3JY3DHrM6VoU3WGWr0Z/T30U1xk2R8maPVhxRc5Eh6w4k8Fl5N8KuOw oEhuUBgAYu7Lq6v1BZ/CJQ+D3gpUZeVaGUV1fPkELU6bWk1XCV3rFUizsCspmXtjyNyU oa8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OKNZhSvny2vr4uRZ5c6kaMXWanjpZeS3KTKIMhNbk0s=; b=lT9HubEjIjsER0AErwF+hgEZfSA6lndWzGA61VU+E+oKAqYzcCAS0LDJFGPEojm7PI OFxKHI9x84zq6a375Bj4Ki1fnen5PbHzgW5Gtdg0XZke7ugbzkSvJsc/9rcVIqmDjUNB ZYZ41FL7+zFtqjFNe0T+zgsZH84D9YA7PnambPFgYZoe+1559JAA4WY8pLBTVf9FsgUO 1tGvxCMYjQNS1WCJ4h7wwDKVNFKz5L6PPHl6YoI0Hv5W0aDx+KFiqiyhVSkl15imXBfm Tn4MvCh87P9L5IuyGNfziZidvVkd8M9i9lpLqRVyHYfdr1lzvf9B2P1ABynFDygp/64t lcAw== X-Gm-Message-State: APt69E0Zg8S9tykE27US8eyv/ynTamz84HHhG0gFqo8wxim/ZCHK3obz GHlBnKtWMyCTpy2EL+/5SZT1edL48nHwOItLkAL/Bg== X-Google-Smtp-Source: AAOMgpf6HnI6JXR2eowjg7Q5zz4Ks/BHSvlcPKRh5IVNZ9rCR6/+O8FQMZuDCuooldLI7cYaJBCR1V1Ares+DfiRCZU= X-Received: by 2002:a1c:3544:: with SMTP id c65-v6mr2270026wma.32.1530034121455; Tue, 26 Jun 2018 10:28:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:f9d2:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 10:28:40 -0700 (PDT) In-Reply-To: <153003265010.20384.5176914373594303074.idtracker@ietfa.amsl.com> References: <153003265010.20384.5176914373594303074.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Tue, 26 Jun 2018 10:28:40 -0700 Message-ID: To: dmm , ila@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [DMM] Fwd: New Version Notification for draft-herbert-idloc-fast-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 17:28:47 -0000 Hello, This draft is an alternative proposal for to optimize anchorless mobility in identifier-locator protocols. Similar to the hICN proposal, this espouses the idea of carrying path information in data packets instead of relying on mapping databases or mapping caches in the datapath. Data packets carry a locator in FAST tickets (IPv6 options) to use in the return path to the mobile device. This requires some end host implementation (FAST), however it eliminates the need to do a mapping database lookup or mapping cache lookup in the datapath. Also, this protocol independent of the transport layer so it works with any transport protocol and doesn't require any transport state to be maintained in the network. Tom ---------- Forwarded message ---------- From: Date: Tue, Jun 26, 2018 at 10:04 AM Subject: New Version Notification for draft-herbert-idloc-fast-00.txt To: Tom Herbert A new version of I-D, draft-herbert-idloc-fast-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-idloc-fast Revision: 00 Title: Lightweight Identifier-Locator Mapping Using FAST Document date: 2018-06-26 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-herbert-idloc-fast-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-idloc-fast/ Htmlized: https://tools.ietf.org/html/draft-herbert-idloc-fast-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-idloc-fast Abstract: This proposal provides a method to implement identifier to locator mapping in the datapath without the need to access an in-network mapping database or cache. Mappings are encoded in Firewall and Service Tickets (FAST) tickets as locator information. When a packet is sent by a mobile node, a ticket is attached that providers the locator to use in the return path. Peer nodes receive packets with these tickets, cache the tickets in a flow context, and then attach them to packets they send as reflected tickets. When a packet with a reflected ticket enters an identifier-locator domain, the ticket is parsed to extract the locator. That locator is then used to send the packet to the appropriate destination over a network overlay. 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 From nobody Fri Jun 29 02:03:10 2018 Return-Path: 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 6CB74130ECD for ; Fri, 29 Jun 2018 02:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 nHCmE9EgUjUq for ; Fri, 29 Jun 2018 02:03:04 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC90130E75 for ; Fri, 29 Jun 2018 02:03:04 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w5T92vLC005159 for ; Fri, 29 Jun 2018 18:02:57 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 5CD84EA801C for ; Fri, 29 Jun 2018 18:02:57 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 52851EA75A2 for ; Fri, 29 Jun 2018 18:02:57 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 4E9D4400CF7 for ; Fri, 29 Jun 2018 18:02:57 +0900 (JST) References: <153026116863.30377.17188017067841211462.idtracker@ietfa.amsl.com> From: Shunsuke Homma X-Forwarded-Message-Id: <153026116863.30377.17188017067841211462.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 29 Jun 2018 18:03:17 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153026116863.30377.17188017067841211462.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit To: dmm@ietf.org X-TM-AS-MML: disable Archived-At: Subject: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 09:03:08 -0000 Hi, We submitted a new I-D to identify GTP-U specifications and architectural aspects on the 5GS in 3GPP. It also provides evaluation aspects for studying user plane protocol in the 5GS rel.16. This work is corresponding to the User Plane Protocol Study work (Ref. CP-180116). We'd like to suggest to submit this document to 3GPP CT4 as one of replies of the LS. We are planning to share this work with 3GPP in the next 3GPP CT4 meeting which is held on right before the week of IETF102, and report the feedback from 3GPP in the IETF102. Your review and feedback would be appreciated. Best regards, Shunsuke -------- Forwarded Message -------- Subject: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-00.txt Date: Fri, 29 Jun 2018 01:32:48 -0700 From: internet-drafts@ietf.org To: daniel.voyer@bell.ca , Daniel Voyer , Takuya Miyasaka , Satoru Matsushima , Shunsuke Homma A new version of I-D, draft-hmm-dmm-5g-uplane-analysis-00.txt has been successfully submitted by Shunsuke Homma and posted to the IETF repository. Name: draft-hmm-dmm-5g-uplane-analysis Revision: 00 Title: User Plane Protocol and Architectural Analysis on 3GPP 5G System Document date: 2018-06-29 Group: Individual Submission Pages: 28 URL: https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-00.txt Status: https://datatracker.ietf.org/doc/draft-hmm-dmm-5g-uplane-analysis/ Htmlized: https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hmm-dmm-5g-uplane-analysis Abstract: This document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side. 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 From nobody Fri Jun 29 02:23:41 2018 Return-Path: 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 66D65130E15 for ; Fri, 29 Jun 2018 02:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizonwireless.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 n63PtcsskyQM for ; Fri, 29 Jun 2018 02:23:36 -0700 (PDT) Received: from mercury.verizonwireless.com (mercury.verizonwireless.com [162.115.227.109]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994F9128BAC for ; Fri, 29 Jun 2018 02:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1530264216; x=1561800216; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=E3/IMWUKakPeL5SYitGhgRB6AU/XleC17NofhoT5G8I=; b=OFeZQLS9oUny0WRHzHAty9HXAxkElz8DNze2nALHsoqi1GUbcfHJazYg JGA6XifEApAZjpKD3Sw5wOn6QyUX2oeVFEa4xI2S+MX4/U/CcujPRS/C/ YD2xPfKVV9sIep93Fmh01zy92hRew/TvhzpmKb+KzJwT80W8roh9JifvS c=; X-Host: discovery.odc.vzwcorp.com Received: from casac1exh001.uswin.ad.vzwcorp.com ([10.11.218.43]) by mercury.verizonwireless.com with ESMTP/TLS/AES128-SHA256; 29 Jun 2018 09:23:34 +0000 Received: from scwexch01apd.uswin.ad.vzwcorp.com (153.114.130.20) by CASAC1EXH001.uswin.ad.vzwcorp.com (10.11.218.43) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 29 Jun 2018 02:23:33 -0700 Received: from scwexch12apd.uswin.ad.vzwcorp.com (153.114.130.31) by scwexch01apd.uswin.ad.vzwcorp.com (153.114.130.20) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 29 Jun 2018 02:23:32 -0700 Received: from scwexch12apd.uswin.ad.vzwcorp.com ([153.114.130.31]) by scwexch12apd.uswin.ad.vzwcorp.com ([153.114.130.31]) with mapi id 15.00.1365.000; Fri, 29 Jun 2018 02:23:32 -0700 From: "Bogineni, Kalyani" To: "dmm@ietf.org" Thread-Topic: [E] New Version Notification for draft-bogineni-dmm-optimized-mobile-user-plane-01.txt Thread-Index: AQHUD4kwtJLGHXTmvESabXWq9ixtYKR29jkg Date: Fri, 29 Jun 2018 09:23:32 +0000 Message-ID: <8ad685a8cda5463293c7f9b373e78a58@scwexch12apd.uswin.ad.vzwcorp.com> References: <153026349624.30328.12804145323691495084.idtracker@ietfa.amsl.com> In-Reply-To: <153026349624.30328.12804145323691495084.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.11.60.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [DMM] FW: [E] New Version Notification for draft-bogineni-dmm-optimized-mobile-user-plane-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 09:23:40 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBK dW5lIDI5LCAyMDE4IDU6MTIgQU0NClRvOiBBbGJlcnRvIFJvZHJpZ3Vlei1OYXRhbCA8bmF0YWxA Y2lzY28uY29tPjsgRGlubyBGYXJpbmFjY2kgPGZhcmluYWNjaUBnbWFpbC5jb20+OyBUb20gSGVy YmVydCA8dG9tQHF1YW50b25pdW0ubmV0PjsgTHVjYSBNdXNjYXJpZWxsbyA8bHVtdXNjYXJAY2lz Y28uY29tPjsgQm9naW5lbmksIEthbHlhbmkgPEthbHlhbmkuQm9naW5lbmlAVmVyaXpvbldpcmVs ZXNzLmNvbT47IEdpb3Zhbm5hIENhcm9maWdsaW8gPGdjYXJvZmlnQGNpc2NvLmNvbT47IEpvcmRh biBBdWdlIDxqb3JkYW4uYXVnZUBjaXNjby5jb20+OyBBcmFzaG1pZCBBa2hhdmFpbiA8YXJhc2ht aWQuYWtoYXZhaW5AaHVhd2VpLmNvbT47IFBhYmxvIENhbWFyaWxsbyA8cGNhbWFyaWxAY2lzY28u Y29tPjsgU2h1bnN1a2UgSG9tbWEgPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+DQpTdWJq ZWN0OiBbRV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ib2dpbmVuaS1kbW0t b3B0aW1pemVkLW1vYmlsZS11c2VyLXBsYW5lLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1ib2dpbmVuaS1kbW0tb3B0aW1pemVkLW1vYmlsZS11c2VyLXBsYW5lLTAxLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMdWNhIE11c2NhcmllbGxvIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWJvZ2luZW5p LWRtbS1vcHRpbWl6ZWQtbW9iaWxlLXVzZXItcGxhbmUNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlP cHRpbWl6ZWQgTW9iaWxlIFVzZXIgUGxhbmUgU29sdXRpb25zIGZvciA1Rw0KRG9jdW1lbnQgZGF0 ZToJMjAxOC0wNi0yOQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJNjUN ClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJvZ2luZW5pLWRt bS1vcHRpbWl6ZWQtbW9iaWxlLXVzZXItcGxhbmUtMDEudHh0DQpTdGF0dXM6ICAgICAgICANCltL Ql0gDQogaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRib2dpbmVuaS0yRGRtbS0yRG9wdGlt aXplZC0yRG1vYmlsZS0yRHVzZXItMkRwbGFuZV8mZD1Ed0lDYVEmYz11ZEJUUnZGdlhDNURocWc3 VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJnI9SWRpU09EaDhhRFJqZENlR2dkOU16cjJ0c0RB OC1nOTc2eVdCMXNQYmRNbyZtPVVjaWlkeE1oMlhaMURsbXdfbWZ0MlhQWHVfbXpTSmlwR2FxbFd3 cWlQZ2Mmcz0yTHEyNVc5MF8yNk5vT0M5VHdVNnViSUZUaGdKaFU4V1NWcExMM1M1YU5ZJmU9DQpI dG1saXplZDogICAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEYm9naW5lbmktMkRkbW0tMkRv cHRpbWl6ZWQtMkRtb2JpbGUtMkR1c2VyLTJEcGxhbmUtMkQwMSZkPUR3SUNhUSZjPXVkQlRSdkZ2 WEM1RGhxZzdVSHBKbFBwczNtWjNMUnhwYjZfXzBQb21CVFEmcj1JZGlTT0RoOGFEUmpkQ2VHZ2Q5 TXpyMnRzREE4LWc5NzZ5V0Ixc1BiZE1vJm09VWNpaWR4TWgyWFoxRGxtd19tZnQyWFBYdV9telNK aXBHYXFsV3dxaVBnYyZzPWcyRUVUa2VwNUp0MTFjcXVMNkRmaTJjZzFCc3FESmp5RmtHdXdhZ1U5 MVUmZT0NCkh0bWxpemVkOiAgICAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19odG1sX2RyYWZ0LTJE Ym9naW5lbmktMkRkbW0tMkRvcHRpbWl6ZWQtMkRtb2JpbGUtMkR1c2VyLTJEcGxhbmUmZD1Ed0lD YVEmYz11ZEJUUnZGdlhDNURocWc3VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJnI9SWRpU09E aDhhRFJqZENlR2dkOU16cjJ0c0RBOC1nOTc2eVdCMXNQYmRNbyZtPVVjaWlkeE1oMlhaMURsbXdf bWZ0MlhQWHVfbXpTSmlwR2FxbFd3cWlQZ2Mmcz1HX19BMTI5eTNmMmZpMmNTVlliTVN4blhucWhl Z05FdW9UVXlDTW9pOFNvJmU9DQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfcmZjZGlmZi0zRnVy bDItM0RkcmFmdC0yRGJvZ2luZW5pLTJEZG1tLTJEb3B0aW1pemVkLTJEbW9iaWxlLTJEdXNlci0y RHBsYW5lLTJEMDEmZD1Ed0lDYVEmYz11ZEJUUnZGdlhDNURocWc3VUhwSmxQcHMzbVozTFJ4cGI2 X18wUG9tQlRRJnI9SWRpU09EaDhhRFJqZENlR2dkOU16cjJ0c0RBOC1nOTc2eVdCMXNQYmRNbyZt PVVjaWlkeE1oMlhaMURsbXdfbWZ0MlhQWHVfbXpTSmlwR2FxbFd3cWlQZ2Mmcz0zdzZweEw0ZWxx R28tcHE0OXFEZTA0THl3RkU0bVY2LWs3STJpOGIwUXVJJmU9DQoNCkFic3RyYWN0Og0KICAgM0dQ UCBDVDQgaGFzIGFwcHJvdmVkIGEgc3R1ZHkgaXRlbSB0byBzdHVkeSBkaWZmZXJlbnQgbW9iaWxp dHkNCiAgIG1hbmFnZW1lbnQgcHJvdG9jb2xzIGZvciBwb3RlbnRpYWwgcmVwbGFjZW1lbnQgb2Yg R1RQIHR1bm5lbHMgYmV0d2Vlbg0KICAgVVBGcyAoTjkgSW50ZXJmYWNlKSBpbiB0aGUgM0dQUCA1 RyBzeXN0ZW0gYXJjaGl0ZWN0dXJlLg0KDQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGFuIG92 ZXJ2aWV3IG9mIDVHIHN5c3RlbSBhcmNoaXRlY3R1cmUgaW4gdGhlDQogICBjb250ZXh0IG9mIE45 IEludGVyZmFjZSB3aGljaCBpcyB0aGUgc2NvcGUgb2YgdGhlIDNHUFAgQ1Q0IHN0dWR5IGl0ZW0N CiAgIFtDUC0xNzMxNjAtMV0sIFtUUy4yMy41MDEtM0dQUF0sIFtUUy4yMy41MDItM0dQUF0sIFtU Uy4yMy41MDMtM0dQUF0sDQogICBbVFMuMjkuMjQ0LTNHUFBdLCBbVFMuMjkuMjgxLTNHUFBdLCBb VFMuMzguMzAwLTNHUFBdLCBhbmQNCiAgIFtUUy4zOC40MDEtM0dQUF0uDQoNCiAgIEFyY2hpdGVj dHVyZSByZXF1aXJlbWVudHMgZm9yIGV2YWx1YXRpb24gb2YgY2FuZGlkYXRlIHByb3RvY29scyBh cmUNCiAgIHByb3ZpZGVkLiAgT3B0aW1pemF0aW9uIG9mIHRoZSB1c2VyIHBsYW5lIGNhbiBiZSBp biBkaWZmZXJlbnQgd2F5cyAtDQogICBwYWNrZXQgb3ZlcmhlYWQsIHRyYW5zcG9ydCBpbnRlZ3Jh dGlvbiwgZXRjLg0KDQogICBTZXZlcmFsIElFVEYgcHJvdG9jb2xzIGFyZSBjb25zaWRlcmVkIGZv ciBjb21wYXJpc29uOiBTUnY2LCBMSVNQLCBJTEENCiAgIGFuZCBzZXZlcmFsIGNvbWJpbmF0aW9u cyBvZiBjb250cm9sIHBsYW5lIGFuZCB1c2VyIHBsYW5lIHByb3RvY29scy4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Jun 29 02:32:39 2018 Return-Path: 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 C766B128BAC for ; Fri, 29 Jun 2018 02:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizonwireless.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 ujFC922mBx9r for ; Fri, 29 Jun 2018 02:32:35 -0700 (PDT) Received: from mercury.verizonwireless.com (mercury.verizonwireless.com [162.115.227.109]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF0C1277D2 for ; Fri, 29 Jun 2018 02:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1530264755; x=1561800755; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S8Z9tNFWztAFGYbL92hOe9T34Lb1PJ4SW9Kpizn4eCs=; b=SWEve3rj4Y3cadEuZ2LW0ksIOtJ6vV0+IzCXQBjwfnb/mJVlVyR59+iV kTxrTy4V+aQQr3laJh1AIxkTdXu0TKRDhEQEeoMA+F9oOA0jRqFh83dO0 AYe/a7m5pUnrR+yOpVz+snv/v9ZjN802T/wu3S00J99peYgWZMsRPo59w Q=; X-Host: ranger.odc.vzwcorp.com Received: from casac1exh002.uswin.ad.vzwcorp.com ([10.11.218.44]) by mercury.verizonwireless.com with ESMTP/TLS/AES128-SHA256; 29 Jun 2018 09:32:34 +0000 Received: from scwexch09apd.uswin.ad.vzwcorp.com (153.114.130.28) by CASAC1EXH002.uswin.ad.vzwcorp.com (10.11.218.44) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 29 Jun 2018 02:32:33 -0700 Received: from scwexch12apd.uswin.ad.vzwcorp.com (153.114.130.31) by scwexch09apd.uswin.ad.vzwcorp.com (153.114.130.28) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 29 Jun 2018 02:32:32 -0700 Received: from scwexch12apd.uswin.ad.vzwcorp.com ([153.114.130.31]) by scwexch12apd.uswin.ad.vzwcorp.com ([153.114.130.31]) with mapi id 15.00.1365.000; Fri, 29 Jun 2018 02:32:32 -0700 From: "Bogineni, Kalyani" To: "dmm@ietf.org" Thread-Topic: [E] New Version Notification for draft-bogineni-dmm-optimized-mobile-user-plane-01.txt Thread-Index: AQHUD4kwtJLGHXTmvESabXWq9ixtYKR29jkggAAAgDCAAAJF0A== Date: Fri, 29 Jun 2018 09:32:32 +0000 Message-ID: <5ee76a164ba34ba88d4b193bc7641b39@scwexch12apd.uswin.ad.vzwcorp.com> References: <153026349624.30328.12804145323691495084.idtracker@ietfa.amsl.com> <8ad685a8cda5463293c7f9b373e78a58@scwexch12apd.uswin.ad.vzwcorp.com> <789c7b68d85644e2bb175fb314a7c3f2@scwexch12apd.uswin.ad.vzwcorp.com> In-Reply-To: <789c7b68d85644e2bb175fb314a7c3f2@scwexch12apd.uswin.ad.vzwcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.11.60.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [DMM] FW: [E] New Version Notification for draft-bogineni-dmm-optimized-mobile-user-plane-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 09:32:38 -0000 SGk6DQoNCkFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgb3B0aW1pemVkIG1vYmlsZSB1c2VyIHBs YW5lIGRvY3VtZW50IGhhcyBiZWVuIHBvc3RlZC4NClRoaXMgY291bGQgYmUgc2VudCB0byBDVDQg YWxvbmcgd2l0aCB0aGUgcmVwbHkgdG8gdGhlIExTLg0KDQpCZXN0IFJlZ2FyZHMsDQpLYWx5YW5p IGFuZCBjby1hdXRob3JzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogRnJpZGF5LCBKdW5lIDI5LCAyMDE4IDU6MTIgQU0NClRvOiBBbGJlcnRvIFJvZHJpZ3Vl ei1OYXRhbCA8bmF0YWxAY2lzY28uY29tPjsgRGlubyBGYXJpbmFjY2kgPGZhcmluYWNjaUBnbWFp bC5jb20+OyBUb20gSGVyYmVydCA8dG9tQHF1YW50b25pdW0ubmV0PjsgTHVjYSBNdXNjYXJpZWxs byA8bHVtdXNjYXJAY2lzY28uY29tPjsgQm9naW5lbmksIEthbHlhbmkgPEthbHlhbmkuQm9naW5l bmlAVmVyaXpvbldpcmVsZXNzLmNvbT47IEdpb3Zhbm5hIENhcm9maWdsaW8gPGdjYXJvZmlnQGNp c2NvLmNvbT47IEpvcmRhbiBBdWdlIDxqb3JkYW4uYXVnZUBjaXNjby5jb20+OyBBcmFzaG1pZCBB a2hhdmFpbiA8YXJhc2htaWQuYWtoYXZhaW5AaHVhd2VpLmNvbT47IFBhYmxvIENhbWFyaWxsbyA8 cGNhbWFyaWxAY2lzY28uY29tPjsgU2h1bnN1a2UgSG9tbWEgPGhvbW1hLnNodW5zdWtlQGxhYi5u dHQuY28uanA+DQpTdWJqZWN0OiBbRV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1ib2dpbmVuaS1kbW0tb3B0aW1pemVkLW1vYmlsZS11c2VyLXBsYW5lLTAxLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ib2dpbmVuaS1kbW0tb3B0aW1pemVkLW1vYmlsZS11 c2VyLXBsYW5lLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMdWNh IE11c2NhcmllbGxvIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJ CWRyYWZ0LWJvZ2luZW5pLWRtbS1vcHRpbWl6ZWQtbW9iaWxlLXVzZXItcGxhbmUNClJldmlzaW9u OgkwMQ0KVGl0bGU6CQlPcHRpbWl6ZWQgTW9iaWxlIFVzZXIgUGxhbmUgU29sdXRpb25zIGZvciA1 Rw0KRG9jdW1lbnQgZGF0ZToJMjAxOC0wNi0yOQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOgkJNjUNClVSTDogICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1i b2dpbmVuaS1kbW0tb3B0aW1pemVkLW1vYmlsZS11c2VyLXBsYW5lLTAxLnR4dA0KU3RhdHVzOiAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9naW5lbmktZG1t LW9wdGltaXplZC1tb2JpbGUtdXNlci1wbGFuZS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm9naW5lbmktZG1tLW9wdGltaXplZC1tb2JpbGUtdXNl ci1wbGFuZS0wMQ0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtYm9naW5lbmktZG1tLW9wdGltaXplZC1tb2JpbGUtdXNlci1wbGFuZQ0K RGlmZjogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib2dp bmVuaS1kbW0tb3B0aW1pemVkLW1vYmlsZS11c2VyLXBsYW5lLTAxDQoNCkFic3RyYWN0Og0KICAg M0dQUCBDVDQgaGFzIGFwcHJvdmVkIGEgc3R1ZHkgaXRlbSB0byBzdHVkeSBkaWZmZXJlbnQgbW9i aWxpdHkNCiAgIG1hbmFnZW1lbnQgcHJvdG9jb2xzIGZvciBwb3RlbnRpYWwgcmVwbGFjZW1lbnQg b2YgR1RQIHR1bm5lbHMgYmV0d2Vlbg0KICAgVVBGcyAoTjkgSW50ZXJmYWNlKSBpbiB0aGUgM0dQ UCA1RyBzeXN0ZW0gYXJjaGl0ZWN0dXJlLg0KDQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGFu IG92ZXJ2aWV3IG9mIDVHIHN5c3RlbSBhcmNoaXRlY3R1cmUgaW4gdGhlDQogICBjb250ZXh0IG9m IE45IEludGVyZmFjZSB3aGljaCBpcyB0aGUgc2NvcGUgb2YgdGhlIDNHUFAgQ1Q0IHN0dWR5IGl0 ZW0NCiAgIFtDUC0xNzMxNjAtMV0sIFtUUy4yMy41MDEtM0dQUF0sIFtUUy4yMy41MDItM0dQUF0s IFtUUy4yMy41MDMtM0dQUF0sDQogICBbVFMuMjkuMjQ0LTNHUFBdLCBbVFMuMjkuMjgxLTNHUFBd LCBbVFMuMzguMzAwLTNHUFBdLCBhbmQNCiAgIFtUUy4zOC40MDEtM0dQUF0uDQoNCiAgIEFyY2hp dGVjdHVyZSByZXF1aXJlbWVudHMgZm9yIGV2YWx1YXRpb24gb2YgY2FuZGlkYXRlIHByb3RvY29s cyBhcmUNCiAgIHByb3ZpZGVkLiAgT3B0aW1pemF0aW9uIG9mIHRoZSB1c2VyIHBsYW5lIGNhbiBi ZSBpbiBkaWZmZXJlbnQgd2F5cyAtDQogICBwYWNrZXQgb3ZlcmhlYWQsIHRyYW5zcG9ydCBpbnRl Z3JhdGlvbiwgZXRjLg0KDQogICBTZXZlcmFsIElFVEYgcHJvdG9jb2xzIGFyZSBjb25zaWRlcmVk IGZvciBjb21wYXJpc29uOiBTUnY2LCBMSVNQLCBJTEENCiAgIGFuZCBzZXZlcmFsIGNvbWJpbmF0 aW9ucyBvZiBjb250cm9sIHBsYW5lIGFuZCB1c2VyIHBsYW5lIHByb3RvY29scy4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Jun 29 07:31:58 2018 Return-Path: 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 0A501130DC5 for ; Fri, 29 Jun 2018 07:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 hWpg1r0rumFP for ; Fri, 29 Jun 2018 07:31:53 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 EC0F5130DD0 for ; Fri, 29 Jun 2018 07:31:52 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 87E40FCCDD0B8 for ; Fri, 29 Jun 2018 15:31:48 +0100 (IST) Received: from YYZEML703-CHM.china.huawei.com (10.218.33.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 29 Jun 2018 15:31:49 +0100 Received: from YYZEML702-CHM.china.huawei.com ([169.254.6.148]) by YYZEML703-CHM.china.huawei.com ([169.254.5.8]) with mapi id 14.03.0382.000; Fri, 29 Jun 2018 10:31:48 -0400 From: Arashmid Akhavain To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" Thread-Topic: [DMM] New Liaison Statement, "CP-173160: New Study Item on User Plane Protocol in 5GC" Thread-Index: AQHUCkVqpr0X0I4hEU2E4wqxMx49W6R3VCVQ Date: Fri, 29 Jun 2018 14:31:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.61.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on User Plane Protocol in 5GC" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 14:31:56 -0000 SGkgU3JpLA0KVGhlcmUgdHdvIGRyYWZ0cyB0aGF0IERNTSBjYW4gcGVyaGFwcyB1c2UgaW4gdGhl IHJlc3BvbnNlLiANCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWhtbS1kbW0tNWctdXBsYW5lLWFuYWx5c2lzLTAwLnR4dA0KaHR0cDovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1ib2dpbmVuaS1kbW0tb3B0aW1pemVkLW1vYmlsZS11c2VyLXBsYW5lLTAxLnR4dA0K DQpQbGVhc2UgbGV0IHVzIGtub3cgaG93IHlvdSB3b3VsZCBsaWtlIHRvIHByb2NlZWQgYW5kIGhv dyB3ZSBjYW4gaGVscC4NCg0KQXJhc2htaWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFNyaSBHdW5kYXZlbGxpDQo+IChzZ3VuZGF2ZSkNCj4gU2VudDogMjIgSnVuZSAyMDE4IDEyOjI0 DQo+IFRvOiBkbW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtETU1dIE5ldyBMaWFpc29uIFN0 YXRlbWVudCwgIkNQLTE3MzE2MDogTmV3IFN0dWR5IEl0ZW0gb24NCj4gVXNlciBQbGFuZSBQcm90 b2NvbCBpbiA1R0MiDQo+IA0KPiBGb2xrcyAtIEJhY2sgdG8gdGhpcy4NCj4gDQo+IEFueSBmZWVk YmFjayBvbiB0aGlzPyBOb3cgdGhhdCB3ZSBoYXZlIHdhaXRlZCBmb3Igc29tZSB0aW1lLCBJIGhv cGUgd2UNCj4gbm93IGhhdmUgYSB2aWV3IG9uIHRoaXMgTFMuIEkgdGVuZCB0byB0aGluayB3ZSBz aG91bGQgc2VuZCBhIHJlc3BvbnNlIHNvb24NCj4gYmVmb3JlIHRoZSBKdWx5IGRlYWRsaW5lLg0K PiANCj4gU3JpDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBPbiA0LzE2LzE4LCA5OjQ3 IEFNLCAiZG1tIG9uIGJlaGFsZiBvZiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIg0KPiA8ZG1t LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHNndW5kYXZlQGNpc2NvLmNvbT4gd3JvdGU6 DQo+IA0KPiA+SGkgQXJhc2htaWQsDQo+ID4NCj4gPkkgd2FzIG5vdCBsb29raW5nIGF0IHRoZWly IEp1bHkgZGF0ZSwgYnV0IG1vcmUgYWJvdXQgZXhjaGFuZ2luZyBzdGF0dXMNCj4gPm9mIHRoZSB3 b3JrIGFuZCBzZWVrIGZlZWRiYWNrLg0KPiA+DQo+ID5JIHRoaW5rLCB3ZSBub3cgYXJlIG9uIHRo ZSBzYW1lIHBhZ2Ugbm93Lg0KPiA+DQo+ID5TcmkNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+T24g NC8xNi8xOCwgODozNyBBTSwgIkFyYXNobWlkIEFraGF2YWluIg0KPiA8YXJhc2htaWQuYWtoYXZh aW5AaHVhd2VpLmNvbT4NCj4gPndyb3RlOg0KPiA+DQo+ID4+VGhhbmtzIEthbHlhbmksDQo+ID4+ VGhhdCBtYWtlcyBzZW5zZS4gVGhlIHdvcmRpbmcgb2YgdGhlIGFjdGlvbiBpdGVtIHRob3VnaCBz b3VuZGVkIGxpa2UNCj4gPj4zR1BQIHdhcyB0cnlpbmcgdG8gaW1wb3NlIGEgZGVhZGxpbmUuDQo+ ID4+SSBqdXN0IHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgd2Fzbid0IHRoZSBjYXNlIGNhdXNlIHRo ZXJlIGlzIHN0aWxsIGENCj4gPj5sb3Qgb2Ygd29yayB0byBiZSBkb25lLg0KPiA+Pg0KPiA+PkFy YXNobWlkDQo+ID4+DQo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJv bTogQm9naW5lbmksIEthbHlhbmkNCj4gPj4+IFttYWlsdG86S2FseWFuaS5Cb2dpbmVuaUBWZXJp em9uV2lyZWxlc3MuY29tXQ0KPiA+Pj4gU2VudDogMTYgQXByaWwgMjAxOCAxMToyNg0KPiA+Pj4g VG86IEFyYXNobWlkIEFraGF2YWluIDxhcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tPjsgU3Jp DQo+IEd1bmRhdmVsbGkNCj4gPj4+IChzZ3VuZGF2ZSkgPHNndW5kYXZlQGNpc2NvLmNvbT47IGRt bUBpZXRmLm9yZw0KPiA+Pj4gU3ViamVjdDogUkU6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIkNQ LTE3MzE2MDogTmV3IFN0dWR5IEl0ZW0gb24NCj4gPj4+IFVzZXIgUGxhbmUgUHJvdG9jb2wgaW4g NUdDIg0KPiA+Pj4NCj4gPj4+IEFyYXNobWlkIC0gQ1Q0IHdpbGwgc3RhcnQgdGhlaXIgc3R1ZHkg aW4gSnVseSAyMDE4LiBTbyB3b3JrIGZyb20NCj4gPj4+SUVURiBjYW4gIHByb3ZpZGUgaW5wdXQg aW50byB0aGF0IHN0dWR5Lg0KPiA+Pj4gS2FseWFuaQ0KPiA+Pj4NCj4gPj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEFyYXNobWlkDQo+ID4+PkFraGF2YWluDQo+ID4+PiBTZW50OiBN b25kYXksIEFwcmlsIDE2LCAyMDE4IDExOjIxIEFNDQo+ID4+PiBUbzogU3JpIEd1bmRhdmVsbGkg KHNndW5kYXZlKSA8c2d1bmRhdmVAY2lzY28uY29tPjsgZG1tQGlldGYub3JnDQo+ID4+PiBTdWJq ZWN0OiBbRV0gUmU6IFtETU1dIE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIkNQLTE3MzE2MDogTmV3 IFN0dWR5DQo+ID4+Pkl0ZW0gIG9uIFVzZXIgUGxhbmUgUHJvdG9jb2wgaW4gNUdDIg0KPiA+Pj4N Cj4gPj4+IEhpIFNyaSwNCj4gPj4+DQo+ID4+PiBUaGFuayB5b3UgZm9yIGNsYXJpZmljYXRpb24u IEkgbmV2ZXIgc3VnZ2VzdGVkIHRoYXQgSUVURiBzaG91bGQNCj4gPj4+c2luZ2xlIG91dCBhICBw YXJ0aWN1bGFyIHByb3Bvc2FsLiBPbiB0aGUgY29udHJhcnksIEkgYmVsaWV2ZSBETU0NCj4gPj4+ c2hvdWxkIHNpbXBseSBjb25kdWN0ICB0aGUgc3R1ZHkgYW5kIHByb3ZpZGUgM0dQUCB3aXRoIGFs bCBkaWZmZXJlbnQNCj4gPj4+b3B0aW9ucy4gM0dQUCB3aWxsIGRlY2lkZSB3aGF0ICB0byBkbyB3 aXRoIHRoZSBwcm9wb3NhbHMgZnJvbSB0aGF0DQo+ID4+PnBvaW50IG9uLiBBcyB5b3UgbWVudGlv bmVkIHRoZXJlIGNvdWxkICBiZSBzZXZlcmFsIGJhY2sgYW5kIGZvcnRoDQo+ID4+PmJldHdlZW4g dGhlIHR3byBTRE9zLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gU28sIHdoaWxlIEkgYWdy ZWUgd2l0aCBhbGwgcG9pbnRzLCBJIGFtIHN0aWxsIHB1enpsZWQgYnkgdGhlDQo+ID4+PmZvbGxv d2luZyBzdGF0ZW1lbnQgIGluIDNHUFAgZW1haWwuDQo+ID4+Pg0KPiA+Pj4gV2hhdCBpcyB0aGUg c2lnbmlmaWNhbmNlIG9mIHRoZSBKdWx5IDIwMTggZGF0ZT8NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+IEFDVElPTjoNCj4gPj4+DQo+ID4+PiBDVDQgcmVzcGVjdGZ1bGx5IGFza3MgSUVURiBE TU0gdG8gcHJvdmlkZSBhbnkgaW5mb3JtYXRpb24gdGhhdCBtYXkNCj4gPj4+IGJlIHJlbGV2YW50 IHRvIHRoZSBhYm92ZSBDVDQNCj4gPj4+DQo+ID4+PiB3b3JrIGJ5IEp1bHkgMjAxOC4NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFyYXNobWlkDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+ PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pg0KPiA+Pj4gPiBGcm9tOiBTcmkg R3VuZGF2ZWxsaSAoc2d1bmRhdmUpIFttYWlsdG86c2d1bmRhdmVAY2lzY28uY29tXQ0KPiA+Pj4N Cj4gPj4+ID4gU2VudDogMTMgQXByaWwgMjAxOCAxOTowNg0KPiA+Pj4NCj4gPj4+ID4gVG86IEFy YXNobWlkIEFraGF2YWluIDxhcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tPjsNCj4gZG1tQGll dGYub3JnDQo+ID4+Pg0KPiA+Pj4gPiBTdWJqZWN0OiBSZTogTmV3IExpYWlzb24gU3RhdGVtZW50 LCAiQ1AtMTczMTYwOiBOZXcgU3R1ZHkgSXRlbSBvbg0KPiA+Pj5Vc2VyDQo+ID4+Pg0KPiA+Pj4g PiBQbGFuZSBQcm90b2NvbCBpbiA1R0MiDQo+ID4+Pg0KPiA+Pj4gPg0KPiA+Pj4NCj4gPj4+ID4g SGkgQXJhc2htaWQsDQo+ID4+Pg0KPiA+Pj4gPg0KPiA+Pj4NCj4gPj4+ID4NCj4gPj4+DQo+ID4+ PiA+IEkgYW0gbm90IHNlZWluZyBhIHJlbGF0aW9uIHRvIHRoZSBMUyBSZXNwb25zZSBhbmQgdGhl IEp1bHkgMjAxOA0KPiA+Pj5kZWFkbGluZQ0KPiA+Pj4gdGhhdA0KPiA+Pj4NCj4gPj4+ID4geW91 IGFyZSByZWZlcnJpbmcgdG8uIEkgdGhpbmsgdGhlcmUgaXMgc29tZSBkaXNjb25uZWN0IGhlcmUu IExldHMNCj4gPj4+cmV2aWV3IHdoYXQNCj4gPj4+DQo+ID4+PiA+IHdlIHRoZSBjaGFpcnMgYXJl IHRoaW5raW5nLg0KPiA+Pj4NCj4gPj4+ID4NCj4gPj4+DQo+ID4+PiA+DQo+ID4+Pg0KPiA+Pj4g PiAxLiBUaGUgd29yayBpbiBJRVRGIHJlbGF0ZWQgdG8gVXNlci1QbGFuZSBvcHRpbWl6YXRpb25z IHdpbGwNCj4gPj4+ID4gY29udGludWUNCj4gPj4+Zm9yDQo+ID4+PiBtYW55DQo+ID4+Pg0KPiA+ Pj4gPiBtb250aHMuIFdoZW4gdGhlcmUgaXMgYSBMUyBSZXF1ZXN0LCB3ZSB3aWxsIHNlbmQgYSBM UyByZXNwb25zZS4gV2UNCj4gPj4+d2lsbCB1c2UNCj4gPj4+DQo+ID4+PiA+IExTIHF1ZXJ5L3Jl c3BvbnNlIGFzIGEgbWVhbnMgdG8gZ2F0aGVyIGZlZWRiYWNrIGZyb20gdGhlIFNETw0KPiA+Pj5j b21tdW5pdHksDQo+ID4+Pg0KPiA+Pj4gPiBhbmQgcHJvdmlkZSBhbiB1cGRhdGUgb24gdGhlIHN0 YXR1cyBvZiBhbGwgdGhlIGRvY3VtZW50cyBpbiBETU0gYXQNCj4gPj4+dGhpcw0KPiA+Pj4NCj4g Pj4+ID4gdGltZS4gVGhlIHN0YXR1cyBpbmNsdWRlcyB1cGRhdGUgb24gV0cgZG9jdW1lbnRzIGFu ZCBpbmRpdmlkdWFsDQo+ID4+PiA+IEktROKAmXMNCj4gPj4+IHVuZGVyDQo+ID4+Pg0KPiA+Pj4g PiBkaXNjdXNzaW9ucy4NCj4gPj4+DQo+ID4+PiA+DQo+ID4+Pg0KPiA+Pj4gPiAyLiBXZSBhcmUg bm90IGdvaW5nIHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCB0aGVyZSB3aWxsIG9ubHkgYmUgYQ0K PiA+Pj5zaW5nbGUgTFMNCj4gPj4+DQo+ID4+PiA+IHJlcXVlc3QvcmVzcG9uc2UgZm9yIHRoaXMg ZW50aXJlIFVQIFN0dWR5LCBidXQgd2Ugd2lsbCBrZWVwDQo+ID4+PmV4Y2hhbmdpbmcNCj4gPj4+ DQo+ID4+PiA+IGluZm9ybWF0aW9uIGJhc2VkIG9uIHRoZSBwcm9ncmVzcywgYW5kIHdoZW5ldmVy IHdlIG5lZWQgYWRkaXRpb25hbA0KPiA+Pj4NCj4gPj4+ID4gY2xhcmlmaWNhdGlvbnMuDQo+ID4+ Pg0KPiA+Pj4gPg0KPiA+Pj4NCj4gPj4+ID4gMy4gVGhlcmUgYXJlIG11bHRpcGxlIHByb3Bvc2Fs cyBpbiBJRVRGLiBBcyB3ZSBoYXZlIGluZGljYXRlZCBpbg0KPiA+Pj4gPiB0aGUNCj4gPj4+cGFz dCwgd2UNCj4gPj4+DQo+ID4+PiA+IGFyZSBub3QgZ29pbmcgdG8gcmVjb21tZW5kIFRIRSBzaW5n bGUgc29sdXRpb24gYW5kIHB1dCBpdCBvbiBhDQo+ID4+PnBsYXR0ZXIgZm9yDQo+ID4+Pg0KPiA+ Pj4gPiAzR1BQIGNvbnN1bXB0aW9uLCBidXQgcmF0aGVyIHRoZSBmb2N1cyB3aWxsIGJlIG9uIGNo YXJhY3Rlcml6YXRpb24NCj4gPj4+ID4gb2YNCj4gPj4+ZWFjaA0KPiA+Pj4NCj4gPj4+ID4gYXBw cm9hY2ggdGhhdCB3ZSB0YWtlIHVwIGluIERNTSBXRy4NCj4gPj4+DQo+ID4+PiA+DQo+ID4+Pg0K PiA+Pj4gPiBOb3csIGtlZXBpbmcgdGhpcyBpbiBtaW5kLCBpZiB0aGVyZSBpcyBhIGdvb2QgcmVh c29uIG5vdCB0byBzZW5kDQo+ID4+PiA+IHRoZQ0KPiA+Pj5MUw0KPiA+Pj4NCj4gPj4+ID4gUmVz cG9uc2Ugbm93LCBkZWxheSBpdCBieSBzb21lIHRpbWUsIG9yIGlmIHdlIGJlbGlldmUgdGhlcmUg aXMNCj4gPj4+bm90aGluZyB0bw0KPiA+Pj4NCj4gPj4+ID4gcmVzcG9uZCwgd2UgY2FuIGRpc2N1 c3MgYW5kIGRlY2lkZSB0byBkbyBqdXN0IHRoYXQuIEhvcGUgdGhpcw0KPiA+Pj4gPiBtYWtlcw0K PiA+Pj5zZW5zZS4NCj4gPj4+DQo+ID4+PiA+DQo+ID4+Pg0KPiA+Pj4gPiBCb3R0b21saW5lLCBh bGwgZmVlZGJhY2sgaXMgd2VsY29tZSENCj4gPj4+DQo+ID4+PiA+DQo+ID4+Pg0KPiA+Pj4gPg0K PiA+Pj4NCj4gPj4+ID4gU3JpDQo+ID4+Pg0KPiA+Pj4gPg0KPiA+Pj4NCj4gPj4+ID4NCj4gPj4+ DQo+ID4+PiA+DQo+ID4+Pg0KPiA+Pj4gPg0KPiA+Pj4NCj4gPj4+ID4gT24gNC8xMy8xOCwgMToz NSBQTSwgIkFyYXNobWlkIEFraGF2YWluIg0KPiA+Pj4NCj4gPj4+ID4gPGFyYXNobWlkLmFraGF2 YWluQGh1YXdlaS5jb20+DQo+ID4+Pg0KPiA+Pj4gPiB3cm90ZToNCj4gPj4+DQo+ID4+PiA+DQo+ ID4+Pg0KPiA+Pj4gPiA+SGkgU3JpLA0KPiA+Pj4NCj4gPj4+ID4gPlRoYW5rIHlvdSBmb3IgZ2V0 dGluZyBiYWNrIHRvIHVzLiBUaGV5IGxpc3RlZCBhIGZldyBkYXRlcyB0aGVyZS4NCj4gPj4+ID4g PlRoZQ0KPiA+Pj4NCj4gPj4+ID4gPmZpbmFsIGRlYWRsaW5lIGlzIEkgZ3Vlc3MgSnVseSAyMDE4 Lg0KPiA+Pj4NCj4gPj4+ID4gPkFyZSB3ZSB0YXJnZXRpbmcgYW55dGhpbmcgZWFybGllcj8NCj4g Pj4+DQo+ID4+PiA+ID4NCj4gPj4+DQo+ID4+PiA+ID5BcmFzaG1pZA0KPiA+Pj4NCj4gPj4+ID4g Pg0KPiA+Pj4NCj4gPj4+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+DQo+ ID4+PiA+ID4+IEZyb206IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgW21haWx0bzpzZ3VuZGF2 ZUBjaXNjby5jb21dDQo+ID4+Pg0KPiA+Pj4gPiA+PiBTZW50OiAxMyBBcHJpbCAyMDE4IDEyOjQ3 DQo+ID4+Pg0KPiA+Pj4gPiA+PiBUbzogQXJhc2htaWQgQWtoYXZhaW4gPGFyYXNobWlkLmFraGF2 YWluQGh1YXdlaS5jb20+Ow0KPiA+Pj4gZG1tQGlldGYub3JnDQo+ID4+Pg0KPiA+Pj4gPiA+PiBT dWJqZWN0OiBSZTogTmV3IExpYWlzb24gU3RhdGVtZW50LCAiQ1AtMTczMTYwOiBOZXcgU3R1ZHkg SXRlbQ0KPiA+Pj4gPiA+PiBvbg0KPiA+Pj4NCj4gPj4+ID4gPj4gVXNlciBQbGFuZSBQcm90b2Nv bCBpbiA1R0MiDQo+ID4+Pg0KPiA+Pj4gPiA+Pg0KPiA+Pj4NCj4gPj4+ID4gPj4gSGkgQXJhc2ht aWQsDQo+ID4+Pg0KPiA+Pj4gPiA+Pg0KPiA+Pj4NCj4gPj4+ID4gPj4gV2UgcHJvdmlkZSB0aGUg c3RhdHVzIG9mIHRoZSByZWxhdGVkIHdvcmsgaXRlbXMgaW4gRE1NLCBhbmQNCj4gPj4+ID4gPj4g c2Vlaw0KPiA+Pj5hbnkNCj4gPj4+DQo+ID4+PiA+ID4+Y2xhcmlmaWNhdGlvbnMgb24gdGhlaXIg Q1Q0IHdvcmsuIEtleSB0aGluZyBmcm9tIG91ciBwb2ludCBvZg0KPiA+Pj4gPiA+PnZpZXcNCj4g Pj4+aXMNCj4gPj4+DQo+ID4+PiA+ID4+dG8gZ2V0ICB0aGVpciBmZWVkYmFjayBvbiB0aGUgd29y ayB3ZSBhcmUgZG9pbmcgYW5kIHRyeSB0byBtZWV0DQo+ID4+PnRoZWlyDQo+ID4+Pg0KPiA+Pj4g PiA+PnRpbWVsaW5lcy4NCj4gPj4+DQo+ID4+PiA+ID4+DQo+ID4+Pg0KPiA+Pj4gPiA+PiBTcmkN Cj4gPj4+DQo+ID4+PiA+ID4+DQo+ID4+Pg0KPiA+Pj4gPiA+Pg0KPiA+Pj4NCj4gPj4+ID4gPj4g T24gNC8xMi8xOCwgMTA6NTMgQU0sICJBcmFzaG1pZCBBa2hhdmFpbiINCj4gPj4+DQo+ID4+PiA+ ID4+IDxhcmFzaG1pZC5ha2hhdmFpbkBodWF3ZWkuY29tPg0KPiA+Pj4NCj4gPj4+ID4gPj4gd3Jv dGU6DQo+ID4+Pg0KPiA+Pj4gPiA+Pg0KPiA+Pj4NCj4gPj4+ID4gPj4gPkhpIFNyaSwNCj4gPj4+ DQo+ID4+PiA+ID4+ID4NCj4gPj4+DQo+ID4+PiA+ID4+ID5BbnkgaWRlYSB3aGF0IHRoZSBwbGFu IGlzIG9uY2Ugd2UgcGFzcyB0aGlzIGluZm9ybWF0aW9uIHRvIENUND8NCj4gPj4+DQo+ID4+PiA+ ID4+ID4NCj4gPj4+DQo+ID4+PiA+ID4+ID5BcmFzaG1pZA0KPiA+Pj4NCj4gPj4+ID4gPj4gPg0K PiA+Pj4NCj4gPj4+ID4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+DQo+ ID4+PiA+ID4+ID4+IEZyb206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgU3JpDQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiBHdW5kYXZlbGxpDQo+ID4+Pg0KPiA+ Pj4gPiA+PiA+PiAoc2d1bmRhdmUpDQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiBTZW50OiAxMiBBcHJp bCAyMDE4IDEyOjQ3DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiBUbzogZG1tQGlldGYub3JnDQo+ID4+ Pg0KPiA+Pj4gPiA+PiA+PiBTdWJqZWN0OiBSZTogW0RNTV0gTmV3IExpYWlzb24gU3RhdGVtZW50 LCAiQ1AtMTczMTYwOiBOZXcNCj4gPj4+ID4gPj4gPj4gU3R1ZHkNCj4gPj4+DQo+ID4+PiA+ID4+ ID4+IEl0ZW0gb24gVXNlciBQbGFuZSBQcm90b2NvbCBpbiA1R0MiDQo+ID4+Pg0KPiA+Pj4gPiA+ PiA+Pg0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gUGxlYXNlIHJldmlldyBhbmQgcG9zdCB5b3VyIGNv bW1lbnRzLiBDaGFpcnMgd2lsbCBkcmFmdCBhDQo+ID4+PnJlc3BvbnNlDQo+ID4+Pg0KPiA+Pj4g PiA+PiA+PmZvciBXRyAgcmV2aWV3Lg0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4NCj4gPj4+DQo+ID4+ PiA+ID4+ID4+IFNyaQ0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiBPbiA0LzExLzE4LCAxMToxNiBBTSwgIkxpYWlzb24gU3Rh dGVtZW50IE1hbmFnZW1lbnQgVG9vbCINCj4gPj4+DQo+ID4+PiA+ID4+ID4+IDxsc210QGlldGYu b3JnPg0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+Pg0K PiA+Pj4NCj4gPj4+ID4gPj4gPj4gPlRpdGxlOiBDUC0xNzMxNjA6IE5ldyBTdHVkeSBJdGVtIG9u IFVzZXIgUGxhbmUgUHJvdG9jb2wgaW4NCj4gPj4+ID4gPj4gPj4gPjVHQw0KPiA+Pj4NCj4gPj4+ ID4gPj4gPj4gPlN1Ym1pc3Npb24gRGF0ZTogMjAxOC0wNC0xMSBVUkwgb2YgdGhlIElFVEYgV2Vi IHBhZ2U6DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiA+Pj4NCj4gM0FfX2RhdGF0cmFja2VyLmlldGYub3Jn X2xpYWlzb25fMTU3Ml8mZD1Ed0lHYVEmYz11ZEJUUnZGdlhDNURocWc3VQ0KPiBIDQo+ID4+Pg0K PiBwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJnI9SWRpU09EaDhhRFJqZENlR2dkOU16bkxITVlL Z0tjc19ZUw0KPiB3DQo+ID4+Pg0KPiBYQkRpYW9maDQ3b2lsemFYWVJZRVRjQnluVWRwVCZtPTZf Z0JRTlNKSHN3Y29LMmxndmE5QVY3azg0ZUhzZUQNCj4gNFENCj4gPj4+IHpOcUs1dU92dG8mcz14 WFJ0VFRvVTh2S1RPTEVGekFDdHd6LXlQRi11OHhEMFN3RUtHcldMelIwJmU9DQo+ID4+Pg0KPiA+ Pj4gPiA+PiA+PiA+UGxlYXNlIHJlcGx5IGJ5IDIwMTgtMDctMjANCj4gPj4+DQo+ID4+PiA+ID4+ ID4+ID5Gcm9tOiBTYXRvcnUgTWF0c3VzaGltYQ0KPiA+Pj4gPiA+PiA+PiA+PHNhdG9ydS5tYXRz dXNoaW1hQGcuc29mdGJhbmsuY28uanA+DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+VG86IFNyaSBH dW5kYXZlbGxpIDxzZ3VuZGF2ZUBjaXNjby5jb20+LERhcGVuZyBMaXUNCj4gPj4+DQo+ID4+PiA+ ID4+ID4+ID48bWF4cGFzc2lvbkBnbWFpbC5jb20+DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+Q2M6 IERhcGVuZyBMaXUgPG1heHBhc3Npb25AZ21haWwuY29tPixUZXJyeSBNYW5kZXJzb24NCj4gPj4+ DQo+ID4+PiA+ID4+ID4+ID48dGVycnkubWFuZGVyc29uQGljYW5uLm9yZz4sRGlzdHJpYnV0ZWQg TW9iaWxpdHkNCj4gTWFuYWdlbWVudA0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPkRpc2N1c3Npb24g TGlzdCA8ZG1tQGlldGYub3JnPixTcmkgR3VuZGF2ZWxsaQ0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4g PjxzZ3VuZGF2ZUBjaXNjby5jb20+LFN1cmVzaCBLcmlzaG5hbg0KPiA8c3VyZXNoQGthbG9vbS5j b20+DQo+ID4+Pg0KPiA+Pj4gPiBSZXNwb25zZQ0KPiA+Pj4NCj4gPj4+ID4gPj4gQ29udGFjdHM6 DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+Z2VvcmcubWF5ZXIuaHVhd2VpQGdteC5jb20sM0dQUExp YWlzb25AZXRzaS5vcmcNCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5UZWNobmljYWwgQ29udGFjdHM6 DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+UHVycG9zZTogRm9yIGFjdGlvbg0KPiA+Pj4NCj4gPj4+ ID4gPj4gPj4gPg0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPkJvZHk6IDEuIE92ZXJhbGwgRGVzY3Jp cHRpb246DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+M0dQUCB3b3JraW5nIGdyb3VwIG9mIENUNCAo Q29yZSBhbmQgVGVybWluYWwpIHdvdWxkIGxpa2UgdG8NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5p bmZvcm0gdGhlIElFVEYgdGhhdCBDVDQgaGFzIGluaXRpYXRlZCBhIHN0dWR5IGl0ZW0gb24gdXNl cg0KPiA+Pj5wbGFuZQ0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPnByb3RvY29sIGluIDVHQyBmb3Ig UmVsZWFzZS0xNiBvZiA1RyBwaGFzZSAyIChzZWUgQ1AtMTczMTYwKS4NCj4gPj4+DQo+ID4+PiA+ ID4+ID4+ID4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5CYXNlZCBvbiB0aGUgb3V0Y29tZSBmcm9t IHRoZSBJRVRGIC8gM0dQUCBDb29yZGluYXRpb24NCj4gPj4+ID4gPj4gPj4gPm1lZXRpbmcNCj4g Pj4+YXQNCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5JRVRGIzEwMCwgM0dQUCBDVDQgZ290IGF3YXJl IHRoYXQgSUVURiBETU0gV0cgaXMgY3VycmVudGx5DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+d29y a2luZyBvbiBhIHBvc3NpYmxlIGNhbmRpZGF0ZSBwcm90b2NvbCBmb3IgdGhlIDNHUFAgNUcNCj4g Pj4+ID4gPj4gPj4gPnVzZXINCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5wbGFuZQ0KPiA+Pj4NCj4g Pj4+ID4gPj5wcm90b2NvbC4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID4NCj4gPj4+DQo+ID4+PiA+ ID4+ID4+ID4zR1BQIENUNCB3YW50cyB0byBlbXBoYXNpemUgdGhhdCBjdXJyZW50bHkgdGhlcmUg aXMgbm8NCj4gPj4+ID4gPj4gPj4gPnJlbGF0ZWQNCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5ldmFs dWF0aW9uIG9uZ29pbmcgaW4gM0dQUC4gTmV2ZXJ0aGVsZXNzLCBhIHN0dWR5IGl0ZW0gd2FzDQo+ ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+YXBwcm92ZWQgZm9yIHN1Y2ggYSBzdHVkeSB0byBzdGFydCBp biB0aGUgc2Vjb25kIGhhbGYgb2YgMjAxOC4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5UaGUgc3R1 ZHkgd2lsbCBldmFsdWF0ZSBiZXR3ZWVuIGV4aXN0aW5nIHNvbHV0aW9ucyB3aXRoaW4NCj4gPj4+ ID4gPj4gPj4gPjNHUFANCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5hbmQgb3RoZXIgcHJvdG9jb2xz LCBiYXNlZCBvbiB0aGUgUmVsZWFzZQ0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPjE2IHN0YWdlIDIg KHN5c3RlbSBhcmNoaXRlY3R1cmUpIHJlcXVpcmVtZW50cy4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ ID4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID4zR1BQIENUNCB3b3VsZCBsaWtlIHRvIHBvaW50IElF VEYgRE1NIHRvIHRoZSBmb2xsb3dpbmcNCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5zcGVjaWZpY2F0 aW9ucyBvbiBHVFAtVS4gVGhlIFJlbGVhc2UgMTYgc3RhZ2UgMg0KPiA+Pj4gPiA+PiA+PiA+cmVx dWlyZW1lbnRzDQo+ID4+PmFyZQ0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPm5vdCB5ZXQga25vd24g YnV0IGl0IGlzIHdvcnRoIGxvb2tpbmcgYXQgbGF0ZXN0IEdUUC1VIHNwZWMNCj4gPj4+d2hpY2gN Cj4gPj4+DQo+ID4+PiA+ID4+ID4+ID53aWxsIGJlIGV2YWx1YXRlZCB0aHJvdWdoIHRoZSBzdHVk eSBhcyB0aGUgZXhpc3RpbmcgcHJvdG9jb2wuDQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+DQo+ID4+ Pg0KPiA+Pj4gPiA+PiA+PiA+4oKsCVsxXSAzR1BQIFRTIDI5LjI4MSAoVjE1LjEuMCk6IEdQUlMg VHVubmVsbGluZyBQcm90b2NvbCBVc2VyDQo+ID4+Pg0KPiA+Pj4gPiBQbGFuZQ0KPiA+Pj4NCj4g Pj4+ID4gPj4gPj4gPihHVFB2MS1VKQ0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPg0KPiA+Pj4NCj4g Pj4+ID4gPj4gPj4gPg0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPkZvbGxvd2luZyB0ZWNobmljYWwg cmVwb3J0IHByb3ZpZGVzIGluZm9ybWF0aW9uIG9mIGhvdyAzR1BQDQo+ID4+Pg0KPiA+Pj4gPiA+ PiA+PiA+Y29uc2lkZXJlZCBHVFAtVSBhcHBseSB0byB1c2VyIHBsYW5lIG9mIDVHX3BoMToNCj4g Pj4+DQo+ID4+PiA+ID4+ID4+ID4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID7igqwJWzJdIDNHUFAg VFIgMjkuODkxIChWMTUuMC4wKTogNUcgU3lzdGVtIMKtIFBoYXNlIDE7IENUNA0KPiA+Pj5Bc3Bl Y3RzDQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+DQo+ID4+ Pg0KPiA+Pj4gPiA+PiA+PiA+RnVydGhlcm1vcmUsIDNHUFAgd291bGQgbGlrZSB0byBnaXZlIHRo ZSBmb2xsb3dpbmcgZ2VuZXJhbA0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPmd1aWRhbmNlIHRvIElF VEYgRE1NLCByZWdhcmRpbmcgdXNlciBwbGFuZSB0cmFuc3BvcnQgd2l0aGluDQo+ID4+PjNHUFAN Cj4gPj4+DQo+ID4+PiA+IG5ldHdvcmtzLg0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPlRoZXNlIGFy ZSB0ZWNobmljYWwgc3BlY2lmaWNhdGlvbnMgdGhhdCBpbmNsdWRlIGFsc28gdGhlDQo+ID4+Pg0K PiA+Pj4gPiA+PiA+PiA+bmVjZXNzYXJ5IGluZm9ybWF0aW9uIHRvIHVuZGVyc3RhbmQgd2hpY2gg YXJjaGl0ZWN0dXJhbCwNCj4gPj4+ID4gPj4gPj4gPlFvUywNCj4gPj4+DQo+ID4+PiA+ID4+ID4+ ID5zZWN1cml0eS1yZWxhdGVkIGFuZCBoaWdoLWxldmVsIHJlcXVpcmVtZW50cyBHVFAtVQ0KPiA+ Pj4gPiA+PiA+PiA+Y3VycmVudGx5DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+Y29tcGxpZXMgdG8g d2l0aGluDQo+ID4+Pg0KPiA+Pj4gPiA+PjVHX3BoMS4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID4N Cj4gPj4+DQo+ID4+PiA+ID4+ID4+ID7igqwJWzNdIDNHUFAgVFMgMjMuNTAxIChWMTUuMC4wKTog U3lzdGVtIEFyY2hpdGVjdHVyZSBmb3IgdGhlIDVHDQo+ID4+Pg0KPiA+Pj4gPiA+PlN5c3RlbQ0K PiA+Pj4NCj4gPj4+ID4gPj4gPj4gPuKCrAlbNF0gM0dQUCBUUyAyMy41MDIgKFYxNS4wLjApOiBQ cm9jZWR1cmVzIGZvciB0aGUgNUcgU3lzdGVtDQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+4oKsCVs1 XSAzR1BQIFRTIDIzLjUwMyAoVjE1LjAuMCk6IFBvbGljeSBhbmQgQ2hhcmdpbmcgRnJhbWV3b3Jr DQo+ID4+Pg0KPiA+Pj4gPiBmb3INCj4gPj4+DQo+ID4+PiA+ID4+dGhlDQo+ID4+Pg0KPiA+Pj4g PiA+PiA+PiA1Rw0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPlN5c3RlbQ0KPiA+Pj4NCj4gPj4+ID4g Pj4gPj4gPuKCrAlbNl0gM0dQUCBUUyAzMy41MDEgKFYwLjYuMCk6IFNlY3VyaXR5IEFyY2hpdGVj dHVyZSAod29yayBpbg0KPiA+Pj4NCj4gPj4+ID4gPj5wcm9ncmVzcykNCj4gPj4+DQo+ID4+PiA+ ID4+ID4+ID4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID4yLiBBY3Rpb25zOg0KPiA+Pj4NCj4gPj4+ ID4gPj4gPj4gPlRvIElFVEYgRE1NOg0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPkFDVElPTjogCUNU NCByZXNwZWN0ZnVsbHkgYXNrcyBJRVRGIERNTSB0byBwcm92aWRlIGFueQ0KPiA+Pj4NCj4gPj4+ ID4gaW5mb3JtYXRpb24NCj4gPj4+DQo+ID4+PiA+ID4+ID4+IHRoYXQNCj4gPj4+DQo+ID4+PiA+ ID4+ID4+ID5tYXkgYmUgcmVsZXZhbnQgdG8gdGhlIGFib3ZlIENUNCB3b3JrIGJ5IEp1bHkgMjAx OC4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID4NCj4gPj4+ DQo+ID4+PiA+ID4+ID4+ID4zLiBEYXRlIG9mIE5leHQgQ1QgYW5kIENUNCBNZWV0aW5nczoNCj4g Pj4+DQo+ID4+PiA+ID4+ID4+ID5DVDQjODMJMjZ0aCBGZWIgwq0gMm5kIE1hciAyMDE4CU1vbnRy ZWFsLCBDQU4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5DVCM3OQkxOXRoIMKtIDIwdGggTWFyIDIw MTgJQ2hlbm5haSwgSW5kaWENCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5DVDQjODQJMTZ0aCDCrSAy MHRoIEFwcmlsIDIwMTgJS3VubWluZywgQ2hpbmENCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5DVDQj ODUJMjFzdCDCrSAyNXRoIE1heSAyMDE4CU9zYWthLCBKYXBhbg0KPiA+Pj4NCj4gPj4+ID4gPj4g Pj4gPkNUIzgwCTExdGggwq0gMTJ0aCBKdW5lIDIwMTgJTGEgSm9sbGEsIFVTQQ0KPiA+Pj4NCj4g Pj4+ID4gPj4gPj4gPkNUNCM4NS1iaXMJICA5dGggwq0xM3RoIEp1bHkgMjAxOAlUQkQsIEZyYW5j ZQ0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gPkNUNCM4NgkyMHN0IMKtIDI0dGggQXVnIDIwMTgJVEJE LCBVU0ENCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5BdHRhY2htZW50czoNCj4gPj4+DQo+ID4+PiA+ ID4+ID4+ID4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID4gICAgQ1AtMTgwMTE2DQo+ID4+Pg0KPiA+ Pj4gPiA+PiA+PiA+DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiA+Pj4gM0FfX3d3dy5pZXRmLm9yZ19saWJf ZHRfZG9jdW1lbnRzX0xJQUlTT05fbGlhaXNvbi0yRDIwMTgtMkQwNC0NCj4gMkQxMS0NCj4gPj4+ DQo+IDJEJmQ9RHdJR2FRJmM9dWRCVFJ2RnZYQzVEaHFnN1VIcEpsUHBzM21aM0xSeHBiNl9fMFBv bUJUUSZyPQ0KPiBJZGkNCj4gPj4+DQo+IFNPRGg4YURSamRDZUdnZDlNem5MSE1ZS2dLY3NfWVN3 WEJEaWFvZmg0N29pbHphWFlSWUVUY0J5blVkcFQmDQo+IG0NCj4gPj4+ID02X2dCUU5TSkhzd2Nv SzJsZ3ZhOUFWN2s4NGVIc2VENFF6TnFLNXVPdnRvJnM9Y3prU295dFZGZ2JxLQ0KPiA+Pj4gZlNp TGtwM2FfQlpmby03N3REZ1E3Ql9SdHotT1M4JmU9DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+M2dw DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+cC10DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+c2djDQo+ ID4+Pg0KPiA+Pj4gPiA+PiA+Pg0KPiA+Pj4+dC1jdDQtZG1tLWNwLTE3MzE2MC1uZXctc3R1ZHkt aXRlbS1vbi11c2VyLXBsYW5lLXByb3RvY29sLWluLTVnYy0NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ ID5hdHQNCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5hY2gNCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID5t ZW4NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ID50LTEuZG9jDQo+ID4+Pg0KPiA+Pj4gPiA+PiA+PiA+ DQo+ID4+Pg0KPiA+Pj4gPiA+PiA+Pg0KPiA+Pj4NCj4gPj4+ID4gPj4gPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+DQo+ID4+PiA+ID4+ID4+ IGRtbSBtYWlsaW5nIGxpc3QNCj4gPj4+DQo+ID4+PiA+ID4+ID4+IGRtbUBpZXRmLm9yZw0KPiA+ Pj4NCj4gPj4+ID4gPj4gPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLQ0KPiA+Pj4NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2Rt bSZkPUR3SUdhUSZjPXVkQlRSdkZ2WEM1RGhxDQo+IGc3DQo+ID4+Pg0KPiBVSHBKbFBwczNtWjNM UnhwYjZfXzBQb21CVFEmcj1JZGlTT0RoOGFEUmpkQ2VHZ2Q5TXpuTEhNWUtnS2NzDQo+IF9ZDQo+ ID4+Pg0KPiBTd1hCRGlhb2ZoNDdvaWx6YVhZUllFVGNCeW5VZHBUJm09Nl9nQlFOU0pIc3djb0sy bGd2YTlBVjdrODRlSHMNCj4gZUQNCj4gPj4+DQo+IDRRek5xSzV1T3Z0byZzPVdweHJ3SFdDQmZN NDhKRkhSNGMzV1V2M1VSVm81OWlpSzJ3NGdJbnAzQTQmDQo+IGU9DQo+ID4+Pg0KPiA+Pj4gPiA+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gZG1tIG1haWxpbmcgbGlzdA0KPiA+Pj4gZG1tQGll dGYub3JnDQo+ID4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtDQo+ID4+Pg0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fZG1tJmQ9 RHdJR2FRJmM9dWRCVFJ2RnZYQzVEaHENCj4gZzcNCj4gPj4+DQo+IFVIcEpsUHBzM21aM0xSeHBi Nl9fMFBvbUJUUSZyPUlkaVNPRGg4YURSamRDZUdnZDlNem5MSE1ZS2dLY3MNCj4gX1kNCj4gPj4+ DQo+IFN3WEJEaWFvZmg0N29pbHphWFlSWUVUY0J5blVkcFQmbT02X2dCUU5TSkhzd2NvSzJsZ3Zh OUFWN2s4NGVIcw0KPiBlRA0KPiA+Pj4NCj4gNFF6TnFLNXVPdnRvJnM9V3B4cndIV0NCZk00OEpG SFI0YzNXVXYzVVJWbzU5aWlLMnc0Z0lucDNBNCYNCj4gZT0NCj4gPg0KPiA+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPmRtbSBtYWlsaW5nIGxpc3QN Cj4gPmRtbUBpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kbW0NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IGRtbSBtYWlsaW5nIGxpc3QNCj4gZG1tQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo= From nobody Fri Jun 29 10:03:26 2018 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4187130EF4; Fri, 29 Jun 2018 10:03:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153029178860.30429.18332479637364996892@ietfa.amsl.com> Date: Fri, 29 Jun 2018 10:03:08 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-pmipv6-dlif-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 17:03:18 -0000 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 : Proxy Mobile IPv6 extensions for Distributed Mobility Management Authors : Carlos J. Bernardos Antonio de la Oliva Fabio Giust Juan Carlos Zuniga Alain Mourad Filename : draft-ietf-dmm-pmipv6-dlif-01.txt Pages : 32 Date : 2018-06-29 Abstract: Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centralized deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (as Mobile IPv6), among others. This document follows the former approach, and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called mobility anchor and access router). The mobility anchor and access router is an enhanced access router which is also able to operate as local mobility anchor or mobility access gateway, on a per prefix basis. The document focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-pmipv6-dlif-01 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-pmipv6-dlif-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-pmipv6-dlif-01 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/ From nobody Fri Jun 29 10:08:17 2018 Return-Path: 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 2055D130E1F for ; Fri, 29 Jun 2018 10:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.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 3QMOwAZMTaEw for ; Fri, 29 Jun 2018 10:08:07 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0D5130ECB for ; Fri, 29 Jun 2018 10:08:04 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id p129-v6so3669706ywg.7 for ; Fri, 29 Jun 2018 10:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=b2jZU4qAc3wvC9znlNMrPRPKOLLVQ8B7YQvGVCDFmco=; b=hnPB5Eteqaq2HgVYADpOrTwsAljheYs+jtSfZgkndIrM5K+g+LuhwV8F8j/l7fTZ+g u1/TTwv0NwbZ3WTGpYV+N8ZNXR6GY0+5MLt8J4rFu3N8uSr5ZBaKiPcEvgp9P3GzZkVd oAEiXtFc2zKFnerVqG1Xb4CGTUKaHJF9nNBg9wCOnkfvuFm2NU8DQ2kx2AZRgfvD/BX7 kINCyZmF4R54NgjSZ5bPxMR6AcedyHuEbOo+mU4ZmE/s/KiHecCQaNonoCPqhi6rXhYS Jo9CrUgm06qt1delxjgOvAe5rCXqcp6SuHn9Y/LSOe7+DyM6INSYl0Vt40CrmWTGcj8x y4RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=b2jZU4qAc3wvC9znlNMrPRPKOLLVQ8B7YQvGVCDFmco=; b=B/yjcJCTVBPdHraOQ66o0iJNvigtd8qHN/03b9B4r5Wa1U57STeu/eo8H2zPW5Bx11 JKHXZ4WKk7hoktujsjJluTz4mV1iOs7TD2f6SodlISMTb9AYrPDtkuGSVwwLu6znyFXL uqJHLrEMov6jbSKGuZ2zAu3m6WCv7F5t65/Rwki3PC3zQAxCy4u2Av6WpRb+6B0V8M7u 7Y6nhX91/rAppYnga2xpu6P35eKAZZarUrvBiwlh9p7FdP2tzqJHVef/SKuaGutmA4Q6 AZCShjNA7r45Mb0TT5t1M/SYpjgZBvordwGVbavLFVICAe9t8HKSfr1ySJa4cc05euOy CBJQ== X-Gm-Message-State: APt69E1nT+HsK9bcKUNQ7q48NNJkDfEIFFDDgkmLxNWzxdlD97wnaQBV XmsAiDgUJrnFrVkL1AOVrHW1ebDVdNfLCkIhym4gNQ== X-Google-Smtp-Source: AAOMgpc+5tf3E1LGZt9BFX0WD/HXut7z0CMVzCFGIfkWDn6jYNSxbJe0/PJC+dvqKwHnFDyvARcmAEYaehF4V5UAKP4= X-Received: by 2002:a25:b225:: with SMTP id i37-v6mr3743628ybj.195.1530292083176; Fri, 29 Jun 2018 10:08:03 -0700 (PDT) MIME-Version: 1.0 References: <153029178860.30429.18332479637364996892@ietfa.amsl.com> In-Reply-To: <153029178860.30429.18332479637364996892@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Fri, 29 Jun 2018 19:07:51 +0200 Message-ID: To: dmm Content-Type: multipart/alternative; boundary="000000000000055ae3056fcae485" Archived-At: Subject: [DMM] Fwd: I-D Action: draft-ietf-dmm-pmipv6-dlif-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 17:08:14 -0000 --000000000000055ae3056fcae485 Content-Type: text/plain; charset="UTF-8" Hi, We've just submitted a revised version addressing all the comments we received during the WG adoption call. We have requested some presentation time in Montreal. It'd be awesome if you can take a look and provide comments, so we can have more fruitful discussions during the meeting. Thanks! Carlos ---------- Forwarded message --------- From: Date: vie., 29 jun. 2018 a las 19:04 Subject: I-D Action: draft-ietf-dmm-pmipv6-dlif-01.txt To: Cc: 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 : Proxy Mobile IPv6 extensions for Distributed Mobility Management Authors : Carlos J. Bernardos Antonio de la Oliva Fabio Giust Juan Carlos Zuniga Alain Mourad Filename : draft-ietf-dmm-pmipv6-dlif-01.txt Pages : 32 Date : 2018-06-29 Abstract: Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centralized deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (as Mobile IPv6), among others. This document follows the former approach, and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called mobility anchor and access router). The mobility anchor and access router is an enhanced access router which is also able to operate as local mobility anchor or mobility access gateway, on a per prefix basis. The document focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-pmipv6-dlif-01 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-pmipv6-dlif-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-pmipv6-dlif-01 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --000000000000055ae3056fcae485 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We've just submitted a revised = version addressing all the comments we received during the WG adoption call= .

We have requested some presentation time in Mont= real. It'd be awesome if you can take a look and provide comments, so w= e can have more fruitful discussions during the meeting.

Thanks!

Carlos

---------- Forwarded message ---------
Fro= m: <intern= et-drafts@ietf.org>
Date: vie., 29 jun. 2018 a las 19:04Subject: I-D Action: draft-ietf-dmm-pmipv6-dlif-01.txt
To: <i-d-announce@ietf.org>
Cc: &l= t;dmm@ietf.org>


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Proxy Mobile IPv6 extensions for Distributed Mobility Management
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Carl= os J. Bernardos
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Antonio de la Oliva
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Fabio Giust
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Juan Carlos Zuniga
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Alain Mourad
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmm-pmipv6-dlif-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-06-29

Abstract:
=C2=A0 =C2=A0Distributed Mobility Management solutions allow for setting up=
=C2=A0 =C2=A0networks so that traffic is distributed in an optimal way and = does
=C2=A0 =C2=A0not rely on centralized deployed anchors to provide IP mobilit= y
=C2=A0 =C2=A0support.

=C2=A0 =C2=A0There are many different approaches to address Distributed Mob= ility
=C2=A0 =C2=A0Management, as for example extending network-based mobility pr= otocols
=C2=A0 =C2=A0(like Proxy Mobile IPv6), or client-based mobility protocols (= as
=C2=A0 =C2=A0Mobile IPv6), among others.=C2=A0 This document follows the fo= rmer
=C2=A0 =C2=A0approach, and proposes a solution based on Proxy Mobile IPv6 i= n which
=C2=A0 =C2=A0mobility sessions are anchored at the last IP hop router (call= ed
=C2=A0 =C2=A0mobility anchor and access router).=C2=A0 The mobility anchor = and access
=C2=A0 =C2=A0router is an enhanced access router which is also able to oper= ate as
=C2=A0 =C2=A0local mobility anchor or mobility access gateway, on a per pre= fix
=C2=A0 =C2=A0basis.=C2=A0 The document focuses on the required extensions t= o
=C2=A0 =C2=A0effectively support simultaneously anchoring several flows at<= br> =C2=A0 =C2=A0different distributed gateways.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-dmm-pmipv6-dlif/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dm= m-pmipv6-dlif-01
https://datatracker.ietf.org/doc/= html/draft-ietf-dmm-pmipv6-dlif-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-dmm-pmipv6-dlif-01


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--000000000000055ae3056fcae485--