From nobody Mon May 2 19:02:48 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A140812D53B for ; Mon, 2 May 2016 19:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 MZfloh2_x7nZ for ; Mon, 2 May 2016 19:02:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA2F12D696 for ; Mon, 2 May 2016 19:02:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIZ98968; Tue, 03 May 2016 02:02:42 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 May 2016 03:02:41 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 3 May 2016 10:02:37 +0800 From: Sheng Jiang To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Proposed change to GRASP Thread-Index: AQHRolVqBJWxQM8IhE+Gy831tdxeMJ+mdnyA Date: Tue, 3 May 2016 02:02:37 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.572806C2.008A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 68e87812c9db101c64763cbed09e70f1 Archived-At: Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 02:02:47 -0000 SGksIEJyaWFuICYgU2lnbmFsaW5nIGRlc2lnbiB0ZWFtLA0KDQpUaGFua3MgZm9yIHlvdXIgaGFy ZCB3b3JrIGFuZCB0aGUgbGF0ZXN0IGRlc2lnbi4gSXQgbG9va3MgdXNlZnVsIHRvIHF1aWNrbHkg Y2xhc3NpZnkgb3IgaWRlbnRpZnkgdGhlIEFTQSBpbiB0aGUgcmVjZWl2ZXIgc2lkZS4gSG93ZXZl ciwgbWF5IEkgcHJvcG9zZWQgdGhlIHJlbmFtZSAiR1JBU1AgcG9ydCBudW1iZXIiIHRvIGJlICJB U0EgdHlwZSBudW1iZXIiLCBvciBzb21ldGhpbmcgZWxzZSB3aXRob3V0ICJwb3J0IG51bWJlciI/ IFRoZSBpbnRyb2R1Y3Rpb24gaXMgZWFzaWx5IHRvIGJlIG1pc3JlYWQuIEFjdHVhbGx5LCB5b3Ug aGF2ZSBjcmVhdGVkIGEgbmV3IG5hbWVzcGFjZS4gVGhlIHdvcmQgInRyYW5zcG9ydCBwb3J0IG51 bWJlciIgaXMgbWlzbGVhZGluZy4gV2Ugc2hvdWxkIGhhdmUgYSBtb3JlIGV4cGxpY2l0IG5hbWUu DQoNCk9uZSBxdWVzdGlvbjogZG9lcyB0aGlzIG5ldyBuYW1lc3BhY2UgYWxzbyBuZWVkIHRvIGJl IG1hbmFnZWQgYnkgSUFOQSBvciB0aGVyZSBjb3VsZCBiZSBvdGhlciBtZWNoYW5pc20gdG8gbWFu YWdlIGl0IHNvIHRoYXQgdGhlIHVuaXF1ZW5lc3MgY291bGQgYmUgZ3VhcmFudGVlZD8NCg0KQmVz dCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9t OiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlh biBFDQo+Q2FycGVudGVyDQo+U2VudDogU2F0dXJkYXksIEFwcmlsIDMwLCAyMDE2IDQ6MjYgQU0N Cj5UbzogQW5pbWEgV0cNCj5TdWJqZWN0OiBbQW5pbWFdIFByb3Bvc2VkIGNoYW5nZSB0byBHUkFT UA0KPg0KPkhpLA0KPg0KPlNob3J0IHZlcnNpb246DQo+DQo+V2UgcHJvcG9zZSB0aGF0IHdoZW4g YW4gQVNBIGxpc3RlbnMgZm9yIG5lZ290aWF0aW9uIG9yIHN5bmNocm9uaXphdGlvbg0KPnJlcXVl c3RzLCBpdCBzaG91bGQgZG8gc28gb24gaXRzIG93biB0cmFuc3BvcnQgcG9ydCBudW1iZXIgcmF0 aGVyIHRoYW4gc2hhcmluZw0KPnRoZSBnZW5lcmljIEdSQVNQIHBvcnQgbnVtYmVyIGFzIGN1cnJl bnRseSBkZWZpbmVkLiBUaGUgY29uc2VxdWVuY2UgZm9yIHRoZQ0KPnByb3RvY29sIGlzIHRoYXQg ZGlzY292ZXJ5IHJlc3BvbnNlcyBtdXN0IGluY2x1ZGUgYSBjb21wbGV0ZSB0cmFuc3BvcnQNCj5h ZGRyZXNzDQo+KGxvY2F0b3IrcHJvdG9jb2wrcG9ydCkgaW5zdGVhZCBvZiBqdXN0IHRoZSBsb2Nh dG9yLg0KPg0KPkxvbmcgdmVyc2lvbjoNCj4NCj5XZSB3YW50IEFTQXMgdG8gYmUgYWJsZSB0byBy dW4gYXMgc2VwYXJhdGUgbW9kdWxlcyBpbiB1c2VyIGFkZHJlc3Mgc3BhY2UsIGFzDQo+YXBwbGlj YXRpb25zLCByYXRoZXIgdGhhbiBiZWluZyBidW5kbGVkIHdpdGggdGhlIEdSQVNQIGVuZ2luZSBp biBrZXJuZWwNCj5zcGFjZS4NCj5UbyBhY2hpZXZlIHRoaXMgd2l0aCBhbGwgQVNBcyBsaXN0ZW5p bmcgb24gdGhlIHNhbWUgcG9ydCBudW1iZXIgd291bGQgcmVxdWlyZQ0KPnF1aXRlIGNvbXBsaWNh dGVkIGludGVyLXByb2Nlc3MgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBHUkFTUCBrZXJuZWwN Cj5hbmQgdGhlDQo+aW5kdmlkdWFsIEFTQXMuIFRoZSBkZXRhaWxzIG9mIHRoaXMgd291bGQgYmUg ZGlmZmVyZW50IGluIGVhY2ggb3BlcmF0aW5nDQo+c3lzdGVtLg0KPklmIHdlIGFsbG93IGVhY2gg QVNBIHRvIGhhdmUgaXRzIG93biBwb3J0IHRoaXMgY2FuIGJlIGF2b2lkZWQsIGFuZCBlYWNoIEFT QQ0KPmNhbg0KPmhhdmUgaXRzIG93biBjb3B5IG9mIHRoZSBHUkFTUCBBUEkgbGlicmFyeSBpZiBy ZXF1aXJlZC4gVGhpcyB3aWxsIG1ha2UgdGhlDQo+c3lzdGVtcyBlbmdpbmVlcmluZyBvZiBwb3J0 YWJsZSBBU0FzIG11Y2ggZWFzaWVyLCBhbmQgd2lsbCBtYWtlIHRoZQ0KPmFkYXB0YXRpb24NCj5v ZiB0aGUgR1JBU1AgQVBJIGxpYnJhcnkgYW5kIHRoZSBHUkFTUCBrZXJuZWwgdG8gdmFyaW91cyBv cGVyYXRpbmcgc3lzdGVtcw0KPmVhc2llciB0b28uDQo+DQo+SW4gcHJhY3RpY2Ugd2UgbmVlZCB0 byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgKFRDUCBvciBVRFApIGFzIHdlbGwsIHNpbmNlDQo+ZHlu YW1pYyBwb3J0cyBhcmUgYXNzaWduZWQgZm9yIGEgc3BlY2lmaWMgc29ja2V0IGFuZCBwcm90b2Nv bC4NCj4NCj5XZSBwcm9wb3NlIHRvIHJlZGVmaW5lIHRoZSBsb2NhdG9yIHJldHVybmVkIGJ5IEdS QVNQIGRpc2NvdmVyeSBhY2NvcmRpbmdseS4NCj5Gb3IgdGhlIElQdjYgY2FzZSB0aGF0IHdvdWxk IGdpdmUgdGhlIGZvbGxvd2luZyBDRERMOg0KPg0KPmxvY2F0b3Itb3B0aW9uIC89IFtPX0lQdjZf TE9DQVRPUiwgaXB2Ni1hZGRyZXNzLCB0cmFuc3BvcnQtcHJvdG8sDQo+cG9ydC1udW1iZXJdDQo+ aXB2Ni1hZGRyZXNzID0gYnl0ZXMgLnNpemUgMTYNCj50cmFuc3BvcnQtcHJvdG8gPSBJUFBST1RP X1RDUCAvIElQUFJPVE9fVURQDQo+SVBQUk9UT19UQ1AgPSA2DQo+SVBQUk9UT19VRFAgPSAxNw0K PnBvcnQtbnVtYmVyID0gMC4uNjU1MzUNCj4NCj5XZSBkaWQgY29uc2lkZXIgbWFraW5nIHRoaXMg b3B0aW9uYWwsIGJ1dCB0aGF0IHdvdWxkIHJhaXNlIGludGVyb3BlcmFiaWxpdHkNCj5pc3N1ZXMu IElmIGFuIGltcGxlbWVudGF0aW9uIGRvZXMgY2hvb3NlIHRvIHVzZSB0aGUgR1JBU1BfTElTVEVO X1BPUlQNCj5mb3IgYWxsIEFTQXMsIHRoYXQgY291bGQgc2ltcGx5IGJlIHJldHVybmVkIGFzIHRo ZSBwb3J0LW51bWJlci4NCj4NCj5JbXBsZW1lbnRhdGlvbiBub3RlOg0KPg0KPklmIHNvbWVvbmUg aW1wbGVtZW50cyBtdWx0aXBsZSBBU0FzIGluIGEgY29tbW9uIGFkZHJlc3Mgc3BhY2UsIHRoZXkg Y2FuDQo+c2hhcmUgYSB1bmljYXN0IHBvcnQgYW5kIGRlbXVsdGlwbGV4IGluY29taW5nIG1lc3Nh Z2VzIHVzaW5nIG90aGVyIGZpZWxkcw0KPih0aGUgU2Vzc2lvbiBJRCBhbmQgdGhlIE9iamVjdGl2 ZSBuYW1lKS4gIFRoaXMgY2hhbmdlIGFsbG93cyB0aGVtIHRvIGJlIGluDQo+c2VwYXJhdGUgc3Bh Y2VzLCB3aXRob3V0IHJlcXVpcmluZyBpdC4NCj4NCj5XaGVuIGl0IHN0YXJ0cyB1cCwgYW4gQVNB IGNhbiBvYnRhaW4gYW4gZXBoZW1lcmFsIHBvcnQgbnVtYmVyIGZvciBlYWNoDQo+dHJhbnNwb3J0 IHByb3RvY29sIHRoYXQgaXQgc3VwcG9ydHMsIGFuZCB0aGF0IHdpbGwgYmUgdXNlZCBpbiBkaXNj b3ZlcnkNCj5yZXNwb25zZXMuDQo+DQo+VGhpcyBjaGFuZ2UgaGFzIGFscmVhZHkgYmVlbiB0ZXN0 ZWQgb3V0IGluIHRoZSBwcm90b3R5cGUgUHl0aG9uIGNvZGUuDQo+DQo+Q29tbWVudHM/DQo+DQo+ Tm90ZTogVG9lcmxlc3MgRWNrZXJ0IGJyb3VnaHQgdXAgdGhpcyBwcm9ibGVtIGFuZCBvdXRsaW5l ZCB0aGUgcHJvcG9zZWQNCj5zb2x1dGlvbi4gSm9lbCBIYWxwZXJuIG1hZGUgdmVyeSBoZWxwZnVs IGNvbW1lbnRzLg0KPg0KPiAgICBCcmlhbiArIGNvLWF1dGhvcnMNCj4NCj4NCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkFuaW1hIG1haWxpbmcg bGlzdA0KPkFuaW1hQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hbmltYQ0K From nobody Mon May 2 19:40:03 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59F512D531 for ; Mon, 2 May 2016 19:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 9g4W1ScmWQUW for ; Mon, 2 May 2016 19:39:59 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 5CAD812D53B for ; Mon, 2 May 2016 19:39:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 432EA267293; Mon, 2 May 2016 19:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462243199; bh=SlJKQMcQkHdvufubvzs46dJwsq1LLe/hFjDBz1vQNME=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZgaUmKm1pzEJcTaf5V/nt8MqxnAA77J/FzprHey32UJ2dvySVAD23cTzzmOmipWOa roN0H6t8h7FItXZAcNiYkyAhGanTI0h1+esaaBsg7Qn60WDtT0kxyJ6CthZ23NsXYa vnNSNDEA9m92XLwDhSE/YJOalEzIRU4bd9wL7pfU= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9C0ED26729A; Mon, 2 May 2016 19:39:58 -0700 (PDT) To: Sheng Jiang , Brian E Carpenter , Anima WG References: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> From: "Joel M. Halpern" Message-ID: <71f9f078-a22e-3d5f-8d80-589104dcb3a7@joelhalpern.com> Date: Mon, 2 May 2016 22:39:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 02:40:03 -0000 Sheng, unless I have misunderstood Brian rather thoroughly, the port numbers in the proposal are TCP or UDP port numbers. They are not some other number / name space. The point is to be able to leverage the kernel demuxing which relies on those port numbers to get traffic to multiple user space ASAs. Yours, Joel On 5/2/16 10:02 PM, Sheng Jiang wrote: > Hi, Brian & Signaling design team, > > Thanks for your hard work and the latest design. It looks useful to > quickly classify or identify the ASA in the receiver side. However, > may I proposed the rename "GRASP port number" to be "ASA type > number", or something else without "port number"? The introduction is > easily to be misread. Actually, you have created a new namespace. The > word "transport port number" is misleading. We should have a more > explicit name. > > One question: does this new namespace also need to be managed by IANA > or there could be other mechanism to manage it so that the uniqueness > could be guaranteed? > > Best regards, > > Sheng > >> -----Original Message----- From: Anima >> [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Saturday, April 30, 2016 4:26 AM To: Anima WG Subject: >> [Anima] Proposed change to GRASP >> >> Hi, >> >> Short version: >> >> We propose that when an ASA listens for negotiation or >> synchronization requests, it should do so on its own transport port >> number rather than sharing the generic GRASP port number as >> currently defined. The consequence for the protocol is that >> discovery responses must include a complete transport address >> (locator+protocol+port) instead of just the locator. >> >> Long version: >> >> We want ASAs to be able to run as separate modules in user address >> space, as applications, rather than being bundled with the GRASP >> engine in kernel space. To achieve this with all ASAs listening on >> the same port number would require quite complicated inter-process >> communication between the GRASP kernel and the indvidual ASAs. The >> details of this would be different in each operating system. If we >> allow each ASA to have its own port this can be avoided, and each >> ASA can have its own copy of the GRASP API library if required. >> This will make the systems engineering of portable ASAs much >> easier, and will make the adaptation of the GRASP API library and >> the GRASP kernel to various operating systems easier too. >> >> In practice we need to indicate the protocol (TCP or UDP) as well, >> since dynamic ports are assigned for a specific socket and >> protocol. >> >> We propose to redefine the locator returned by GRASP discovery >> accordingly. For the IPv6 case that would give the following CDDL: >> >> locator-option /= [O_IPv6_LOCATOR, ipv6-address, transport-proto, >> port-number] ipv6-address = bytes .size 16 transport-proto = >> IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP = 6 IPPROTO_UDP = 17 >> port-number = 0..65535 >> >> We did consider making this optional, but that would raise >> interoperability issues. If an implementation does choose to use >> the GRASP_LISTEN_PORT for all ASAs, that could simply be returned >> as the port-number. >> >> Implementation note: >> >> If someone implements multiple ASAs in a common address space, they >> can share a unicast port and demultiplex incoming messages using >> other fields (the Session ID and the Objective name). This change >> allows them to be in separate spaces, without requiring it. >> >> When it starts up, an ASA can obtain an ephemeral port number for >> each transport protocol that it supports, and that will be used in >> discovery responses. >> >> This change has already been tested out in the prototype Python >> code. >> >> Comments? >> >> Note: Toerless Eckert brought up this problem and outlined the >> proposed solution. Joel Halpern made very helpful comments. >> >> Brian + co-authors >> >> >> >> _______________________________________________ Anima mailing list >> Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list > Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima > From nobody Mon May 2 20:11:40 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFC912D0A6 for ; Mon, 2 May 2016 20:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 xQ688Qjt4e9T for ; Mon, 2 May 2016 20:11:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB3812D53B for ; Mon, 2 May 2016 20:11:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNU24349; Tue, 03 May 2016 03:11:30 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 May 2016 04:11:30 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 3 May 2016 11:11:17 +0800 From: "Liubing (Leo)" To: Sheng Jiang , Brian E Carpenter , Anima WG Thread-Topic: [Anima] Proposed change to GRASP Thread-Index: AQHRolVqNf4Qo/puFU6AC+wBCX6Mm5+l9POAgACNVfA= Date: Tue, 3 May 2016 03:11:16 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D6C6BC@nkgeml514-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.572816E3.0042, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d4427c564906d85735fb53c3356934bb Archived-At: Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:11:39 -0000 Hi Sheng, I guess pure text is not easy to clearly describe the logic. Brian had noti= ced the issue of how to explain it to the WG when we had private discussion= . So let me quote Toerless' drawing. Maybe it's more easy to be understood. Before quoting the drawings, let me make a short explanation: 1. As Joel replied, the port numbers are not "name space" or "identifier" o= f the ASAs, they are used in TCP/UDP when communicate with the ASAs. 2. Although the port numbers are defined as "port-number =3D 0..65535" in t= he locater option, in practice, as we know they only have a limited range t= o avoid collision with other applications. For IANA registration, I guess n= o need for ASAs? Or maybe only the meta-ASAs (such as bootstrapping) need t= o be registered? ***Now the drawings*** If we allocate ports for each ASA, then the OS kernel can de-multiplex ASAs= by ports, thus directly interact with the ASAs through syscall (via the us= erland GRASP Lib ). In this case, the basic GRASP Daemon/Engine could be im= plemented in the OS kernel space, it handles generic GRASP messages (not to= ward a specific ASA) such as Discovery, Flood etc. |<----- one binaery -------> per ASA __________ __________ ________ | Userland | | Userland | | | | ASA |---- | GRASP Lib|--- syscall --- | Kernel | | _________| ^ |__________| /|________| | ------/ API _____________ / | GRASP | | Daemon | |_____________| Without ASA ports, there will be no way for the OS kernel to do the de-mult= iplexing. Thus, the GRASP Daemon needs to be in the userland for de-multipl= exing (de-multiplex by Session ID). Then, IPC will be involved between ASA = and GRASP daemon, as the figure shows below. And IPC is something we'd bett= er not get involved in, to avoid unnecessary additional standardization wor= k. |<----- one binaery -------> per ASA __________ __________ ______________ ________ | Userland | | Userland | | Userland | | = | | ASA |----| GRASP Lib|---IPC -- | GRASP daemon | --- | Kerne= l | | _________| ^ |__________| |______________| |________| | API Best regards, Bing > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: Tuesday, May 03, 2016 10:03 AM > To: Brian E Carpenter; Anima WG > Subject: Re: [Anima] Proposed change to GRASP >=20 > Hi, Brian & Signaling design team, >=20 > Thanks for your hard work and the latest design. It looks useful to quick= ly > classify or identify the ASA in the receiver side. However, may I propose= d the > rename "GRASP port number" to be "ASA type number", or something else > without "port number"? The introduction is easily to be misread. Actually= , > you have created a new namespace. The word "transport port number" is > misleading. We should have a more explicit name. >=20 > One question: does this new namespace also need to be managed by IANA > or there could be other mechanism to manage it so that the uniqueness > could be guaranteed? >=20 > Best regards, >=20 > Sheng >=20 > >-----Original Message----- > >From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > >Carpenter > >Sent: Saturday, April 30, 2016 4:26 AM > >To: Anima WG > >Subject: [Anima] Proposed change to GRASP > > > >Hi, > > > >Short version: > > > >We propose that when an ASA listens for negotiation or synchronization > >requests, it should do so on its own transport port number rather than > >sharing the generic GRASP port number as currently defined. The > >consequence for the protocol is that discovery responses must include a > >complete transport address > >(locator+protocol+port) instead of just the locator. > > > >Long version: > > > >We want ASAs to be able to run as separate modules in user address > >space, as applications, rather than being bundled with the GRASP engine > >in kernel space. > >To achieve this with all ASAs listening on the same port number would > >require quite complicated inter-process communication between the > GRASP > >kernel and the indvidual ASAs. The details of this would be different > >in each operating system. > >If we allow each ASA to have its own port this can be avoided, and each > >ASA can have its own copy of the GRASP API library if required. This > >will make the systems engineering of portable ASAs much easier, and > >will make the adaptation of the GRASP API library and the GRASP kernel > >to various operating systems easier too. > > > >In practice we need to indicate the protocol (TCP or UDP) as well, > >since dynamic ports are assigned for a specific socket and protocol. > > > >We propose to redefine the locator returned by GRASP discovery > accordingly. > >For the IPv6 case that would give the following CDDL: > > > >locator-option /=3D [O_IPv6_LOCATOR, ipv6-address, transport-proto, > >port-number] ipv6-address =3D bytes .size 16 transport-proto =3D > >IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP =3D 6 IPPROTO_UDP =3D 17 > port-number > >=3D 0..65535 > > > >We did consider making this optional, but that would raise > >interoperability issues. If an implementation does choose to use the > >GRASP_LISTEN_PORT for all ASAs, that could simply be returned as the > port-number. > > > >Implementation note: > > > >If someone implements multiple ASAs in a common address space, they can > >share a unicast port and demultiplex incoming messages using other > >fields (the Session ID and the Objective name). This change allows > >them to be in separate spaces, without requiring it. > > > >When it starts up, an ASA can obtain an ephemeral port number for each > >transport protocol that it supports, and that will be used in discovery > >responses. > > > >This change has already been tested out in the prototype Python code. > > > >Comments? > > > >Note: Toerless Eckert brought up this problem and outlined the proposed > >solution. Joel Halpern made very helpful comments. > > > > Brian + co-authors > > > > > > > >_______________________________________________ > >Anima mailing list > >Anima@ietf.org > >https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon May 2 20:56:23 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D78912D0E2 for ; Mon, 2 May 2016 20:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 GY6aHXCv0ItS for ; Mon, 2 May 2016 20:56:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B7612D164 for ; Mon, 2 May 2016 20:56:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNU29962; Tue, 03 May 2016 03:56:14 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 May 2016 04:56:13 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 3 May 2016 11:56:04 +0800 From: Sheng Jiang To: "Liubing (Leo)" , Brian E Carpenter , Anima WG , Joel Halpern Thread-Topic: [Anima] Proposed change to GRASP Thread-Index: AQHRolVqBJWxQM8IhE+Gy831tdxeMJ+mdnyA//+RpQCAAI/M8A== Date: Tue, 3 May 2016 03:56:03 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927C65D3FB@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D6C6BC@nkgeml514-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D6C6BC@nkgeml514-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5728215E.017D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d4427c564906d85735fb53c3356934bb Archived-At: Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:56:22 -0000 T29wcy4uLiBUaGFua3MgdGhlIGV4cGxhbmF0aW9uIGZyb20gQmluZyBhbmQgSm9lbC4gVGhpcyBk ZXNpZ24gY2FuIGNlcnRhaW5seSBoZWxwIHRoZSBlZmZpY2llbmN5IG9mIEFTQSBjb21tdW5pY2F0 aW9uLiBIb3dldmVyLCBzaW5jZSB3ZSBhcmUgZ29pbmcgdG8gdXNlIGEgVENQL1VEUCBwb3J0IGZv ciBlYWNoIEFTQSwgdGhpcyBhY3R1YWxseSBicmluZ3MgbWUgYW5vdGhlciBxdWVzdGlvbjogaG93 IG1hbnkgQVNBIG1heSB3ZSBleHBlY3QgaW4gdG90YWw/IFRoaXMgbWF5IG5vdCBiZSBlc3NlbnRp YWwgZm9yIHRoaXMgZGVzaWduLCBidXQgaXQgaXMgYSBuZWNlc3NhcnkgZGlzY3Vzc2lvbiBwb2lu dCByZWdhcmRpbmcgdG8gdGhlIGdyYW51bGFyaXR5IG9mIEFTQS4NCg0KUmVnYXJkcywNCg0KU2hl bmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogTGl1YmluZyAoTGVvKQ0K PlNlbnQ6IFR1ZXNkYXksIE1heSAwMywgMjAxNiAxMToxMSBBTQ0KPlRvOiBTaGVuZyBKaWFuZzsg QnJpYW4gRSBDYXJwZW50ZXI7IEFuaW1hIFdHDQo+U3ViamVjdDogUkU6IFtBbmltYV0gUHJvcG9z ZWQgY2hhbmdlIHRvIEdSQVNQDQo+DQo+SGkgU2hlbmcsDQo+DQo+SSBndWVzcyBwdXJlIHRleHQg aXMgbm90IGVhc3kgdG8gY2xlYXJseSBkZXNjcmliZSB0aGUgbG9naWMuIEJyaWFuIGhhZCBub3Rp Y2VkDQo+dGhlIGlzc3VlIG9mIGhvdyB0byBleHBsYWluIGl0IHRvIHRoZSBXRyB3aGVuIHdlIGhh ZCBwcml2YXRlIGRpc2N1c3Npb24uDQo+U28gbGV0IG1lIHF1b3RlIFRvZXJsZXNzJyBkcmF3aW5n LiBNYXliZSBpdCdzIG1vcmUgZWFzeSB0byBiZSB1bmRlcnN0b29kLg0KPg0KPkJlZm9yZSBxdW90 aW5nIHRoZSBkcmF3aW5ncywgbGV0IG1lIG1ha2UgYSBzaG9ydCBleHBsYW5hdGlvbjoNCj4xLiBB cyBKb2VsIHJlcGxpZWQsIHRoZSBwb3J0IG51bWJlcnMgYXJlIG5vdCAibmFtZSBzcGFjZSIgb3Ig ImlkZW50aWZpZXIiIG9mDQo+dGhlIEFTQXMsIHRoZXkgYXJlIHVzZWQgaW4gVENQL1VEUCB3aGVu IGNvbW11bmljYXRlIHdpdGggdGhlIEFTQXMuDQo+Mi4gQWx0aG91Z2ggdGhlIHBvcnQgbnVtYmVy cyBhcmUgZGVmaW5lZCBhcyAicG9ydC1udW1iZXIgPSAwLi42NTUzNSIgaW4gdGhlDQo+bG9jYXRl ciBvcHRpb24sIGluIHByYWN0aWNlLCBhcyB3ZSBrbm93IHRoZXkgb25seSBoYXZlIGEgbGltaXRl ZCByYW5nZSB0bw0KPmF2b2lkIGNvbGxpc2lvbiB3aXRoIG90aGVyIGFwcGxpY2F0aW9ucy4gRm9y IElBTkEgcmVnaXN0cmF0aW9uLCBJIGd1ZXNzIG5vIG5lZWQNCj5mb3IgQVNBcz8gT3IgbWF5YmUg b25seSB0aGUgbWV0YS1BU0FzIChzdWNoIGFzIGJvb3RzdHJhcHBpbmcpIG5lZWQgdG8gYmUNCj5y ZWdpc3RlcmVkPw0KPg0KPg0KPioqKk5vdyB0aGUgZHJhd2luZ3MqKioNCj5JZiB3ZSBhbGxvY2F0 ZSBwb3J0cyBmb3IgZWFjaCBBU0EsIHRoZW4gdGhlIE9TIGtlcm5lbCBjYW4gZGUtbXVsdGlwbGV4 IEFTQXMgYnkNCj5wb3J0cywgdGh1cyBkaXJlY3RseSBpbnRlcmFjdCB3aXRoIHRoZSBBU0FzIHRo cm91Z2ggc3lzY2FsbCAodmlhIHRoZSB1c2VybGFuZA0KPkdSQVNQIExpYiApLiBJbiB0aGlzIGNh c2UsIHRoZSBiYXNpYyBHUkFTUCBEYWVtb24vRW5naW5lIGNvdWxkIGJlDQo+aW1wbGVtZW50ZWQg aW4gdGhlIE9TIGtlcm5lbCBzcGFjZSwgaXQgaGFuZGxlcyBnZW5lcmljIEdSQVNQIG1lc3NhZ2Vz IChub3QNCj50b3dhcmQgYSBzcGVjaWZpYyBBU0EpIHN1Y2ggYXMgRGlzY292ZXJ5LCBGbG9vZCBl dGMuDQo+DQo+ICAgfDwtLS0tLSBvbmUgYmluYWVyeSAtLS0tLS0tPg0KPiAgICAgICAgICBwZXIg QVNBDQo+ICBfX19fX19fX19fICAgICAgX19fX19fX19fXyAgICAgICAgICAgICAgIF9fX19fX19f DQo+ICB8IFVzZXJsYW5kIHwgICAgICB8IFVzZXJsYW5kIHwgICAgICAgICAgICAgICB8ICAgICAg ICB8DQo+ICB8ICAgQVNBICB8LS0tLSAgIHwgR1JBU1AgTGlifC0tLSBzeXNjYWxsIC0tLSAgICAg fCAgS2VybmVsIHwNCj4gIHwgX19fX19fX19ffCBeICAgfF9fX19fX19fX198ICAgICAgICAgICAg ICAvfF9fX19fX19ffA0KPiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIC0tLS0t LS8NCj4gICAgICAgICAgICAgIEFQSSAgICAgX19fX19fX19fX19fXyAvDQo+ICAgICAgICAgICAg ICAgICAgICAgfCAgR1JBU1AgICAgIHwNCj4gICAgICAgICAgICAgICAgICAgICB8ICBEYWVtb24g ICAgfA0KPiAgICAgICAgICAgICAgICAgICAgIHxfX19fX19fX19fX19ffA0KPg0KPg0KPg0KPldp dGhvdXQgQVNBIHBvcnRzLCB0aGVyZSB3aWxsIGJlIG5vIHdheSBmb3IgdGhlIE9TIGtlcm5lbCB0 byBkbyB0aGUNCj5kZS1tdWx0aXBsZXhpbmcuIFRodXMsIHRoZSBHUkFTUCBEYWVtb24gbmVlZHMg dG8gYmUgaW4gdGhlIHVzZXJsYW5kIGZvcg0KPmRlLW11bHRpcGxleGluZyAoZGUtbXVsdGlwbGV4 IGJ5IFNlc3Npb24gSUQpLiBUaGVuLCBJUEMgd2lsbCBiZSBpbnZvbHZlZA0KPmJldHdlZW4gQVNB IGFuZCBHUkFTUCBkYWVtb24sIGFzIHRoZSBmaWd1cmUgc2hvd3MgYmVsb3cuIEFuZCBJUEMgaXMN Cj5zb21ldGhpbmcgd2UnZCBiZXR0ZXIgbm90IGdldCBpbnZvbHZlZCBpbiwgdG8gYXZvaWQgdW5u ZWNlc3NhcnkgYWRkaXRpb25hbA0KPnN0YW5kYXJkaXphdGlvbiB3b3JrLg0KPg0KPiAgfDwtLS0t LSBvbmUgYmluYWVyeSAtLS0tLS0tPg0KPiAgICAgICAgICBwZXIgQVNBDQo+DQo+ICAgX19fX19f X19fXyAgICAgIF9fX19fX19fX18gICAgICAgICAgIF9fX19fX19fX19fX19fDQo+X19fX19fX18N Cj4gIHwgVXNlcmxhbmQgfCAgICAgIHwgVXNlcmxhbmQgfCAgICAgICAgICAgICB8IFVzZXJsYW5k ICAgICB8ICAgICAgfA0KPnwNCj4gIHwgICBBU0EgICAgfC0tLS18IEdSQVNQIExpYnwtLS1JUEMg LS0gICAgIHwgR1JBU1AgZGFlbW9uIHwgLS0tICAgfA0KPktlcm5lbCB8DQo+ICB8IF9fX19fX19f X3wgXiAgfF9fX19fX19fX198ICAgICAgICAgIHxfX19fX19fX19fX19fX3wNCj58X19fX19fX198 DQo+ICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgIEFQSQ0KPg0KPkJlc3QgcmVnYXJk cywNCj5CaW5nDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogQW5p bWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2hlbmcgSmlh bmcNCj4+IFNlbnQ6IFR1ZXNkYXksIE1heSAwMywgMjAxNiAxMDowMyBBTQ0KPj4gVG86IEJyaWFu IEUgQ2FycGVudGVyOyBBbmltYSBXRw0KPj4gU3ViamVjdDogUmU6IFtBbmltYV0gUHJvcG9zZWQg Y2hhbmdlIHRvIEdSQVNQDQo+Pg0KPj4gSGksIEJyaWFuICYgU2lnbmFsaW5nIGRlc2lnbiB0ZWFt LA0KPj4NCj4+IFRoYW5rcyBmb3IgeW91ciBoYXJkIHdvcmsgYW5kIHRoZSBsYXRlc3QgZGVzaWdu LiBJdCBsb29rcyB1c2VmdWwgdG8gcXVpY2tseQ0KPj4gY2xhc3NpZnkgb3IgaWRlbnRpZnkgdGhl IEFTQSBpbiB0aGUgcmVjZWl2ZXIgc2lkZS4gSG93ZXZlciwgbWF5IEkgcHJvcG9zZWQgdGhlDQo+ PiByZW5hbWUgIkdSQVNQIHBvcnQgbnVtYmVyIiB0byBiZSAiQVNBIHR5cGUgbnVtYmVyIiwgb3Ig c29tZXRoaW5nIGVsc2UNCj4+IHdpdGhvdXQgInBvcnQgbnVtYmVyIj8gVGhlIGludHJvZHVjdGlv biBpcyBlYXNpbHkgdG8gYmUgbWlzcmVhZC4gQWN0dWFsbHksDQo+PiB5b3UgaGF2ZSBjcmVhdGVk IGEgbmV3IG5hbWVzcGFjZS4gVGhlIHdvcmQgInRyYW5zcG9ydCBwb3J0IG51bWJlciIgaXMNCj4+ IG1pc2xlYWRpbmcuIFdlIHNob3VsZCBoYXZlIGEgbW9yZSBleHBsaWNpdCBuYW1lLg0KPj4NCj4+ IE9uZSBxdWVzdGlvbjogZG9lcyB0aGlzIG5ldyBuYW1lc3BhY2UgYWxzbyBuZWVkIHRvIGJlIG1h bmFnZWQgYnkgSUFOQQ0KPj4gb3IgdGhlcmUgY291bGQgYmUgb3RoZXIgbWVjaGFuaXNtIHRvIG1h bmFnZSBpdCBzbyB0aGF0IHRoZSB1bmlxdWVuZXNzDQo+PiBjb3VsZCBiZSBndWFyYW50ZWVkPw0K Pj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+ID4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gPkZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIEUNCj4+ID5DYXJwZW50ZXINCj4+ID5TZW50OiBTYXR1 cmRheSwgQXByaWwgMzAsIDIwMTYgNDoyNiBBTQ0KPj4gPlRvOiBBbmltYSBXRw0KPj4gPlN1Ympl Y3Q6IFtBbmltYV0gUHJvcG9zZWQgY2hhbmdlIHRvIEdSQVNQDQo+PiA+DQo+PiA+SGksDQo+PiA+ DQo+PiA+U2hvcnQgdmVyc2lvbjoNCj4+ID4NCj4+ID5XZSBwcm9wb3NlIHRoYXQgd2hlbiBhbiBB U0EgbGlzdGVucyBmb3IgbmVnb3RpYXRpb24gb3Igc3luY2hyb25pemF0aW9uDQo+PiA+cmVxdWVz dHMsIGl0IHNob3VsZCBkbyBzbyBvbiBpdHMgb3duIHRyYW5zcG9ydCBwb3J0IG51bWJlciByYXRo ZXIgdGhhbg0KPj4gPnNoYXJpbmcgdGhlIGdlbmVyaWMgR1JBU1AgcG9ydCBudW1iZXIgYXMgY3Vy cmVudGx5IGRlZmluZWQuIFRoZQ0KPj4gPmNvbnNlcXVlbmNlIGZvciB0aGUgcHJvdG9jb2wgaXMg dGhhdCBkaXNjb3ZlcnkgcmVzcG9uc2VzIG11c3QgaW5jbHVkZSBhDQo+PiA+Y29tcGxldGUgdHJh bnNwb3J0IGFkZHJlc3MNCj4+ID4obG9jYXRvcitwcm90b2NvbCtwb3J0KSBpbnN0ZWFkIG9mIGp1 c3QgdGhlIGxvY2F0b3IuDQo+PiA+DQo+PiA+TG9uZyB2ZXJzaW9uOg0KPj4gPg0KPj4gPldlIHdh bnQgQVNBcyB0byBiZSBhYmxlIHRvIHJ1biBhcyBzZXBhcmF0ZSBtb2R1bGVzIGluIHVzZXIgYWRk cmVzcw0KPj4gPnNwYWNlLCBhcyBhcHBsaWNhdGlvbnMsIHJhdGhlciB0aGFuIGJlaW5nIGJ1bmRs ZWQgd2l0aCB0aGUgR1JBU1AgZW5naW5lDQo+PiA+aW4ga2VybmVsIHNwYWNlLg0KPj4gPlRvIGFj aGlldmUgdGhpcyB3aXRoIGFsbCBBU0FzIGxpc3RlbmluZyBvbiB0aGUgc2FtZSBwb3J0IG51bWJl ciB3b3VsZA0KPj4gPnJlcXVpcmUgcXVpdGUgY29tcGxpY2F0ZWQgaW50ZXItcHJvY2VzcyBjb21t dW5pY2F0aW9uIGJldHdlZW4gdGhlDQo+PiBHUkFTUA0KPj4gPmtlcm5lbCBhbmQgdGhlIGluZHZp ZHVhbCBBU0FzLiBUaGUgZGV0YWlscyBvZiB0aGlzIHdvdWxkIGJlIGRpZmZlcmVudA0KPj4gPmlu IGVhY2ggb3BlcmF0aW5nIHN5c3RlbS4NCj4+ID5JZiB3ZSBhbGxvdyBlYWNoIEFTQSB0byBoYXZl IGl0cyBvd24gcG9ydCB0aGlzIGNhbiBiZSBhdm9pZGVkLCBhbmQgZWFjaA0KPj4gPkFTQSBjYW4g aGF2ZSBpdHMgb3duIGNvcHkgb2YgdGhlIEdSQVNQIEFQSSBsaWJyYXJ5IGlmIHJlcXVpcmVkLiBU aGlzDQo+PiA+d2lsbCBtYWtlIHRoZSBzeXN0ZW1zIGVuZ2luZWVyaW5nIG9mIHBvcnRhYmxlIEFT QXMgbXVjaCBlYXNpZXIsIGFuZA0KPj4gPndpbGwgbWFrZSB0aGUgYWRhcHRhdGlvbiBvZiB0aGUg R1JBU1AgQVBJIGxpYnJhcnkgYW5kIHRoZSBHUkFTUCBrZXJuZWwNCj4+ID50byB2YXJpb3VzIG9w ZXJhdGluZyBzeXN0ZW1zIGVhc2llciB0b28uDQo+PiA+DQo+PiA+SW4gcHJhY3RpY2Ugd2UgbmVl ZCB0byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgKFRDUCBvciBVRFApIGFzIHdlbGwsDQo+PiA+c2lu Y2UgZHluYW1pYyBwb3J0cyBhcmUgYXNzaWduZWQgZm9yIGEgc3BlY2lmaWMgc29ja2V0IGFuZCBw cm90b2NvbC4NCj4+ID4NCj4+ID5XZSBwcm9wb3NlIHRvIHJlZGVmaW5lIHRoZSBsb2NhdG9yIHJl dHVybmVkIGJ5IEdSQVNQIGRpc2NvdmVyeQ0KPj4gYWNjb3JkaW5nbHkuDQo+PiA+Rm9yIHRoZSBJ UHY2IGNhc2UgdGhhdCB3b3VsZCBnaXZlIHRoZSBmb2xsb3dpbmcgQ0RETDoNCj4+ID4NCj4+ID5s b2NhdG9yLW9wdGlvbiAvPSBbT19JUHY2X0xPQ0FUT1IsIGlwdjYtYWRkcmVzcywgdHJhbnNwb3J0 LXByb3RvLA0KPj4gPnBvcnQtbnVtYmVyXSBpcHY2LWFkZHJlc3MgPSBieXRlcyAuc2l6ZSAxNiB0 cmFuc3BvcnQtcHJvdG8gPQ0KPj4gPklQUFJPVE9fVENQIC8gSVBQUk9UT19VRFAgSVBQUk9UT19U Q1AgPSA2IElQUFJPVE9fVURQID0gMTcNCj4+IHBvcnQtbnVtYmVyDQo+PiA+PSAwLi42NTUzNQ0K Pj4gPg0KPj4gPldlIGRpZCBjb25zaWRlciBtYWtpbmcgdGhpcyBvcHRpb25hbCwgYnV0IHRoYXQg d291bGQgcmFpc2UNCj4+ID5pbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4gSWYgYW4gaW1wbGVtZW50 YXRpb24gZG9lcyBjaG9vc2UgdG8gdXNlIHRoZQ0KPj4gPkdSQVNQX0xJU1RFTl9QT1JUIGZvciBh bGwgQVNBcywgdGhhdCBjb3VsZCBzaW1wbHkgYmUgcmV0dXJuZWQgYXMgdGhlDQo+PiBwb3J0LW51 bWJlci4NCj4+ID4NCj4+ID5JbXBsZW1lbnRhdGlvbiBub3RlOg0KPj4gPg0KPj4gPklmIHNvbWVv bmUgaW1wbGVtZW50cyBtdWx0aXBsZSBBU0FzIGluIGEgY29tbW9uIGFkZHJlc3Mgc3BhY2UsIHRo ZXkNCj5jYW4NCj4+ID5zaGFyZSBhIHVuaWNhc3QgcG9ydCBhbmQgZGVtdWx0aXBsZXggaW5jb21p bmcgbWVzc2FnZXMgdXNpbmcgb3RoZXINCj4+ID5maWVsZHMgKHRoZSBTZXNzaW9uIElEIGFuZCB0 aGUgT2JqZWN0aXZlIG5hbWUpLiAgVGhpcyBjaGFuZ2UgYWxsb3dzDQo+PiA+dGhlbSB0byBiZSBp biBzZXBhcmF0ZSBzcGFjZXMsIHdpdGhvdXQgcmVxdWlyaW5nIGl0Lg0KPj4gPg0KPj4gPldoZW4g aXQgc3RhcnRzIHVwLCBhbiBBU0EgY2FuIG9idGFpbiBhbiBlcGhlbWVyYWwgcG9ydCBudW1iZXIg Zm9yIGVhY2gNCj4+ID50cmFuc3BvcnQgcHJvdG9jb2wgdGhhdCBpdCBzdXBwb3J0cywgYW5kIHRo YXQgd2lsbCBiZSB1c2VkIGluIGRpc2NvdmVyeQ0KPj4gPnJlc3BvbnNlcy4NCj4+ID4NCj4+ID5U aGlzIGNoYW5nZSBoYXMgYWxyZWFkeSBiZWVuIHRlc3RlZCBvdXQgaW4gdGhlIHByb3RvdHlwZSBQ eXRob24gY29kZS4NCj4+ID4NCj4+ID5Db21tZW50cz8NCj4+ID4NCj4+ID5Ob3RlOiBUb2VybGVz cyBFY2tlcnQgYnJvdWdodCB1cCB0aGlzIHByb2JsZW0gYW5kIG91dGxpbmVkIHRoZSBwcm9wb3Nl ZA0KPj4gPnNvbHV0aW9uLiBKb2VsIEhhbHBlcm4gbWFkZSB2ZXJ5IGhlbHBmdWwgY29tbWVudHMu DQo+PiA+DQo+PiA+ICAgIEJyaWFuICsgY28tYXV0aG9ycw0KPj4gPg0KPj4gPg0KPj4gPg0KPj4g Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+QW5p bWEgbWFpbGluZyBsaXN0DQo+PiA+QW5pbWFAaWV0Zi5vcmcNCj4+ID5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+PiBBbmltYUBp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Mon May 2 21:05:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8012D6C4 for ; Mon, 2 May 2016 21:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 cw7caqH837ZP for ; Mon, 2 May 2016 21:05:00 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 8990F12D6BD for ; Mon, 2 May 2016 21:05:00 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id y69so4255277pfb.1 for ; Mon, 02 May 2016 21:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=p1/gxDtLkuydVbFFRBMtPRPkWskGmTm3lyu5+6tBVGY=; b=oHYnjI9Cjt5h33Qh7KHijEK0Eyl+RgGzkodhsOYif/lgntRfVJyaZn+HX2QQmiKnAg YiFQDiBuZo1UzjWlYrauqcuwFNuNv0Qnf2pUSpDSo9tVotPQVGfwtbAloL6nBwlK6KU4 eNWYuC/2VhJrYkeTG3o+w4vMR1OZ1BN9mki605rqAWydOmHcbDwbJVMSZ9t2T68DZPQP Akf2p8zdfhp9QZLTYjCbfpOnvG9GZy9UqHnt0ZvZV0ml625IqHXk5jE4rnAByjC2Xp3/ JnqsZHiGz6oTkoaDvIDdUaUgwhkR2ETiL6XUWOqW3exp1ELlum8cj7XudGYT6os/MeVE EMdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=p1/gxDtLkuydVbFFRBMtPRPkWskGmTm3lyu5+6tBVGY=; b=mlsg3Kw5i4+fQs+We1raUtRDh61oGYFb2aqgoCQMwHuYa/7rf70G44YkTkP8WdfPHf rAQFnBpKfkVURoPsJpMpslDdbdh4KIADXTH2EZol2g6sPmcm1bNe/cjlrRo5Rvp+tY8e ns5mXzL19hjbtoNUIK/o9YbEuRQd5svYOtf4dujuv9icwnfkqws1qiybJRj9FVkzm8fC qEkXPfWJZMZpyLZiAPKL23ZMRn6sEjNpgzThIxmx/09n1iGako+Govnyp0SmtKIRnbHK LjJCOSzvC7ePqAjwMMxcciqXlcmuZWWPfUYMkWKWsxXrxQUt8s6ySOcfeX0JUotpCJCV OxWw== X-Gm-Message-State: AOPr4FVy69q6R8AQDbG0sr9OjzHSd3FgF/nOrAxXMMmAU7aLoXEJFeu4MrQjMPi+hoNewQ== X-Received: by 10.98.94.194 with SMTP id s185mr273855pfb.135.1462248300123; Mon, 02 May 2016 21:05:00 -0700 (PDT) Received: from ?IPv6:2406:e007:7e24:1:28cc:dc4c:9703:6781? ([2406:e007:7e24:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g5sm1504521pac.1.2016.05.02.21.04.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 21:04:58 -0700 (PDT) To: "Liubing (Leo)" , Sheng Jiang , Anima WG References: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D6C6BC@nkgeml514-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6605faac-23bb-ff83-ddb9-dd25768773a4@gmail.com> Date: Tue, 3 May 2016 16:05:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D6C6BC@nkgeml514-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 04:05:03 -0000 Thanks, Bing and Joel. Of course if the WG agrees to this change, we will have to explain it carefully in the next version of the draft, although some of the material perhaps belongs in the Reference Model. I actually believe that this change makes GRASP a more robust protocol; for example I can now run two copies of the Python prototype in one machine, and they can negotiate with each other quite nicely using a dynamic port. Regards Brian On 03/05/2016 15:11, Liubing (Leo) wrote: > Hi Sheng, > > I guess pure text is not easy to clearly describe the logic. Brian had noticed the issue of how to explain it to the WG when we had private discussion. > So let me quote Toerless' drawing. Maybe it's more easy to be understood. > > Before quoting the drawings, let me make a short explanation: > 1. As Joel replied, the port numbers are not "name space" or "identifier" of the ASAs, they are used in TCP/UDP when communicate with the ASAs. > 2. Although the port numbers are defined as "port-number = 0..65535" in the locater option, in practice, as we know they only have a limited range to avoid collision with other applications. For IANA registration, I guess no need for ASAs? Or maybe only the meta-ASAs (such as bootstrapping) need to be registered? > > > ***Now the drawings*** > If we allocate ports for each ASA, then the OS kernel can de-multiplex ASAs by ports, thus directly interact with the ASAs through syscall (via the userland GRASP Lib ). In this case, the basic GRASP Daemon/Engine could be implemented in the OS kernel space, it handles generic GRASP messages (not toward a specific ASA) such as Discovery, Flood etc. > > |<----- one binaery -------> > per ASA > __________ __________ ________ > | Userland | | Userland | | | > | ASA |---- | GRASP Lib|--- syscall --- | Kernel | > | _________| ^ |__________| /|________| > | ------/ > API _____________ / > | GRASP | > | Daemon | > |_____________| > > > > Without ASA ports, there will be no way for the OS kernel to do the de-multiplexing. Thus, the GRASP Daemon needs to be in the userland for de-multiplexing (de-multiplex by Session ID). Then, IPC will be involved between ASA and GRASP daemon, as the figure shows below. And IPC is something we'd better not get involved in, to avoid unnecessary additional standardization work. > > |<----- one binaery -------> > per ASA > > __________ __________ ______________ ________ > | Userland | | Userland | | Userland | | | > | ASA |----| GRASP Lib|---IPC -- | GRASP daemon | --- | Kernel | > | _________| ^ |__________| |______________| |________| > | > API > > Best regards, > Bing > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang >> Sent: Tuesday, May 03, 2016 10:03 AM >> To: Brian E Carpenter; Anima WG >> Subject: Re: [Anima] Proposed change to GRASP >> >> Hi, Brian & Signaling design team, >> >> Thanks for your hard work and the latest design. It looks useful to quickly >> classify or identify the ASA in the receiver side. However, may I proposed the >> rename "GRASP port number" to be "ASA type number", or something else >> without "port number"? The introduction is easily to be misread. Actually, >> you have created a new namespace. The word "transport port number" is >> misleading. We should have a more explicit name. >> >> One question: does this new namespace also need to be managed by IANA >> or there could be other mechanism to manage it so that the uniqueness >> could be guaranteed? >> >> Best regards, >> >> Sheng >> >>> -----Original Message----- >>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>> Carpenter >>> Sent: Saturday, April 30, 2016 4:26 AM >>> To: Anima WG >>> Subject: [Anima] Proposed change to GRASP >>> >>> Hi, >>> >>> Short version: >>> >>> We propose that when an ASA listens for negotiation or synchronization >>> requests, it should do so on its own transport port number rather than >>> sharing the generic GRASP port number as currently defined. The >>> consequence for the protocol is that discovery responses must include a >>> complete transport address >>> (locator+protocol+port) instead of just the locator. >>> >>> Long version: >>> >>> We want ASAs to be able to run as separate modules in user address >>> space, as applications, rather than being bundled with the GRASP engine >>> in kernel space. >>> To achieve this with all ASAs listening on the same port number would >>> require quite complicated inter-process communication between the >> GRASP >>> kernel and the indvidual ASAs. The details of this would be different >>> in each operating system. >>> If we allow each ASA to have its own port this can be avoided, and each >>> ASA can have its own copy of the GRASP API library if required. This >>> will make the systems engineering of portable ASAs much easier, and >>> will make the adaptation of the GRASP API library and the GRASP kernel >>> to various operating systems easier too. >>> >>> In practice we need to indicate the protocol (TCP or UDP) as well, >>> since dynamic ports are assigned for a specific socket and protocol. >>> >>> We propose to redefine the locator returned by GRASP discovery >> accordingly. >>> For the IPv6 case that would give the following CDDL: >>> >>> locator-option /= [O_IPv6_LOCATOR, ipv6-address, transport-proto, >>> port-number] ipv6-address = bytes .size 16 transport-proto = >>> IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP = 6 IPPROTO_UDP = 17 >> port-number >>> = 0..65535 >>> >>> We did consider making this optional, but that would raise >>> interoperability issues. If an implementation does choose to use the >>> GRASP_LISTEN_PORT for all ASAs, that could simply be returned as the >> port-number. >>> >>> Implementation note: >>> >>> If someone implements multiple ASAs in a common address space, they can >>> share a unicast port and demultiplex incoming messages using other >>> fields (the Session ID and the Objective name). This change allows >>> them to be in separate spaces, without requiring it. >>> >>> When it starts up, an ASA can obtain an ephemeral port number for each >>> transport protocol that it supports, and that will be used in discovery >>> responses. >>> >>> This change has already been tested out in the prototype Python code. >>> >>> Comments? >>> >>> Note: Toerless Eckert brought up this problem and outlined the proposed >>> solution. Joel Halpern made very helpful comments. >>> >>> Brian + co-authors >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Mon May 2 21:09:47 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C632812D6D5 for ; Mon, 2 May 2016 21:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 ZLE6wd163A3f for ; Mon, 2 May 2016 21:09:43 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 6AA6912D6BD for ; Mon, 2 May 2016 21:09:43 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id r5so4340047pag.1 for ; Mon, 02 May 2016 21:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=BfCf/FZgk3crvnOQ3WtM0uYKjp4Lo6Xu/rWioNpsbdo=; b=h3kw7zqZL38/W2SCn3ehNuArLpz2V2IdWyca9kaXse8sdVhws+PIKdqSE+QdZw60/j n1gUYmal+nOO6raXOE1v3m50BQwX+kQk/NsOgC7OWv5+GLLqB0YaLmBxUttk32bq+B5d 7sE5vTwdQw9cYIQwlFGBas2Tb+0zkNbj4S/79QpJGcbLJjzv0Ns/9sleCAOzTTJLtJXV lqLTbX/l1Q8VqoXOxLm4EV6RJm8hhZbHt4qOKVbJqhE16XtsnpvMnj7JPUDMnwZfwK78 /fEibXW/yQVqh4AxXeououoISlQD0fTmgxERVpgedLdB0peg45w3mlAJD9Qt91582dt5 cFtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BfCf/FZgk3crvnOQ3WtM0uYKjp4Lo6Xu/rWioNpsbdo=; b=WE4nelGGB/2/O7VMqklcLQtUXhZvoV8N/I0moberf/0C6xK8DglVUbAkjGYfJH4EEz ZU7MKeZ/svhCO42WPoa689pXVhTJnjOI7lxFyK3BiKklMLxu6RQkx4XEg0mQxeZNuG06 kyAL8BSN5IutCtngUB1lnCRC6erWnE3G3UGig/NMFzm/ndaVvYvHh+RDimyi17PNSHUM IDxm04A1l/ZKgLb84+eE/rx3lxFtprpPsqcWkcT5YEngZj2c77ZBCdu9E+VABQifbypD dlZfsrs0Jui2FyM05ZVvJT2ipIMGBTmAetoe++JdH/LoGSyPFYFRGBZjNTJ3WN4WS78z YjEQ== X-Gm-Message-State: AOPr4FXiaY4aTQF0y0YMaq51KuCFWXtOEMfabc9WLk+SWfq/mXzpml9U2Jp2IsfSqnljFQ== X-Received: by 10.66.43.143 with SMTP id w15mr358866pal.76.1462248583035; Mon, 02 May 2016 21:09:43 -0700 (PDT) Received: from ?IPv6:2406:e007:7e24:1:28cc:dc4c:9703:6781? ([2406:e007:7e24:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s124sm1488169pfb.63.2016.05.02.21.09.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 21:09:41 -0700 (PDT) To: Sheng Jiang , "Liubing (Leo)" , Anima WG , Joel Halpern References: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D6C6BC@nkgeml514-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B927C65D3FB@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 3 May 2016 16:09:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927C65D3FB@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 04:09:46 -0000 On 03/05/2016 15:56, Sheng Jiang wrote: > Oops... Thanks the explanation from Bing and Joel. This design can certainly help the efficiency of ASA communication. However, since we are going to use a TCP/UDP port for each ASA, this actually brings me another question: how many ASA may we expect in total? This may not be essential for this design, but it is a necessary discussion point regarding to the granularity of ASA. Right, there is no design limit on ASAs or objectives, but there is probably a practical limit in any implementation. I have no idea what the limits should be. Brian > > Regards, > > Sheng > >> -----Original Message----- >> From: Liubing (Leo) >> Sent: Tuesday, May 03, 2016 11:11 AM >> To: Sheng Jiang; Brian E Carpenter; Anima WG >> Subject: RE: [Anima] Proposed change to GRASP >> >> Hi Sheng, >> >> I guess pure text is not easy to clearly describe the logic. Brian had noticed >> the issue of how to explain it to the WG when we had private discussion. >> So let me quote Toerless' drawing. Maybe it's more easy to be understood. >> >> Before quoting the drawings, let me make a short explanation: >> 1. As Joel replied, the port numbers are not "name space" or "identifier" of >> the ASAs, they are used in TCP/UDP when communicate with the ASAs. >> 2. Although the port numbers are defined as "port-number = 0..65535" in the >> locater option, in practice, as we know they only have a limited range to >> avoid collision with other applications. For IANA registration, I guess no need >> for ASAs? Or maybe only the meta-ASAs (such as bootstrapping) need to be >> registered? >> >> >> ***Now the drawings*** >> If we allocate ports for each ASA, then the OS kernel can de-multiplex ASAs by >> ports, thus directly interact with the ASAs through syscall (via the userland >> GRASP Lib ). In this case, the basic GRASP Daemon/Engine could be >> implemented in the OS kernel space, it handles generic GRASP messages (not >> toward a specific ASA) such as Discovery, Flood etc. >> >> |<----- one binaery -------> >> per ASA >> __________ __________ ________ >> | Userland | | Userland | | | >> | ASA |---- | GRASP Lib|--- syscall --- | Kernel | >> | _________| ^ |__________| /|________| >> | ------/ >> API _____________ / >> | GRASP | >> | Daemon | >> |_____________| >> >> >> >> Without ASA ports, there will be no way for the OS kernel to do the >> de-multiplexing. Thus, the GRASP Daemon needs to be in the userland for >> de-multiplexing (de-multiplex by Session ID). Then, IPC will be involved >> between ASA and GRASP daemon, as the figure shows below. And IPC is >> something we'd better not get involved in, to avoid unnecessary additional >> standardization work. >> >> |<----- one binaery -------> >> per ASA >> >> __________ __________ ______________ >> ________ >> | Userland | | Userland | | Userland | | >> | >> | ASA |----| GRASP Lib|---IPC -- | GRASP daemon | --- | >> Kernel | >> | _________| ^ |__________| |______________| >> |________| >> | >> API >> >> Best regards, >> Bing >> >>> -----Original Message----- >>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang >>> Sent: Tuesday, May 03, 2016 10:03 AM >>> To: Brian E Carpenter; Anima WG >>> Subject: Re: [Anima] Proposed change to GRASP >>> >>> Hi, Brian & Signaling design team, >>> >>> Thanks for your hard work and the latest design. It looks useful to quickly >>> classify or identify the ASA in the receiver side. However, may I proposed the >>> rename "GRASP port number" to be "ASA type number", or something else >>> without "port number"? The introduction is easily to be misread. Actually, >>> you have created a new namespace. The word "transport port number" is >>> misleading. We should have a more explicit name. >>> >>> One question: does this new namespace also need to be managed by IANA >>> or there could be other mechanism to manage it so that the uniqueness >>> could be guaranteed? >>> >>> Best regards, >>> >>> Sheng >>> >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>> Carpenter >>>> Sent: Saturday, April 30, 2016 4:26 AM >>>> To: Anima WG >>>> Subject: [Anima] Proposed change to GRASP >>>> >>>> Hi, >>>> >>>> Short version: >>>> >>>> We propose that when an ASA listens for negotiation or synchronization >>>> requests, it should do so on its own transport port number rather than >>>> sharing the generic GRASP port number as currently defined. The >>>> consequence for the protocol is that discovery responses must include a >>>> complete transport address >>>> (locator+protocol+port) instead of just the locator. >>>> >>>> Long version: >>>> >>>> We want ASAs to be able to run as separate modules in user address >>>> space, as applications, rather than being bundled with the GRASP engine >>>> in kernel space. >>>> To achieve this with all ASAs listening on the same port number would >>>> require quite complicated inter-process communication between the >>> GRASP >>>> kernel and the indvidual ASAs. The details of this would be different >>>> in each operating system. >>>> If we allow each ASA to have its own port this can be avoided, and each >>>> ASA can have its own copy of the GRASP API library if required. This >>>> will make the systems engineering of portable ASAs much easier, and >>>> will make the adaptation of the GRASP API library and the GRASP kernel >>>> to various operating systems easier too. >>>> >>>> In practice we need to indicate the protocol (TCP or UDP) as well, >>>> since dynamic ports are assigned for a specific socket and protocol. >>>> >>>> We propose to redefine the locator returned by GRASP discovery >>> accordingly. >>>> For the IPv6 case that would give the following CDDL: >>>> >>>> locator-option /= [O_IPv6_LOCATOR, ipv6-address, transport-proto, >>>> port-number] ipv6-address = bytes .size 16 transport-proto = >>>> IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP = 6 IPPROTO_UDP = 17 >>> port-number >>>> = 0..65535 >>>> >>>> We did consider making this optional, but that would raise >>>> interoperability issues. If an implementation does choose to use the >>>> GRASP_LISTEN_PORT for all ASAs, that could simply be returned as the >>> port-number. >>>> >>>> Implementation note: >>>> >>>> If someone implements multiple ASAs in a common address space, they >> can >>>> share a unicast port and demultiplex incoming messages using other >>>> fields (the Session ID and the Objective name). This change allows >>>> them to be in separate spaces, without requiring it. >>>> >>>> When it starts up, an ASA can obtain an ephemeral port number for each >>>> transport protocol that it supports, and that will be used in discovery >>>> responses. >>>> >>>> This change has already been tested out in the prototype Python code. >>>> >>>> Comments? >>>> >>>> Note: Toerless Eckert brought up this problem and outlined the proposed >>>> solution. Joel Halpern made very helpful comments. >>>> >>>> Brian + co-authors >>>> >>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima From nobody Tue May 3 02:14:42 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C36B12D692 for ; Tue, 3 May 2016 02:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 Yx_3uG-8pY2z for ; Tue, 3 May 2016 02:14:39 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8EB12D0CF for ; Tue, 3 May 2016 02:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1236; q=dns/txt; s=iport; t=1462266879; x=1463476479; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=V/BzEwuUTw135RGzJhwtTgDG4htEWi1a6vcyd1SAgfg=; b=fUIAJZUf2pqv+/cUKLz+gC4QniD7D+HoWxtT7Lk6mUP6e72OvCnHOV9E q1J3bu78t+K8AcAQidSzN4oR0d4Bzbh1zkIgfWdItNKe0xzAoEAnhu3u9 DwRssc6X+JV7/nG/0AqouveWJDV6ns7aMFtNrw1HzQ4x+Y+TPl91rdmCc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQD8aihX/4wNJK1dgziBUAauKIlTg?= =?us-ascii?q?g8BDYF2hhACgT44FAEBAQEBAQFlJ4RBAQEBBDpLBAIBCBEEAQEfCQchERQJCAI?= =?us-ascii?q?EARIIiA0DErYWDYROAQEBAQEBAQEBAQEBAQEBAQEBAQEWhiGETYJDh1UFl2UxA?= =?us-ascii?q?YwggXCPGYdRh2ABHgEBQoNrbAGHPH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208";a="268247378" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 09:14:38 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u439Ecm8006195 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 09:14:38 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 04:14:37 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Tue, 3 May 2016 04:14:37 -0500 From: "Michael Behringer (mbehring)" To: Sheng Jiang , Brian E Carpenter , Anima WG Thread-Topic: [Anima] Proposed change to GRASP Thread-Index: AQHRolVfo1thHjfShUuITphYEhACsJ+mzuGA///9P6A= Date: Tue, 3 May 2016 09:14:37 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 09:14:41 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: 03 May 2016 04:03 > To: Brian E Carpenter ; Anima WG > > Subject: Re: [Anima] Proposed change to GRASP >=20 [...] > One question: does this new namespace also need to be managed by IANA > or there could be other mechanism to manage it so that the uniqueness > could be guaranteed? We need some "common point" to start with. When a node comes up and hasn't = established any AN neighborship, it needs to know which port number to use.= =20 For the bootstrap case, intuitively, that ASA port number should be well kn= own. However, that doesn't help with other ASAs.=20 Maybe there should be a common port for general negotiation, from which we = then derive the other port numbers dynamically?=20 The way I see it right now, on every node there will be a "management ASA",= or "meta ASA", which must be on every node, and is used for controlling th= e other ASAs. We could define a port number for that with IANA, and have al= l other ports negotiated dynamically. Now Stuart would probably say we shou= ld use mDNS for such a purpose... =20 Michael From nobody Tue May 3 02:51:10 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CDD12B05A for ; Tue, 3 May 2016 02:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 4e0rWj-f_R7e for ; Tue, 3 May 2016 02:51:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA74812B02B for ; Tue, 3 May 2016 02:51:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNU93539; Tue, 03 May 2016 09:51:00 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 May 2016 10:50:23 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 3 May 2016 17:50:12 +0800 From: Sheng Jiang To: Brian E Carpenter , "Liubing (Leo)" , Anima WG Thread-Topic: [Anima] Proposed change to GRASP Thread-Index: AQHRolVqBJWxQM8IhE+Gy831tdxeMJ+mdnyA//+RpQCAAA8EAIAA5WKg Date: Tue, 3 May 2016 09:50:11 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927C65D692@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D6C6BC@nkgeml514-mbx.china.huawei.com> <6605faac-23bb-ff83-ddb9-dd25768773a4@gmail.com> In-Reply-To: <6605faac-23bb-ff83-ddb9-dd25768773a4@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57287485.00F5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d4427c564906d85735fb53c3356934bb Archived-At: Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 09:51:09 -0000 PkkgYWN0dWFsbHkgYmVsaWV2ZSB0aGF0IHRoaXMgY2hhbmdlIG1ha2VzIEdSQVNQIGEgbW9yZSBy b2J1c3QNCj5wcm90b2NvbDsgZm9yIGV4YW1wbGUgSSBjYW4gbm93IHJ1biB0d28gY29waWVzIG9m IHRoZSBQeXRob24gcHJvdG90eXBlDQo+aW4gb25lIG1hY2hpbmUsIGFuZCB0aGV5IGNhbiBuZWdv dGlhdGUgd2l0aCBlYWNoIG90aGVyIHF1aXRlIG5pY2VseQ0KPnVzaW5nIGEgZHluYW1pYyBwb3J0 Lg0KDQpUaGlzIGRlc2lnbiB3b3VsZCBoZWxwIHRvIHN0cnVjdHVyZSB0aGUgQVNBcyB3aXRoaW4g YW4gQXV0b25vbWljIE5vZGUuIENvbGxhYm9yYXRpb24gZnVuY3Rpb24vQVNBIGNvdWxkIGJlIGVh c2llciB0byBjb21tdW5pY2F0aW9uIGFtb25nIEFTQXMuDQoNClNoZW5nDQoNCj5SZWdhcmRzDQo+ ICAgQnJpYW4NCj4NCj4NCj5PbiAwMy8wNS8yMDE2IDE1OjExLCBMaXViaW5nIChMZW8pIHdyb3Rl Og0KPj4gSGkgU2hlbmcsDQo+Pg0KPj4gSSBndWVzcyBwdXJlIHRleHQgaXMgbm90IGVhc3kgdG8g Y2xlYXJseSBkZXNjcmliZSB0aGUgbG9naWMuIEJyaWFuIGhhZCBub3RpY2VkDQo+dGhlIGlzc3Vl IG9mIGhvdyB0byBleHBsYWluIGl0IHRvIHRoZSBXRyB3aGVuIHdlIGhhZCBwcml2YXRlIGRpc2N1 c3Npb24uDQo+PiBTbyBsZXQgbWUgcXVvdGUgVG9lcmxlc3MnIGRyYXdpbmcuIE1heWJlIGl0J3Mg bW9yZSBlYXN5IHRvIGJlIHVuZGVyc3Rvb2QuDQo+Pg0KPj4gQmVmb3JlIHF1b3RpbmcgdGhlIGRy YXdpbmdzLCBsZXQgbWUgbWFrZSBhIHNob3J0IGV4cGxhbmF0aW9uOg0KPj4gMS4gQXMgSm9lbCBy ZXBsaWVkLCB0aGUgcG9ydCBudW1iZXJzIGFyZSBub3QgIm5hbWUgc3BhY2UiIG9yICJpZGVudGlm aWVyIiBvZg0KPnRoZSBBU0FzLCB0aGV5IGFyZSB1c2VkIGluIFRDUC9VRFAgd2hlbiBjb21tdW5p Y2F0ZSB3aXRoIHRoZSBBU0FzLg0KPj4gMi4gQWx0aG91Z2ggdGhlIHBvcnQgbnVtYmVycyBhcmUg ZGVmaW5lZCBhcyAicG9ydC1udW1iZXIgPSAwLi42NTUzNSIgaW4NCj50aGUgbG9jYXRlciBvcHRp b24sIGluIHByYWN0aWNlLCBhcyB3ZSBrbm93IHRoZXkgb25seSBoYXZlIGEgbGltaXRlZCByYW5n ZSB0bw0KPmF2b2lkIGNvbGxpc2lvbiB3aXRoIG90aGVyIGFwcGxpY2F0aW9ucy4gRm9yIElBTkEg cmVnaXN0cmF0aW9uLCBJIGd1ZXNzIG5vIG5lZWQNCj5mb3IgQVNBcz8gT3IgbWF5YmUgb25seSB0 aGUgbWV0YS1BU0FzIChzdWNoIGFzIGJvb3RzdHJhcHBpbmcpIG5lZWQgdG8gYmUNCj5yZWdpc3Rl cmVkPw0KPj4NCj4+DQo+PiAqKipOb3cgdGhlIGRyYXdpbmdzKioqDQo+PiBJZiB3ZSBhbGxvY2F0 ZSBwb3J0cyBmb3IgZWFjaCBBU0EsIHRoZW4gdGhlIE9TIGtlcm5lbCBjYW4gZGUtbXVsdGlwbGV4 IEFTQXMNCj5ieSBwb3J0cywgdGh1cyBkaXJlY3RseSBpbnRlcmFjdCB3aXRoIHRoZSBBU0FzIHRo cm91Z2ggc3lzY2FsbCAodmlhIHRoZSB1c2VybGFuZA0KPkdSQVNQIExpYiApLiBJbiB0aGlzIGNh c2UsIHRoZSBiYXNpYyBHUkFTUCBEYWVtb24vRW5naW5lIGNvdWxkIGJlDQo+aW1wbGVtZW50ZWQg aW4gdGhlIE9TIGtlcm5lbCBzcGFjZSwgaXQgaGFuZGxlcyBnZW5lcmljIEdSQVNQIG1lc3NhZ2Vz IChub3QNCj50b3dhcmQgYSBzcGVjaWZpYyBBU0EpIHN1Y2ggYXMgRGlzY292ZXJ5LCBGbG9vZCBl dGMuDQo+Pg0KPj4gICAgfDwtLS0tLSBvbmUgYmluYWVyeSAtLS0tLS0tPg0KPj4gICAgICAgICAg IHBlciBBU0ENCj4+ICAgX19fX19fX19fXyAgICAgIF9fX19fX19fX18gICAgICAgICAgICAgICBf X19fX19fXw0KPj4gICB8IFVzZXJsYW5kIHwgICAgICB8IFVzZXJsYW5kIHwgICAgICAgICAgICAg ICB8ICAgICAgICB8DQo+PiAgIHwgICBBU0EgIHwtLS0tICAgfCBHUkFTUCBMaWJ8LS0tIHN5c2Nh bGwgLS0tICAgICB8ICBLZXJuZWwgfA0KPj4gICB8IF9fX19fX19fX3wgXiAgIHxfX19fX19fX19f fCAgICAgICAgICAgICAgL3xfX19fX19fX3wNCj4+ICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgIC0tLS0tLS8NCj4+ICAgICAgICAgICAgICAgQVBJICAgICBfX19fX19fX19fX19f IC8NCj4+ICAgICAgICAgICAgICAgICAgICAgIHwgIEdSQVNQICAgICB8DQo+PiAgICAgICAgICAg ICAgICAgICAgICB8ICBEYWVtb24gICAgfA0KPj4gICAgICAgICAgICAgICAgICAgICAgfF9fX19f X19fX19fX198DQo+Pg0KPj4NCj4+DQo+PiBXaXRob3V0IEFTQSBwb3J0cywgdGhlcmUgd2lsbCBi ZSBubyB3YXkgZm9yIHRoZSBPUyBrZXJuZWwgdG8gZG8gdGhlDQo+ZGUtbXVsdGlwbGV4aW5nLiBU aHVzLCB0aGUgR1JBU1AgRGFlbW9uIG5lZWRzIHRvIGJlIGluIHRoZSB1c2VybGFuZCBmb3INCj5k ZS1tdWx0aXBsZXhpbmcgKGRlLW11bHRpcGxleCBieSBTZXNzaW9uIElEKS4gVGhlbiwgSVBDIHdp bGwgYmUgaW52b2x2ZWQNCj5iZXR3ZWVuIEFTQSBhbmQgR1JBU1AgZGFlbW9uLCBhcyB0aGUgZmln dXJlIHNob3dzIGJlbG93LiBBbmQgSVBDIGlzDQo+c29tZXRoaW5nIHdlJ2QgYmV0dGVyIG5vdCBn ZXQgaW52b2x2ZWQgaW4sIHRvIGF2b2lkIHVubmVjZXNzYXJ5IGFkZGl0aW9uYWwNCj5zdGFuZGFy ZGl6YXRpb24gd29yay4NCj4+DQo+PiAgIHw8LS0tLS0gb25lIGJpbmFlcnkgLS0tLS0tLT4NCj4+ ICAgICAgICAgICBwZXIgQVNBDQo+Pg0KPj4gICAgX19fX19fX19fXyAgICAgIF9fX19fX19fX18g ICAgICAgICAgIF9fX19fX19fX19fX19fDQo+X19fX19fX18NCj4+ICAgfCBVc2VybGFuZCB8ICAg ICAgfCBVc2VybGFuZCB8ICAgICAgICAgICAgIHwgVXNlcmxhbmQgICAgIHwNCj58ICAgICAgICB8 DQo+PiAgIHwgICBBU0EgICAgfC0tLS18IEdSQVNQIExpYnwtLS1JUEMgLS0gICAgIHwgR1JBU1Ag ZGFlbW9uIHwgLS0tICAgfA0KPktlcm5lbCB8DQo+PiAgIHwgX19fX19fX19ffCBeICB8X19fX19f X19fX3wgICAgICAgICAgfF9fX19fX19fX19fX19ffA0KPnxfX19fX19fX3wNCj4+ICAgICAgICAg ICAgICAgIHwNCj4+ICAgICAgICAgICAgICAgIEFQSQ0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+ IEJpbmcNCj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBBbmlt YSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGVuZyBKaWFu Zw0KPj4+IFNlbnQ6IFR1ZXNkYXksIE1heSAwMywgMjAxNiAxMDowMyBBTQ0KPj4+IFRvOiBCcmlh biBFIENhcnBlbnRlcjsgQW5pbWEgV0cNCj4+PiBTdWJqZWN0OiBSZTogW0FuaW1hXSBQcm9wb3Nl ZCBjaGFuZ2UgdG8gR1JBU1ANCj4+Pg0KPj4+IEhpLCBCcmlhbiAmIFNpZ25hbGluZyBkZXNpZ24g dGVhbSwNCj4+Pg0KPj4+IFRoYW5rcyBmb3IgeW91ciBoYXJkIHdvcmsgYW5kIHRoZSBsYXRlc3Qg ZGVzaWduLiBJdCBsb29rcyB1c2VmdWwgdG8gcXVpY2tseQ0KPj4+IGNsYXNzaWZ5IG9yIGlkZW50 aWZ5IHRoZSBBU0EgaW4gdGhlIHJlY2VpdmVyIHNpZGUuIEhvd2V2ZXIsIG1heSBJIHByb3Bvc2Vk DQo+dGhlDQo+Pj4gcmVuYW1lICJHUkFTUCBwb3J0IG51bWJlciIgdG8gYmUgIkFTQSB0eXBlIG51 bWJlciIsIG9yIHNvbWV0aGluZyBlbHNlDQo+Pj4gd2l0aG91dCAicG9ydCBudW1iZXIiPyBUaGUg aW50cm9kdWN0aW9uIGlzIGVhc2lseSB0byBiZSBtaXNyZWFkLiBBY3R1YWxseSwNCj4+PiB5b3Ug aGF2ZSBjcmVhdGVkIGEgbmV3IG5hbWVzcGFjZS4gVGhlIHdvcmQgInRyYW5zcG9ydCBwb3J0IG51 bWJlciIgaXMNCj4+PiBtaXNsZWFkaW5nLiBXZSBzaG91bGQgaGF2ZSBhIG1vcmUgZXhwbGljaXQg bmFtZS4NCj4+Pg0KPj4+IE9uZSBxdWVzdGlvbjogZG9lcyB0aGlzIG5ldyBuYW1lc3BhY2UgYWxz byBuZWVkIHRvIGJlIG1hbmFnZWQgYnkgSUFOQQ0KPj4+IG9yIHRoZXJlIGNvdWxkIGJlIG90aGVy IG1lY2hhbmlzbSB0byBtYW5hZ2UgaXQgc28gdGhhdCB0aGUgdW5pcXVlbmVzcw0KPj4+IGNvdWxk IGJlIGd1YXJhbnRlZWQ/DQo+Pj4NCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4NCj4+PiBTaGVuZw0K Pj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IEFuaW1hIFtt YWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIEUNCj4+Pj4g Q2FycGVudGVyDQo+Pj4+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAzMCwgMjAxNiA0OjI2IEFNDQo+ Pj4+IFRvOiBBbmltYSBXRw0KPj4+PiBTdWJqZWN0OiBbQW5pbWFdIFByb3Bvc2VkIGNoYW5nZSB0 byBHUkFTUA0KPj4+Pg0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4gU2hvcnQgdmVyc2lvbjoNCj4+Pj4N Cj4+Pj4gV2UgcHJvcG9zZSB0aGF0IHdoZW4gYW4gQVNBIGxpc3RlbnMgZm9yIG5lZ290aWF0aW9u IG9yIHN5bmNocm9uaXphdGlvbg0KPj4+PiByZXF1ZXN0cywgaXQgc2hvdWxkIGRvIHNvIG9uIGl0 cyBvd24gdHJhbnNwb3J0IHBvcnQgbnVtYmVyIHJhdGhlciB0aGFuDQo+Pj4+IHNoYXJpbmcgdGhl IGdlbmVyaWMgR1JBU1AgcG9ydCBudW1iZXIgYXMgY3VycmVudGx5IGRlZmluZWQuIFRoZQ0KPj4+ PiBjb25zZXF1ZW5jZSBmb3IgdGhlIHByb3RvY29sIGlzIHRoYXQgZGlzY292ZXJ5IHJlc3BvbnNl cyBtdXN0IGluY2x1ZGUgYQ0KPj4+PiBjb21wbGV0ZSB0cmFuc3BvcnQgYWRkcmVzcw0KPj4+PiAo bG9jYXRvcitwcm90b2NvbCtwb3J0KSBpbnN0ZWFkIG9mIGp1c3QgdGhlIGxvY2F0b3IuDQo+Pj4+ DQo+Pj4+IExvbmcgdmVyc2lvbjoNCj4+Pj4NCj4+Pj4gV2Ugd2FudCBBU0FzIHRvIGJlIGFibGUg dG8gcnVuIGFzIHNlcGFyYXRlIG1vZHVsZXMgaW4gdXNlciBhZGRyZXNzDQo+Pj4+IHNwYWNlLCBh cyBhcHBsaWNhdGlvbnMsIHJhdGhlciB0aGFuIGJlaW5nIGJ1bmRsZWQgd2l0aCB0aGUgR1JBU1Ag ZW5naW5lDQo+Pj4+IGluIGtlcm5lbCBzcGFjZS4NCj4+Pj4gVG8gYWNoaWV2ZSB0aGlzIHdpdGgg YWxsIEFTQXMgbGlzdGVuaW5nIG9uIHRoZSBzYW1lIHBvcnQgbnVtYmVyIHdvdWxkDQo+Pj4+IHJl cXVpcmUgcXVpdGUgY29tcGxpY2F0ZWQgaW50ZXItcHJvY2VzcyBjb21tdW5pY2F0aW9uIGJldHdl ZW4gdGhlDQo+Pj4gR1JBU1ANCj4+Pj4ga2VybmVsIGFuZCB0aGUgaW5kdmlkdWFsIEFTQXMuIFRo ZSBkZXRhaWxzIG9mIHRoaXMgd291bGQgYmUgZGlmZmVyZW50DQo+Pj4+IGluIGVhY2ggb3BlcmF0 aW5nIHN5c3RlbS4NCj4+Pj4gSWYgd2UgYWxsb3cgZWFjaCBBU0EgdG8gaGF2ZSBpdHMgb3duIHBv cnQgdGhpcyBjYW4gYmUgYXZvaWRlZCwgYW5kIGVhY2gNCj4+Pj4gQVNBIGNhbiBoYXZlIGl0cyBv d24gY29weSBvZiB0aGUgR1JBU1AgQVBJIGxpYnJhcnkgaWYgcmVxdWlyZWQuIFRoaXMNCj4+Pj4g d2lsbCBtYWtlIHRoZSBzeXN0ZW1zIGVuZ2luZWVyaW5nIG9mIHBvcnRhYmxlIEFTQXMgbXVjaCBl YXNpZXIsIGFuZA0KPj4+PiB3aWxsIG1ha2UgdGhlIGFkYXB0YXRpb24gb2YgdGhlIEdSQVNQIEFQ SSBsaWJyYXJ5IGFuZCB0aGUgR1JBU1Aga2VybmVsDQo+Pj4+IHRvIHZhcmlvdXMgb3BlcmF0aW5n IHN5c3RlbXMgZWFzaWVyIHRvby4NCj4+Pj4NCj4+Pj4gSW4gcHJhY3RpY2Ugd2UgbmVlZCB0byBp bmRpY2F0ZSB0aGUgcHJvdG9jb2wgKFRDUCBvciBVRFApIGFzIHdlbGwsDQo+Pj4+IHNpbmNlIGR5 bmFtaWMgcG9ydHMgYXJlIGFzc2lnbmVkIGZvciBhIHNwZWNpZmljIHNvY2tldCBhbmQgcHJvdG9j b2wuDQo+Pj4+DQo+Pj4+IFdlIHByb3Bvc2UgdG8gcmVkZWZpbmUgdGhlIGxvY2F0b3IgcmV0dXJu ZWQgYnkgR1JBU1AgZGlzY292ZXJ5DQo+Pj4gYWNjb3JkaW5nbHkuDQo+Pj4+IEZvciB0aGUgSVB2 NiBjYXNlIHRoYXQgd291bGQgZ2l2ZSB0aGUgZm9sbG93aW5nIENEREw6DQo+Pj4+DQo+Pj4+IGxv Y2F0b3Itb3B0aW9uIC89IFtPX0lQdjZfTE9DQVRPUiwgaXB2Ni1hZGRyZXNzLCB0cmFuc3BvcnQt cHJvdG8sDQo+Pj4+IHBvcnQtbnVtYmVyXSBpcHY2LWFkZHJlc3MgPSBieXRlcyAuc2l6ZSAxNiB0 cmFuc3BvcnQtcHJvdG8gPQ0KPj4+PiBJUFBST1RPX1RDUCAvIElQUFJPVE9fVURQIElQUFJPVE9f VENQID0gNiBJUFBST1RPX1VEUCA9IDE3DQo+Pj4gcG9ydC1udW1iZXINCj4+Pj4gPSAwLi42NTUz NQ0KPj4+Pg0KPj4+PiBXZSBkaWQgY29uc2lkZXIgbWFraW5nIHRoaXMgb3B0aW9uYWwsIGJ1dCB0 aGF0IHdvdWxkIHJhaXNlDQo+Pj4+IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzLiBJZiBhbiBpbXBs ZW1lbnRhdGlvbiBkb2VzIGNob29zZSB0byB1c2UgdGhlDQo+Pj4+IEdSQVNQX0xJU1RFTl9QT1JU IGZvciBhbGwgQVNBcywgdGhhdCBjb3VsZCBzaW1wbHkgYmUgcmV0dXJuZWQgYXMgdGhlDQo+Pj4g cG9ydC1udW1iZXIuDQo+Pj4+DQo+Pj4+IEltcGxlbWVudGF0aW9uIG5vdGU6DQo+Pj4+DQo+Pj4+ IElmIHNvbWVvbmUgaW1wbGVtZW50cyBtdWx0aXBsZSBBU0FzIGluIGEgY29tbW9uIGFkZHJlc3Mg c3BhY2UsIHRoZXkNCj5jYW4NCj4+Pj4gc2hhcmUgYSB1bmljYXN0IHBvcnQgYW5kIGRlbXVsdGlw bGV4IGluY29taW5nIG1lc3NhZ2VzIHVzaW5nIG90aGVyDQo+Pj4+IGZpZWxkcyAodGhlIFNlc3Np b24gSUQgYW5kIHRoZSBPYmplY3RpdmUgbmFtZSkuICBUaGlzIGNoYW5nZSBhbGxvd3MNCj4+Pj4g dGhlbSB0byBiZSBpbiBzZXBhcmF0ZSBzcGFjZXMsIHdpdGhvdXQgcmVxdWlyaW5nIGl0Lg0KPj4+ Pg0KPj4+PiBXaGVuIGl0IHN0YXJ0cyB1cCwgYW4gQVNBIGNhbiBvYnRhaW4gYW4gZXBoZW1lcmFs IHBvcnQgbnVtYmVyIGZvciBlYWNoDQo+Pj4+IHRyYW5zcG9ydCBwcm90b2NvbCB0aGF0IGl0IHN1 cHBvcnRzLCBhbmQgdGhhdCB3aWxsIGJlIHVzZWQgaW4gZGlzY292ZXJ5DQo+Pj4+IHJlc3BvbnNl cy4NCj4+Pj4NCj4+Pj4gVGhpcyBjaGFuZ2UgaGFzIGFscmVhZHkgYmVlbiB0ZXN0ZWQgb3V0IGlu IHRoZSBwcm90b3R5cGUgUHl0aG9uIGNvZGUuDQo+Pj4+DQo+Pj4+IENvbW1lbnRzPw0KPj4+Pg0K Pj4+PiBOb3RlOiBUb2VybGVzcyBFY2tlcnQgYnJvdWdodCB1cCB0aGlzIHByb2JsZW0gYW5kIG91 dGxpbmVkIHRoZSBwcm9wb3NlZA0KPj4+PiBzb2x1dGlvbi4gSm9lbCBIYWxwZXJuIG1hZGUgdmVy eSBoZWxwZnVsIGNvbW1lbnRzLg0KPj4+Pg0KPj4+PiAgICBCcmlhbiArIGNvLWF1dGhvcnMNCj4+ Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+Pj4+IEFuaW1hQGlldGYub3Jn DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEFuaW1h IG1haWxpbmcgbGlzdA0KPj4+IEFuaW1hQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPj4NCg== From nobody Tue May 3 02:57:52 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CDF12D6D9 for ; Tue, 3 May 2016 02:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 29kP4m5xNCWz for ; Tue, 3 May 2016 02:57:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA01A12D6D3 for ; Tue, 3 May 2016 02:57:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNU95025; Tue, 03 May 2016 09:57:48 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 May 2016 10:57:42 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 3 May 2016 17:57:35 +0800 From: Sheng Jiang To: "Michael Behringer (mbehring)" , Brian E Carpenter , Anima WG Thread-Topic: [Anima] Proposed change to GRASP Thread-Index: AQHRolVqBJWxQM8IhE+Gy831tdxeMJ+mdnyA///3KoCAAJCAoA== Date: Tue, 3 May 2016 09:57:34 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927C65D6B0@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5728761C.0084, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d4427c564906d85735fb53c3356934bb Archived-At: Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 09:57:51 -0000 PldlIG5lZWQgc29tZSAiY29tbW9uIHBvaW50IiB0byBzdGFydCB3aXRoLiBXaGVuIGEgbm9kZSBj b21lcyB1cCBhbmQNCj5oYXNuJ3QgZXN0YWJsaXNoZWQgYW55IEFOIG5laWdoYm9yc2hpcCwgaXQg bmVlZHMgdG8ga25vdyB3aGljaCBwb3J0IG51bWJlcg0KPnRvIHVzZS4NCj4NCj5Gb3IgdGhlIGJv b3RzdHJhcCBjYXNlLCBpbnR1aXRpdmVseSwgdGhhdCBBU0EgcG9ydCBudW1iZXIgc2hvdWxkIGJl IHdlbGwNCj5rbm93bi4gSG93ZXZlciwgdGhhdCBkb2Vzbid0IGhlbHAgd2l0aCBvdGhlciBBU0Fz Lg0KPk1heWJlIHRoZXJlIHNob3VsZCBiZSBhIGNvbW1vbiBwb3J0IGZvciBnZW5lcmFsIG5lZ290 aWF0aW9uLCBmcm9tIHdoaWNoDQo+d2UgdGhlbiBkZXJpdmUgdGhlIG90aGVyIHBvcnQgbnVtYmVy cyBkeW5hbWljYWxseT8NCj4NCj5UaGUgd2F5IEkgc2VlIGl0IHJpZ2h0IG5vdywgb24gZXZlcnkg bm9kZSB0aGVyZSB3aWxsIGJlIGEgIm1hbmFnZW1lbnQgQVNBIiwNCj5vciAibWV0YSBBU0EiLCB3 aGljaCBtdXN0IGJlIG9uIGV2ZXJ5IG5vZGUsIGFuZCBpcyB1c2VkIGZvciBjb250cm9sbGluZyB0 aGUNCj5vdGhlciBBU0FzLiBXZSBjb3VsZCBkZWZpbmUgYSBwb3J0IG51bWJlciBmb3IgdGhhdCB3 aXRoIElBTkEsIGFuZCBoYXZlIGFsbA0KPm90aGVyIHBvcnRzIG5lZ290aWF0ZWQgZHluYW1pY2Fs bHkuIE5vdyBTdHVhcnQgd291bGQgcHJvYmFibHkgc2F5IHdlDQo+c2hvdWxkIHVzZSBtRE5TIGZv ciBzdWNoIGEgcHVycG9zZS4uLg0KDQpJIGFncmVlIHRoZSBuZWVkIGZvciBhIG1hbmFnZW1lbnQg QVNBLiBCdXQgSSBhbSBub3Qgc3VyZSBpdCBuZWVkcyBhIGZpeGVkIHBvcnQgbnVtYmVyLiBEeW5h bWljIHBvcnQgbnVtYmVyIGNvdWxkIHdvcmsgd2VsbCBmb3IgbWFuYWdlbWVudCBBU0EsIHRvby4g VGhlICJkaXNjb3ZlcnkgQVNBIiwgaWYgdGhlcmUgd2lsbCBiZSBvbmUsIG5lZWRzIGEgZml4ZWQg cG9ydCBudW1iZXIuIEhvd2V2ZXIsIGl0IGNvdWxkIGp1c3QgdXNlIHRoZSBHUkFTUCBwb3J0IG51 bWJlciwgSSBndWVzcy4gT3IgeW91IG1lYW4gYSBtYW5hZ2VtZW50IEFTQSBpbmNsdWRlcyBkaXNj b3ZlcnkgZnVuY3Rpb24gdG8gZGlzY292ZXIgQVNBcyBvbiBvdGhlciBub2RlPw0KDQpTaGVuZw0K DQo+TWljaGFlbA0KDQo= From nobody Tue May 3 05:51:28 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F57B12D767 for ; Tue, 3 May 2016 05:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 cN1xmOrsoiY6 for ; Tue, 3 May 2016 05:51:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54F912D1DC for ; Tue, 3 May 2016 05:51:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 03EF12002A; Tue, 3 May 2016 08:56:28 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 45AF563755; Tue, 3 May 2016 08:51:22 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG , Sheng Jiang Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:51:26 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > We need some "common point" to start with. When a node comes up and > hasn't established any AN neighborship, it needs to know which port > number to use. I thought that the discovery process for the ASAs ran on the well-known GRASP port. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVyiex4CLcPvd0N1lAQLOCggAnrWgtovkMPZKwAGUOshyFfVH85PLSMO/ 3SWtG79357TVrPvzG7e5hqGjUqtc8hFOlQynYPyMV9fiCHXDWq2ZQzsZIdYKhuJa 1dc5ZAd3III8frnbbguLHMpfBV9QOpQu/fgWyO1hLBGfu23eDvCkhCXHuqtap0qi 8bvcoLW0IcKqtZSah5ARoZzyxbhRdvvZ52InGlJF4sUAg9CkDf4OiRFw3YmS7yhs OOehWY8C7Ol5ete1JQCLBGaZS4T2r1VlNwmt1gaQ2Uev/6xNtPXAW0DnadC7CVt6 xs0DGrG7jCnilZ8J9C6MD2ExxSld7Ga9hCGzXMk5NgWzbX3Tr7i5wg== =5UhG -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 3 12:52:10 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC33412D0DC for ; Tue, 3 May 2016 12:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 nb6FPFW5gGwJ for ; Tue, 3 May 2016 12:52:07 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 1175912D5F6 for ; Tue, 3 May 2016 12:52:07 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id y69so14748910pfb.1 for ; Tue, 03 May 2016 12:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=h918rdw81CEaoban2Nc0jFu6NcSLw1+0gvyJuhiExSg=; b=lG63Gb2IeP3BukPYZGm1iv2REnFC/YVpVukBOQqB76Jat80IXW+vGd+V57SfPpaYjf GEDd1szxIwafqHB++qZewva3t6yuNm0lJ4PgUA0Nt787cJZYZt3RPixvvTnE/2joz+0L vMx09apx4V7e5IoIZXA96VbgJOs6SG1z/HQ5iVXVbFvHK6QpPO0TEQD8AAdtHYDmVy2T rfvB3j7+7669hSVz56vsK/QT9TpHGqOa7Zsbp7KoBTShwz1YDcGb53UKpCaO0qMILzMJ jeDRj57vvxstiiY8Nvvp7ssrfNeFYrvBIRxwnqVWfpyiqvQ02Ck8ynWjdNar6qJ3nS6G QoqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=h918rdw81CEaoban2Nc0jFu6NcSLw1+0gvyJuhiExSg=; b=fQOn0NTTRq112PhXVhkIFzbr/QwuBaNioLtkMDU0n2a6c6QRiw9bsM0sLAIakmx4Hz 34LnQ8BqVk5Yxl0WZJR5yV5rCqKQ8Dv51JZ591PHWnrgBYX2bZYnd4jaRiaumRMvAFhM OMeFR3aBnvB7Qi9TbrkbSkwa6/mhFO8Gr9vXV6jWApvrHIZcLTn1EOlTYfEYgop/3s6f Aetgr1klKLVpJZ6iFr4mIuovBSq3EpC5N0w2lmBGQOte2EBXiYtko1zU8OSfM3LLoih9 Oi2rT1F5Rk7nv1Wz8fJveBu70XrdKkl7vnyRcSNAr8mvJHnwJDCstGrpO0GTX3TP7bmL V7Rg== X-Gm-Message-State: AOPr4FVXH5qQjdkBqVOEYoPnO+EgwGtZTKsgSYCahy1i0blGvlgRuc3Tm6gL+Ox/zJK/0A== X-Received: by 10.98.69.132 with SMTP id n4mr6166009pfi.53.1462305126566; Tue, 03 May 2016 12:52:06 -0700 (PDT) Received: from ?IPv6:2406:e007:4f16:1:28cc:dc4c:9703:6781? ([2406:e007:4f16:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u127sm30150pfb.82.2016.05.03.12.52.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2016 12:52:05 -0700 (PDT) To: Michael Richardson , "Michael Behringer (mbehring)" References: <5D36713D8A4E7348A7E10DF7437A4B927C65D2F3@NKGEML515-MBX.china.huawei.com> <4525.1462279882@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <8eb1b31a-115e-dfa5-2936-4595be6584c3@gmail.com> Date: Wed, 4 May 2016 07:52:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4525.1462279882@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG , Sheng Jiang Subject: Re: [Anima] Proposed change to GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 19:52:09 -0000 On 04/05/2016 00:51, Michael Richardson wrote: > > Michael Behringer (mbehring) wrote: > > We need some "common point" to start with. When a node comes up and > > hasn't established any AN neighborship, it needs to know which port > > number to use. > > I thought that the discovery process for the ASAs ran on the well-known GRASP > port. Yes. The dynamic port only comes in when the ASA starts to listen for specific requests for (unicast) synchronization or negotiation. Brian From nobody Wed May 11 23:22:22 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D464512D61A; Wed, 11 May 2016 23:22:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160512062220.15163.58144.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 23:22:20 -0700 Archived-At: Cc: anima-chairs@ietf.org, terry.manderson@icann.org, anima@ietf.org, jiangsheng@huawei.com Subject: [Anima] anima - New Meeting Session Request for IETF 96 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 06:22:21 -0000 A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: homenet netconf dhc 6tisch nmlrg nmrg Second Priority: 6man softwire roll 6lo supa v6ops Third Priority: cfrg saag intarea opsarea Special Requests: Please arrange the first session on Monday/Tuesday and the second session on Thursday. So the WG participatants could work and make progress between the two sessions. --------------------------------------------------------- From nobody Thu May 12 20:48:30 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F416612D099; Thu, 12 May 2016 20:48:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513034817.31516.10173.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2016 20:48:17 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-grasp-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 03:48:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : A Generic Autonomic Signaling Protocol (GRASP) Authors : Carsten Bormann Brian Carpenter Bing Liu Filename : draft-ietf-anima-grasp-05.txt Pages : 61 Date : 2016-05-12 Abstract: This document establishes requirements for a signaling protocol that enables autonomic devices and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings mutually with them. The document then defines a general protocol for discovery, synchronization and negotiation, while the technical objectives for specific scenarios are to be described in separate documents. An Appendix briefly discusses existing protocols with comparable features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-05 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 Thu May 12 20:53:28 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84312B078 for ; Thu, 12 May 2016 20:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 SKlGCDKKDkXk for ; Thu, 12 May 2016 20:53:25 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 4174C12B061 for ; Thu, 12 May 2016 20:53:25 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id 77so37502403pfv.2 for ; Thu, 12 May 2016 20:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=SFCjOUO1Al7ZsuycwvGe4TX5pSndJwMArCSBhYyK5q0=; b=T+jb0/xRDtaM6XcmcoPfHZLsMxAQ5HyZuuBmDEUkANWjj9RkTxDiRf3/RPtMmUu4YE q4xODrCOIIfwXNSFnpGqNMKnXIHZan9ftGwMVQoDaQVWX2FH88DKnDBH0bhQQp45Lr/b U597DWyvCNWJ6s4EwJWCLLj90jDRByy7gs6I/+DIggvfPsEIGFGuwDS9r/reNcoE01td DrCEYVtd/PWa+mrQl4yC4iEdsbLOF0PVjmeoeTy8wSohEEjVJdhglKTIXkjoO7ji775R 1DHOi6LgvwNs4lDoPK7jYkrhduld8KNx/UOzSg0PY3RDA/xjc3eMGAMqCINeXv8nn+e6 OJzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=SFCjOUO1Al7ZsuycwvGe4TX5pSndJwMArCSBhYyK5q0=; b=MPAvbHsXsHvrJOpQ6p2hdTtm9LQYuR5jVs8VsYJBd/2SUZc3xwrugI4p0nLnm+vj8N DhOy8G6LOkgHWV12jfO5xsEv70ynwILMWvhFSerA3TpI5LL5chM/XkakslRynVmh7rYu Lc1C4OqEJdPdGy6SE3kv+taLlQBXc+ag4R+Xl6dqZw+IX+tCgUU9fCwMOp0qPJWlrpG0 3TN3ZO6vbO1r0OJzudoQQ82YkdffVoAWKBBZp2q3D+ph7umxt9i+6HTxe3w71gJRUqd4 WHTfFaeHCrsbMuyHCn667/a5VTlGvrYgXv8kdkYzOlnb0VBiBhpeLWag79I0n+GJkFV/ b42A== X-Gm-Message-State: AOPr4FXpA2UOVwZAtfIiKeemvn4H2DNqaOEqsH0aUgZGOcbyohlb9lWAmlAqYj/borhdZQ== X-Received: by 10.98.0.9 with SMTP id 9mr19117554pfa.19.1463111604783; Thu, 12 May 2016 20:53:24 -0700 (PDT) Received: from ?IPv6:2406:e007:69e1:1:28cc:dc4c:9703:6781? ([2406:e007:69e1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id fv10sm23166373pad.40.2016.05.12.20.53.22 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 20:53:23 -0700 (PDT) References: <20160513034817.31516.10173.idtracker@ietfa.amsl.com> To: anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 13 May 2016 15:53:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160513034817.31516.10173.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 03:53:27 -0000 Hi, This is an update of GRASP with the change discussed recently (dynamic ports). The full list of changes: Noted in requirement T1 that it should be possible to implement ASAs independently as user space programs. Protocol change: Added protocol number and port to discovery response. Updated protocol description, CDDL and IANA considerations accordingly. Clarified that discovery and flood multicasts are handled by the GRASP kernel, not directly by ASAs. Clarified that a node may discover an objective without supporting it for synchronization or negotiation. Added Implementation Status section. Added reference to SCSP. Editorial fixes. Regards Brian + co-authors On 13/05/2016 15:48, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > Title : A Generic Autonomic Signaling Protocol (GRASP) > Authors : Carsten Bormann > Brian Carpenter > Bing Liu > Filename : draft-ietf-anima-grasp-05.txt > Pages : 61 > Date : 2016-05-12 > > Abstract: > This document establishes requirements for a signaling protocol that > enables autonomic devices and autonomic service agents to dynamically > discover peers, to synchronize state with them, and to negotiate > parameter settings mutually with them. The document then defines a > general protocol for discovery, synchronization and negotiation, > while the technical objectives for specific scenarios are to be > described in separate documents. An Appendix briefly discusses > existing protocols with comparable features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-anima-grasp-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-05 > > > 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 > From nobody Mon May 23 13:44:36 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C9712DBA4 for ; Mon, 23 May 2016 13:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 SkpxNEzmpMUz for ; Mon, 23 May 2016 13:44:34 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 5549E12DB0A for ; Mon, 23 May 2016 13:44:34 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id qo8so66199563pab.1 for ; Mon, 23 May 2016 13:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=vJLjHuuF8MN8Tsvri6Z90+m9KnJXg3Fufo3ip2L/oY0=; b=oTXUwUERdKtuG0BEjLBfLlY2VcswQjpAopxYzG+i6k8ETWhJTDyMYHd4bM4FbjUXCq 4HnZ3HHAyvFs9sUEoxa+lhkketsf+T21uxaWbv5r1x0VvRLlvqs69rjW/DauZtEtilTP YeS8lDURIPR2CMihh8B/bNzzAR/Dff5DYBedqjaxEd1t9H+e4Jgsua+glUeAc1oDhPrm Ia36aHlplxD411/5ZDrKQXxQWEnMnmWIzMwHLE0qH0dUpfQ1bG5ikLU7SEWjF27JmQEw 2cFwRvUStDinaerSMFHNXm/f/CbnexUSvUlJAPAIqq4tWi8VzbUPCDZJUj/6HdiZ3IDs GiHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=vJLjHuuF8MN8Tsvri6Z90+m9KnJXg3Fufo3ip2L/oY0=; b=F92XJ0VgrdnF9R7/k8HL3z5jCBplEZHZJ8K/FUP9KClW5Ha/VpmDelwl911n6YdM48 i4Q6Qwl6reuxQa7/NYe9+oWnMD/iy5s9YW2GIZKJsFtY9NkTy8ssbaMvuCCgqOR0Jms+ 4v9xOH55St08xbLJaHru8r1pzqr6DO9mVXZT5OzkCH4z0BA5J7daPyQDMzoNunOxohVL pBAj9LPrKjZBoq2LLcB0Fzy1DuIO7TlUucVYp5GpqhqghjCLVsjby1dAbUeIxg4duJeF koWod5uht/k5t9OYMHzNcPnzipRllJeOy6jCC/2j7iYv2XGm2SRE6CW5n+a2w8V8t0Nd mckQ== X-Gm-Message-State: ALyK8tIJtcQD/ieuqEwWaPzf6kG2EWJwJlZB7EKtPAS28TEVtEMGaIi3RWoRbhBZtgpAgA== X-Received: by 10.66.27.101 with SMTP id s5mr1097622pag.111.1464036273877; Mon, 23 May 2016 13:44:33 -0700 (PDT) Received: from ?IPv6:2406:e007:5038:1:78b2:4cf2:d9b2:556a? ([2406:e007:5038:1:78b2:4cf2:d9b2:556a]) by smtp.gmail.com with ESMTPSA id eh9sm48801623pad.47.2016.05.23.13.44.32 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 13:44:33 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <084164d1-d54a-b1ca-d657-63c863522984@gmail.com> Date: Tue, 24 May 2016 08:44:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Anima and renumbering X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 20:44:35 -0000 I made an unplanned experiment yesterday. Because of a discussion in 6man, I set up my laptop to run with only temporary IPv6 addresses (RFC 4941 addresses). And then I ran my tests of the GRASP prototype for a while. After half an hour or so, GRASP stopped working, because the laptop's address changed automatically, so the cached discovery results became invalid. So, one conclusion is that my implementation should be more aggressive about aging out the discovery cache. But it raises a question about how resistant we need the Anima infrastructure to be against renumbering. It seems to me that an autonomic mechanism really needs to repair itself in that case. Any thoughts? Regards Brian From nobody Tue May 24 04:45:56 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7779312D0B0 for ; Tue, 24 May 2016 04:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 j-FpkCVggv9f for ; Tue, 24 May 2016 04:45:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF37A12D1A7 for ; Tue, 24 May 2016 04:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2062; q=dns/txt; s=iport; t=1464090352; x=1465299952; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VAcNMcY0tQVjFpYZJXdnfQ/hUS299c/0QOgmNI2oSBY=; b=bAANTWPlBIsUt7872rMVm0xqW9L89KFEbOfi4T7qJ0MzGwb7mQe3Gvbn 9oTXnFlXYWlcDmuG7TFYSCNA66xBelUEM0sKXbmgjup2Zhl9UdXKxaj0L AKUL8+D3KtX73e+5+VclCKq/C2FI3UMvhh1uIo1+TITtVr9NFKsH87Dh1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgB9PkRX/49dJa1cgzdWfQa5eAENg?= =?us-ascii?q?XYihW8CgTM4FAEBAQEBAQFlJ4RCAQEBBDoxGgQCAQgRBAEBHwkHMhQJCAIEARI?= =?us-ascii?q?IiCcOxCYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYnhEyKGQWYNwGFf4gZgXCET?= =?us-ascii?q?4hkj0sBHgEBQoNtbgGIEiQbfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,359,1459814400"; d="scan'208";a="105476586" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2016 11:45:52 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4OBjqE0007177 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 May 2016 11:45:52 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 May 2016 06:45:51 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Tue, 24 May 2016 06:45:51 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Anima and renumbering Thread-Index: AQHRtTPv3boZo0h320C/K0P+Cdcr/p/H9AtQ Date: Tue, 24 May 2016 11:45:50 +0000 Message-ID: References: <084164d1-d54a-b1ca-d657-63c863522984@gmail.com> In-Reply-To: <084164d1-d54a-b1ca-d657-63c863522984@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Anima and renumbering X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 11:45:54 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 23 May 2016 22:45 > To: Anima WG > Subject: [Anima] Anima and renumbering >=20 > I made an unplanned experiment yesterday. Because of a discussion in > 6man, I set up my laptop to run with only temporary IPv6 addresses (RFC > 4941 addresses). And then I ran my tests of the GRASP prototype for a whi= le. > After half an hour or so, GRASP stopped working, because the laptop's > address changed automatically, so the cached discovery results became > invalid. >=20 > So, one conclusion is that my implementation should be more aggressive > about aging out the discovery cache. But it raises a question about how > resistant we need the Anima infrastructure to be against renumbering. It > seems to me that an autonomic mechanism really needs to repair itself in > that case. Any thoughts? Hmmm... I'm not an IPv6 expert, so please bear with me.=20 https://tools.ietf.org/html/rfc4862#section-5.3 states explicitly that "A l= ink-local address has an infinite preferred and valid lifetime; it is never= timed out." https://tools.ietf.org/html/rfc4941#section-3.3 implies that the procedure = applies only to global scope addresses:=20 "This document extends [ADDRCONF] as follows. When processing a Router Advertisement with a Prefix Information option carrying a global scope prefix for the purposes of address autoconfiguration (i.e., the A bit is set), the node MUST perform the following steps:" Therefore, link local addresses, in my reading, do not use temporary addres= ses a la RFC 4941. Correct so far?=20 I would further claim that addressing inside the ACP does not require tempo= rary addresses, since the ACP is a secured overlay network.=20 Therefore, if GRASP runs on link local addressing in the data plane, and if= we use static, greater-than-link-local scope only inside the ACP (which is= my assumption), we should be fine, right? Michael From nobody Tue May 24 13:27:39 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D8712D512 for ; Tue, 24 May 2016 13:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 thyUd-ZhLuqN for ; Tue, 24 May 2016 13:27:28 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 2B19C12D504 for ; Tue, 24 May 2016 13:27:28 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id xk12so9868712pac.0 for ; Tue, 24 May 2016 13:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=iBdZBU1x6OvnogF0UKp7fONgP8vYDXE0h9+zoY5ZVYM=; b=0N4BXcvUHlVV/T1DAJf35vQaRssHKDAlLRy26wbAo0BB7o1md0fo8T0eh5Y8p4Upaz SxuGgEuDCVwaW3yPkqOAWoR2bJYHm9dG6Wu9cR8XqXGnPSJDa0xhVZ1YcKXKyAjAwc8c o9JHnu+T48afs3cjQeXYxUOlvV0LJOBj1kER1IpRCr7sPnGi4fNZYQvj+9wMZe0IYlST Cven0JQQFDFToTPQGyznPJTu9mA3ljGAy4SxwM9Ps2BBTrUzPEP19nhiDO54t4CkaDQt gP6C70HZe6sNUgyc3l/euOFOFbIt3gNCee/h5xYQbIdI3GUXbXmMjs2Jv7R2lFqwNWBn ZH1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=iBdZBU1x6OvnogF0UKp7fONgP8vYDXE0h9+zoY5ZVYM=; b=DqbNwj7ET/LmdFliPM0dbI68ko3s3IiXhKWR/0AY1bqGZ3mk1ceKl1wzqDjCHYAMBz uYDaHwQEIYqfgOHSHMOCjKdvjjbvu3mqeleFq78q+dVvbhFW5eokZMwLx/MJov5MGW9Y 2TDYW2bRA+rgAF+0Ny8PyJ6k/i9Olk8Pvb9Ttj7uY1fRzY9TySS6DinvC11s7JbgscrU +kiD8w/HoEDBXXbP1EasKAx2iBcF7nQXY8JT6RJgkG/FIMHIGKn26hHYyzaDBH5eXjnA DuyM5l4oLesiXgj0z6gLOabhNJgo/rkN+dSNFzoFMFzvrXYd3Q2ox4IFsGKoG+z6Uspb gXqw== X-Gm-Message-State: ALyK8tLV/EBcS+Q1EpYc1DY8ujmkmjgHcGB/zfrcLVFT1sOvDNfJi73K0MTMBQUTk/88kg== X-Received: by 10.66.148.230 with SMTP id tv6mr70119pab.89.1464121647692; Tue, 24 May 2016 13:27:27 -0700 (PDT) Received: from ?IPv6:2406:e007:51cc:1:6d59:c4ad:d071:e461? ([2406:e007:51cc:1:6d59:c4ad:d071:e461]) by smtp.gmail.com with ESMTPSA id 141sm19234935pfx.68.2016.05.24.13.27.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 13:27:26 -0700 (PDT) To: "Michael Behringer (mbehring)" , Anima WG References: <084164d1-d54a-b1ca-d657-63c863522984@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2a1587d7-2ca9-69ae-8c04-49300d2f73b1@gmail.com> Date: Wed, 25 May 2016 08:27:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Anima and renumbering X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 20:27:37 -0000 Hi Michael, On 24/05/2016 23:45, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 23 May 2016 22:45 >> To: Anima WG >> Subject: [Anima] Anima and renumbering >> >> I made an unplanned experiment yesterday. Because of a discussion in >> 6man, I set up my laptop to run with only temporary IPv6 addresses (RFC >> 4941 addresses). And then I ran my tests of the GRASP prototype for a while. >> After half an hour or so, GRASP stopped working, because the laptop's >> address changed automatically, so the cached discovery results became >> invalid. >> >> So, one conclusion is that my implementation should be more aggressive >> about aging out the discovery cache. But it raises a question about how >> resistant we need the Anima infrastructure to be against renumbering. It >> seems to me that an autonomic mechanism really needs to repair itself in >> that case. Any thoughts? > > Hmmm... I'm not an IPv6 expert, so please bear with me. > > https://tools.ietf.org/html/rfc4862#section-5.3 states explicitly that "A link-local address has an infinite preferred and valid lifetime; it is never timed out." Correct, although there is one corner case. If you build your link local address using the MAC address, and you are running with randomized MAC addresses, I suppose the link local address could become invalid. > > https://tools.ietf.org/html/rfc4941#section-3.3 implies that the procedure applies only to global scope addresses: > "This document extends [ADDRCONF] as > follows. When processing a Router Advertisement with a Prefix > Information option carrying a global scope prefix for the purposes of > address autoconfiguration (i.e., the A bit is set), the node MUST > perform the following steps:" > > Therefore, link local addresses, in my reading, do not use temporary addresses a la RFC 4941. Correct so far? Correct. > I would further claim that addressing inside the ACP does not require temporary addresses, since the ACP is a secured overlay network. I believe that's correct, but probably it should be stated explicitly in the addressing specification, since stable vs temporary addresses is a very hot topic in 6man at the moment. > Therefore, if GRASP runs on link local addressing in the data plane, and if we use static, greater-than-link-local scope only inside the ACP (which is my assumption), we should be fine, right? Yes. But in the case that people deploy AN components without an ACP, which we have always said would be possible but not recommended, I think the issue could arise. Acually the possibility of data plane renumbering is a very strong argument for the ACP approach with ULA addressing, since it allows stable addresses for the ANI whatever happens in the data plane. So maybe this is something for the next rev of the reference model. Brian From nobody Tue May 24 17:03:21 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB91612D5D4 for ; Tue, 24 May 2016 17:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 pjRj9VYWA0ZE for ; Tue, 24 May 2016 17:03:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3DA12D132 for ; Tue, 24 May 2016 17:03:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 207FE2009E; Tue, 24 May 2016 20:09:37 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7B2A3638BF; Tue, 24 May 2016 20:03:17 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <084164d1-d54a-b1ca-d657-63c863522984@gmail.com> References: <084164d1-d54a-b1ca-d657-63c863522984@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] Anima and renumbering X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 00:03:20 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > I made an unplanned experiment yesterday. Because of a discussion in > 6man, I set up my laptop to run with only temporary IPv6 addresses (RFC > 4941 addresses). And then I ran my tests of the GRASP prototype for a > while. After half an hour or so, GRASP stopped working, because the > laptop's address changed automatically, so the cached discovery results > became invalid. I think that this is possibly a fault in OS or GRASP code :-) Does your implemention bind(2) a socket to the address in question, or just to ::? If it bind(2)s, then the OS can't remove the IP, even if it moves on to use another address. I've seen bugs where it does anyway... If it binds :: only, then it didn't latch onto an IP, and it should have been listening for address changes if it's going to tells others how to reach it. This isn't easy with the official APIs that we have, alas. If it had heard the address change, then it would have sent out a new address, right? > So, one conclusion is that my implementation should be more aggressive > about aging out the discovery cache. But it raises a question about how > resistant we need the Anima infrastructure to be against > renumbering. It seems to me that an autonomic mechanism really needs to > repair itself in that case. Any thoughts? Again, our APIs don't tell us what the TTL on the temporary address is either, so we can't even know when to stop announcing it. My belief is that our ACP will be designed to essentially avoid renumbering; doing so only when two ACPs merge due to an acquisition or something, and then it will be very much make-before-break over a period of days to months. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV0TrwoCLcPvd0N1lAQK2IAf/dr7Yn0Mm70cPBpntEqd6XseJ0i6JH3qS j1sTFkjvhf8xXwsmpL5P0ub82d0oKMnJ1iZpMnM49tPb7H7hEx3PpUhvgrtC8sLG 9Jm6G8aH+rtr0hBPt0JI7VaCneAUeszN/75BMgp7BbAGdV8fo86hx+B7ETh6K+pY ODUwrinPBgwCcV4kTtSny8q1OZab8lkFTbGNussmvroUP+6KxYUwbHydpGr7xN/Q xYf+rVl9ecZa65ms9N0k8y7jEH03PNxS99tDoI9NU2l17zCFN86nKMAxVbXbuARZ tOUYpmWn4GbnOg+tv4Fi+x7rQE+ajbTuA0zgG9rkD7jtslyYAZOGNQ== =OnJ1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 24 18:22:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBB012D5E8 for ; Tue, 24 May 2016 18:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 8Gw2j2Sx6mlC for ; Tue, 24 May 2016 18:22:41 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 335D312D5E3 for ; Tue, 24 May 2016 18:22:41 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id c189so12455738pfb.3 for ; Tue, 24 May 2016 18:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CmMwM9Hoo5URK3/jgoiKVGWl51kwMaVWKh/ZF2gxE4U=; b=RFATJ3UsmfRYG2m7Lrf2hEfPpgY5deOyfXicWO4DIDZs3ZTJWfQjOk63qF+bXYOCG2 IfEBveuaW1EuCYbUNqqZWqfqq+p+ju/RysxCnYovIu24FCGUXn8WGP84LwT4qDBI7VPI Km4zIKAK7TP6uE4x1UrRyorGFMPVX7/HUwxJkOIKiIMa+Rw+fa+I58cqbkg7eHhzTNcd vrl7iAic8LLGUwvPDm9d9+cb87DoGZvJ2QnIXGn5kcsUlOom0nUrAH94P1a7FD4n5H/c bCiUmChggZ47Khw8pcOtqq6B7UPdhIGboGs6Wiv0EP/tcJedNNB53MxKCHqVmPerIG4k YzJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=CmMwM9Hoo5URK3/jgoiKVGWl51kwMaVWKh/ZF2gxE4U=; b=Cum/ZfOw8Sm0Muk0w35h+BbUlcIOTYrklDGDPTiMZhuaEMMFGTC01esnaq9FhI9vg2 6Y3+DAOARPrmE4/nxAv1pnfGWxsmtY8yvjj+49iU+xp7xFyywj2of3kJx/H0pzQ6E25P D4tjJP/LA3MqN0CDt7627G+ei0iGgMYSdDZYXzeNze2SgMIKEISIo6n3Rj7TIyQ+Hw6w HS6y95YrRbSpl8LjIlPVRqVZHAckyNSdLET4sfR8RtN+myaX6gM95dmHo2n9jDAt4yaI A+9ol2k/PonrSZWk+APQx9/gmibBnuaShfe4qKnWOBQngovls+Wr4H6mj33TwMDLfQAF hHFw== X-Gm-Message-State: ALyK8tKQZGIT9Slkol1tPoSc0Iy+6DOX/VTcvHvW+dMpXbB8W0J5aFndOrD5Dpv4U16cpQ== X-Received: by 10.98.100.132 with SMTP id y126mr1745700pfb.101.1464139360560; Tue, 24 May 2016 18:22:40 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:15e6:4315:e561:8f34? ([2001:df0:0:2006:15e6:4315:e561:8f34]) by smtp.gmail.com with ESMTPSA id lg17sm8007410pab.36.2016.05.24.18.22.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 18:22:39 -0700 (PDT) To: Michael Richardson References: <084164d1-d54a-b1ca-d657-63c863522984@gmail.com> <8585.1464134597@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <375290bc-f12f-a0d3-1606-4068c8db9986@gmail.com> Date: Wed, 25 May 2016 13:22:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <8585.1464134597@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] Anima and renumbering X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 01:22:43 -0000 Hi Michael, On 25/05/2016 12:03, Michael Richardson wrote: > > Brian E Carpenter wrote: > > I made an unplanned experiment yesterday. Because of a discussion in > > 6man, I set up my laptop to run with only temporary IPv6 addresses (RFC > > 4941 addresses). And then I ran my tests of the GRASP prototype for a > > while. After half an hour or so, GRASP stopped working, because the > > laptop's address changed automatically, so the cached discovery results > > became invalid. > > I think that this is possibly a fault in OS or GRASP code :-) > > Does your implemention bind(2) a socket to the address in question, or just > to ::? If it bind(2)s, then the OS can't remove the IP, even if it moves on > to use another address. I've seen bugs where it does anyway... You mean at the "server" end (the responder, in GRASPtalk)? It binds to '' (in Python, which is ::). But the code needs to know the current address, because it has to be included in discovery responses. The bug is lazy implementation in the prototype. I would need to check periodically if the local address had changed, and then work some magic to kill and recreate all affected sockets, and rely on discovery cache timeouts in other nodes. If we want to be renumbering proof, that needs to be mentioned in the protocol spec. If not, we need a warning that we are not renumbering proof. > If it binds :: only, then it didn't latch onto an IP, and it should have > been listening for address changes if it's going to tells others how to reach > it. This isn't easy with the official APIs that we have, alas. If it had > heard the address change, then it would have sent out a new address, right? s/would/should/ ;-) I know where to do this, because I already have some dummy code that 'watches' the ACP and in theory would switch TLS on if the ACP went away. The same thread could watch for an address change. > > So, one conclusion is that my implementation should be more aggressive > > about aging out the discovery cache. But it raises a question about how > > resistant we need the Anima infrastructure to be against > > renumbering. It seems to me that an autonomic mechanism really needs to > > repair itself in that case. Any thoughts? > > Again, our APIs don't tell us what the TTL on the temporary address is > either, so we can't even know when to stop announcing it. Yep. I have a Python hack that runs on both Windows and Linux to find a valid global address, given the lack of a good way to do it. I could use that code to detect address changes after the fact. But it's messy. (So is the code I have to figure out link-local details. If you care, look in my source code for the comment including "pain-in-the-neck".) > My belief is that our ACP will be designed to essentially avoid renumbering; > doing so only when two ACPs merge due to an acquisition or something, and > then it will be very much make-before-break over a period of days to months. Agreed. I would just like GRASP to be robust when it is unfortunate enough to run without an ACP. Brian From nobody Mon May 30 19:17:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9818512D113 for ; Mon, 30 May 2016 19:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 WtoJKtS57-0Y for ; Mon, 30 May 2016 19:17:00 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 CADC412B076 for ; Mon, 30 May 2016 19:17:00 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id b124so69068214pfb.0 for ; Mon, 30 May 2016 19:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=RD0vlHjyp5dviog20YDK1lxDUB3iaMkhU3B/NvMbhA8=; b=YoWUlsHG5brMwdlwn3Yq84CR82m/7X2PsJKt+Yhm7He50+7CIpmMF2ICOOI3r+TLWg 5WL3P8/yOpuqEkZjr0rHV4/ZyMcDJUSmBDrAA6ywVdXbsej0dY9xP+F85vjRsKZMJkjA cMu9YrPcvkaJxKnXv+CLPWXTsG7QvSrfuqC3rQHR1MTRqAO6rKJ/RgH8efyzblNdlL5l PIkurlRlO3uyZEmdlglx57lpMOYLw88cpv4UgQn6IpYYn6vJOESooVsA7GzBWfcq4Qoa zeHd1HhwzzBez6lu2ILIupO+Pq+dKYxGTsfeOxwlMbvY825NsdZwrkD62YqzdVbSM//z G7Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=RD0vlHjyp5dviog20YDK1lxDUB3iaMkhU3B/NvMbhA8=; b=G11HkiZhZNyPCkjtj9rpiWputRa5fzvcv7f322iOhaHrzJDw00USLOYQ8hdTNKLLhK 9O6JWKb4CxOpU8QlbWQWDGRnHpLlcY6X8W4/YEL1PLK/fHI5mvTPzDrKbI3sR4DJ/Jpd UQMf/bjPf1lf/BdwiafkpCs0r0fMWIoy3iy1IZpL0t9PtMlFrPioKiQFjQ7nWSpvLYuc R2OOMaklCLWTEEtmoQkYcc3kVB3stPGlwmECzBeFRRCUkqZ/UK3G4qwxeCneh9E2nqlI Y5Xci0dSvaw6nigfRplO2Bh4l6ZY2N/YXCxzKIO3Vnx/ptE2qCTvdKk9yIChH2ZL8NE0 tUHw== X-Gm-Message-State: ALyK8tIymCSAH8XL//azKFb9sBg1LqK1/f6a2hcSNkDMHwr4192e+RfglC9gOffsEUMIgQ== X-Received: by 10.98.3.4 with SMTP id 4mr51389114pfd.33.1464661020166; Mon, 30 May 2016 19:17:00 -0700 (PDT) Received: from ?IPv6:2406:e007:7211:1:801:a825:24ba:aefd? ([2406:e007:7211:1:801:a825:24ba:aefd]) by smtp.gmail.com with ESMTPSA id s90sm27930599pfj.86.2016.05.30.19.16.58 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 19:16:59 -0700 (PDT) From: Brian E Carpenter To: Anima WG Organization: University of Auckland Message-ID: Date: Tue, 31 May 2016 14:16:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP and renumbering: suggestions and a question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 02:17:02 -0000 Hi WG, I expect you saw the recent messages about renumbering, and you may have seen the big discussion in 6man about stable addresses. I think we are clear that address stability for the autonomic infrastructure is very desirable, but the fact remains that in IPv6 addresses can always change, so GRASP needs to tolerate that. After a little discussion on the design team list, I have two suggestions for GRASP, and a question for the WG: 1) In the description of discovery, we need to say more about the discovery cache timeout After a GRASP device successfully discovers a Discovery Responder supporting a specific objective, it MUST cache this information. This cache record MAY be used for future negotiation or synchronization, and SHOULD be passed on when appropriate as a Divert option to another Discovery Initiator. The cache lifetime is an implementation choice that MAY be modified by network Intent. I suggest adding something more here: In some environments, unexpected address renumbering might occur. In such cases, the cache lifetime SHOULD be short compared to the expected address lifetime and a mechanism to flush the discovery cache SHOULD be implemented. 2) We should also add something to the API, to allow an ASA to optionally flush previously discovered locators. Now the question. Should we add a TTL to discovery responses? It isn't very hard to do. Pro: - This would allow discovery cache timeouts to be tailored per ASA instance instead of per network. Con: - It slightly expands the Discovery Response message. - It adds minor complexity to the discovery cache handling. Comments? Opinions? Brian