From nobody Mon May 4 00:12:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675361ACD98 for ; Mon, 4 May 2015 00:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ORKqeklHRp8Z for ; Mon, 4 May 2015 00:12:38 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2BE1ACD8A for ; Mon, 4 May 2015 00:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2210; q=dns/txt; s=iport; t=1430723558; x=1431933158; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xwJrxDErhZL13me6+jjyAuUBZm4wVRWedxw538wepPs=; b=isxSyQ0sFH/eLOdo1b4IkRbJR2CW8948MPt2KwO87KqGLiNL+TsIKBna TVt1/KKr9qZECllg6In8mqXx7Olp3EVZWzYVAGVqH0eYfEkrbPpH7HOHx tVSoIkcGOm6+AkGzdZS/mS4BBc7lqyXxabdYW0qVFPec1ri6cJaLqCFjG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CUBACIG0dV/4wNJK1cgwxTXAXEemYJgUwKhgQCgTs4FAEBAQEBAQGBCoQgAQEBAwEBAQE3NBAHBAIBCBEEAQEBChQJBycLFAkIAQEEARIIiBsIDcRbAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLOYRUOAaDEYEWBZINoHAjggccgVFvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,365,1427760000"; d="scan'208";a="146733549" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP; 04 May 2015 07:12:37 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t447Cbjx008197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 May 2015 07:12:37 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.98]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 4 May 2015 02:12:37 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Addressing-interface addressing Thread-Index: AdB+aWxBd2bophqyRBWx7u68gJs1cwAbZbqAAAaploAB0fSNgA== Date: Mon, 4 May 2015 07:12:36 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> In-Reply-To: <553A9E3F.1020008@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 May 2015 07:12:39 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 24 April 2015 21:49 > To: anima@ietf.org > Subject: Re: [Anima] Addressing-interface addressing >=20 > On 25/04/2015 04:38, Michael Richardson wrote: > > > > Liubing (Leo) wrote: > > > This is another topic regarding to autonomic addressing. > > > > > For autonomic network infrastructure, is it sufficient to self-as= sign > > > the devices' interfaces link-local addresses? Do we need to assig= n the > > > interfaces ULA/GUA addresses in some scenarios? > > > > I think that the answer depends upon which interface you are talking > about. > > > > The only way that I can see that we can use and also route link-local > > addresses would be if we are in fact creating some kind of NBMA > > interface for an ACP "LAN". > > > > I don't think that's a good idea. I think it is better to use a ULA >=20 > I agree. Otherwise, how do nodes on different links communication > independently of the user-visible addressing scheme? >=20 > > (and I > > have said I favour a ULA-C approach) on a loopback interface. >=20 > IMHO we don't need -C. That would imply yet another external dependency > (on a non-existent registry that has no funding model anyway). Vanilla UL= A > works fine. Slightly confused. I think on the loopback interfaces we agree we need some= thing routable, and that ULA (ignore the flavour for a second) is the right= thing here. And on the interfaces to other nodes we use link local. Are we= saying the same thing?=20 Michael =20 > Regards > Brian >=20 > > I am happy to > > use SLAAC or Stable-Private (7217) for that address. > > > > > > -- > > Michael Richardson , Sandelman Software > Works > > -=3D IPv6 IoT consulting =3D- > > > > > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon May 4 00:44:35 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F316E1ACDBD for ; Mon, 4 May 2015 00:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 jbLUKwcGgCyg for ; Mon, 4 May 2015 00:44:32 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (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 518DA1ACDBB for ; Mon, 4 May 2015 00:44:32 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so156290618pdb.0 for ; Mon, 04 May 2015 00:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f692pMP5onrlP0dFC/e43ynLSVaygHu5QppD2TsrbSY=; b=NB3BjW7Fzc9Cw7eKCIxBbJy+qYl1+37iRMjL0Vp4zHyQjiMLC1Y5AsdvC16kqKW10L +aDkdBwDxdt3StbN2p2qT/eLuyHREshVZ8/8Ckc10Zl2kA2ou3SYoPq/JUOX8pVJNCGy h0orIkqiTVmDGLa5XeKxRY6ibpOYmxucPQoWBixoSW5bG+TI+cAu/60yokj84/5/BY8Q sRSLpV91aa1SWAJvxEX0cUVwcU+C7lUghxDGh2y9j/wY+cSicplAIyF08mNQraUAU/RW fMJu386ZwA1AxInUZvMeI4MNPbRXAna81YpWDnT9mOfgNOAMez3IHKbc3XFMyn9BKmbu FXtw== X-Received: by 10.66.65.204 with SMTP id z12mr40840105pas.155.1430725471982; Mon, 04 May 2015 00:44:31 -0700 (PDT) Received: from ?IPv6:2406:e007:52e2:1:28cc:dc4c:9703:6781? ([2406:e007:52e2:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id mx5sm11877937pdb.75.2015.05.04.00.44.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2015 00:44:30 -0700 (PDT) Message-ID: <5547235B.5090401@gmail.com> Date: Mon, 04 May 2015 19:44:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "anima@ietf.org" References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 May 2015 07:44:34 -0000 Hi Michael, On 04/05/2015 19:12, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 24 April 2015 21:49 >> To: anima@ietf.org >> Subject: Re: [Anima] Addressing-interface addressing >> >> On 25/04/2015 04:38, Michael Richardson wrote: >>> >>> Liubing (Leo) wrote: >>> > This is another topic regarding to autonomic addressing. >>> >>> > For autonomic network infrastructure, is it sufficient to self-assign >>> > the devices' interfaces link-local addresses? Do we need to assign the >>> > interfaces ULA/GUA addresses in some scenarios? >>> >>> I think that the answer depends upon which interface you are talking >> about. >>> >>> The only way that I can see that we can use and also route link-local >>> addresses would be if we are in fact creating some kind of NBMA >>> interface for an ACP "LAN". >>> >>> I don't think that's a good idea. I think it is better to use a ULA >> >> I agree. Otherwise, how do nodes on different links communication >> independently of the user-visible addressing scheme? >> >>> (and I >>> have said I favour a ULA-C approach) on a loopback interface. >> >> IMHO we don't need -C. That would imply yet another external dependency >> (on a non-existent registry that has no funding model anyway). Vanilla ULA >> works fine. > > Slightly confused. I think on the loopback interfaces we agree we need something routable, and that ULA (ignore the flavour for a second) is the right thing here. And on the interfaces to other nodes we use link local. Are we saying the same thing? In the context of the ACP, I think we're saying the same thing. ACP addresses are routeable within the ACP (which is to say, they are routeable among ASAs, via their ACP virtual* interfaces). However, if for some reason we have no ACP, the ASAs will need some other kind of routeable address, of course. *"loopback interface" is not in my vocabulary. Brian > > Michael > >> Regards >> Brian >> >>> I am happy to >>> use SLAAC or Stable-Private (7217) for that address. >>> >>> >>> -- >>> Michael Richardson , Sandelman Software >> Works >>> -= IPv6 IoT consulting =- >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 4 07:18:30 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E031A0145 for ; Mon, 4 May 2015 07:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 fvs0VSOcX2Bb for ; Mon, 4 May 2015 07:18:27 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC32D1A0111 for ; Mon, 4 May 2015 07:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2382; q=dns/txt; s=iport; t=1430749101; x=1431958701; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KYe0m2L6MV1/yP2SWjr1InWRblVZf8fBIYqNy5Nw4IU=; b=Km7wCyjW9kOadWkJ2X5NUHWohQmK+/0dB51fO0YWhaWpRjuoXWyd3dp7 Jxp7OSuv6fWb6w08tyYWRL7jjyQwOVaIfDkWIpTezkLky8oOGqS+qiOW8 Cx18pcSDAWV86ccGCeDpMdKqueA+X5j1gz84Ro3Camowtv30wEZA6ZbT7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CSBAD6fkdV/4wNJK1cgwyBNIMYwWJmCYR9gl0CHIEOOBQBAQEBAQEBgQqEIAEBAQMBIxFKCwIBCBoCBiACAgIwFRABAQQBGogbCLI6kzQBAQEBAQEBAQEBAQEBAQEBAQEBGYEhihiEVBYigmgvgRYFkg2LdpEog1Ijg3SCM4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,366,1427760000"; d="scan'208";a="146921099" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP; 04 May 2015 14:18:21 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t44EIKKi003779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 May 2015 14:18:20 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.98]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Mon, 4 May 2015 09:18:20 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Addressing-interface addressing Thread-Index: AdB+aWxBd2bophqyRBWx7u68gJs1cwAbZbqAAAaploAB0fSNgAALpKyAAAgz3VA= Date: Mon, 4 May 2015 14:18:19 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> In-Reply-To: <5547235B.5090401@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.136] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 May 2015 14:18:29 -0000 PiBJbiB0aGUgY29udGV4dCBvZiB0aGUgQUNQLCBJIHRoaW5rIHdlJ3JlIHNheWluZyB0aGUgc2Ft ZSB0aGluZy4gQUNQDQo+IGFkZHJlc3NlcyBhcmUgcm91dGVhYmxlIHdpdGhpbiB0aGUgQUNQICh3 aGljaCBpcyB0byBzYXksIHRoZXkgYXJlIHJvdXRlYWJsZQ0KPiBhbW9uZyBBU0FzLCB2aWEgdGhl aXIgQUNQIHZpcnR1YWwqIGludGVyZmFjZXMpLiBIb3dldmVyLCBpZiBmb3Igc29tZSByZWFzb24N Cj4gd2UgaGF2ZSBubyBBQ1AsIHRoZSBBU0FzIHdpbGwgbmVlZCBzb21lIG90aGVyIGtpbmQgb2Yg cm91dGVhYmxlIGFkZHJlc3MsDQo+IG9mIGNvdXJzZS4NCg0KQWdyZWVkLiBSZS1waHJhc2luZzog SW4gYm90aCBjYXNlcyAod2l0aCBhbmQgd2l0aG91dCBBQ1ApIGEgZGV2aWNlIG5lZWRzIGEgcm91 dGFibGUgYWRkcmVzcyB3aGljaCBpcyB1c2VkIGJ5IEFTQXMuIFRoaXMgY2FuIGJlIChwcm9iYWJs eTogc2hvdWxkIGJlKSBhIGxvb3BiYWNrIGFkZHJlc3MgKG9yIHdoYXRldmVyIHdlIGNhbGwgaXQs IHNlZSBiZWxvdykuIFNvIGZhciBJIHRoaW5rIHRoZXJlIGlzIG5vIGNvbnRlbnRpb24uIA0KDQpJ IHdvdWxkIGZ1cnRoZXIgY29udGVuZCB0aGF0IGluIGJvdGggY2FzZXMgKHdpdGggYW5kIHdpdGhv dXQgQUNQKSB0aGUgYXV0b25vbWljIGluZnJhc3RydWN0dXJlIHNob3VsZCBOT1QgYXNzaWduL25l Z290aWF0ZS9wdXQgb24gcm91dGFibGUgYWRkcmVzc2VzIG9uIGxpbmtzLCBidXQgdXNlIGV4Y2x1 c2l2ZWx5IGxpbmsgbG9jYWwgdGhlcmUuIERvIHdlIGFsc28gYWdyZWUgb24gdGhhdD8gDQoNCkFu ZCwgYm90aCBvZiB0aGUgYWJvdmUgcG9pbnRzIGFyZSBpbmRlcGVuZGVudCBvbiB0aGF0IHRoZSBh ZG1pbiBkb2VzIGluIHRoZSAibm9ybWFsIiBkZXZpY2UgY29uZmlnLiBIZSBtYXkgd2VsbCBjaG9v c2UgdG8gYXNzaWduIGFkZHJlc3NlcyB0byBsaW5rcyBmb3IgaGlzIG5vcm1hbCBvcGVyYXRpb24u IA0KIA0KRG9lcyB0aGlzIG1hcCB5b3VyIHVuZGVyc3RhbmRpbmc/IA0KDQo+ICoibG9vcGJhY2sg aW50ZXJmYWNlIiBpcyBub3QgaW4gbXkgdm9jYWJ1bGFyeS4NCg0KT0ssIEkgaGVhcmQgdGhpcyAo dG8gbWUgc3RyYW5nZSkgY29tbWVudCBiZWZvcmUsIGFuZCB3b3VsZCBsaWtlIHRvIHVuZGVyc3Rh bmQgYW5kIHNldHRsZSB0aGlzIHdpdGggdGhlIHJpZ2h0IHdvcmRpbmcuIA0KDQpUaGVyZSBhcmUg cGxlbnR5IG9mIGNhc2VzIHdoZXJlIHRoaXMgdGVybSBpcyB1c2VkIGluIFJGQ3M6IA0KDQpSRkMz MzMwOiANCiIxMjcuMC4wLjAvOCAtIFRoaXMgYmxvY2sgaXMgYXNzaWduZWQgZm9yIHVzZSBhcyB0 aGUgSW50ZXJuZXQgaG9zdCBsb29wYmFjayBhZGRyZXNzLiINClJGQzM1MTM6IA0KIiAgICAgICAg IDA6MDowOjA6MDowOjA6MSAgICAgICAgICAgICB0aGUgbG9vcGJhY2sgYWRkcmVzcyINCk9uIFVu aXggc3lzdGVtcyAoZm9yIGV4YW1wbGUpIHlvdSBoYXZlIGEgbG9vcGJhY2sgaW50ZXJmYWNlIGFz IHdlbGwsIGRvY3VtZW50ZWQgYXMgc3VjaC4gDQoNClNvIC0gd2h5IGlzIHRoYXQgdGVybSB3cm9u ZyBhbmQgd2hhdCBpcyB0aGUgcmlnaHQgb25lPyBIYXMgdGhpcyBhbHJlYWR5IGJlZW4gZGlzY3Vz c2VkIGVsc2V3aGVyZSBpbiB0aGUgSUVURiwgYW5kIGNhbiB5b3UgcG9pbnQgdG8gYSBjb25zZW5z dXM/IChvciBpcyBpdCB5b3VyIG9waW5pb24gb25seSBhdCB0aGlzIHBvaW50PykgIFRoYW5rcyBm b3IgeW91ciBoZWxwISANCg0KTWljaGFlbA0KDQo= From nobody Mon May 4 20:41:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F1D1B2DF0 for ; Mon, 4 May 2015 20:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fJ4ZQTz3XOWD for ; Mon, 4 May 2015 20:41:08 -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 08DAA1B2DF1 for ; Mon, 4 May 2015 20:41:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVQ93720; Tue, 05 May 2015 03:41:06 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 May 2015 04:41:05 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 5 May 2015 11:40:58 +0800 From: "Liubing (Leo)" To: "Michael Behringer (mbehring)" , Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Addressing-interface addressing Thread-Index: AdB+aWxBd2bophqyRBWx7u68gJs1cwAAJ/yAAAaploAB3Hx1AAABHMOAAA3BcoAAKSjVEA== Date: Tue, 5 May 2015 03:40:58 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEE1B1@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.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 Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 May 2015 03:41:10 -0000 Hi Michael, > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Behringer (mbehring) > Sent: Monday, May 04, 2015 10:18 PM > To: Brian E Carpenter; anima@ietf.org > Subject: Re: [Anima] Addressing-interface addressing >=20 > > In the context of the ACP, I think we're saying the same thing. ACP > > addresses are routeable within the ACP (which is to say, they are > > routeable among ASAs, via their ACP virtual* interfaces). However, if > > for some reason we have no ACP, the ASAs will need some other kind of > > routeable address, of course. >=20 > Agreed. Re-phrasing: In both cases (with and without ACP) a device needs = a > routable address which is used by ASAs. This can be (probably: should be)= a > loopback address (or whatever we call it, see below). So far I think ther= e is > no contention. >=20 > I would further contend that in both cases (with and without ACP) the > autonomic infrastructure should NOT assign/negotiate/put on routable > addresses on links, but use exclusively link local there. Do we also agre= e on > that? [Bing] I think this claim has an implications: each ASA is binding to a dev= ice (the loopback interface), rather than a link interface. I think this implication might be ok, but I don't have a 100% confidence. C= an anybody point out an exception? > And, both of the above points are independent on that the admin does in t= he > "normal" device config. He may well choose to assign addresses to links f= or > his normal operation. >=20 > Does this map your understanding? >=20 > > *"loopback interface" is not in my vocabulary. >=20 > OK, I heard this (to me strange) comment before, and would like to > understand and settle this with the right wording. >=20 > There are plenty of cases where this term is used in RFCs: >=20 > RFC3330: > "127.0.0.0/8 - This block is assigned for use as the Internet host loopba= ck > address." > RFC3513: > " 0:0:0:0:0:0:0:1 the loopback address" > On Unix systems (for example) you have a loopback interface as well, > documented as such. >=20 > So - why is that term wrong and what is the right one?=20 [Bing] My understanding is that Brian's concern is about the definition acc= uracy. Although loopback interface is commonly used as representing a node = in practice, it is a specific concept of loopback inside a node by definiti= on. So, as Brian commented before, here we are actually talking about the conce= pt of "virtual interface" which represents a node rather than an interface = on a specific link. But I also don't know whether there is a formal naming = to express the "virtual interface".=20 If there is no such a name, my rough suggestion would be: we can briefly ex= plain that "loopback interface" is something we borrow to assign IP address= es for ASA communication, and this is a common way in practice to make an I= P represents a node rather than an interface on a link. Best regards, Bing > Has this already been > discussed elsewhere in the IETF, and can you point to a consensus? (or is= it > your opinion only at this point?) Thanks for your help! >=20 > Michael >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue May 5 00:36:41 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37791B2EE2 for ; Tue, 5 May 2015 00:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Debbr2jMegu1 for ; Tue, 5 May 2015 00:36:38 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A051B2EDE for ; Tue, 5 May 2015 00:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3202; q=dns/txt; s=iport; t=1430811397; x=1432020997; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=H0OVOwL0w1unrSlpBzbO7Ce8+aoMN7NFiArep+CCm9w=; b=aggMrnbWwIJQeFvCIUiian7I94zIb30U6Rc0GCIHkcigP+r6qlX5Hy81 +DtoeP7B3jJ0Qp+GRHI+o5M7xaeApQM/6rj6sNMDcsJFg9sHACDATcrx3 B8La7eK0RujtT0MpeOpfOMyz+utFCerOD6ZHHEgwF70uGZiuWOtuTX90t M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BVBACdcUhV/4wNJK1cgwxTXAXFDmYJgUwKhgUCgTE4FAEBAQEBAQGBCoQgAQEBAwEBAQE3NBALAgEIIhQQJwslAgQBEgiIGwgNxF4BAQEBAQEBAQEBAQEBAQEBAQEWBIs5hFQ4gxeBFgWLGYZ0i3aRKINSI4N0b4FEgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,371,1427760000"; d="scan'208";a="147038640" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 05 May 2015 07:36:36 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t457aa1C002067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 07:36:36 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.98]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 5 May 2015 02:36:36 -0500 From: "Michael Behringer (mbehring)" To: "Liubing (Leo)" , Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Addressing-interface addressing Thread-Index: AdB+aWxBd2bophqyRBWx7u68gJs1cwAbZbqAAAaploAB0fSNgAALpKyAAAgz3VAAIZXUAAACXz7Q Date: Tue, 5 May 2015 07:36:35 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F784A7@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEEE1B1@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEE1B1@nkgeml506-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 May 2015 07:36:40 -0000 > > Agreed. Re-phrasing: In both cases (with and without ACP) a device > > needs a routable address which is used by ASAs. This can be (probably: > > should be) a loopback address (or whatever we call it, see below). So > > far I think there is no contention. > > > > I would further contend that in both cases (with and without ACP) the > > autonomic infrastructure should NOT assign/negotiate/put on routable > > addresses on links, but use exclusively link local there. Do we also > > agree on that? > [Bing] I think this claim has an implications: each ASA is binding to a d= evice > (the loopback interface), rather than a link interface. > I think this implication might be ok, but I don't have a 100% confidence.= Can > anybody point out an exception? Agreed. If someone can come up with a good reason where we need to have rou= table interface addresses, let's do it. If not, let's use link-local only.= =20 =20 > > And, both of the above points are independent on that the admin does > > in the "normal" device config. He may well choose to assign addresses > > to links for his normal operation. > > > > Does this map your understanding? > > > > > *"loopback interface" is not in my vocabulary. > > > > OK, I heard this (to me strange) comment before, and would like to > > understand and settle this with the right wording. > > > > There are plenty of cases where this term is used in RFCs: > > > > RFC3330: > > "127.0.0.0/8 - This block is assigned for use as the Internet host > > loopback address." > > RFC3513: > > " 0:0:0:0:0:0:0:1 the loopback address" > > On Unix systems (for example) you have a loopback interface as well, > > documented as such. > > > > So - why is that term wrong and what is the right one? > [Bing] My understanding is that Brian's concern is about the definition > accuracy. Although loopback interface is commonly used as representing a > node in practice, it is a specific concept of loopback inside a node by > definition. > So, as Brian commented before, here we are actually talking about the > concept of "virtual interface" which represents a node rather than an > interface on a specific link. But I also don't know whether there is a fo= rmal > naming to express the "virtual interface". > If there is no such a name, my rough suggestion would be: we can briefly > explain that "loopback interface" is something we borrow to assign IP > addresses for ASA communication, and this is a common way in practice to > make an IP represents a node rather than an interface on a link. I guess, neither is "officially" defined. Happy to add some definition to t= he text. I would still tend to call it a loopback interface though (with de= finition). Brian, would that solve your concern?=20 Michael =20 > Best regards, > Bing >=20 > > Has this already been > > discussed elsewhere in the IETF, and can you point to a consensus? (or > > is it your opinion only at this point?) Thanks for your help! > > > > Michael > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima From nobody Tue May 5 11:56:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA34E1B2F9A for ; Tue, 5 May 2015 11:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rTf5Gy1E9JaH for ; Tue, 5 May 2015 11:56:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED171A873E for ; Tue, 5 May 2015 11:56:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0485920098 for ; Tue, 5 May 2015 15:08:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B7EA063B86; Tue, 5 May 2015 14:56:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A6A2B63731 for ; Tue, 5 May 2015 14:56:07 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 May 2015 18:56:10 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: mcr> (and I mcr> have said I favour a ULA-C approach) on a loopback interface. brian> IMHO we don't need -C. That would imply yet another external brian> dependency (on a non-existent registry that has no funding model brian> anyway). Vanilla ULA works fine. mb> Slightly confused. I think on the loopback interfaces we agree we mb> need something routable, and that ULA (ignore the flavour for a mb> second) is the right thing here. And on the interfaces to other nodes mb> we use link local. Are we saying the same thing? I think we all agree that ULA is the way to number the autonomic control plane. Current ULA-Random has the disadvantage that, when there are routing leaks, where they come from. We see this today with RFC1918 address spaces, and the AS112 project exists to deal with the resulting reverse DNS lookup impact of those leaks. A ULA-C had the advantage that while they are seperate from an ISP or enterprise's GUA allocation, they are still trackable when they leak. I think it very important that the ACP be numbered in a different space than production. With ULA-C, one would get reverse DNS delegated to you, etc. cf: https://tools.ietf.org/html/draft-ietf-ipv6-ula-central-02 which is from 2007, but could be revived, I think. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVUkSR4CLcPvd0N1lAQL9Qwf/dv9EXcMVQz4MuADfQ12HogwbuFMOBvRV ZISRI/17R5AbEjsj2LxXqNbVQ9NZNeoQgyeI1PmBPq6pngzmbNUIiFuBZD8LoVNI X56xaGkLPJWoIusGX97sTC07feEnwNSyi8rWZASHl7E2eFM828wZ+MmDdDkG9nd8 9By7LkPSfqMQ//e6qZ2JFWqwcv3XMj1k6AnmOdg0NoSLk05zxbVrFD2ArlfONvZ8 trujz4yEWfdB6MSY0a8JzUd9cD1wxLCB91emahtyHRF8fL//jayD7/lrMO884HsA LZtN1+ptWkMTcraKTJGT9fSd62edIZ5d1Ot7L0FckEx1yLDUbzpk/g== =XR5R -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 5 12:02:25 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D841B2FC1 for ; Tue, 5 May 2015 12:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UdFazpJeefWb for ; Tue, 5 May 2015 12:02:21 -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 8D1821B2FC6 for ; Tue, 5 May 2015 12:02:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2086C20098 for ; Tue, 5 May 2015 15:14:35 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D2E5063B86; Tue, 5 May 2015 15:02:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C240563731 for ; Tue, 5 May 2015 15:02:16 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 May 2015 19:02:23 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > And, both of the above points are independent on that the admin does in > the "normal" device config. He may well choose to assign addresses to > links for his normal operation. > Does this map your understanding? >> *"loopback interface" is not in my vocabulary. > OK, I heard this (to me strange) comment before, and would like to > understand and settle this with the right wording. What is meant by loopback interface address is that the autonomic numbering mechanism would configure the ACP prefix (the ULA) onto a loopback interface, and then would announce that address into the autonomic network. The alternative is that the address is configured onto specific interfaces, and therefore a router with a multitude of interfaces would have a multitude of addressess. Worse, if one has a management session up with one of those interfaces, and the interface goes down, then the session goes down. Had the session been up with a loopback IP, then routing fixes the path, and the session stays up. Configuring /128s (and /32s) onto loopback interfaces and then using OSPF to announce that is how ISPs operate today. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVUkTuICLcPvd0N1lAQKHNgf/Rvju74992oKfApM3UQ51T5D8ls6WV3eY DHiRusWSS2g7I3EVkEH4+N0XIheaCusHOFb+gqgBHej+7hxsdykzEq8TJ9opkSPL PUdhdJQTuxGlmkyPXSgdndPy2xu8Cxq+eJq9OjGwrU6cfq2O9V9hPC2DrYO/OvC8 gBfyZgQVqVBs9BIxtNj26EPBNQBzPFmM+c0yVq2fpJGshGIuhAklO0KahlYUk2it hA5yYEl6ujv0sj0DIVVCq5kT7tZqUtK0/Aw3ZKC0d/cqMMFP+bnqDaEJ4uc3j84P 75DPU0vGVNgjgtv3pwJV1uX3CiaI/SeMxcjZ8QrhWwfgL6IFf/lw2Q== =jF1S -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 5 14:05:00 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FF11AC425 for ; Tue, 5 May 2015 14:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 z2Czulnrvhmv for ; Tue, 5 May 2015 14:04:54 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08DF1B2850 for ; Tue, 5 May 2015 14:04:53 -0700 (PDT) Received: by pdbqd1 with SMTP id qd1so209036373pdb.2 for ; Tue, 05 May 2015 14:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U0LB9w6E5S6vVoJGcU1dLlyTWP+hYk46fTXnMIgEqyg=; b=sdy7WCT1LJ8+VsqagDSsIt2pZMV6jmGejkjokrtsguWcz3rwBSNEwcaAHbA8UrpKXk uYk2NU8fzP/wo/rR/8faag+7Fdtv1Xpn5iu5H7v/bwhYYLjFlWHOGvSSuX6m4bCf9oB4 uprdbziqDGMQF+Pp8minfzfTF/iQ0eyVDIEV9zNW13pbWF/MapiYMJNrGruw0Dq8kxi1 rF2iIp2Yqe+49Cfr52nJKMSHsiPvxNYn6XfrjOIfHzUDCMBZEJzSNqqlI5hfdgIeqa+A OBOOsvjMTDYuLwPnqNp0tuAZD2Vz3lVLOzBr6V2VR+16EZageXJeI7gtFUVas4T/bhxx lFEQ== X-Received: by 10.68.198.36 with SMTP id iz4mr55695107pbc.167.1430859893491; Tue, 05 May 2015 14:04:53 -0700 (PDT) Received: from [172.20.1.37] ([119.17.36.195]) by mx.google.com with ESMTPSA id u3sm16718920pbs.30.2015.05.05.14.04.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2015 14:04:52 -0700 (PDT) Message-ID: <5549306D.8020008@gmail.com> Date: Wed, 06 May 2015 09:04:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: anima@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> <24211.1430852536@sandelman.ca> In-Reply-To: <24211.1430852536@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 May 2015 21:04:57 -0000 On 06/05/2015 07:02, Michael Richardson wrote: > > Michael Behringer (mbehring) wrote: > > And, both of the above points are independent on that the admin does in > > the "normal" device config. He may well choose to assign addresses to > > links for his normal operation. > > > Does this map your understanding? > > >> *"loopback interface" is not in my vocabulary. > > > OK, I heard this (to me strange) comment before, and would like to > > understand and settle this with the right wording. > > What is meant by loopback interface address is that the autonomic numbering > mechanism would configure the ACP prefix (the ULA) onto a loopback interface, > and then would announce that address into the autonomic network. > > The alternative is that the address is configured onto specific interfaces, > and therefore a router with a multitude of interfaces would have a multitude > of addressess. Worse, if one has a management session up with one of those > interfaces, and the interface goes down, then the session goes down. > Had the session been up with a loopback IP, then routing fixes the path, and > the session stays up. > > Configuring /128s (and /32s) onto loopback interfaces and then using OSPF to > announce that is how ISPs operate today. Can somebody explain how this term "loopback interface" came into use? There's no loopback address involved, it's just a virtual interface. Brian From nobody Tue May 5 14:08:20 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380861B29A7 for ; Tue, 5 May 2015 14:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 RH2xgf7JskaA for ; Tue, 5 May 2015 14:08:16 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::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 4F5801ACDEE for ; Tue, 5 May 2015 14:08:16 -0700 (PDT) Received: by pdea3 with SMTP id a3so209375751pde.3 for ; Tue, 05 May 2015 14:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M0b+aLIQEpsyatyvKJJtdNuof4x1MbBR1qUbsY2CIFQ=; b=ReowIABF95ZghdUBrieUbfxIOjM9rlKL9Rgz2bE4z4OcRRLP8lcuySVP5c+XTLc0Mu Vnc5uQ8WkM5nqYMK5rOpf9UdjjloTo9NtKWEkANxKOPIvgU2AgKiM6wIki5m7bR5PKT0 FQP4EiUbY2khZ3ZVQOZioPYKGi84sS8PR8Z+swFo4NiXkfy6adR3Lu0PhAwOt43sfg8w Z3DjOLwrrXlbggrgPA0TsnaPev+LMOHMaQroD/F/cKrToKQxmxQ5D0T0//YH1Ew0WqIS j3tdhtkR/FNhGNuV+r6vpQ2XDKFuBJMLE6tRUUB6+opVnmn2WpWVmFcsw0rGmrX1bWqC vX8g== X-Received: by 10.70.38.138 with SMTP id g10mr55002808pdk.98.1430860096020; Tue, 05 May 2015 14:08:16 -0700 (PDT) Received: from [172.20.1.37] ([119.17.36.195]) by mx.google.com with ESMTPSA id sf6sm16705301pbb.82.2015.05.05.14.08.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2015 14:08:14 -0700 (PDT) Message-ID: <55493140.5020802@gmail.com> Date: Wed, 06 May 2015 09:08:16 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "anima@ietf.org" References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 May 2015 21:08:18 -0000 On 05/05/2015 02:18, Michael Behringer (mbehring) wrote: >> In the context of the ACP, I think we're saying the same thing. ACP >> addresses are routeable within the ACP (which is to say, they are routeable >> among ASAs, via their ACP virtual* interfaces). However, if for some reason >> we have no ACP, the ASAs will need some other kind of routeable address, >> of course. > > Agreed. Re-phrasing: In both cases (with and without ACP) a device needs a routable address which is used by ASAs. This can be (probably: should be) a loopback address (or whatever we call it, see below). So far I think there is no contention. > > I would further contend that in both cases (with and without ACP) the autonomic infrastructure should NOT assign/negotiate/put on routable addresses on links, but use exclusively link local there. Do we also agree on that? I believe so. It would be to good walk through an off-link discovery process in gory detail to check that this is OK in all cases. > > And, both of the above points are independent on that the admin does in the "normal" device config. He may well choose to assign addresses to links for his normal operation. > > Does this map your understanding? Yes. > >> *"loopback interface" is not in my vocabulary. > > OK, I heard this (to me strange) comment before, and would like to understand and settle this with the right wording. See my reply to Michael Richardson. It's only terminology. Brian > > There are plenty of cases where this term is used in RFCs: > > RFC3330: > "127.0.0.0/8 - This block is assigned for use as the Internet host loopback address." > RFC3513: > " 0:0:0:0:0:0:0:1 the loopback address" > On Unix systems (for example) you have a loopback interface as well, documented as such. > > So - why is that term wrong and what is the right one? Has this already been discussed elsewhere in the IETF, and can you point to a consensus? (or is it your opinion only at this point?) Thanks for your help! > > Michael > From nobody Tue May 5 19:38:38 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7481B2A34 for ; Tue, 5 May 2015 19:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TBNrSVSa7S-o for ; Tue, 5 May 2015 19:38:35 -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 E29A31B2A2C for ; Tue, 5 May 2015 19:38:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2AC1720098 for ; Tue, 5 May 2015 22:50:53 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BC90B63B86; Tue, 5 May 2015 22:38:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A12F463731 for ; Tue, 5 May 2015 22:38:33 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <5549306D.8020008@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> <24211.1430852536@sandelman.ca> <5549306D.8020008@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2015 02:38:37 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Michael Behringer (mbehring) wrote: >> > And, both of the above points are independent on that the admin does in >> > the "normal" device config. He may well choose to assign addresses to >> > links for his normal operation. >> >> > Does this map your understanding? >> >> >> *"loopback interface" is not in my vocabulary. >> >> > OK, I heard this (to me strange) comment before, and would like to >> > understand and settle this with the right wording. >> >> What is meant by loopback interface address is that the autonomic numbering >> mechanism would configure the ACP prefix (the ULA) onto a loopback interface, >> and then would announce that address into the autonomic network. >> >> The alternative is that the address is configured onto specific interfaces, >> and therefore a router with a multitude of interfaces would have a multitude >> of addressess. Worse, if one has a management session up with one of those >> interfaces, and the interface goes down, then the session goes down. >> Had the session been up with a loopback IP, then routing fixes the path, and >> the session stays up. >> >> Configuring /128s (and /32s) onto loopback interfaces and then using OSPF to >> announce that is how ISPs operate today. > Can somebody explain how this term "loopback interface" came into use? > There's no loopback address involved, it's just a virtual interface. It's an interface on which, when you send a packet, it is immediately received as local. It's always up. Some dummy or virtual interfaces just eat the packet... Our *convention* is that we put 127.0.0.1 on it, (or ::1), but of course, you can put any address you like, and operators regularly do exactly that. For instance, here is the (slightly obscured) ifconfig output for anycast DNS server. The addresses are /32 announced by BGP upstream: lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xd inet 127.0.0.1 netmask 0xff000000 inet 63.263.294.1 netmask 0xffffffff inet 63.263.294.2 netmask 0xffffffff inet 63.263.294.3 netmask 0xffffffff inet 63.263.294.4 netmask 0xffffffff inet 63.263.294.5 netmask 0xffffffff inet 63.263.294.6 netmask 0xffffffff inet 63.263.294.7 netmask 0xffffffff inet 63.263.294.8 netmask 0xffffffff inet6 3123:5h0:10::1 prefixlen 128 inet6 3123:5h0:10::2 prefixlen 128 inet6 3123:5h0:10::3 prefixlen 128 inet6 3123:5h0:10::4 prefixlen 128 inet6 3123:5h0:10::5 prefixlen 128 inet6 3123:5h0:10::6 prefixlen 128 inet6 3123:5h0:10::7 prefixlen 128 inet6 3123:5h0:10::8 prefixlen 128 nd6 options=23 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVUl+p4CLcPvd0N1lAQLABAgAp1QdRXlAEtkmA79eZZb7y8eRAdzmDpAL RsZGkp33mgppWOY8GkLFqoYVMUHyJAwGAbX5JdzKdIJtRMyC5CTDkeG4U3ZIT7xz utR3N4CtUqycr4KJ/sR2m1KhtfCbCBMKbGV+NOEFoz6nxn+4lWDiQpngqwc/BFLF nVRZK1PrDyJXBoM6anINVPm6huDZ0XknFkNuYwMWJm7dP2FqNJ+vwSQID8dLEDIJ jqWu0A6M2d7qKQGiEBKSjH8FB+8yONsj4J/26ZuxImZaOcSIn+L4L5nmy5X+0t6U vui6tMKP+AVApGIPmOSjKlVbGtKKSL2XTAmP3vYS8aiPOIlvXyeSCw== =slBS -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 5 21:01:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0421B2AA8; Tue, 5 May 2015 21:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zexJADBMAh2n; Tue, 5 May 2015 21:01:30 -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 A7BE21B2AA2; Tue, 5 May 2015 21:01:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVS10007; Wed, 06 May 2015 04:01:28 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 May 2015 05:01:25 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 6 May 2015 12:01:12 +0800 From: Sheng Jiang To: "anima-signaling@ietf.org" , Anima WG Thread-Topic: ANIMA signaling design team Thread-Index: AdCHsUUsVtBZlufWTsKVfurhC3JusQ== Date: Wed, 6 May 2015 04:01:12 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F508E91@nkgeml512-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 Archived-At: Cc: Toerless Eckert , Michael Richardson , Laurent Ciavaglia , Michael Richardson , "anima-chairs@tools.ietf.org" , Michael Behringer , "Liubing \(Leo\)" , "tom.taylor.stds@gmail.com" , "jcnobre@inf.ufrgs.br" Subject: [Anima] ANIMA signaling design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2015 04:01:32 -0000 SGksIGFsbCwNCg0KRm9sbG93aW5nIG91ciBjYWxsIGZvciB2b2x1bnRlZXIgbGFzdCB3ZWVrLCBJ IGFtIGhhcHB5IHRvIGFsc28gYW5ub3VuY2UgdGhlIG1lbWJlcnNoaXAgb2YgdGhlIGRlc2lnbiB0 ZWFtIHdpdGggbWFueSB0aGFua3MgdG8gdGhlbSBmb3IgdGFraW5nIG9uIHRoaXMgdGltZS1jb25z dW1pbmcgYW5kIGNyaXRpY2FsIGpvYi4gVGhlIGNoYXJ0ZXIgZm9yIHRoZSBkZXNpZ24gdGVhbSBp cyBiZWxvdy4gIA0KDQogICBCcmlhbiBDYXJwZW50ZXIgKExlYWRlciAmIEVkaXRvciwpDQogICBC aW5nIExpdSAoRWRpdG9yKQ0KICAgTWljaGFlbCBSaWNoYXJkc29uDQogICBUb20gVGF5bG9yDQog ICBMYXVyZW50IENpYXZhZ2xpYQ0KICAgTWljaGFlbCBCZWhyaW5nZXINCiAgIEplZmVyc29uIE5v YnJlDQoNClRoZSBkZXNpZ24gdGVhbSBoYXMgYSBzZXBhcmF0ZWQgbWFpbGluZyBsaXN0IGFuaW1h LXNpZ25hbGluZ0BpZXRmLm9yZy4gSW4gcHJpbmNpcGxlLCB0aGUgZGVzaWduIHRlYW0gZGlzY3Vz c2lvbnMgc2hvdWxkIGJlIG9wZW4gZm9yIGFsbCBBTklNQSBwYXJ0aWNpcGF0b3JzLiBQZW9wbGUg d2hvIGlzIGludGVyZXN0ZWQsIGJ1dCBkbyBub3QgaGF2ZSBlbm91Z2ggdGltZSB0byBjb21taXQs IGNvdWxkIGFsc28gYmUgYWJsZSB0byBwYXJ0aWNpcGF0ZSBhbmQgbWFrZSBjb250cmlidXRpb25z IG9yIGNvbW1lbnRzLiBQbGVhc2Ugc3Vic2NyaWJlIGlmIHlvdSBpbnRlbmQgdG8gYWN0aXZlbHkg Y29udHJpYnV0ZSB0byB0aGUgYW5pbWFsIHNpZ25hbGxpbmcgd29yay4gT3RoZXJ3aXNlIHdlIHJl Y29tbWVuZCB5b3UgdG8gc2ltcGx5IHN1YnNjcmliZSB0byB0aGUgQU5JTUEgbWFpbGluZyBsaXN0 IHRoYXQgd2Ugd2lsbCByZWd1bGFybHkgdXBkYXRlIG9uIHdvcmsgcHJvZ3Jlc3MuDQoNCkNoYXJ0 ZXIgKGFsc28gYXQgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvYW5pbWEvdHJhYy93aWtp L0Rlc2lnbiUyMFRlYW0lMjBDaGFydGVyKTogDQoNClRoZSBBbmltYSBXRyBjaGFydGVyIHN0YXRl cyBhIHJlcXVpcmVtZW50IGZvciBkaXNjb3ZlcnkgYW5kIG5lZ290aWF0aW9uIG1lY2hhbmlzbXMg dG8gZW5hYmxlIGNsb3NlZC1sb29wIGludGVyYWN0aW9uIGJldHdlZW4gYXV0b25vbWljIG5vZGVz LiBJdCBhbHNvIHN0YXRlcyB0aGUgZ29hbCBvZiBkZXZlbG9waW5nIG9uZSBvciBtb3JlIHByb3Rv Y29sIHNwZWNpZmljYXRpb25zIChvciBleHRlbnNpb25zIHRvIGV4aXN0aW5nIHByb3RvY29scykg dG8gYWNoaWV2ZSB0aGVzZSBnb2Fscy4gVGhlcmUgaXMgYW4gZXhpc3RpbmcgZHJhZnQgcmVxdWly ZW1lbnRzIGFuYWx5c2lzLCB3aG9zZSBtYWluIHBvaW50cyBpbmNsdWRlDQoNCiAgIC0gc3VwcG9y dCBmb3IgYW55IHR5cGUgb2YgbmV0d29yayBvYmplY3RpdmUgcGFyYW1ldGVyOw0KICAgLSBkaXNj b3ZlcnkgbXVzdCBzdXBwb3J0IGFueSB0b3BvbG9neSBhbmQgYm9vdHN0cmFwIHNjZW5hcmlvOw0K ICAgLSBzeW5jaHJvbml6ZSBwYXJhbWV0ZXJzIHdpdGggb3RoZXIgbm9kZXMgaW5kaXZpZHVhbGx5 IG9yIGJ5IGZsb29kaW5nOw0KICAgLSBuZWdvdGlhdGUgcGFyYW1ldGVycyB3aXRoIG90aGVyIG5v ZGVzOw0KICAgLSBhbHdheXMgc2VjdXJlOw0KICAgLSBBIHNpbXBsZSBUTFYgZm9ybWF0IGlzIHBy b3Bvc2VkIGZvciB0aGUgcHJvdG9jb2wgZGVzaWduLiBCaW5hcnkgb3IgbmFtZS1iYXNlZCBkaXNj b3ZlcnkgYXJlIHByb3Bvc2VkIGFzIGFsdGVybmF0aXZlIGRpc2NvdmVyeSBhcHByb2FjaGVzLg0K DQpUaGUgcHVycG9zZSBvZiB0aGUgZGVzaWduIHRlYW0gaXMgdG8gYW5hbHlzZSB0aGVzZSBpc3N1 ZXMgYW5kIHJlY29tbWVuZCBhIGNvbWJpbmVkIGFwcHJvYWNoIHRvIHRoZSB3b3JraW5nIGdyb3Vw LCBwcmVmZXJhYmx5IGluIHRoZSBmb3JtIG9mIG9uZSBkcmFmdCBvciBhIHNtYWxsIHNldCBvZiBj b29yZGluYXRlZCBkcmFmdHMuIFRoZSBwcm9wb3NlZCBhcHByb2FjaCBzaG91bGQgYmUgc3VpdGFi bGUgZm9yIHVzZSBieSB0aGUgQXV0b25vbWljIENvbnRyb2wgUGxhbmUsIGFuZCBmb3Igb3RoZXIg dXNlIGNhc2VzIGluY2x1ZGluZyB0aG9zZSBsaXN0ZWQgaW4gdGhlIEFuaW1hIFdHIGNoYXJ0ZXIu DQoNCkluIHByZXBhcmluZyB0aGUgcmVjb21tZW5kYXRpb24sIHRoZSBkZXNpZ24gdGVhbSB3aWxs IHZlcmlmeSBhbmQgdXBkYXRlIHRoZSBleGlzdGluZyByZXF1aXJlbWVudHMgYW5kIHVuZGVyc3Rh bmQgdGhlIHJlbGV2YW50IHVzZSBjYXNlcy4gSG93ZXZlciwgZG9jdW1lbnRpbmcgYW5kIHNvbHZp bmcgdXNlIGNhc2VzIGlzIG91dCBvZiBzY29wZSBmb3IgdGhlIGRlc2lnbiB0ZWFtLiBUaGUgZGVz aWduIHRlYW0gaXMgZW5jb3VyYWdlZCB0byBkZXZlbG9wIHByb3RvY29sIHdhbGt0aHJvdWdocyBh bmQgYW4gYWJzdHJhY3QgQVBJIGFzIGFpZHMgdG8gdW5kZXJzdGFuZGluZy4gVGhlIGRlc2lnbiB0 ZWFtIGlzIG5vdCBpdHNlbGYgZXhwZWN0ZWQgdG8gcHJvZHVjZSBjb2RlLCBidXQgZWFzZSBvZiBp bXBsZW1lbnRhdGlvbiBpcyBhbiBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbi4NCg0KVGhlIGRyYWZ0 KHMpIHNob3VsZCBiZSBkZWxpdmVyZWQgYnkgdGhlIEp1bHkgMjAxNSBJRVRGICgyMDE1LTA3LTA2 IGN1dG9mZiBkYXRlKS4NCg0KTW9yZSBpbmZvcm1hdGlvbiBjYW4gYmUgZm91bmQgYXQ6DQoNCmh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2FuaW1hL3RyYWMvd2lraS9TaWduYWxpbmcNCg0K UmVnYXJkcywNCg0KVG9lcmxlc3MgKyBTaGVuZw0K From nobody Tue May 5 23:38:20 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5BC1A1C06 for ; Tue, 5 May 2015 23:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Z7Yka7RzWTSd for ; Tue, 5 May 2015 23:38:17 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 6F2451A1BF6 for ; Tue, 5 May 2015 23:38:17 -0700 (PDT) Received: from mb-aye.local ([46.252.67.170]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t466cERX008454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 May 2015 06:38:16 GMT (envelope-from joelja@bogus.com) To: Michael Richardson , anima@ietf.org references: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> <24211.1430852536@sandelman.ca> <5549306D.8020008@gmail.com> <22274.1430879913@sandelman.ca> From: joel jaeggli x-enigmail-draft-status: N1110 message-id: <5549B6CF.2000702@bogus.com> Date: Wed, 6 May 2015 07:38:07 +0100 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <22274.1430879913@sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SiAx3MJn5FF0PiSJNvHN10LfucJAictDC" Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2015 06:38:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SiAx3MJn5FF0PiSJNvHN10LfucJAictDC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/6/15 3:38 AM, Michael Richardson wrote: >=20 > Brian E Carpenter wrote: > >> Michael Behringer (mbehring) wrote: > >> > And, both of the above points are independent on that the admi= n does in > >> > the "normal" device config. He may well choose to assign addre= sses to > >> > links for his normal operation. > >> > >> > Does this map your understanding? > >> > >> >> *"loopback interface" is not in my vocabulary. > >> > >> > OK, I heard this (to me strange) comment before, and would lik= e to > >> > understand and settle this with the right wording. > >> > >> What is meant by loopback interface address is that the autonomi= c numbering > >> mechanism would configure the ACP prefix (the ULA) onto a loopba= ck interface, > >> and then would announce that address into the autonomic network.= > >> > >> The alternative is that the address is configured onto specific = interfaces, > >> and therefore a router with a multitude of interfaces would have= a multitude > >> of addressess. Worse, if one has a management session up with o= ne of those > >> interfaces, and the interface goes down, then the session goes d= own. > >> Had the session been up with a loopback IP, then routing fixes t= he path, and > >> the session stays up. > >> > >> Configuring /128s (and /32s) onto loopback interfaces and then u= sing OSPF to > >> announce that is how ISPs operate today. >=20 > > Can somebody explain how this term "loopback interface" came into= use? > > There's no loopback address involved, it's just a virtual interfa= ce. loopback as a term of art significantly predates the existence of ip networks. if you want to refer to a device by an address which is not associated with any of it's interfaces that address will be bound to it's loopback interface typically. > It's an interface on which, when you send a packet, it is immediately > received as local. It's always up. Some dummy or virtual interfaces = just > eat the packet... Our *convention* is that we put 127.0.0.1 on it, (or= > ::1), but of course, you can put any address you like, and operators > regularly do exactly that. For instance, here is the (slightly obscure= d) > ifconfig output for anycast DNS server. The addresses are /32 announce= d by > BGP upstream: >=20 > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0xd > inet 127.0.0.1 netmask 0xff000000 > inet 63.263.294.1 netmask 0xffffffff > inet 63.263.294.2 netmask 0xffffffff > inet 63.263.294.3 netmask 0xffffffff > inet 63.263.294.4 netmask 0xffffffff > inet 63.263.294.5 netmask 0xffffffff > inet 63.263.294.6 netmask 0xffffffff > inet 63.263.294.7 netmask 0xffffffff > inet 63.263.294.8 netmask 0xffffffff > inet6 3123:5h0:10::1 prefixlen 128 > inet6 3123:5h0:10::2 prefixlen 128 > inet6 3123:5h0:10::3 prefixlen 128 > inet6 3123:5h0:10::4 prefixlen 128 > inet6 3123:5h0:10::5 prefixlen 128 > inet6 3123:5h0:10::6 prefixlen 128 > inet6 3123:5h0:10::7 prefixlen 128 > inet6 3123:5h0:10::8 prefixlen 128 > nd6 options=3D23 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 --SiAx3MJn5FF0PiSJNvHN10LfucJAictDC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVJttAACgkQ8AA1q7Z/VrKrQACeIuK/icgHElilsThztBVVCMZO FisAoIJsCLVlYIpOyEix/zwKSZmQ4Ik4 =dvQZ -----END PGP SIGNATURE----- --SiAx3MJn5FF0PiSJNvHN10LfucJAictDC-- From nobody Wed May 6 00:08:01 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357421A870F for ; Wed, 6 May 2015 00:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 wt98J0ZjRzO8 for ; Wed, 6 May 2015 00:07:58 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::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 44A0C1A7D80 for ; Wed, 6 May 2015 00:07:58 -0700 (PDT) Received: by pdbqd1 with SMTP id qd1so1321042pdb.2 for ; Wed, 06 May 2015 00:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qIQVb8VfaTvxxvqGXeP8IcOiPZ4F0fSuC4/bXDQkbgQ=; b=yfUqR3kTngPjIbdqfx1HxPxqBTkI3F/OjUJf26RfcKFH2Ytq14V6hDWws7aW2mNTEK nnpHxaNyZvsVBVrSqe4Z5/KJd5hkUIgy8AfPdNf2+E5g4uJCTsVGHsvdpVhzYHUICI4S adDddQNCY+s2n9pyDkh+PSkETByj/i2BZkqI8bskxhOmeIbbI5RmYyvvgO6C2p3NMYBd qzFm5gPld1zTHu++xjqOx//WWtgQ+IJVKv2TGePv+8OE+ma/jhGb8MtHrnRZNltTyC0E ofmKqZWHoPDsnsze8gbFsT4AU+ltPHHOdqClJnP6vh20E29sreg5VODNDV+eR2sgjd6S ZMiw== X-Received: by 10.68.198.36 with SMTP id iz4mr59187549pbc.167.1430896077974; Wed, 06 May 2015 00:07:57 -0700 (PDT) Received: from [10.177.229.228] ([175.103.25.98]) by mx.google.com with ESMTPSA id qm2sm911858pdb.57.2015.05.06.00.07.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2015 00:07:56 -0700 (PDT) Message-ID: <5549BDC7.1070505@gmail.com> Date: Wed, 06 May 2015 19:07:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: joel jaeggli , Michael Richardson , anima@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> <24211.1430852536@sandelman.ca> <5549306D.8020008@gmail.com> <22274.1430879913@sandelman.ca> <5549B6CF.2000702@bogus.com> In-Reply-To: <5549B6CF.2000702@bogus.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2015 07:08:00 -0000 On 06/05/2015 18:38, joel jaeggli wrote: > On 5/6/15 3:38 AM, Michael Richardson wrote: >> >> Brian E Carpenter wrote: >> >> Michael Behringer (mbehring) wrote: >> >> > And, both of the above points are independent on that the admin does in >> >> > the "normal" device config. He may well choose to assign addresses to >> >> > links for his normal operation. >> >> >> >> > Does this map your understanding? >> >> >> >> >> *"loopback interface" is not in my vocabulary. >> >> >> >> > OK, I heard this (to me strange) comment before, and would like to >> >> > understand and settle this with the right wording. >> >> >> >> What is meant by loopback interface address is that the autonomic numbering >> >> mechanism would configure the ACP prefix (the ULA) onto a loopback interface, >> >> and then would announce that address into the autonomic network. >> >> >> >> The alternative is that the address is configured onto specific interfaces, >> >> and therefore a router with a multitude of interfaces would have a multitude >> >> of addressess. Worse, if one has a management session up with one of those >> >> interfaces, and the interface goes down, then the session goes down. >> >> Had the session been up with a loopback IP, then routing fixes the path, and >> >> the session stays up. >> >> >> >> Configuring /128s (and /32s) onto loopback interfaces and then using OSPF to >> >> announce that is how ISPs operate today. >> >> > Can somebody explain how this term "loopback interface" came into use? >> > There's no loopback address involved, it's just a virtual interface. > > loopback as a term of art significantly predates the existence of ip > networks. Sure. > if you want to refer to a device by an address which is not associated > with any of it's interfaces that address will be bound to it's loopback > interface typically. Sure. Michael Richardson's example is clear enough. But in the ACP case we are trying to send packets amongst a set of ASAs over secure L3overSomething tunnels. That sounds like a VPN in the full sense of the term, so the addresses in question are associated with the virtual interfaces that terminate the VPN tunnels. So they are *not* addresses that are not associated with any interface. I don't see why they are any different than the addresses on a TAP interface. There's a degenerate case when the two ASAs that want to communicate happen to be on the same machine. In that case there is indeed a loopback, but it isn't the general case. Sorry to appear obtuse but I do want our terminology to be accurate and not linked to specific implementation techniques. If there's an RFC that clarifies all this I'd be pleased to study it. Brian > >> It's an interface on which, when you send a packet, it is immediately >> received as local. It's always up. Some dummy or virtual interfaces just >> eat the packet... Our *convention* is that we put 127.0.0.1 on it, (or >> ::1), but of course, you can put any address you like, and operators >> regularly do exactly that. For instance, here is the (slightly obscured) >> ifconfig output for anycast DNS server. The addresses are /32 announced by >> BGP upstream: >> >> lo0: flags=8049 metric 0 mtu 16384 >> options=600003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0xd >> inet 127.0.0.1 netmask 0xff000000 >> inet 63.263.294.1 netmask 0xffffffff >> inet 63.263.294.2 netmask 0xffffffff >> inet 63.263.294.3 netmask 0xffffffff >> inet 63.263.294.4 netmask 0xffffffff >> inet 63.263.294.5 netmask 0xffffffff >> inet 63.263.294.6 netmask 0xffffffff >> inet 63.263.294.7 netmask 0xffffffff >> inet 63.263.294.8 netmask 0xffffffff >> inet6 3123:5h0:10::1 prefixlen 128 >> inet6 3123:5h0:10::2 prefixlen 128 >> inet6 3123:5h0:10::3 prefixlen 128 >> inet6 3123:5h0:10::4 prefixlen 128 >> inet6 3123:5h0:10::5 prefixlen 128 >> inet6 3123:5h0:10::6 prefixlen 128 >> inet6 3123:5h0:10::7 prefixlen 128 >> inet6 3123:5h0:10::8 prefixlen 128 >> nd6 options=23 >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >> >> _______________________________________________ >> 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 Wed May 6 11:05:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B9A1B2D81 for ; Wed, 6 May 2015 11:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 X1bQIuaXWEHC for ; Wed, 6 May 2015 11:05:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C52D1B2D8C for ; Wed, 6 May 2015 11:05:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6E0DE200A7 for ; Wed, 6 May 2015 14:17:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8CCA763B86; Wed, 6 May 2015 14:05:30 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 78DDD63731 for ; Wed, 6 May 2015 14:05:30 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <5549BDC7.1070505@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> <24211.1430852536@sandelman.ca> <5549306D.8020008@gmail.com> <22274.1430879913@sandelman.ca> <5549B6CF.2000702@bogus.com> <5549BDC7.1070505@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2015 18:05:39 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> if you want to refer to a device by an address which is not associated >> with any of it's interfaces that address will be bound to it's loopback >> interface typically. > Sure. Michael Richardson's example is clear enough. But in the ACP > case we are trying to send packets amongst a set of ASAs over > secure L3overSomething tunnels. That sounds like a VPN in the full > sense of the term, so the addresses in question are associated with > the virtual interfaces that terminate the VPN tunnels. So they > are *not* addresses that are not associated with any interface. > I don't see why they are any different than the addresses > on a TAP interface. If we have *no* dynamic routing over the secure L3 tunnels, then we can never have a problem, but even RPL's DODAG can change. ANIMA typically won't be dealing exclusively with radio interfaces (important thing about radio, is that it's multiple access, but adjacencies are not transitive: so you can change adjancies without necessarily changing interfaces), then one can not depend upon the end points of the tunnels being stable. In order to not create multi-link subnets, RPL node are actually encouraged to configure /128 addresses on their loopback, and depend upon routing to get to "adjacent" neighbours. > There's a degenerate case when the two ASAs that want to communicate > happen to be on the same machine. In that case there is indeed > a loopback, but it isn't the general case. > Sorry to appear obtuse but I do want our terminology to be accurate > and not linked to specific implementation techniques. If there's > an RFC that clarifies all this I'd be pleased to study it. So, there isn't any difference between an address on a loopback interface and one on a virtual interface like a TAP interface, except that TAP interfaces generally send the packet *somewhere*, whereas loopback doesn't. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVUpX6oCLcPvd0N1lAQKE2Af/XazhRvWufapLK7tIk74AW38PhHKtbgt5 6voLbfDBBrhAwAQcJoc3gxKKJBpM31Ed6XSOiGlDtuSnzZhp1JSD3V8DpR3ZwMIF Vir0pDGWhR+e+BtOlwC4ROSUrCLVgyXSkQT2iLp/TXvCulnxEXez+GBdLoAKFuFa UllO/l4pWBZ06ZoRajULqkouIsAoFeM6pYeAimdkuK+6IyC+Y2qsbHJzsZ4Or5My AEMj5vws9Y8yBKa3CBiMTR61T5Q2ou2SqST9yE7z7Fc7oP6QdvdhgYCJK9ccGPPz xpSR+ePT2GL4eVikwyla94TUrmMdFJT8TcK6w/uQNveYTni4OiHTjA== =8uPa -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 6 14:53:18 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B141ACE8E; Wed, 6 May 2015 14:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Gph75awUZsXe; Wed, 6 May 2015 14:53:15 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 21B101ACD63; Wed, 6 May 2015 14:53:15 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so20859249pac.1; Wed, 06 May 2015 14:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WWkFsFglQ3hZRARdgfWn3Pd88tbOs9utApEr5+RmVrs=; b=Mn+tLAohfvzHn4uCMVpPwuUvsB76g4B9wXcx7XMiXqWHkdc96Bqrvb2nH1sRfXGU5Q 2YWe6GCW0IazZTPApuRF4dM6+shjSh+0+AIEhXqOeN6C15fkOPzckJYOrcaszjr4Q/1g ocqh4vbzMDovdVUm/5vK2pqxENsXSW8ljTokTuNLV3tj2AgC6uHKgfLw4b8Aanz7qetR MdGhJp5IFbqzrmsXilZ1r6ozNVO43hARH/Q+XjRCKEbuTRGewZ3cuikTZLD/I+5Lr5dD GxfA6CYd3VLtuDc02g8lku653m7vMso794UscX679Yz/AfLLaJikac8o75rjZLdQMgv9 xwXA== X-Received: by 10.70.32.164 with SMTP id k4mr1392692pdi.138.1430949194793; Wed, 06 May 2015 14:53:14 -0700 (PDT) Received: from [10.177.231.214] ([175.103.25.98]) by mx.google.com with ESMTPSA id fh9sm40734pdb.17.2015.05.06.14.53.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2015 14:53:13 -0700 (PDT) Message-ID: <554A8D49.3000100@gmail.com> Date: Thu, 07 May 2015 09:53:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "anima-signaling@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B925F508E91@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F508E91@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Toerless Eckert , Michael Richardson , "anima-chairs@tools.ietf.org" , Michael Richardson , "tom.taylor.stds@gmail.com" , Michael Behringer , "Liubing \(Leo\)" , Laurent Ciavaglia , "jcnobre@inf.ufrgs.br" , Anima WG , Sheng Jiang Subject: Re: [Anima] ANIMA signaling design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2015 21:53:17 -0000 Hi all, I happen to be on a few days holiday this week so will get more active next week. For now it would be very useful if people could look at the requirements and issues sub-pages of http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling Regards Brian On 06/05/2015 16:01, Sheng Jiang wrote: > Hi, all, > > Following our call for volunteer last week, I am happy to also announce the membership of the design team with many thanks to them for taking on this time-consuming and critical job. The charter for the design team is below. > > Brian Carpenter (Leader & Editor,) > Bing Liu (Editor) > Michael Richardson > Tom Taylor > Laurent Ciavaglia > Michael Behringer > Jeferson Nobre > > The design team has a separated mailing list anima-signaling@ietf.org. In principle, the design team discussions should be open for all ANIMA participators. People who is interested, but do not have enough time to commit, could also be able to participate and make contributions or comments. Please subscribe if you intend to actively contribute to the animal signalling work. Otherwise we recommend you to simply subscribe to the ANIMA mailing list that we will regularly update on work progress. > > Charter (also at http://trac.tools.ietf.org/wg/anima/trac/wiki/Design%20Team%20Charter): > > The Anima WG charter states a requirement for discovery and negotiation mechanisms to enable closed-loop interaction between autonomic nodes. It also states the goal of developing one or more protocol specifications (or extensions to existing protocols) to achieve these goals. There is an existing draft requirements analysis, whose main points include > > - support for any type of network objective parameter; > - discovery must support any topology and bootstrap scenario; > - synchronize parameters with other nodes individually or by flooding; > - negotiate parameters with other nodes; > - always secure; > - A simple TLV format is proposed for the protocol design. Binary or name-based discovery are proposed as alternative discovery approaches. > > The purpose of the design team is to analyse these issues and recommend a combined approach to the working group, preferably in the form of one draft or a small set of coordinated drafts. The proposed approach should be suitable for use by the Autonomic Control Plane, and for other use cases including those listed in the Anima WG charter. > > In preparing the recommendation, the design team will verify and update the existing requirements and understand the relevant use cases. However, documenting and solving use cases is out of scope for the design team. The design team is encouraged to develop protocol walkthroughs and an abstract API as aids to understanding. The design team is not itself expected to produce code, but ease of implementation is an important consideration. > > The draft(s) should be delivered by the July 2015 IETF (2015-07-06 cutoff date). > > More information can be found at: > > http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling > > Regards, > > Toerless + Sheng > From nobody Wed May 6 23:53:37 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91F11AD2C4; Wed, 6 May 2015 23:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 I-AB1kCtcGux; Wed, 6 May 2015 23:53:32 -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 F00AA1AD272; Wed, 6 May 2015 23:53:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVT38129; Thu, 07 May 2015 06:53:30 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 May 2015 07:53:28 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 7 May 2015 14:53:25 +0800 From: Sheng Jiang To: Anima WG Thread-Topic: Discussion on the technical goals of the signaling design team Thread-Index: AdCIkoPD/wLO8MEVSAuK45HfxmFbQQ== Date: Thu, 7 May 2015 06:53:25 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F50A77A@nkgeml512-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 Archived-At: Cc: "Toerless Eckert \(eckert\)" , "anima-signaling@ietf.org" , "anima-chairs@tools.ietf.org" Subject: [Anima] Discussion on the technical goals of the signaling design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 06:53:34 -0000 RGVhciBBbmltYSBwYXJ0aWNpcGFudHM6DQoNClRoZSBBTklNQSBzaWduYWxpbmcgZGVzaWduIHRl YW0gaXMgc3RhcnRpbmcsIHRoZSB0ZWFtcyBjaGFydGVyIGlzIG9uIHRoZSB3aWtpOiANCiAgIGh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2FuaW1hL3RyYWMvd2lraS9TaWduYWxpbmcNCg0K VGhlIGluaXRpYWwgdGVjaG5pY2FsIGdvYWxzIG9mIHRoZSBzaWduYWxpbmcgZGVzaWduIHRlYW0g aXM6DQoNCi0gVmFsaWRhdGUgYW5kIHVwZGF0ZSB0aGUgZXhpc3RpbmcgbGlzdCBvZiByZXF1aXJl bWVudHMgKHN0YXJ0IHBvaW50IGFzIGRyYWZ0LWNhcnBlbnRlci1hbmltYS1nZG4tcHJvdG9jb2wj c2VjdGlvbi0yKSBhZ2FpbnN0IGJvb3RzdHJhcCBhbmQgQUNQIGRyYWZ0cyAoYW5kIG9wdGlvbmFs bHkgYWdhaW5zdCBvdGhlciB1c2UgY2FzZSB2YWxpZGF0aW9uIGRyYWZ0cykuIFRhcmdldCBkYXRl OiBlbmQgTWF5Lg0KLSBSZWNvbW1lbmQgaG93IHRoZSBvdGhlciBtaWxlc3RvbmUgY29tcG9uZW50 cyBvZiBBTklNQSAoYm9vdHN0cmFwLCBBQ1AsIHZhbGlkYXRpb24gZHJhZnRzKSBzaG91bGQgdXNl IHRoZSBzaWduYWxpbmcgcHJvdG9jb2wocykuIEFzIGEgc2lkZS1lZmZlY3QsIGNyaXRpcXVlIHRo ZSBwcm9wb3NhbCBvbiB0aGUgdGFibGUgKHN0YXJ0IHBvaW50IGFzIGRyYWZ0LWNhcnBlbnRlci1h bmltYS1nZG4tcHJvdG9jb2wjc2VjdGlvbi0zKS4gVGFyZ2V0IGRhdGU6IG1pZCBKdW5lLg0KDQpP bmUgb2YgdGhlIGdvYWxzIHdlIHdvdWxkIGxpa2UgdG8gYWNoaWV2ZSBpcyB0byBkcml2ZSB0b3dh cmRzIGFkb3B0aW9uIG9mIHdvcmtncm91cCBkb2N1bWVudCBmb3IgdGhlIGFuaW1hIGNoYXJ0ZXIg bWlsZXN0b25lIG9mIHNpZ25hbGluZyBhcyBwcm9kdWNlZCBieSB0aGUgZGVzaWduIHRlYW0gZHVy aW5nL2FmdGVyIFByYWd1ZS4gU28sIHdlIHdvdWxkIGxpa2UgdG8ga25vdyBmcm9tIHlvdSBhbmlt YSBwYXJ0aWNpcGFudHMgd2hldGhlciB0aGUgYWJvdmUgdGVjaG5pY2FsIGdvYWxzIGFyZSBzdWZm aWNpZW50IHRvIHN1cHBvcnQgV0cgYWRvcHRpb24gZm9yIFByYWd1ZSwgb3Igd2hhdCBlbHNlIHNw ZWNpZmljIHRlY2huaWNhbCBnb2FscyBzaG91bGQgYmUgYWNoaWV2ZWQgYmVzaWRlIHRoZSBhYm92 ZSBsaXN0ZWQuDQoNCkJlc3QgcmVnYXJkcywNCg0KVG9lcmxlc3MgKyBTaGVuZw0K From nobody Sat May 9 21:28:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB6C1A004A for ; Sat, 9 May 2015 21:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ApPmPUUgJlxy for ; Sat, 9 May 2015 21:28:41 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045791A0046 for ; Sat, 9 May 2015 21:28:40 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so82795600pac.0 for ; Sat, 09 May 2015 21:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9Jds3DWOycLXp+W7hw/21huRGDTfPYuGLbvTbWYPnN8=; b=FSsxcOAj6GsQf6RzHziRqfUw1ziRGkfUFDp91NSOKklvUPJpONR46ZSLFXXvRDnfdq ayWsAO1kqqsBY97RBVfQrc1PqbnYAgi+9OJuP2oloDPUgjCDnkz7jFy1OPaXOwM8AIMg /VTV7X2HmyrtAIasj7FDPi3E3ga8S4v2Q4DXAISexZW5ktZMgOxO/JnS1dAd5rYShxtB wzZvp8dXvA4xb8wblpKCXPhCRENq116gaqNI1+X4dVhKHd5AHH9GtsATWxBmHHQRkBkw USjmCPb7h4aYNf5CkP/kaYWNL2iADKwidrn8b3Li5B90OxoWjQs5B/xk/Xj2Pk2Z/wB1 gBTw== X-Received: by 10.70.90.162 with SMTP id bx2mr8878320pdb.60.1431232120612; Sat, 09 May 2015 21:28:40 -0700 (PDT) Received: from ?IPv6:2406:e007:6595:1:28cc:dc4c:9703:6781? ([2406:e007:6595:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id bc14sm9296620pac.6.2015.05.09.21.28.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 May 2015 21:28:39 -0700 (PDT) Message-ID: <554EDE73.5060301@gmail.com> Date: Sun, 10 May 2015 16:28:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Richardson , anima@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com> <5547235B.5090401@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F780E6@xmb-rcd-x14.cisco.com> <24211.1430852536@sandelman.ca> <5549306D.8020008@gmail.com> <22274.1430879913@sandelman.ca> <5549B6CF.2000702@bogus.com> <5549BDC7.1070505@gmail.com> <20951.1430935530@sandelman.ca> In-Reply-To: <20951.1430935530@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 04:28:43 -0000 Michael, and Michael, Let's hope we can close this off soon... On 07/05/2015 06:05, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> if you want to refer to a device by an address which is not associated > >> with any of it's interfaces that address will be bound to it's loopback > >> interface typically. > > > Sure. Michael Richardson's example is clear enough. But in the ACP > > case we are trying to send packets amongst a set of ASAs over > > secure L3overSomething tunnels. That sounds like a VPN in the full > > sense of the term, so the addresses in question are associated with > > the virtual interfaces that terminate the VPN tunnels. So they > > are *not* addresses that are not associated with any interface. > > I don't see why they are any different than the addresses > > on a TAP interface. > > If we have *no* dynamic routing over the secure L3 tunnels, then we can never > have a problem, but even RPL's DODAG can change. ANIMA typically won't be > dealing exclusively with radio interfaces (important thing about radio, is > that it's multiple access, but adjacencies are not transitive: so you can > change adjancies without necessarily changing interfaces), then one can not > depend upon the end points of the tunnels being stable. > In order to not create multi-link subnets, RPL node are actually encouraged > to configure /128 addresses on their loopback, and depend upon routing to get > to "adjacent" neighbours. That's fine. That's routing, and the routing community, for whatever historical reason, uses a trick -- parking addresses on the imaginary loopback interface -- to ensure that they aren't assigned to any physical interface. (Just to show that this is a trick: it appears that to install a loopback interface on Windows 8, you have to go via "Add Legacy Hardware" and add an imaginary device called "Microsoft KM-TEST Loopback Adapter". Duh.) What niggles me in Michael Behringer's proposal is embedding this trick in specification language; it makes anyone who actually parses the word "loopback" wonder what is going on. So I have the following suggestion for draft-behringer-anima-autonomic-addressing: OLD This scheme targets exclusively loopback addresses of nodes. We assume that link-local addressing is used on the interfaces of links. NEW This scheme targets exclusively virtual addresses of nodes within the ACP. We assume that only link-local addressing is used for ACP traffic on the physical interfaces of links. Brian > > > There's a degenerate case when the two ASAs that want to communicate > > happen to be on the same machine. In that case there is indeed > > a loopback, but it isn't the general case. > > > Sorry to appear obtuse but I do want our terminology to be accurate > > and not linked to specific implementation techniques. If there's > > an RFC that clarifies all this I'd be pleased to study it. > > So, there isn't any difference between an address on a loopback interface > and one on a virtual interface like a TAP interface, except that TAP > interfaces generally send the packet *somewhere*, whereas loopback doesn't. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu May 14 18:18:52 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32921B2EAA for ; Thu, 14 May 2015 18:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 gAgldR59CVfn for ; Thu, 14 May 2015 18:18:49 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::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 5B0EB1B2EAB for ; Thu, 14 May 2015 18:18:49 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so90629789igb.1 for ; Thu, 14 May 2015 18:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Bo+XIDhonWEKNwB8n10rtGEpGvjZyRlsuQQzkW35sSI=; b=KSDBtHP3j0k+DewrH7mnaRvFctwEm4TxxNcFbNhmBCw/BoigqjPPrBgPoR+eqRDLsO +LcKvSupr+IjVvyFn5265hI3/oG1iTkZ4upAdJwb+L3k9gh0AUOm+LvGIc267QYPD5wz F5Q6UCI4u/K5YnMWy5a3Z00v+mG5ArB7CQ+kvrXC0jyQQL4FqkiX3EKek9cErRblTVGq ODL6WSGk2sT83LD0YMmcwPlRlQZNpjK26MVOKmEh5lsnDp9OkNe2OFhBkKw+e+lX5YCe /me2tx5riQMbcRJEMmkA/6XTNPzQC4+WIyd2DCnnSsQL8bJjgcgedbJcIKMdkXgWcktl csDg== X-Received: by 10.68.191.101 with SMTP id gx5mr13503596pbc.148.1431652728841; Thu, 14 May 2015 18:18:48 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id nw8sm33271pdb.30.2015.05.14.18.18.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 18:18:47 -0700 (PDT) Message-ID: <5555497F.3070700@gmail.com> Date: Fri, 15 May 2015 13:18:55 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Anima WG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 May 2015 01:18:51 -0000 While doing some thinking in the context of the signaling design team, I came upon another addressing question. A single physical node might contain several independent autonomic service agents (ASAs) handling different resources. Will those ASAs all use the same layer 3 address, or will they have an address each? This matters for the signaling design, because if they all have the same address, it isn't clear how they could share a listen port. At the least, it creates a complicated demultiplexing requirement. (We have that anyway for incoming discovery messages, but they are distinguished by an 'objective' parameter.) draft-behringer-anima-autonomic-addressing-00 describes one address per node, as far as I can tell. Brian From nobody Thu May 14 19:34:27 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6853C1A1EED for ; Thu, 14 May 2015 19:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oqKIE8Yow_q7 for ; Thu, 14 May 2015 19:34:24 -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 94ECF1A1BF3 for ; Thu, 14 May 2015 19:34:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWB16916; Fri, 15 May 2015 02:34:22 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 May 2015 03:34:21 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 15 May 2015 10:34:14 +0800 From: Sheng Jiang To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0ds6q5IfZSBEaKKYcYjkykR518TuDg Date: Fri, 15 May 2015 02:34:13 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> References: <5555497F.3070700@gmail.com> In-Reply-To: <5555497F.3070700@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 Archived-At: Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 May 2015 02:34:26 -0000 SW4gbXkgb3BpbmlvbiwgYWRkcmVzc2luZyBwZXIgQVNBIHdvdWxkIGJlIGlkZWFsLiBCdXQgaXQg aXMgdG9vIGlkZWFsIHRvIGJlIHRha2VuIGFzIGEgY29tbW9uIGFzc3VtcHRpb24uIFRoZSBzaWdu YWxpbmcgc2hvdWxkIGJlIGFibGUgdG8gc3VwcG9ydCB0aGUgc2NlbmFyaW8gdGhhdCBBU0FzIHNo YXJlIHRoZSBzYW1lIGxheWVyIDMgYWRkcmVzcy4gT25lIGFkZHJlc3MgcGVyIEFTQSBjb3VsZCBi ZSBjb25zaWRlcmVkIGFzIGEgc3Vic2V0IG9mIGl0LiBJIHBlcnNvbmFsbHkgYmVsaWV2ZSB0aGUg Y3VycmVudCBkZXNpZ24gaGFzIGFscmVhZHkgc3VwcG9ydCB0aGlzLg0KDQpTaGVuZw0KDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFDQo+Q2FycGVudGVyDQo+U2VudDogRnJp ZGF5LCBNYXkgMTUsIDIwMTUgOToxOSBBTQ0KPlRvOiBBbmltYSBXRw0KPlN1YmplY3Q6IFtBbmlt YV0gQWRkcmVzc2luZyBBU0FzIG9yIG5vZGVzPw0KPg0KPldoaWxlIGRvaW5nIHNvbWUgdGhpbmtp bmcgaW4gdGhlIGNvbnRleHQgb2YgdGhlIHNpZ25hbGluZw0KPmRlc2lnbiB0ZWFtLCBJIGNhbWUg dXBvbiBhbm90aGVyIGFkZHJlc3NpbmcgcXVlc3Rpb24uDQo+DQo+QSBzaW5nbGUgcGh5c2ljYWwg bm9kZSBtaWdodCBjb250YWluIHNldmVyYWwgaW5kZXBlbmRlbnQNCj5hdXRvbm9taWMgc2Vydmlj ZSBhZ2VudHMgKEFTQXMpIGhhbmRsaW5nIGRpZmZlcmVudCByZXNvdXJjZXMuDQo+DQo+V2lsbCB0 aG9zZSBBU0FzIGFsbCB1c2UgdGhlIHNhbWUgbGF5ZXIgMyBhZGRyZXNzLCBvciB3aWxsDQo+dGhl eSBoYXZlIGFuIGFkZHJlc3MgZWFjaD8NCj4NCj5UaGlzIG1hdHRlcnMgZm9yIHRoZSBzaWduYWxp bmcgZGVzaWduLCBiZWNhdXNlIGlmIHRoZXkgYWxsDQo+aGF2ZSB0aGUgc2FtZSBhZGRyZXNzLCBp dCBpc24ndCBjbGVhciBob3cgdGhleSBjb3VsZCBzaGFyZQ0KPmEgbGlzdGVuIHBvcnQuIEF0IHRo ZSBsZWFzdCwgaXQgY3JlYXRlcyBhIGNvbXBsaWNhdGVkDQo+ZGVtdWx0aXBsZXhpbmcgcmVxdWly ZW1lbnQuIChXZSBoYXZlIHRoYXQgYW55d2F5IGZvcg0KPmluY29taW5nIGRpc2NvdmVyeSBtZXNz YWdlcywgYnV0IHRoZXkgYXJlIGRpc3Rpbmd1aXNoZWQgYnkNCj5hbiAnb2JqZWN0aXZlJyBwYXJh bWV0ZXIuKQ0KPg0KPmRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtYWRkcmVzc2luZy0w MCBkZXNjcmliZXMgb25lDQo+YWRkcmVzcyBwZXIgbm9kZSwgYXMgZmFyIGFzIEkgY2FuIHRlbGwu DQo+DQo+ICAgIEJyaWFuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5BbmltYSBtYWlsaW5nIGxpc3QNCj5BbmltYUBpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg== From nobody Thu May 14 20:30:32 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DED1A871B for ; Thu, 14 May 2015 20:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 kR7NzpBLq9YU for ; Thu, 14 May 2015 20:30:30 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 ADDAA1A8726 for ; Thu, 14 May 2015 20:30:28 -0700 (PDT) Received: by labbd9 with SMTP id bd9so99529799lab.2 for ; Thu, 14 May 2015 20:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3aWmfntM+An5E6evzc/OH7JCDF5jccQh+MluhhBBaMs=; b=aF4fBCKn/n8GP5ayn1BdbZoBLKVUbBr74rqdOMJ13iyqIVNd6LMAYVszuhTuecP/Wi QnklDhkc46EP+Z5gBw/1swouoOY9rEptEutqtNbM8YM0KGejmU2HuFUL3y2oIXsV0U/z dCyvRWK4l2MojQjheF3WivSr3x5gw5762LNV6Bo9NzXvgYTeityz5gLLN2PlH8N5kIoN ER+zyTNR+OoljzNvUpGkwSVVBqfEM8UiVnffrr+G/iqq+w5jOT3mSLApNA3nxF1Gj/xG ttb761O3ej3zFxe/FUlgHLtUce914Gc0gcwja83/kqarVGug630PPpkmYJy/NdTB5PI+ Ml5A== MIME-Version: 1.0 X-Received: by 10.112.210.2 with SMTP id mq2mr5513997lbc.17.1431660627149; Thu, 14 May 2015 20:30:27 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.252.198 with HTTP; Thu, 14 May 2015 20:30:27 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> Date: Fri, 15 May 2015 00:30:27 -0300 X-Google-Sender-Auth: Bue88wVI8P61Pjn8pMS5rp_MOUM Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: Sheng Jiang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Anima WG Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 May 2015 03:30:32 -0000 Hi. I think that all ASAs must use the same layer 3 address. As a demux approach, a valid analogy is the presence of multiple SNMP agents in a node. Thus, something like the contextEngineID/snmpEngineID could be used. Best. J=C3=A9ferson Campos Nobre PhD Student Computer Networks Group - Institute of Informatics Federal University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre On Thu, May 14, 2015 at 11:34 PM, Sheng Jiang wrote= : > In my opinion, addressing per ASA would be ideal. But it is too ideal to = be taken as a common assumption. The signaling should be able to support th= e scenario that ASAs share the same layer 3 address. One address per ASA co= uld be considered as a subset of it. I personally believe the current desig= n has already support this. > > Sheng > >>-----Original Message----- >>From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>Carpenter >>Sent: Friday, May 15, 2015 9:19 AM >>To: Anima WG >>Subject: [Anima] Addressing ASAs or nodes? >> >>While doing some thinking in the context of the signaling >>design team, I came upon another addressing question. >> >>A single physical node might contain several independent >>autonomic service agents (ASAs) handling different resources. >> >>Will those ASAs all use the same layer 3 address, or will >>they have an address each? >> >>This matters for the signaling design, because if they all >>have the same address, it isn't clear how they could share >>a listen port. At the least, it creates a complicated >>demultiplexing requirement. (We have that anyway for >>incoming discovery messages, but they are distinguished by >>an 'objective' parameter.) >> >>draft-behringer-anima-autonomic-addressing-00 describes one >>address per node, as far as I can tell. >> >> Brian >> >>_______________________________________________ >>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 Thu May 14 20:35:52 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23291A871C for ; Thu, 14 May 2015 20:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 EbRq7UREG188 for ; Thu, 14 May 2015 20:35:49 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78A21A8745 for ; Thu, 14 May 2015 20:35:48 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so99364274igb.1 for ; Thu, 14 May 2015 20:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hTfLStBYMOJmWMjM/xuwyrd5x8gD0g5VnLYnvHXOV/M=; b=rY0TxwwYeauve0YVgNGSLgjE1J+GUeNMznG3iWxj7Ji/1Rum3PMPXEMfRgf2nMfsL5 e74nGmUbEIlV8e3BJJXsPlEeDYKJiHbqqYcTODogge9hAB1cnlfwj9g0LjmvC91kFuIH 7yVlEhocIjbdJuESZuJTGpF4wNFP6DgtlaoSM80yKm3js9w1R2mKgoPBbfoqLdPSlulL 5qHT2DU1u+uqgKPOPGamQOoy7pNFPGgF7xbQqQvKqJ0Yegc4/14sSNWatYAKwbG3M0wk Zx78cywz06C1Mz/IOxcu3JQBIZnFM4/HZZAzBIXETefSbOy6478fO2p/SOY0V9sLDmoi sFeg== X-Received: by 10.68.135.233 with SMTP id pv9mr14389610pbb.115.1431660948109; Thu, 14 May 2015 20:35:48 -0700 (PDT) Received: from ?IPv6:2406:e007:5921:1:28cc:dc4c:9703:6781? ([2406:e007:5921:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id eu5sm225485pbb.44.2015.05.14.20.35.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 20:35:46 -0700 (PDT) Message-ID: <5555699A.9010605@gmail.com> Date: Fri, 15 May 2015 15:35:54 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?UTF-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Sheng Jiang References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Anima WG Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 May 2015 03:35:51 -0000 On 15/05/2015 15:30, J=C3=A9ferson Campos Nobre wrote: > Hi. > I think that all ASAs must use the same layer 3 address. > As a demux approach, a valid analogy is the presence of multiple SNMP > agents in a node. Thus, something like the > contextEngineID/snmpEngineID could be used. Actually we have a SessionID in the GDNP design. I will have to check, but I think that occurs in all cases where we would need to demultiplex. As long as it is allocated uniquely per-node (rather than per-ASA), that would be enough. Brian > Best. >=20 > J=C3=A9ferson Campos Nobre > PhD Student > Computer Networks Group - Institute of Informatics > Federal University of Rio Grande do Sul > http://www.inf.ufrgs.br/~jcnobre >=20 > On Thu, May 14, 2015 at 11:34 PM, Sheng Jiang w= rote: >> In my opinion, addressing per ASA would be ideal. But it is too ideal = to be taken as a common assumption. The signaling should be able to suppo= rt the scenario that ASAs share the same layer 3 address. One address per= ASA could be considered as a subset of it. I personally believe the curr= ent design has already support this. >> >> Sheng >> >>> -----Original Message----- >>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>> Carpenter >>> Sent: Friday, May 15, 2015 9:19 AM >>> To: Anima WG >>> Subject: [Anima] Addressing ASAs or nodes? >>> >>> While doing some thinking in the context of the signaling >>> design team, I came upon another addressing question. >>> >>> A single physical node might contain several independent >>> autonomic service agents (ASAs) handling different resources. >>> >>> Will those ASAs all use the same layer 3 address, or will >>> they have an address each? >>> >>> This matters for the signaling design, because if they all >>> have the same address, it isn't clear how they could share >>> a listen port. At the least, it creates a complicated >>> demultiplexing requirement. (We have that anyway for >>> incoming discovery messages, but they are distinguished by >>> an 'objective' parameter.) >>> >>> draft-behringer-anima-autonomic-addressing-00 describes one >>> address per node, as far as I can tell. >>> >>> Brian >>> >>> _______________________________________________ >>> 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 >=20 From nobody Sat May 16 11:38:42 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C061A0273 for ; Sat, 16 May 2015 11:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 d_BpJZGmOdxF for ; Sat, 16 May 2015 11:38:39 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781181A026F for ; Sat, 16 May 2015 11:38:38 -0700 (PDT) Received: by wguv19 with SMTP id v19so85568256wgu.1 for ; Sat, 16 May 2015 11:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8Z2XZdjXX5aAznwE0Y12LS3YMfxGCv+/CH5I29vj7q4=; b=eKsR0NJUzEbq5HgtYcPqMIO+qHH5rXpglRRAKw96HTXEnNzQokpT2sdW5NH85/+bmN I+N4Qszc7CBD3zT43zd+y8bm+xvMh3mOkU5bHglxxcnt/dYq01hESlspQFMONE1jbGY3 uiQ3AfiMYu5MxmlsU1oM8McMh+yQAO7UdF/9LMdGPgALKQz2yGINtplxacHlD+m2iIJq WAsNyHMsNNSt5q0B+cMTunjq47Ksjv99UxO7pvPhCsy3UD9I1Aep6E8EMK5szPHt1bAX uI5UUPMWX5OVjpXDQUYfp/C1sThgDQH7GcAaKaBAuLI5egvdYcJ8lY/VCeHO2b8gwcHH TfLQ== MIME-Version: 1.0 X-Received: by 10.180.109.136 with SMTP id hs8mr7709159wib.73.1431801517216; Sat, 16 May 2015 11:38:37 -0700 (PDT) Received: by 10.27.220.19 with HTTP; Sat, 16 May 2015 11:38:37 -0700 (PDT) In-Reply-To: <5555699A.9010605@gmail.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> Date: Sat, 16 May 2015 11:38:37 -0700 Message-ID: From: John Strassner To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8f234557d29810051637446a Archived-At: Cc: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= , Anima WG , Sheng Jiang Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 18:38:41 -0000 --e89a8f234557d29810051637446a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Sheng. In general, agents should be at least semi-autonomous, as they will have different purposes and targets. Therefore, they should have the freedom to use their own unique address. regards, John On Thu, May 14, 2015 at 8:35 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 15/05/2015 15:30, J=C3=A9ferson Campos Nobre wrote: > > Hi. > > I think that all ASAs must use the same layer 3 address. > > As a demux approach, a valid analogy is the presence of multiple SNMP > > agents in a node. Thus, something like the > > contextEngineID/snmpEngineID could be used. > > Actually we have a SessionID in the GDNP design. I will have to check, > but I think that occurs in all cases where we would need to demultiplex. > As long as it is allocated uniquely per-node (rather than per-ASA), that > would be enough. > > Brian > > > Best. > > > > J=C3=A9ferson Campos Nobre > > PhD Student > > Computer Networks Group - Institute of Informatics > > Federal University of Rio Grande do Sul > > http://www.inf.ufrgs.br/~jcnobre > > > > On Thu, May 14, 2015 at 11:34 PM, Sheng Jiang > wrote: > >> In my opinion, addressing per ASA would be ideal. But it is too ideal > to be taken as a common assumption. The signaling should be able to suppo= rt > the scenario that ASAs share the same layer 3 address. One address per AS= A > could be considered as a subset of it. I personally believe the current > design has already support this. > >> > >> Sheng > >> > >>> -----Original Message----- > >>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > >>> Carpenter > >>> Sent: Friday, May 15, 2015 9:19 AM > >>> To: Anima WG > >>> Subject: [Anima] Addressing ASAs or nodes? > >>> > >>> While doing some thinking in the context of the signaling > >>> design team, I came upon another addressing question. > >>> > >>> A single physical node might contain several independent > >>> autonomic service agents (ASAs) handling different resources. > >>> > >>> Will those ASAs all use the same layer 3 address, or will > >>> they have an address each? > >>> > >>> This matters for the signaling design, because if they all > >>> have the same address, it isn't clear how they could share > >>> a listen port. At the least, it creates a complicated > >>> demultiplexing requirement. (We have that anyway for > >>> incoming discovery messages, but they are distinguished by > >>> an 'objective' parameter.) > >>> > >>> draft-behringer-anima-autonomic-addressing-00 describes one > >>> address per node, as far as I can tell. > >>> > >>> Brian > >>> > >>> _______________________________________________ > >>> 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 > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --=20 regards, John --e89a8f234557d29810051637446a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Sheng. In general, agents should be at l= east semi-autonomous, as they will have different purposes and targets. The= refore, they should have the freedom to use their own unique address.
=

regards,
John

On Thu, May 14, 2015 at 8:35 PM, Bria= n E Carpenter <brian.e.carpenter@gmail.com> wrote:=
On 15/05/2015 15:30, J=C3=A9ferson Campo= s Nobre wrote:
> Hi.
> I think that all ASAs must use the same layer 3 address.
> As a demux approach, a valid analogy is the presence of multiple SNMP<= br> > agents in a node. Thus, something like the
> contextEngineID/snmpEngineID could be used.

Actually we have a SessionID in the GDNP design. I will have to check,
but I think that occurs in all cases where we would need to demultiplex. As long as it is allocated uniquely per-node (rather than per-ASA), that would be enough.

=C2=A0 =C2=A0Brian

> Best.
>
> J=C3=A9ferson Campos Nobre
> PhD Student
> Computer Networks Group -=C2=A0 Institute of Informatics
> Federal University of Rio Grande do Sul
> http://= www.inf.ufrgs.br/~jcnobre
>
> On Thu, May 14, 2015 at 11:34 PM, Sheng Jiang <jiangsheng@huawei.com> wrote:
>> In my opinion, addressing per ASA would be ideal. But it is too id= eal to be taken as a common assumption. The signaling should be able to sup= port the scenario that ASAs share the same layer 3 address. One address per= ASA could be considered as a subset of it. I personally believe the curren= t design has already support this.
>>
>> Sheng
>>
>>> -----Original Message-----
>>> From: Anima [mailto:= anima-bounces@ietf.org] On Behalf Of Brian E
>>> Carpenter
>>> Sent: Friday, May 15, 2015 9:19 AM
>>> To: Anima WG
>>> Subject: [Anima] Addressing ASAs or nodes?
>>>
>>> While doing some thinking in the context of the signaling
>>> design team, I came upon another addressing question.
>>>
>>> A single physical node might contain several independent
>>> autonomic service agents (ASAs) handling different resources.<= br> >>>
>>> Will those ASAs all use the same layer 3 address, or will
>>> they have an address each?
>>>
>>> This matters for the signaling design, because if they all
>>> have the same address, it isn't clear how they could share=
>>> a listen port. At the least, it creates a complicated
>>> demultiplexing requirement. (We have that anyway for
>>> incoming discovery messages, but they are distinguished by
>>> an 'objective' parameter.)
>>>
>>> draft-behringer-anima-autonomic-addressing-00 describes one >>> address per node, as far as I can tell.
>>>
>>>=C2=A0 =C2=A0 Brian
>>>
>>> _______________________________________________
>>> 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
>

_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima



--
regards,
John
--e89a8f234557d29810051637446a-- From nobody Sat May 16 12:50:12 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EAE1A3B9C for ; Sat, 16 May 2015 12:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 QpTLh9Yxezbl for ; Sat, 16 May 2015 12:50:09 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::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 93B6E1A212A for ; Sat, 16 May 2015 12:50:09 -0700 (PDT) Received: by pdeq5 with SMTP id q5so76458420pde.1 for ; Sat, 16 May 2015 12:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WeV3dcKtFk3ahixHLDIZ/D7vdmMbjxTrLho60MCP5xA=; b=vxwEOYu7fzH1strUNG/E5d4H1ZxlOv4enS/vjTwtaG37NLH3hYAyEVI9Pob1g3In8T qd4FQqfqdg6Eo13fbxWhk7JuSzZV0BYHecEV0PkcoTAMMQvBix50iuRW45ll7w5wTqqk CtTvSl4tSOLT8+cxCdAC7icvWGhKD39D6sdUBbTn6L9/+9LXM6iJVoaLA+Nn+w99dnjT /eiU9U9BIrTl7oQWljRXH+jRBMAwWZlUgiTFQnt7ffZirX5Ct7VuPjkmJjz1a6MQ6qW3 02VK78mUQnoRCtGGmqrMQ/LdCKoLbUghhKNhioOpLSe4Av/9ExR/wxTglVasDqpXAYJP kCIw== X-Received: by 10.70.41.135 with SMTP id f7mr29503150pdl.113.1431805809279; Sat, 16 May 2015 12:50:09 -0700 (PDT) Received: from ?IPv6:2406:e007:468a:1:28cc:dc4c:9703:6781? ([2406:e007:468a:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id nt15sm5509013pdb.14.2015.05.16.12.50.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 12:50:07 -0700 (PDT) Message-ID: <55579F6A.9030802@gmail.com> Date: Sun, 17 May 2015 07:50:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Strassner References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?UTF-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Anima WG , Sheng Jiang Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 19:50:11 -0000 On 17/05/2015 06:38, John Strassner wrote: > I agree with Sheng. In general, agents should be at least semi-autonomo= us, > as they will have different purposes and targets. Therefore, they shoul= d > have the freedom to use their own unique address. Certainly we shouldn't have any arbitrary restrictions. It does interact with the authentication mechanisms, though. Does an ASA inherit its trust= from the device, and how does that work if there are several ASAs with different addresses in the same device? Brian >=20 > regards, > John >=20 > On Thu, May 14, 2015 at 8:35 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> On 15/05/2015 15:30, J=C3=A9ferson Campos Nobre wrote: >>> Hi. >>> I think that all ASAs must use the same layer 3 address. >>> As a demux approach, a valid analogy is the presence of multiple SNMP= >>> agents in a node. Thus, something like the >>> contextEngineID/snmpEngineID could be used. >> >> Actually we have a SessionID in the GDNP design. I will have to check,= >> but I think that occurs in all cases where we would need to demultiple= x. >> As long as it is allocated uniquely per-node (rather than per-ASA), th= at >> would be enough. >> >> Brian >> >>> Best. >>> >>> J=C3=A9ferson Campos Nobre >>> PhD Student >>> Computer Networks Group - Institute of Informatics >>> Federal University of Rio Grande do Sul >>> http://www.inf.ufrgs.br/~jcnobre >>> >>> On Thu, May 14, 2015 at 11:34 PM, Sheng Jiang = >> wrote: >>>> In my opinion, addressing per ASA would be ideal. But it is too idea= l >> to be taken as a common assumption. The signaling should be able to su= pport >> the scenario that ASAs share the same layer 3 address. One address per= ASA >> could be considered as a subset of it. I personally believe the curren= t >> design has already support this. >>>> >>>> Sheng >>>> >>>>> -----Original Message----- >>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>>> Carpenter >>>>> Sent: Friday, May 15, 2015 9:19 AM >>>>> To: Anima WG >>>>> Subject: [Anima] Addressing ASAs or nodes? >>>>> >>>>> While doing some thinking in the context of the signaling >>>>> design team, I came upon another addressing question. >>>>> >>>>> A single physical node might contain several independent >>>>> autonomic service agents (ASAs) handling different resources. >>>>> >>>>> Will those ASAs all use the same layer 3 address, or will >>>>> they have an address each? >>>>> >>>>> This matters for the signaling design, because if they all >>>>> have the same address, it isn't clear how they could share >>>>> a listen port. At the least, it creates a complicated >>>>> demultiplexing requirement. (We have that anyway for >>>>> incoming discovery messages, but they are distinguished by >>>>> an 'objective' parameter.) >>>>> >>>>> draft-behringer-anima-autonomic-addressing-00 describes one >>>>> address per node, as far as I can tell. >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >=20 >=20 >=20 From nobody Sun May 17 13:08:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BAF1ACD27 for ; Sun, 17 May 2015 13:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 oCH6pH8cCwWB for ; Sun, 17 May 2015 13:08:10 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::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 2898B1ACD23 for ; Sun, 17 May 2015 13:08:10 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so117440709pdb.0 for ; Sun, 17 May 2015 13:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+x4jSEO4hh4jkaoWQA6BsuQwjnoSNqA6jl+guWQZnkA=; b=0hjzn5dskeBMiEfne+MJcpnw9DpaBiB23L99+fYw0Witkxg2ze/z843BlYKWDPMCQj 0+GbY/oCwbmWV7n0X8ESynxzcaKX+ySG0P0272CAuQnK17N7Hc9Str21bkNF22x/2s+O gV09MjcXkrdRPaeraS/e8BnYSVISHYuxz9xFJb7AzzNV7wueiWgPWvvwctlLZY8Uca1C OWaJtKK86FNl22xhXu98SAwBvNADi1nH6J+fQtJE53BOp2WQhnMB7VVm7mXuzjfnMViz su+6ydmgPeni/9jYx08b1mTwSD08BhVWxH1KvxrlPwNV7PmKz7apnWU7OieKh4W+JSVJ 1TSQ== X-Received: by 10.68.131.196 with SMTP id oo4mr37434320pbb.119.1431893289810; Sun, 17 May 2015 13:08:09 -0700 (PDT) Received: from ?IPv6:2406:e007:5d8c:1:28cc:dc4c:9703:6781? ([2406:e007:5d8c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id om4sm7838047pdb.68.2015.05.17.13.08.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 May 2015 13:08:08 -0700 (PDT) Message-ID: <5558F525.4060000@gmail.com> Date: Mon, 18 May 2015 08:08:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Strassner References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> In-Reply-To: <55579F6A.9030802@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?UTF-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Anima WG , Sheng Jiang Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 20:08:12 -0000 OK, answering half of my own quetion... On 17/05/2015 07:50, Brian E Carpenter wrote: > On 17/05/2015 06:38, John Strassner wrote: >> I agree with Sheng. In general, agents should be at least semi-autonom= ous, >> as they will have different purposes and targets. Therefore, they shou= ld >> have the freedom to use their own unique address. >=20 > Certainly we shouldn't have any arbitrary restrictions. It does interac= t > with the authentication mechanisms, though. Does an ASA inherit its tru= st > from the device, and how does that work if there are several ASAs with > different addresses in the same device? While working on the next update of the signaling protocol, I reached a f= irm conclusion that an ASA needs to inherit the trust credentials of the devi= ce that contains it. Otherwise each ASA would have to go through the trust bootstrap process for itself, and that seems like a perverse requirement.= Brian >=20 > Brian >=20 >> >> regards, >> John >> >> On Thu, May 14, 2015 at 8:35 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> On 15/05/2015 15:30, J=C3=A9ferson Campos Nobre wrote: >>>> Hi. >>>> I think that all ASAs must use the same layer 3 address. >>>> As a demux approach, a valid analogy is the presence of multiple SNM= P >>>> agents in a node. Thus, something like the >>>> contextEngineID/snmpEngineID could be used. >>> >>> Actually we have a SessionID in the GDNP design. I will have to check= , >>> but I think that occurs in all cases where we would need to demultipl= ex. >>> As long as it is allocated uniquely per-node (rather than per-ASA), t= hat >>> would be enough. >>> >>> Brian >>> >>>> Best. >>>> >>>> J=C3=A9ferson Campos Nobre >>>> PhD Student >>>> Computer Networks Group - Institute of Informatics >>>> Federal University of Rio Grande do Sul >>>> http://www.inf.ufrgs.br/~jcnobre >>>> >>>> On Thu, May 14, 2015 at 11:34 PM, Sheng Jiang >>> wrote: >>>>> In my opinion, addressing per ASA would be ideal. But it is too ide= al >>> to be taken as a common assumption. The signaling should be able to s= upport >>> the scenario that ASAs share the same layer 3 address. One address pe= r ASA >>> could be considered as a subset of it. I personally believe the curre= nt >>> design has already support this. >>>>> >>>>> Sheng >>>>> >>>>>> -----Original Message----- >>>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>>>> Carpenter >>>>>> Sent: Friday, May 15, 2015 9:19 AM >>>>>> To: Anima WG >>>>>> Subject: [Anima] Addressing ASAs or nodes? >>>>>> >>>>>> While doing some thinking in the context of the signaling >>>>>> design team, I came upon another addressing question. >>>>>> >>>>>> A single physical node might contain several independent >>>>>> autonomic service agents (ASAs) handling different resources. >>>>>> >>>>>> Will those ASAs all use the same layer 3 address, or will >>>>>> they have an address each? >>>>>> >>>>>> This matters for the signaling design, because if they all >>>>>> have the same address, it isn't clear how they could share >>>>>> a listen port. At the least, it creates a complicated >>>>>> demultiplexing requirement. (We have that anyway for >>>>>> incoming discovery messages, but they are distinguished by >>>>>> an 'objective' parameter.) >>>>>> >>>>>> draft-behringer-anima-autonomic-addressing-00 describes one >>>>>> address per node, as far as I can tell. >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> >> >=20 From nobody Sun May 17 18:17:21 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE5F1ACEAA for ; Sun, 17 May 2015 18:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PzL3k1aiGcJh for ; Sun, 17 May 2015 18:17:17 -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 26F581ACEA9 for ; Sun, 17 May 2015 18:17:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSQ16594; Mon, 18 May 2015 01:17:15 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 May 2015 02:17:14 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 18 May 2015 09:17:08 +0800 From: Sheng Jiang To: Brian E Carpenter , John Strassner Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0ds6q5IfZSBEaKKYcYjkykR518TuDg//+MooCAAAGGAIACjoyAgAAT9ACAAZdggIAA2MfQ Date: Mon, 18 May 2015 01:17:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F5286DD@nkgeml512-mbx.china.huawei.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> In-Reply-To: <5558F525.4060000@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 Archived-At: Cc: =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Anima WG Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 18 May 2015 01:17:20 -0000 Pj4gQ2VydGFpbmx5IHdlIHNob3VsZG4ndCBoYXZlIGFueSBhcmJpdHJhcnkgcmVzdHJpY3Rpb25z LiBJdCBkb2VzIGludGVyYWN0DQo+PiB3aXRoIHRoZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21z LCB0aG91Z2guIERvZXMgYW4gQVNBIGluaGVyaXQgaXRzIHRydXN0DQo+PiBmcm9tIHRoZSBkZXZp Y2UsIGFuZCBob3cgZG9lcyB0aGF0IHdvcmsgaWYgdGhlcmUgYXJlIHNldmVyYWwgQVNBcyB3aXRo DQo+PiBkaWZmZXJlbnQgYWRkcmVzc2VzIGluIHRoZSBzYW1lIGRldmljZT8NCj4NCj5XaGlsZSB3 b3JraW5nIG9uIHRoZSBuZXh0IHVwZGF0ZSBvZiB0aGUgc2lnbmFsaW5nIHByb3RvY29sLCBJIHJl YWNoZWQgYSBmaXJtDQo+Y29uY2x1c2lvbiB0aGF0IGFuIEFTQSBuZWVkcyB0byBpbmhlcml0IHRo ZSB0cnVzdCBjcmVkZW50aWFscyBvZiB0aGUgZGV2aWNlDQo+dGhhdCBjb250YWlucyBpdC4gT3Ro ZXJ3aXNlIGVhY2ggQVNBIHdvdWxkIGhhdmUgdG8gZ28gdGhyb3VnaCB0aGUgdHJ1c3QNCj5ib290 c3RyYXAgcHJvY2VzcyBmb3IgaXRzZWxmLCBhbmQgdGhhdCBzZWVtcyBsaWtlIGEgcGVydmVyc2Ug cmVxdWlyZW1lbnQuDQoNCkkgYWdyZWUgdGhhdCB0aGUgYWJvdmUgaW5oZXJpdGluZyBvZiB0aGUg dHJ1c3QgY3JlZGVudGlhbCBmcm9tIHRoZSBkZXZpY2UgdG8gQVNBIHNob3VsZCBiZSBkZWZhdWx0 IGJlaGF2aW9yLiBGdXJ0aGVybW9yZSwgSSBzdGlsbCBiZWxpZXZlIG9ubHkgb25lIHNlY3VyaXR5 IGxldmVsIGlzIE5PVCBlbm91Z2guIFNvbWUgc3BlY2lmaWMgQVNBcyBtYXkgaGF2ZSBoaWdoZXIg cmVxdWlyZW1lbnRzIGZvciBpdHNlbGYuIFRoZXkgc2hvdWxkIGJlIGFsbG93ZWQgdG8gaGF2ZSB0 aGVpciBvd24gYXV0aGVudGljYXRpb24gb24gdGhlIHRvcCBvZiB0aGUgZGVmYXVsdCB0cnVzdCBj cmVkZW50aWFsLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4gICBCcmlhbg0KPg0KPj4g ICAgIEJyaWFuDQo+Pj4NCj4+PiByZWdhcmRzLA0KPj4+IEpvaG4NCj4+Pg0KPj4+IE9uIFRodSwg TWF5IDE0LCAyMDE1IGF0IDg6MzUgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDwNCj4+PiBicmlhbi5l LmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPj4+DQo+Pj4+IE9uIDE1LzA1LzIwMTUgMTU6 MzAsIErDqWZlcnNvbiBDYW1wb3MgTm9icmUgd3JvdGU6DQo+Pj4+PiBIaS4NCj4+Pj4+IEkgdGhp bmsgdGhhdCBhbGwgQVNBcyBtdXN0IHVzZSB0aGUgc2FtZSBsYXllciAzIGFkZHJlc3MuDQo+Pj4+ PiBBcyBhIGRlbXV4IGFwcHJvYWNoLCBhIHZhbGlkIGFuYWxvZ3kgaXMgdGhlIHByZXNlbmNlIG9m IG11bHRpcGxlIFNOTVANCj4+Pj4+IGFnZW50cyBpbiBhIG5vZGUuIFRodXMsIHNvbWV0aGluZyBs aWtlIHRoZQ0KPj4+Pj4gY29udGV4dEVuZ2luZUlEL3NubXBFbmdpbmVJRCBjb3VsZCBiZSB1c2Vk Lg0KPj4+Pg0KPj4+PiBBY3R1YWxseSB3ZSBoYXZlIGEgU2Vzc2lvbklEIGluIHRoZSBHRE5QIGRl c2lnbi4gSSB3aWxsIGhhdmUgdG8gY2hlY2ssDQo+Pj4+IGJ1dCBJIHRoaW5rIHRoYXQgb2NjdXJz IGluIGFsbCBjYXNlcyB3aGVyZSB3ZSB3b3VsZCBuZWVkIHRvIGRlbXVsdGlwbGV4Lg0KPj4+PiBB cyBsb25nIGFzIGl0IGlzIGFsbG9jYXRlZCB1bmlxdWVseSBwZXItbm9kZSAocmF0aGVyIHRoYW4g cGVyLUFTQSksIHRoYXQNCj4+Pj4gd291bGQgYmUgZW5vdWdoLg0KPj4+Pg0KPj4+PiAgICBCcmlh bg0KPj4+Pg0KPj4+Pj4gQmVzdC4NCj4+Pj4+DQo+Pj4+PiBKw6lmZXJzb24gQ2FtcG9zIE5vYnJl DQo+Pj4+PiBQaEQgU3R1ZGVudA0KPj4+Pj4gQ29tcHV0ZXIgTmV0d29ya3MgR3JvdXAgLSAgSW5z dGl0dXRlIG9mIEluZm9ybWF0aWNzDQo+Pj4+PiBGZWRlcmFsIFVuaXZlcnNpdHkgb2YgUmlvIEdy YW5kZSBkbyBTdWwNCj4+Pj4+IGh0dHA6Ly93d3cuaW5mLnVmcmdzLmJyL35qY25vYnJlDQo+Pj4+ Pg0KPj4+Pj4gT24gVGh1LCBNYXkgMTQsIDIwMTUgYXQgMTE6MzQgUE0sIFNoZW5nIEppYW5nDQo+ PGppYW5nc2hlbmdAaHVhd2VpLmNvbT4NCj4+Pj4gd3JvdGU6DQo+Pj4+Pj4gSW4gbXkgb3Bpbmlv biwgYWRkcmVzc2luZyBwZXIgQVNBIHdvdWxkIGJlIGlkZWFsLiBCdXQgaXQgaXMgdG9vIGlkZWFs DQo+Pj4+IHRvIGJlIHRha2VuIGFzIGEgY29tbW9uIGFzc3VtcHRpb24uIFRoZSBzaWduYWxpbmcg c2hvdWxkIGJlIGFibGUgdG8NCj5zdXBwb3J0DQo+Pj4+IHRoZSBzY2VuYXJpbyB0aGF0IEFTQXMg c2hhcmUgdGhlIHNhbWUgbGF5ZXIgMyBhZGRyZXNzLiBPbmUgYWRkcmVzcyBwZXINCj5BU0ENCj4+ Pj4gY291bGQgYmUgY29uc2lkZXJlZCBhcyBhIHN1YnNldCBvZiBpdC4gSSBwZXJzb25hbGx5IGJl bGlldmUgdGhlIGN1cnJlbnQNCj4+Pj4gZGVzaWduIGhhcyBhbHJlYWR5IHN1cHBvcnQgdGhpcy4N Cj4+Pj4+Pg0KPj4+Pj4+IFNoZW5nDQo+Pj4+Pj4NCj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRQ0KPj4+Pj4+PiBDYXJwZW50ZXINCj4+Pj4+Pj4gU2Vu dDogRnJpZGF5LCBNYXkgMTUsIDIwMTUgOToxOSBBTQ0KPj4+Pj4+PiBUbzogQW5pbWEgV0cNCj4+ Pj4+Pj4gU3ViamVjdDogW0FuaW1hXSBBZGRyZXNzaW5nIEFTQXMgb3Igbm9kZXM/DQo+Pj4+Pj4+ DQo+Pj4+Pj4+IFdoaWxlIGRvaW5nIHNvbWUgdGhpbmtpbmcgaW4gdGhlIGNvbnRleHQgb2YgdGhl IHNpZ25hbGluZw0KPj4+Pj4+PiBkZXNpZ24gdGVhbSwgSSBjYW1lIHVwb24gYW5vdGhlciBhZGRy ZXNzaW5nIHF1ZXN0aW9uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBBIHNpbmdsZSBwaHlzaWNhbCBub2Rl IG1pZ2h0IGNvbnRhaW4gc2V2ZXJhbCBpbmRlcGVuZGVudA0KPj4+Pj4+PiBhdXRvbm9taWMgc2Vy dmljZSBhZ2VudHMgKEFTQXMpIGhhbmRsaW5nIGRpZmZlcmVudCByZXNvdXJjZXMuDQo+Pj4+Pj4+ DQo+Pj4+Pj4+IFdpbGwgdGhvc2UgQVNBcyBhbGwgdXNlIHRoZSBzYW1lIGxheWVyIDMgYWRkcmVz cywgb3Igd2lsbA0KPj4+Pj4+PiB0aGV5IGhhdmUgYW4gYWRkcmVzcyBlYWNoPw0KPj4+Pj4+Pg0K Pj4+Pj4+PiBUaGlzIG1hdHRlcnMgZm9yIHRoZSBzaWduYWxpbmcgZGVzaWduLCBiZWNhdXNlIGlm IHRoZXkgYWxsDQo+Pj4+Pj4+IGhhdmUgdGhlIHNhbWUgYWRkcmVzcywgaXQgaXNuJ3QgY2xlYXIg aG93IHRoZXkgY291bGQgc2hhcmUNCj4+Pj4+Pj4gYSBsaXN0ZW4gcG9ydC4gQXQgdGhlIGxlYXN0 LCBpdCBjcmVhdGVzIGEgY29tcGxpY2F0ZWQNCj4+Pj4+Pj4gZGVtdWx0aXBsZXhpbmcgcmVxdWly ZW1lbnQuIChXZSBoYXZlIHRoYXQgYW55d2F5IGZvcg0KPj4+Pj4+PiBpbmNvbWluZyBkaXNjb3Zl cnkgbWVzc2FnZXMsIGJ1dCB0aGV5IGFyZSBkaXN0aW5ndWlzaGVkIGJ5DQo+Pj4+Pj4+IGFuICdv YmplY3RpdmUnIHBhcmFtZXRlci4pDQo+Pj4+Pj4+DQo+Pj4+Pj4+IGRyYWZ0LWJlaHJpbmdlci1h bmltYS1hdXRvbm9taWMtYWRkcmVzc2luZy0wMCBkZXNjcmliZXMgb25lDQo+Pj4+Pj4+IGFkZHJl c3MgcGVyIG5vZGUsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICBC cmlhbg0KPj4+Pj4+Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+Pj4+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gQW5pbWFA aWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h bmltYQ0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+Pj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gQW5pbWFAaWV0Zi5vcmcNCj4+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo+Pj4+Pg0K Pj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4+Pj4gQW5pbWFAaWV0Zi5vcmcNCj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPj4+Pg0KPj4+DQo+Pj4N Cj4+Pg0KPj4NCg0K From nobody Mon May 18 01:39:56 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA5E1A87E2 for ; Mon, 18 May 2015 01:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 a-f3RxB-95zI for ; Mon, 18 May 2015 01:39:51 -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 6CBF51A87E1 for ; Mon, 18 May 2015 01:39:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWF01390; Mon, 18 May 2015 08:39:48 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 May 2015 09:39:47 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.186]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 18 May 2015 16:39:35 +0800 From: "Liubing (Leo)" To: Sheng Jiang , Brian E Carpenter , John Strassner Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0f5PA1WqT30U2bo6CjYanqz517y8yAgAAPtoCAAAGGAIACjoyAgAAT9ACAAZdggIAAVlkAgACKMOA= Date: Mon, 18 May 2015 08:39:34 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45A677C98A@nkgeml506-mbx.china.huawei.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F5286DD@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F5286DD@nkgeml512-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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Anima WG Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 18 May 2015 08:39:54 -0000 SGkgQnJpYW4sIFNoZW5nLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNoZW5n IEppYW5nDQo+IFNlbnQ6IE1vbmRheSwgTWF5IDE4LCAyMDE1IDk6MTcgQU0NCj4gVG86IEJyaWFu IEUgQ2FycGVudGVyOyBKb2huIFN0cmFzc25lcg0KPiBDYzogSsOpZmVyc29uIENhbXBvcyBOb2Jy ZTsgQW5pbWEgV0cNCj4gU3ViamVjdDogUmU6IFtBbmltYV0gQWRkcmVzc2luZyBBU0FzIG9yIG5v ZGVzPw0KPiANCj4gPj4gQ2VydGFpbmx5IHdlIHNob3VsZG4ndCBoYXZlIGFueSBhcmJpdHJhcnkg cmVzdHJpY3Rpb25zLiBJdCBkb2VzDQo+ID4+IGludGVyYWN0IHdpdGggdGhlIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbXMsIHRob3VnaC4gRG9lcyBhbiBBU0ENCj4gPj4gaW5oZXJpdCBpdHMgdHJ1 c3QgZnJvbSB0aGUgZGV2aWNlLCBhbmQgaG93IGRvZXMgdGhhdCB3b3JrIGlmIHRoZXJlDQo+ID4+ IGFyZSBzZXZlcmFsIEFTQXMgd2l0aCBkaWZmZXJlbnQgYWRkcmVzc2VzIGluIHRoZSBzYW1lIGRl dmljZT8NCj4gPg0KPiA+V2hpbGUgd29ya2luZyBvbiB0aGUgbmV4dCB1cGRhdGUgb2YgdGhlIHNp Z25hbGluZyBwcm90b2NvbCwgSSByZWFjaGVkIGENCj4gPmZpcm0gY29uY2x1c2lvbiB0aGF0IGFu IEFTQSBuZWVkcyB0byBpbmhlcml0IHRoZSB0cnVzdCBjcmVkZW50aWFscyBvZg0KPiA+dGhlIGRl dmljZSB0aGF0IGNvbnRhaW5zIGl0LiBPdGhlcndpc2UgZWFjaCBBU0Egd291bGQgaGF2ZSB0byBn bw0KPiA+dGhyb3VnaCB0aGUgdHJ1c3QgYm9vdHN0cmFwIHByb2Nlc3MgZm9yIGl0c2VsZiwgYW5k IHRoYXQgc2VlbXMgbGlrZSBhDQo+IHBlcnZlcnNlIHJlcXVpcmVtZW50Lg0KPiBJIGFncmVlIHRo YXQgdGhlIGFib3ZlIGluaGVyaXRpbmcgb2YgdGhlIHRydXN0IGNyZWRlbnRpYWwgZnJvbSB0aGUg ZGV2aWNlIHRvDQo+IEFTQSBzaG91bGQgYmUgZGVmYXVsdCBiZWhhdmlvci4gRnVydGhlcm1vcmUs IEkgc3RpbGwgYmVsaWV2ZSBvbmx5IG9uZSBzZWN1cml0eQ0KPiBsZXZlbCBpcyBOT1QgZW5vdWdo LiBTb21lIHNwZWNpZmljIEFTQXMgbWF5IGhhdmUgaGlnaGVyIHJlcXVpcmVtZW50cyBmb3INCj4g aXRzZWxmLiBUaGV5IHNob3VsZCBiZSBhbGxvd2VkIHRvIGhhdmUgdGhlaXIgb3duIGF1dGhlbnRp Y2F0aW9uIG9uIHRoZSB0b3Agb2YNCj4gdGhlIGRlZmF1bHQgdHJ1c3QgY3JlZGVudGlhbC4NCg0K W0JpbmddIEkgYWxzbyBhZ3JlZToNCjEuIGFuIEFTQSBuZWVkcyB0byBpbmhlcml0IHRoZSB0cnVz dCBjcmVkZW50aWFscyBvZiB0aGUgZGV2aWNlIHRoYXQgY29udGFpbnMgDQoyLiBBU0FzIG1pZ2h0 IGhhdmUgdGhlaXIgb3duIGF1dGhlbnRpY2F0aW9uIG9uIHRoZSB0b3Agb2YgdGhlIHNlY3VyZSBj aGFubmVsIGJhc2VkIG9uIHRoZSB0cnVzdCBjcmVkZW50aWFsDQoNCkJ1dCBJIGd1ZXNzIHlvdSBk aWRuJ3QgaW1wbGljaXRseSBtZWFuIEFTQXMgbmVlZCBkZWRpY2F0ZWQgSVAgYWRkcmVzc2VzIGR1 ZSB0byB0aGUgYWJvdmUgcmVhc29ucywgcmlnaHQ/IA0KTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0 IHRoZSB0cnVzdCBjcmVkZW50aWFsIGFuZCB0aGUgQVNBIGF1dGhlbnRpY2F0aW9uIGRvIG5vdCBu ZWNlc3NhcmlseSByZWx5IG9uIElQIGFkZHJlc3Nlcy4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0K DQoNCj4gQmVzdCByZWdhcmRzLA0KPiANCj4gU2hlbmcNCj4gDQo+ID4gICBCcmlhbg0KPiA+DQo+ ID4+ICAgICBCcmlhbg0KPiA+Pj4NCj4gPj4+IHJlZ2FyZHMsDQo+ID4+PiBKb2huDQo+ID4+Pg0K PiA+Pj4gT24gVGh1LCBNYXkgMTQsIDIwMTUgYXQgODozNSBQTSwgQnJpYW4gRSBDYXJwZW50ZXIg PA0KPiA+Pj4gYnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gPj4+DQo+ID4+ Pj4gT24gMTUvMDUvMjAxNSAxNTozMCwgSsOpZmVyc29uIENhbXBvcyBOb2JyZSB3cm90ZToNCj4g Pj4+Pj4gSGkuDQo+ID4+Pj4+IEkgdGhpbmsgdGhhdCBhbGwgQVNBcyBtdXN0IHVzZSB0aGUgc2Ft ZSBsYXllciAzIGFkZHJlc3MuDQo+ID4+Pj4+IEFzIGEgZGVtdXggYXBwcm9hY2gsIGEgdmFsaWQg YW5hbG9neSBpcyB0aGUgcHJlc2VuY2Ugb2YgbXVsdGlwbGUNCj4gPj4+Pj4gU05NUCBhZ2VudHMg aW4gYSBub2RlLiBUaHVzLCBzb21ldGhpbmcgbGlrZSB0aGUNCj4gPj4+Pj4gY29udGV4dEVuZ2lu ZUlEL3NubXBFbmdpbmVJRCBjb3VsZCBiZSB1c2VkLg0KPiA+Pj4+DQo+ID4+Pj4gQWN0dWFsbHkg d2UgaGF2ZSBhIFNlc3Npb25JRCBpbiB0aGUgR0ROUCBkZXNpZ24uIEkgd2lsbCBoYXZlIHRvDQo+ ID4+Pj4gY2hlY2ssIGJ1dCBJIHRoaW5rIHRoYXQgb2NjdXJzIGluIGFsbCBjYXNlcyB3aGVyZSB3 ZSB3b3VsZCBuZWVkIHRvDQo+IGRlbXVsdGlwbGV4Lg0KPiA+Pj4+IEFzIGxvbmcgYXMgaXQgaXMg YWxsb2NhdGVkIHVuaXF1ZWx5IHBlci1ub2RlIChyYXRoZXIgdGhhbiBwZXItQVNBKSwNCj4gPj4+ PiB0aGF0IHdvdWxkIGJlIGVub3VnaC4NCj4gPj4+Pg0KPiA+Pj4+ICAgIEJyaWFuDQo+ID4+Pj4N Cj4gPj4+Pj4gQmVzdC4NCj4gPj4+Pj4NCj4gPj4+Pj4gSsOpZmVyc29uIENhbXBvcyBOb2JyZQ0K PiA+Pj4+PiBQaEQgU3R1ZGVudA0KPiA+Pj4+PiBDb21wdXRlciBOZXR3b3JrcyBHcm91cCAtICBJ bnN0aXR1dGUgb2YgSW5mb3JtYXRpY3MgRmVkZXJhbA0KPiA+Pj4+PiBVbml2ZXJzaXR5IG9mIFJp byBHcmFuZGUgZG8gU3VsIGh0dHA6Ly93d3cuaW5mLnVmcmdzLmJyL35qY25vYnJlDQo+ID4+Pj4+ DQo+ID4+Pj4+IE9uIFRodSwgTWF5IDE0LCAyMDE1IGF0IDExOjM0IFBNLCBTaGVuZyBKaWFuZw0K PiA+PGppYW5nc2hlbmdAaHVhd2VpLmNvbT4NCj4gPj4+PiB3cm90ZToNCj4gPj4+Pj4+IEluIG15 IG9waW5pb24sIGFkZHJlc3NpbmcgcGVyIEFTQSB3b3VsZCBiZSBpZGVhbC4gQnV0IGl0IGlzIHRv bw0KPiA+Pj4+Pj4gaWRlYWwNCj4gPj4+PiB0byBiZSB0YWtlbiBhcyBhIGNvbW1vbiBhc3N1bXB0 aW9uLiBUaGUgc2lnbmFsaW5nIHNob3VsZCBiZSBhYmxlIHRvDQo+ID5zdXBwb3J0DQo+ID4+Pj4g dGhlIHNjZW5hcmlvIHRoYXQgQVNBcyBzaGFyZSB0aGUgc2FtZSBsYXllciAzIGFkZHJlc3MuIE9u ZSBhZGRyZXNzDQo+ID4+Pj4gcGVyDQo+ID5BU0ENCj4gPj4+PiBjb3VsZCBiZSBjb25zaWRlcmVk IGFzIGEgc3Vic2V0IG9mIGl0LiBJIHBlcnNvbmFsbHkgYmVsaWV2ZSB0aGUNCj4gPj4+PiBjdXJy ZW50IGRlc2lnbiBoYXMgYWxyZWFkeSBzdXBwb3J0IHRoaXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g U2hlbmcNCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g Pj4+Pj4+PiBGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBCcmlhbg0KPiBFDQo+ID4+Pj4+Pj4gQ2FycGVudGVyDQo+ID4+Pj4+Pj4gU2VudDog RnJpZGF5LCBNYXkgMTUsIDIwMTUgOToxOSBBTQ0KPiA+Pj4+Pj4+IFRvOiBBbmltYSBXRw0KPiA+ Pj4+Pj4+IFN1YmplY3Q6IFtBbmltYV0gQWRkcmVzc2luZyBBU0FzIG9yIG5vZGVzPw0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4gV2hpbGUgZG9pbmcgc29tZSB0aGlua2luZyBpbiB0aGUgY29udGV4dCBv ZiB0aGUgc2lnbmFsaW5nIGRlc2lnbg0KPiA+Pj4+Pj4+IHRlYW0sIEkgY2FtZSB1cG9uIGFub3Ro ZXIgYWRkcmVzc2luZyBxdWVzdGlvbi4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEEgc2luZ2xlIHBo eXNpY2FsIG5vZGUgbWlnaHQgY29udGFpbiBzZXZlcmFsIGluZGVwZW5kZW50DQo+ID4+Pj4+Pj4g YXV0b25vbWljIHNlcnZpY2UgYWdlbnRzIChBU0FzKSBoYW5kbGluZyBkaWZmZXJlbnQgcmVzb3Vy Y2VzLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gV2lsbCB0aG9zZSBBU0FzIGFsbCB1c2UgdGhlIHNh bWUgbGF5ZXIgMyBhZGRyZXNzLCBvciB3aWxsIHRoZXkNCj4gPj4+Pj4+PiBoYXZlIGFuIGFkZHJl c3MgZWFjaD8NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoaXMgbWF0dGVycyBmb3IgdGhlIHNpZ25h bGluZyBkZXNpZ24sIGJlY2F1c2UgaWYgdGhleSBhbGwgaGF2ZQ0KPiA+Pj4+Pj4+IHRoZSBzYW1l IGFkZHJlc3MsIGl0IGlzbid0IGNsZWFyIGhvdyB0aGV5IGNvdWxkIHNoYXJlIGEgbGlzdGVuDQo+ ID4+Pj4+Pj4gcG9ydC4gQXQgdGhlIGxlYXN0LCBpdCBjcmVhdGVzIGEgY29tcGxpY2F0ZWQgZGVt dWx0aXBsZXhpbmcNCj4gPj4+Pj4+PiByZXF1aXJlbWVudC4gKFdlIGhhdmUgdGhhdCBhbnl3YXkg Zm9yIGluY29taW5nIGRpc2NvdmVyeQ0KPiA+Pj4+Pj4+IG1lc3NhZ2VzLCBidXQgdGhleSBhcmUg ZGlzdGluZ3Vpc2hlZCBieSBhbiAnb2JqZWN0aXZlJw0KPiA+Pj4+Pj4+IHBhcmFtZXRlci4pDQo+ ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBkcmFmdC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLWFkZHJl c3NpbmctMDAgZGVzY3JpYmVzIG9uZQ0KPiA+Pj4+Pj4+IGFkZHJlc3MgcGVyIG5vZGUsIGFzIGZh ciBhcyBJIGNhbiB0ZWxsLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgQnJpYW4NCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+Pj4+Pj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4gQW5pbWFAaWV0Zi5v cmcNCj4gPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1h DQo+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4+Pj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+ID4+Pj4+PiBBbmltYUBpZXRmLm9yZw0K PiA+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiA+ Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gPj4+PiBBbmltYUBpZXRm Lm9yZw0KPiA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEN Cj4gPj4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pg0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+ IEFuaW1hQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YW5pbWENCg== From nobody Mon May 18 05:54:39 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5181ACD2B for ; Mon, 18 May 2015 05:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 6IB57LDwmfab for ; Mon, 18 May 2015 05:54:34 -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 61E051ACD12 for ; Mon, 18 May 2015 05:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2024; q=dns/txt; s=iport; t=1431953674; x=1433163274; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gqn9J9kRruW51Je+T61kPCNvLCzK0aPIIAlBZXkePCE=; b=Kt+QoG/cgXAkPdNXyjNOpOWMy2VCTy/C46CiNaXkiGg+1xSXATXlYttJ bcDQHVIBjWUWHZPmNPkLgysBhryIXrJxKSdZhqnUWRxsT1xkiyhkbfC9W HfcusRZtFpNmZf1Z0CVI+oLR2fXRTR8JqpGrABO4Y4zxRx45xfPmp1von U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfBQBx4FlV/4oNJK1cgw+BMgaDGMBriD0CHIETPBABAQEBAQEBgQqEIgEBAQQjEUUMBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQBDQUIiCSzX6RBAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhihmEVDEHBoJiL4EWAQSSYYwZjgaHUCODd2+BRYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,453,1427760000"; d="scan'208";a="151005218" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 18 May 2015 12:54:33 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4ICsXhj032185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 May 2015 12:54:33 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 18 May 2015 07:54:33 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , John Strassner Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0ekFbLEiZNXEqa5tLuw2MAT518pbqAgAAPtoCAAAGFAIACjo2AgAAT9ACAAZdggIAAwrpw Date: Mon, 18 May 2015 12:54:33 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> In-Reply-To: <5558F525.4060000@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.139] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Anima WG , Sheng Jiang Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 18 May 2015 12:54:36 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1h LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFDQo+IENhcnBlbnRlcg0KPiBT ZW50OiAxNyBNYXkgMjAxNSAyMjowOA0KPiBUbzogSm9obiBTdHJhc3NuZXINCj4gQ2M6IErDqWZl cnNvbiBDYW1wb3MgTm9icmU7IEFuaW1hIFdHOyBTaGVuZyBKaWFuZw0KPiBTdWJqZWN0OiBSZTog W0FuaW1hXSBBZGRyZXNzaW5nIEFTQXMgb3Igbm9kZXM/DQo+IA0KWy4uLl0NCj4gV2hpbGUgd29y a2luZyBvbiB0aGUgbmV4dCB1cGRhdGUgb2YgdGhlIHNpZ25hbGluZyBwcm90b2NvbCwgSSByZWFj aGVkIGEgZmlybQ0KPiBjb25jbHVzaW9uIHRoYXQgYW4gQVNBIG5lZWRzIHRvIGluaGVyaXQgdGhl IHRydXN0IGNyZWRlbnRpYWxzIG9mIHRoZSBkZXZpY2UNCj4gdGhhdCBjb250YWlucyBpdC4gT3Ro ZXJ3aXNlIGVhY2ggQVNBIHdvdWxkIGhhdmUgdG8gZ28gdGhyb3VnaCB0aGUgdHJ1c3QNCj4gYm9v dHN0cmFwIHByb2Nlc3MgZm9yIGl0c2VsZiwgYW5kIHRoYXQgc2VlbXMgbGlrZSBhIHBlcnZlcnNl IHJlcXVpcmVtZW50Lg0KDQpXZSd2ZSBiZWVuIGNoZXdpbmcgb24gdGhpcyBmb3IgYSBsb25nIHRp bWUgYXMgd2VsbC4gWW91IG5lZWQgdG8gZGUtbXV4IHRoZSBBU0FzIHRoYXQgYXJlIGhvc3RlZCBv biBhbiBhdXRvbm9taWMgbm9kZS4gVGhlIHByb3RvY29scyBzaG91bGQgYmUgYWJsZSB0byBwcm92 aWRlIHRoYXQgZGVtdXggZnVuY3Rpb24sIGFuZCBJIHRoaW5rIHRoYXQncyBtb3JlIGVsZWdhbnQg dGhhbiBkZW11eGluZyB3aXRoIGlwIGFkZHJlc3Mgc3BhY2UuLi4gU28gSSB3b3VsZCBhbHNvIHN1 Z2dlc3Q6IE9uZSBJUCBhZGRyZXNzIGZvciBhbiBhdXRvbm9taWMgbm9kZSwgc29tZSBpbnN0YW5j ZSBJRCBmb3IgYW4gQVNBLiBIb3dldmVyLCB0aGlzIGluc3RhbmNlIElEIG5lZWRzIHRvIGJlIGNv bnNpc3RlbnQgYWNyb3NzIHRoZSBwcm90b2NvbHMgdGhlIEFTQXMgdXNlLiANCg0KUmVnYXJkaW5n IHRoZSBzZWN1cml0eSBsZXZlbCwgSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSBBTkkgc2V0cyBhbmQg YXV0b21hdGljYWxseSBlbmZvcmNlcyBhIGRlZmF1bHQgc2VjdXJpdHkgbGV2ZWwsIHdoaWNoIGhh cyBjZXJ0YWluIHByb3BlcnRpZXMuIElmIHRoZXJlIGFyZSBzcGVjaWZpYyBBU0FzIHRoYXQgcmVx dWlyZSBoaWdoZXItdGhhbi1ub3JtYWwgc2VjdXJpdHkgc3RhbmRhcmRzLCB0aGVuIHRoZXkgY291 bGQgc3RpbGwgdXNlIGZvciBleGFtcGxlIGFuIGFkZGl0aW9uYWwgc2VjdXJpdHkgbGF5ZXIsIHNw ZWNpZmljYWxseSBiZXR3ZWVuIEFTQXMgd2l0aCB0aG9zZSByZXF1aXJlbWVudHMuIENlcnRhaW5s eSBmb3IgY29tbWVyY2lhbCBwcm9kdWN0cyB3ZSBzaG91bGQgYmUgYWJsZSB0byBoYXZlIGEgImdv b2QgZW5vdWdoIiBzZWN1cml0eSBsZXZlbCBieSBkZWZhdWx0LiANCg0KTWljaGFlbA0KDQo= From nobody Mon May 18 13:38:45 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11F51A1A7F for ; Mon, 18 May 2015 13:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 2iMmyIrCplk8 for ; Mon, 18 May 2015 13:38:43 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CCD61A1A77 for ; Mon, 18 May 2015 13:38:43 -0700 (PDT) Received: by padbw4 with SMTP id bw4so166258276pad.0 for ; Mon, 18 May 2015 13:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=a1jZJY9wIr0E0QTeLoO7XXwxWmQ8jZkR0wQjciT1nLA=; b=zWOptdTNgj2ygDvZfFTphm4ahPRcZdN1kiaOFWDuPpviEvQjhZk2pyfk/BTfen0HCa zhCnZMOA8MhzJnCe8yJ1Di62EjkgkOcSg2bhyTP1yZgQ/h4CCBPFfEeHsOPq1gOE7g/n 5h9+8QJ04s3pKZoHuPDbxHtLCo2+lyN85gE3mzifTWguTZRz6zRFgPO0NA5y1qzenCfl QTqbGcf/HNo85KLXD03C8Z3sXxIVMtRaQB5uoJfMw5A7/IzLdIO2lhcu7xHL/mybXCGb 7EXEurjuu7HTN1uZKURoSlzunzc0UcdXTEqCYGQDu6IsNKKkHghvAINuwjgMfP1ijxr0 OSSA== X-Received: by 10.70.130.198 with SMTP id og6mr46922262pdb.153.1431981522906; Mon, 18 May 2015 13:38:42 -0700 (PDT) Received: from ?IPv6:2406:e007:7351:1:28cc:dc4c:9703:6781? ([2406:e007:7351:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id qa15sm10954211pab.12.2015.05.18.13.38.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2015 13:38:41 -0700 (PDT) Message-ID: <555A4DCF.8060100@gmail.com> Date: Tue, 19 May 2015 08:38:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , John Strassner References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?UTF-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Anima WG , Sheng Jiang Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 18 May 2015 20:38:45 -0000 Hi Michael, On 19/05/2015 00:54, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 17 May 2015 22:08 >> To: John Strassner >> Cc: J=C3=A9ferson Campos Nobre; Anima WG; Sheng Jiang >> Subject: Re: [Anima] Addressing ASAs or nodes? >> > [...] >> While working on the next update of the signaling protocol, I reached = a firm >> conclusion that an ASA needs to inherit the trust credentials of the d= evice >> that contains it. Otherwise each ASA would have to go through the trus= t >> bootstrap process for itself, and that seems like a perverse requireme= nt. >=20 > We've been chewing on this for a long time as well. You need to de-mux = the ASAs that are hosted on an autonomic node. The protocols should be ab= le to provide that demux function, and I think that's more elegant than d= emuxing with ip address space...=20 We can consider this in the signaling DT, but GDNP currently assumes you can demux on the Objective ID (to get the correct ASA) and then on a Sess= ion ID (to get the correct thread within the ASA). This doesn't exclude using separate IP addresses but I agree they should not be a requirement. > So I would also suggest: One IP address for an autonomic node, some ins= tance ID for an ASA. However, this instance ID needs to be consistent acr= oss the protocols the ASAs use.=20 Using the Objective ID should satisfy this. But if we need to add an ASA instance ID, that would be quite easy. > Regarding the security level, I would argue that the ANI sets and autom= atically enforces a default security level, which has certain properties.= If there are specific ASAs that require higher-than-normal security stan= dards, then they could still use for example an additional security layer= , specifically between ASAs with those requirements. Certainly for commer= cial products we should be able to have a "good enough" security level by= default.=20 Agreed. We might even have cases of lower-than-normal security, who knows= ? (Note however that SNMPv3 took a different approach by going for its own security solution.) Brian From nobody Mon May 18 15:02:56 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E310C1A9081 for ; Mon, 18 May 2015 15:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 RO0C84FcQwHe for ; Mon, 18 May 2015 15:02:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B914D1ACD83 for ; Mon, 18 May 2015 15:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5264; q=dns/txt; s=iport; t=1431986573; x=1433196173; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Tc68LqsL6Tttnxel07hfgdJxkESCh/o3YqN2MMs9L+E=; b=LnhSZ8FanBdzV119r9uDpQVt+inB4660v2HOW43ogw4DmnRWh4zwRxTE Jw672G/r2tgbKYOj0qVhFQ2OQUqsn7LaYL1w3djouUnQ06zj4h0HQdKLi RwgGY7zkvESYjaYjPaNLwOe4V+tZjcQuzCvZCB6s2Xqa0DL1z+TJtnUpm M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AvBQAKYVpV/4QNJK1cFoJ6VF4GxksKhXYCgThMAQEBAQEBgQuEIgEBAQMBAQEBawsMBAIBCBEEAQEBJwchBgsUCQgCBA4FiBcDCggN1BgNhQUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqCTYFfJjMHBoMRgRYFkmWJJYFVgSeIQoVOWwmGcSODeG8BgQJCgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,455,1427760000"; d="scan'208";a="417601442" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP; 18 May 2015 22:02:41 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4IM2Age011904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 May 2015 22:02:41 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 18 May 2015 17:02:15 -0500 From: "Max Pritikin (pritikin)" To: Sheng Jiang Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0edFJekHxjIUyjzKUAM7XUGp18pbqAgAAPtoCAAAGFAIACjo2AgAAT9ACAAZdggIAAVlkAgAFb5IA= Date: Mon, 18 May 2015 22:02:15 +0000 Message-ID: <006C00B8-6483-4434-9683-7292B0446EDB@cisco.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F5286DD@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F5286DD@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.69.244] Content-Type: text/plain; charset="Windows-1252" Content-ID: <81069A13A9D7E34CB0E8914569DD3A94@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: =?Windows-1252?Q?J=E9ferson_Campos_Nobre?= , Anima WG , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 18 May 2015 22:02:56 -0000 On May 17, 2015, at 7:17 PM, Sheng Jiang wrote: >>> Certainly we shouldn't have any arbitrary restrictions. It does interac= t >>> with the authentication mechanisms, though. Does an ASA inherit its tru= st >>> from the device, and how does that work if there are several ASAs with >>> different addresses in the same device? >>=20 >> While working on the next update of the signaling protocol, I reached a = firm >> conclusion that an ASA needs to inherit the trust credentials of the dev= ice >> that contains it. Otherwise each ASA would have to go through the trust >> bootstrap process for itself, and that seems like a perverse requirement= . >=20 > I agree that the above inheriting of the trust credential from the device= to ASA should be default behavior. Furthermore, I still believe only one s= ecurity level is NOT enough. Some specific ASAs may have higher requirement= s for itself. They should be allowed to have their own authentication on th= e top of the default trust credential. Secure bootstrapping requires an initial credential but I=92d be open to th= e idea that the existing credential could be either the initial device cred= ential or a locally issued device credential. Enrollment protocols should s= upport =93higher requirements=94 such as two factor authentication. Also it= makes sense for the existing credential to be used to obtain a limited use= (one time?) token that can be used for an enrollment. This provides method= s for virtualized ASA=92s to =93inherit=94 the existing credential w/o expe= cting to provide the necessary interfaces to use the device credential in r= eal time during the enrollment.=20 - max >=20 > Best regards, >=20 > Sheng >=20 >> Brian >>=20 >>> Brian >>>>=20 >>>> regards, >>>> John >>>>=20 >>>> On Thu, May 14, 2015 at 8:35 PM, Brian E Carpenter < >>>> brian.e.carpenter@gmail.com> wrote: >>>>=20 >>>>> On 15/05/2015 15:30, J=E9ferson Campos Nobre wrote: >>>>>> Hi. >>>>>> I think that all ASAs must use the same layer 3 address. >>>>>> As a demux approach, a valid analogy is the presence of multiple SNM= P >>>>>> agents in a node. Thus, something like the >>>>>> contextEngineID/snmpEngineID could be used. >>>>>=20 >>>>> Actually we have a SessionID in the GDNP design. I will have to check= , >>>>> but I think that occurs in all cases where we would need to demultipl= ex. >>>>> As long as it is allocated uniquely per-node (rather than per-ASA), t= hat >>>>> would be enough. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> Best. >>>>>>=20 >>>>>> J=E9ferson Campos Nobre >>>>>> PhD Student >>>>>> Computer Networks Group - Institute of Informatics >>>>>> Federal University of Rio Grande do Sul >>>>>> http://www.inf.ufrgs.br/~jcnobre >>>>>>=20 >>>>>> On Thu, May 14, 2015 at 11:34 PM, Sheng Jiang >> >>>>> wrote: >>>>>>> In my opinion, addressing per ASA would be ideal. But it is too ide= al >>>>> to be taken as a common assumption. The signaling should be able to >> support >>>>> the scenario that ASAs share the same layer 3 address. One address pe= r >> ASA >>>>> could be considered as a subset of it. I personally believe the curre= nt >>>>> design has already support this. >>>>>>>=20 >>>>>>> Sheng >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>>>>>> Carpenter >>>>>>>> Sent: Friday, May 15, 2015 9:19 AM >>>>>>>> To: Anima WG >>>>>>>> Subject: [Anima] Addressing ASAs or nodes? >>>>>>>>=20 >>>>>>>> While doing some thinking in the context of the signaling >>>>>>>> design team, I came upon another addressing question. >>>>>>>>=20 >>>>>>>> A single physical node might contain several independent >>>>>>>> autonomic service agents (ASAs) handling different resources. >>>>>>>>=20 >>>>>>>> Will those ASAs all use the same layer 3 address, or will >>>>>>>> they have an address each? >>>>>>>>=20 >>>>>>>> This matters for the signaling design, because if they all >>>>>>>> have the same address, it isn't clear how they could share >>>>>>>> a listen port. At the least, it creates a complicated >>>>>>>> demultiplexing requirement. (We have that anyway for >>>>>>>> incoming discovery messages, but they are distinguished by >>>>>>>> an 'objective' parameter.) >>>>>>>>=20 >>>>>>>> draft-behringer-anima-autonomic-addressing-00 describes one >>>>>>>> address per node, as far as I can tell. >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon May 18 23:55:05 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B9C1A879D for ; Mon, 18 May 2015 23:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 M-UQYkAPTyu4 for ; Mon, 18 May 2015 23:55:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86791A879A for ; Mon, 18 May 2015 23:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=624; q=dns/txt; s=iport; t=1432018502; x=1433228102; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZLfOMFD+EuA8WU2OBncsccnkTP8wt7xp2A96KVf7RQ0=; b=CKSZ+gDgsxg52tN1zmGIRDVx5n7aBc/kE+vArZ5/Zpxc2RT2Oojzw8EM VuLu8EpNyrIe0cWDWgRclHwwO/YCl0dzIMp3GuTead0OtCnhu86Z4PIz/ kFLM9nAZai0EkIzS7Ry9LFM7Lb0YgrTHQH+uqnaCtrkV4II1IC2LIjn4v I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BkBADg3VpV/5BdJa1cgxCBOIMYwHxmCYdPAhyBFjgUAQEBAQEBAYEKhCMBAQQjEUUQAgEIGgIGIAICAjAVEAIEAQ0NE4gRtESkOgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYoZhFQxB4JoL4EWAQSSbKIMI4N4gjSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,456,1427760000"; d="scan'208";a="31891" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP; 19 May 2015 06:55:02 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t4J6t1XR029213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 May 2015 06:55:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 19 May 2015 01:55:01 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , John Strassner Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0ekFbLEiZNXEqa5tLuw2MAT518pbqAgAAPtoCAAAGFAIACjo2AgAAT9ACAAZdggIAAwrpwgADYJYCAAFc9QA== Date: Tue, 19 May 2015 06:55:01 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> In-Reply-To: <555A4DCF.8060100@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.139] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Anima WG , Sheng Jiang Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 May 2015 06:55:04 -0000 PiAoTm90ZSBob3dldmVyIHRoYXQgU05NUHYzIHRvb2sgYSBkaWZmZXJlbnQgYXBwcm9hY2ggYnkg Z29pbmcgZm9yIGl0cyBvd24NCj4gc2VjdXJpdHkgc29sdXRpb24uKQ0KDQpJZiB3ZSBkbyBvdXIg am9iIGluIHRoZSBBTkkgc28gbmljZWx5IHdpdGggc2VjdXJpdHksIHBlb3BsZSB3b24ndCBzZWUg YSBuZWVkIGZvciBwcm90b2NvbCBzcGVjaWZpYyBzZWN1cml0eSwgc3VjaCBhcyBTTk1QdjMuIEhv d2V2ZXIsIHRoaXMgd2lsbCBvbmx5IGhhcHBlbiBpZiB0aGUgQU5JIGd1YXJhbnRlZXMgc2VjdXJp dHkuIFRoaXMgaXMgd2h5IEknbSBoZXNpdGFudCBhYm91dCAiZG93bmdyYWRpbmciIHNlY3VyaXR5 LiANCg0KTG90cyBvZiBleGNlcHRpb25zIHRvIHRha2UgY2FyZSBvZiBmb3Igbm93IHRob3VnaCwg Zm9yIGV4YW1wbGUsIG1peGVkIEFOL25vbi1BTiBlbnZpcm9ubWVudHMuIA0KDQpNaWNoYWVsDQo= From nobody Tue May 19 13:01:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47AD1B2A54 for ; Tue, 19 May 2015 13:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 9IGwqYuNytFu for ; Tue, 19 May 2015 13:01:29 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 33D7F1A1A4E for ; Tue, 19 May 2015 13:01:29 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so37918393pac.2 for ; Tue, 19 May 2015 13:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yh24RLCYEyfIDxrk5splis3OK4bSpkJZM2pQKHI4kf0=; b=CbcbX8d/Y8NSNAcG33xMr+HdHEnm0103KTKW0H60sn4h6mM6QqLC4SH6FuoHjq3Sqp XtQX5ygPRRQZRuaOxLPTpQxq+XMXOXUB+x7vGSrXMBrSSHMnCI5JoM7z2+20m7UkAKVF oLyPIqZHk95kGNrYLnxFqMGi+Uc1YBNgQ9gVoOmRobxQctwhwVCU5p496y9owSLrZipr ecqBg+M5lNyAl05ClL5MKJxl++hJC6ZVNIeAG4Tik1sJHWv3n8/RPer8LLmckMy7lb3D 6R/M4LGB5M5/aiB2Ee8ulCWY1KL/iu8w8cFTbS/BfO9Zm35DIeM1+HQpfsphOtfqf6YF 60kA== X-Received: by 10.68.169.34 with SMTP id ab2mr56503487pbc.120.1432065688805; Tue, 19 May 2015 13:01:28 -0700 (PDT) Received: from ?IPv6:2406:e007:4858:1:28cc:dc4c:9703:6781? ([2406:e007:4858:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id lc14sm13954433pab.33.2015.05.19.13.01.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 13:01:27 -0700 (PDT) Message-ID: <555B9696.7070002@gmail.com> Date: Wed, 20 May 2015 08:01:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , John Strassner References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: =?UTF-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Anima WG , Sheng Jiang Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 May 2015 20:01:30 -0000 Hi Michael, On 19/05/2015 18:55, Michael Behringer (mbehring) wrote: >> (Note however that SNMPv3 took a different approach by going for its own >> security solution.) > > If we do our job in the ANI so nicely with security, people won't see a need for protocol specific security, such as SNMPv3. However, this will only happen if the ANI guarantees security. This is why I'm hesitant about "downgrading" security. Indeed. It would have to be very careful. One possible case would be if two operators wanted to allow AN across their mutual boundary, for a certain purpose only. > Lots of exceptions to take care of for now though, for example, mixed AN/non-AN environments. Indeed. That can create weak points. For now perhaps these issues belong in the security section of the reference model? Brian From nobody Tue May 19 13:37:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8E11B320B for ; Tue, 19 May 2015 13:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 Zzz1z_wWNvhZ for ; Tue, 19 May 2015 13:37:36 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010: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 D8B441B322D for ; Tue, 19 May 2015 13:37:35 -0700 (PDT) Received: by lagr1 with SMTP id r1so42878826lag.0 for ; Tue, 19 May 2015 13:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=uc/T1IMA/oATNDjB2FL9QgB3RhzOBO9KqR4T7LYpPuc=; b=l5U6vlUSgkaW4sQmcjmRBVwgZR7BX5kPkG0ZiHXDhUHEWhyilDGL6QTmHxFxgI+bwl PU8gpQtw5GTH/QHvTTsH3U/cfLtZVebzSnv/v4J/GxG/SjyzmpDpzqf2skMGp5oCC5+0 NzJ4gwo9PjQIwELlDOsYv+BB1FkkyCLjw9AmpQaEMMez5O7uGn2NYFPH1ewyq1QQoqhG vyo5uUphF9rYpUU1JXcgbFD5soDfA/u6mM4PZsavKGuGzOjianxwqg9Au+YwrWnIx3R+ XoLfB1SYJgT85ml8eWMIEE7HVMUzkV2CjD3FvxEJVmggFXRVw2vX1UDGfaWT8sDkrO3F 4Uzg== MIME-Version: 1.0 X-Received: by 10.112.72.104 with SMTP id c8mr23807434lbv.77.1432067854326; Tue, 19 May 2015 13:37:34 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.252.198 with HTTP; Tue, 19 May 2015 13:37:34 -0700 (PDT) In-Reply-To: <006C00B8-6483-4434-9683-7292B0446EDB@cisco.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F5286DD@nkgeml512-mbx.china.huawei.com> <006C00B8-6483-4434-9683-7292B0446EDB@cisco.com> Date: Tue, 19 May 2015 17:37:34 -0300 X-Google-Sender-Auth: nDSKl7yjop8EPCQ3Qh3oitg1kNk Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: "Max Pritikin (pritikin)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: John Strassner , Anima WG , Sheng Jiang Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 May 2015 20:37:38 -0000 Hi Max. On Mon, May 18, 2015 at 7:02 PM, Max Pritikin (pritikin) wrote: > > On May 17, 2015, at 7:17 PM, Sheng Jiang wrote: > >>>> Certainly we shouldn't have any arbitrary restrictions. It does intera= ct >>>> with the authentication mechanisms, though. Does an ASA inherit its tr= ust >>>> from the device, and how does that work if there are several ASAs with >>>> different addresses in the same device? >>> >>> While working on the next update of the signaling protocol, I reached a= firm >>> conclusion that an ASA needs to inherit the trust credentials of the de= vice >>> that contains it. Otherwise each ASA would have to go through the trust >>> bootstrap process for itself, and that seems like a perverse requiremen= t. >> >> I agree that the above inheriting of the trust credential from the devic= e to ASA should be default behavior. Furthermore, I still believe only one = security level is NOT enough. Some specific ASAs may have higher requiremen= ts for itself. They should be allowed to have their own authentication on t= he top of the default trust credential. > > Secure bootstrapping requires an initial credential but I=E2=80=99d be op= en to the idea that the existing credential could be either the initial dev= ice credential or a locally issued device credential. Enrollment protocols = should support =E2=80=9Chigher requirements=E2=80=9D such as two factor aut= hentication. Also it makes sense for the existing credential to be used to = obtain a limited use (one time?) token that can be used for an enrollment. = This provides methods for virtualized ASA=E2=80=99s to =E2=80=9Cinherit=E2= =80=9D the existing credential w/o expecting to provide the necessary inter= faces to use the device credential in real time during the enrollment. Just to add up: I think the use of temporary ID should be also used to avoid eavesdropping. > - max > > >> >> Best regards, >> >> Sheng >> >>> Brian >>> >>>> Brian >>>>> >>>>> regards, >>>>> John >>>>> >>>>> On Thu, May 14, 2015 at 8:35 PM, Brian E Carpenter < >>>>> brian.e.carpenter@gmail.com> wrote: >>>>> >>>>>> On 15/05/2015 15:30, J=C3=A9ferson Campos Nobre wrote: >>>>>>> Hi. >>>>>>> I think that all ASAs must use the same layer 3 address. >>>>>>> As a demux approach, a valid analogy is the presence of multiple SN= MP >>>>>>> agents in a node. Thus, something like the >>>>>>> contextEngineID/snmpEngineID could be used. >>>>>> >>>>>> Actually we have a SessionID in the GDNP design. I will have to chec= k, >>>>>> but I think that occurs in all cases where we would need to demultip= lex. >>>>>> As long as it is allocated uniquely per-node (rather than per-ASA), = that >>>>>> would be enough. >>>>>> >>>>>> Brian >>>>>> >>>>>>> Best. >>>>>>> >>>>>>> J=C3=A9ferson Campos Nobre >>>>>>> PhD Student >>>>>>> Computer Networks Group - Institute of Informatics >>>>>>> Federal University of Rio Grande do Sul >>>>>>> http://www.inf.ufrgs.br/~jcnobre >>>>>>> >>>>>>> On Thu, May 14, 2015 at 11:34 PM, Sheng Jiang >>> >>>>>> wrote: >>>>>>>> In my opinion, addressing per ASA would be ideal. But it is too id= eal >>>>>> to be taken as a common assumption. The signaling should be able to >>> support >>>>>> the scenario that ASAs share the same layer 3 address. One address p= er >>> ASA >>>>>> could be considered as a subset of it. I personally believe the curr= ent >>>>>> design has already support this. >>>>>>>> >>>>>>>> Sheng >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>>>>>>> Carpenter >>>>>>>>> Sent: Friday, May 15, 2015 9:19 AM >>>>>>>>> To: Anima WG >>>>>>>>> Subject: [Anima] Addressing ASAs or nodes? >>>>>>>>> >>>>>>>>> While doing some thinking in the context of the signaling >>>>>>>>> design team, I came upon another addressing question. >>>>>>>>> >>>>>>>>> A single physical node might contain several independent >>>>>>>>> autonomic service agents (ASAs) handling different resources. >>>>>>>>> >>>>>>>>> Will those ASAs all use the same layer 3 address, or will >>>>>>>>> they have an address each? >>>>>>>>> >>>>>>>>> This matters for the signaling design, because if they all >>>>>>>>> have the same address, it isn't clear how they could share >>>>>>>>> a listen port. At the least, it creates a complicated >>>>>>>>> demultiplexing requirement. (We have that anyway for >>>>>>>>> incoming discovery messages, but they are distinguished by >>>>>>>>> an 'objective' parameter.) >>>>>>>>> >>>>>>>>> draft-behringer-anima-autonomic-addressing-00 describes one >>>>>>>>> address per node, as far as I can tell. >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue May 19 13:38:17 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED27E1B3248 for ; Tue, 19 May 2015 13:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 07R4SRLGKzsz for ; Tue, 19 May 2015 13:38:12 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::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 C4B131B3232 for ; Tue, 19 May 2015 13:38:10 -0700 (PDT) Received: by labbd9 with SMTP id bd9so43637633lab.2 for ; Tue, 19 May 2015 13:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fTOkz0rPobHYn7QpUlw0aTbMB2upvyzgHWgCepqtNV4=; b=Ps9WazqWE352MC6H1WGSqckdTsaxTnE5js7Y6WCuARGxKU7Rn9GWyPyrrTn3YOcAcC pofvma+RNqCagDlwCEjVUicJWZOOjsHb+51SPPpF/ab9OJp4uQGB6sT555/pRXhe2YAE h+G8h6pvsdHFfF9sdqu98EBQd+9zP8DsnjP8Njg4pB7sG3eV2WxZruBGhAcbjVo0alZz Hkq8G6c118oNs3Rm/KYVjGlXhsbL9mOtB4UNOAaY9QyZN2Di+yD1W4imcD0YMwurtP8U uVHUB1nOBKjmgSeUqwZgwmnjZ0UJAmXKHsQuu+j0/Xk0qXQ5R3EX0NwZVjU6ZnSGJUFY xyDw== MIME-Version: 1.0 X-Received: by 10.152.3.161 with SMTP id d1mr23101658lad.70.1432067889264; Tue, 19 May 2015 13:38:09 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.252.198 with HTTP; Tue, 19 May 2015 13:38:09 -0700 (PDT) In-Reply-To: <555B9696.7070002@gmail.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> Date: Tue, 19 May 2015 17:38:09 -0300 X-Google-Sender-Auth: m0HDBuBEeeaOU1BKI58X6T-YJFU Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= , Sheng Jiang , Anima WG , "Michael Behringer \(mbehring\)" , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 May 2015 20:38:16 -0000 Hi Brian. On Tue, May 19, 2015 at 5:01 PM, Brian E Carpenter wrote: > Hi Michael, > > On 19/05/2015 18:55, Michael Behringer (mbehring) wrote: >>> (Note however that SNMPv3 took a different approach by going for its own >>> security solution.) >> >> If we do our job in the ANI so nicely with security, people won't see a need for protocol specific security, such as SNMPv3. However, this will only happen if the ANI guarantees security. This is why I'm hesitant about "downgrading" security. > > Indeed. It would have to be very careful. One possible case would be if > two operators wanted to allow AN across their mutual boundary, for a certain > purpose only. I think this is the right approach: what are the cases for "downgrading security"? I am also hesitant about this. >> Lots of exceptions to take care of for now though, for example, mixed AN/non-AN environments. > > Indeed. That can create weak points. > > For now perhaps these issues belong in the security section of the reference model? +1 > Brian From nobody Tue May 19 17:41:53 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51701ACDFD for ; Tue, 19 May 2015 17:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 eh7T41Q0Dovh for ; Tue, 19 May 2015 17:41:52 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8AD1ACDF7 for ; Tue, 19 May 2015 17:41:51 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so46806553pdb.0 for ; Tue, 19 May 2015 17:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0xX61U9KV9wggNH2/zC3BSOJbDqzkR0Asx40sW2BvyA=; b=uwktoTWEeldUFwBME85mJhy0dp4KG1wQQtv637JOtT+KYSycpV5s3Knk3406La4Qan f5bgLtWgojhE1gnAErJkbpeZtf10IOq717DMG26CwNsucxGFHNw0cygyBdyv650qF3eA JWKmpuVX1QqGqzK+5C9l5vgiWSa3KxQl5tusWwpJXy6HwcWLpth6WPobk+7Yz5D+goDs y+jx7BfQfnbN2/XgbVAQBpkfTdnYILV9ZqpMz8OteYGIexx7IG32YLqXWYivEEYYv4q5 nbC/mscLpTDoOQ0ie5CXPqydDog35p+nPiADGot+l08kUgarl4MmEhToVytsNs5Tkb7t tVzw== X-Received: by 10.68.180.131 with SMTP id do3mr58698448pbc.42.1432082511654; Tue, 19 May 2015 17:41:51 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id gs7sm14191351pbc.6.2015.05.19.17.41.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 17:41:50 -0700 (PDT) Message-ID: <555BD84C.2090406@gmail.com> Date: Wed, 20 May 2015 12:41:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?UTF-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Sheng Jiang , Anima WG , "Michael Behringer \(mbehring\)" , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 20 May 2015 00:41:53 -0000 Hi, On 20/05/2015 08:38, J=C3=A9ferson Campos Nobre wrote: > Hi Brian. >=20 > On Tue, May 19, 2015 at 5:01 PM, Brian E Carpenter > wrote: >> Hi Michael, >> >> On 19/05/2015 18:55, Michael Behringer (mbehring) wrote: >>>> (Note however that SNMPv3 took a different approach by going for its= own >>>> security solution.) >>> >>> If we do our job in the ANI so nicely with security, people won't see= a need for protocol specific security, such as SNMPv3. However, this wil= l only happen if the ANI guarantees security. This is why I'm hesitant ab= out "downgrading" security. >> >> Indeed. It would have to be very careful. One possible case would be i= f >> two operators wanted to allow AN across their mutual boundary, for a c= ertain >> purpose only. >=20 > I think this is the right approach: what are the cases for > "downgrading security"? I am also hesitant about this. In my example, ASA1 in ISP1 needs a 1:1 trust relationship with ASA2 in ISP2, and that is quite distinct from the mutual trust between all ASAs inside a single ISP. Brian >=20 >>> Lots of exceptions to take care of for now though, for example, mixed= AN/non-AN environments. >> >> Indeed. That can create weak points. >> >> For now perhaps these issues belong in the security section of the ref= erence model? >=20 > +1 >=20 >> Brian >=20 From nobody Tue May 19 18:52:36 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED271B2B1F for ; Tue, 19 May 2015 18:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UfFuD5-7DmVa for ; Tue, 19 May 2015 18:52:32 -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 D096A1B2B20 for ; Tue, 19 May 2015 18:52:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWH04146; Wed, 20 May 2015 01:52:30 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 May 2015 02:52:29 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 20 May 2015 09:52:23 +0800 From: Sheng Jiang To: Brian E Carpenter , =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0ds6q5IfZSBEaKKYcYjkykR518TuDg//+MooCAAAGGAIACjoyAgAAT9ACAAZdggIABGTSAgACBq4CAAKw2gIAA27kAgAAKQoCAAEQTAIAAjswg Date: Wed, 20 May 2015 01:52:23 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F53A9EA@nkgeml512-mbx.china.huawei.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> In-Reply-To: <555BD84C.2090406@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 Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 20 May 2015 01:52:33 -0000 Pj4+Pj4gKE5vdGUgaG93ZXZlciB0aGF0IFNOTVB2MyB0b29rIGEgZGlmZmVyZW50IGFwcHJvYWNo IGJ5IGdvaW5nIGZvciBpdHMNCj5vd24NCj4+Pj4+IHNlY3VyaXR5IHNvbHV0aW9uLikNCj4+Pj4N Cj4+Pj4gSWYgd2UgZG8gb3VyIGpvYiBpbiB0aGUgQU5JIHNvIG5pY2VseSB3aXRoIHNlY3VyaXR5 LCBwZW9wbGUgd29uJ3Qgc2VlIGENCj5uZWVkIGZvciBwcm90b2NvbCBzcGVjaWZpYyBzZWN1cml0 eSwgc3VjaCBhcyBTTk1QdjMuIEhvd2V2ZXIsIHRoaXMgd2lsbCBvbmx5DQo+aGFwcGVuIGlmIHRo ZSBBTkkgZ3VhcmFudGVlcyBzZWN1cml0eS4gVGhpcyBpcyB3aHkgSSdtIGhlc2l0YW50IGFib3V0 DQo+ImRvd25ncmFkaW5nIiBzZWN1cml0eS4NCj4+Pg0KPj4+IEluZGVlZC4gSXQgd291bGQgaGF2 ZSB0byBiZSB2ZXJ5IGNhcmVmdWwuIE9uZSBwb3NzaWJsZSBjYXNlIHdvdWxkIGJlIGlmDQo+Pj4g dHdvIG9wZXJhdG9ycyB3YW50ZWQgdG8gYWxsb3cgQU4gYWNyb3NzIHRoZWlyIG11dHVhbCBib3Vu ZGFyeSwgZm9yIGENCj5jZXJ0YWluDQo+Pj4gcHVycG9zZSBvbmx5Lg0KPj4NCj4+IEkgdGhpbmsg dGhpcyBpcyB0aGUgcmlnaHQgYXBwcm9hY2g6IHdoYXQgYXJlIHRoZSBjYXNlcyBmb3INCj4+ICJk b3duZ3JhZGluZyBzZWN1cml0eSI/ICBJIGFtIGFsc28gaGVzaXRhbnQgYWJvdXQgdGhpcy4NCj4N Cj5JbiBteSBleGFtcGxlLCBBU0ExIGluIElTUDEgbmVlZHMgYSAxOjEgdHJ1c3QgcmVsYXRpb25z aGlwIHdpdGgNCj5BU0EyIGluIElTUDIsIGFuZCB0aGF0IGlzIHF1aXRlIGRpc3RpbmN0IGZyb20g dGhlIG11dHVhbCB0cnVzdA0KPmJldHdlZW4gYWxsIEFTQXMgaW5zaWRlIGEgc2luZ2xlIElTUC4N Cg0KSSBkb24ndCB0aGluayB3ZSBwcm9wZXJseSBleHBsb3JlIHRoZSBhcmVhIHJlZ2FyZGluZyB0 byBkb21haW4gYXQgYWxsLiBVcCB0byBub3csIHdlIGhhdmUgYW4gYXNzdW1wdGlvbiB0aGF0IHdo ZW4gd2UgdGFsayBhYm91dCBhdXRvbm9taWMgbm9kZSwgaXQgYmVsb25ncyB0byBvbmUgYW5kIG9u bHkgb25lIGRlZmF1bHQgYXV0b25vbWljIG5ldHdvcmsgZG9tYWluLiBUaGlzIHdvdWxkIGJlIGEg cmVhc29uYWJsZSBzdGFydCBwb2ludCBzaW5jZSB3ZSBjb3VsZCBzb2x2ZSBhbGwgY29tcGxleCBp c3N1ZXMgZnJvbSB0aGUgdmVyeSBiZWdpbm5pbmcuIEhvd2V2ZXIsIHJpZ2lkIHNpbmdsZSBkb21h aW4gaXMgY2VydGFpbmx5IG5vdCBlbm91Z2ggdG8gaGFuZGxlIHRoZXNlIGNvbXBsaWNhdGVkIHJl YWwgcmVxdWlyZW1lbnRzLiBTbywgbXVsdGlwbGUgZG9tYWluIGFuZCBkb21haW4tcmVsZXZhbnQg b3BlcmF0aW9uIGlzIHJlYWxseSB3b3J0aCBvZiBkZWVwIGV4cGxvcmluZy4NCg0KUmVnYXJkcywN Cg0KU2hlbmcNCg0KPiAgICBCcmlhbg0KPg0KPj4NCj4+Pj4gTG90cyBvZiBleGNlcHRpb25zIHRv IHRha2UgY2FyZSBvZiBmb3Igbm93IHRob3VnaCwgZm9yIGV4YW1wbGUsIG1peGVkDQo+QU4vbm9u LUFOIGVudmlyb25tZW50cy4NCj4+Pg0KPj4+IEluZGVlZC4gVGhhdCBjYW4gY3JlYXRlIHdlYWsg cG9pbnRzLg0KPj4+DQo+Pj4gRm9yIG5vdyBwZXJoYXBzIHRoZXNlIGlzc3VlcyBiZWxvbmcgaW4g dGhlIHNlY3VyaXR5IHNlY3Rpb24gb2YgdGhlDQo+cmVmZXJlbmNlIG1vZGVsPw0KPj4NCj4+ICsx DQo+Pg0KPj4+ICAgICBCcmlhbg0KPj4NCg0K From nobody Tue May 19 19:20:50 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A481B2B9C for ; Tue, 19 May 2015 19:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 lNpW_hhijs8K for ; Tue, 19 May 2015 19:20:48 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::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 5CBE11B2B96 for ; Tue, 19 May 2015 19:20:48 -0700 (PDT) Received: by pdea3 with SMTP id a3so49641088pde.2 for ; Tue, 19 May 2015 19:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=r1yxiHzZPp9AKqotfIseA/dofd0mh2n4bLfKM4FTi94=; b=P/uObYqY74anx144DcSstBOjIDpncuZvQ0LXfLRRDhn1Aqze298gKViltWxzsnf5Oa KD5MTYQZVmklFshfx+aR7Yf8jFOuSXS3dG1ADTm+ct8uztX5pVpQKvJtY2rUTLd5n/cg Q2sM3OdvVFqm51VKH08/cNPnmW20n+WTv0DxewsMsnCcD8APkiR1lPa4CkDhOcjAGPh7 jgHGgXIjkmnPP90Ag0EBbnncKPJR/q4WucLh+vVE6rjQbLu34OLKQxlJ5dLuPzmio0H4 M2T8vaRq4XF/gVBQ60YyBheHtbFLJ/YWdkD0zilwUsfFiTny8DnpdlsETwRzdvAPjt5U cFdQ== X-Received: by 10.66.194.201 with SMTP id hy9mr60218264pac.140.1432088447881; Tue, 19 May 2015 19:20:47 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id pn6sm14335075pdb.72.2015.05.19.19.20.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 19:20:46 -0700 (PDT) Message-ID: <555BEF7D.7060700@gmail.com> Date: Wed, 20 May 2015 14:20:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sheng Jiang , =?UTF-8?B?SsOpZmVyc29uIENhbXBvcyA=?= =?UTF-8?B?Tm9icmU=?= References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F53A9EA@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F53A9EA@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 20 May 2015 02:20:49 -0000 Hi Sheng, On 20/05/2015 13:52, Sheng Jiang wrote: >>>>>> (Note however that SNMPv3 took a different approach by going for its >> own >>>>>> security solution.) >>>>> >>>>> If we do our job in the ANI so nicely with security, people won't see a >> need for protocol specific security, such as SNMPv3. However, this will only >> happen if the ANI guarantees security. This is why I'm hesitant about >> "downgrading" security. >>>> >>>> Indeed. It would have to be very careful. One possible case would be if >>>> two operators wanted to allow AN across their mutual boundary, for a >> certain >>>> purpose only. >>> >>> I think this is the right approach: what are the cases for >>> "downgrading security"? I am also hesitant about this. >> >> In my example, ASA1 in ISP1 needs a 1:1 trust relationship with >> ASA2 in ISP2, and that is quite distinct from the mutual trust >> between all ASAs inside a single ISP. > > I don't think we properly explore the area regarding to domain at all. Up to now, we have an assumption that when we talk about autonomic node, it belongs to one and only one default autonomic network domain. This would be a reasonable start point since we could solve all complex issues from the very beginning. However, rigid single domain is certainly not enough to handle these complicated real requirements. So, multiple domain and domain-relevant operation is really worth of deep exploring. Agreed. I suppose it is out of WG charter scope at the moment, but we need to be sure that we do not block these possibilities in the initial design. Brian > Sheng > >> Brian >> >>> >>>>> Lots of exceptions to take care of for now though, for example, mixed >> AN/non-AN environments. >>>> >>>> Indeed. That can create weak points. >>>> >>>> For now perhaps these issues belong in the security section of the >> reference model? >>> >>> +1 >>> >>>> Brian >>> > From nobody Tue May 19 20:28:10 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AAD1B2D33 for ; Tue, 19 May 2015 20:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E7Jz02NeMpLH for ; Tue, 19 May 2015 20:28:07 -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 85EA01B2D20 for ; Tue, 19 May 2015 20:28:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWH10653; Wed, 20 May 2015 03:28:05 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 May 2015 04:28:03 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 20 May 2015 11:28:00 +0800 From: Sheng Jiang To: Brian E Carpenter , =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0ds6q5IfZSBEaKKYcYjkykR518TuDg//+MooCAAAGGAIACjoyAgAAT9ACAAZdggIABGTSAgACBq4CAAKw2gIAA27kAgAAKQoCAAEQTAIAAjswg//+M2oCAAI9OsA== Date: Wed, 20 May 2015 03:27:59 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F53AB84@nkgeml512-mbx.china.huawei.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F53A9EA@nkgeml512-mbx.china.huawei.com> <555BEF7D.7060700@gmail.com> In-Reply-To: <555BEF7D.7060700@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 Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 20 May 2015 03:28:08 -0000 Pj4+Pj4+PiAoTm90ZSBob3dldmVyIHRoYXQgU05NUHYzIHRvb2sgYSBkaWZmZXJlbnQgYXBwcm9h Y2ggYnkgZ29pbmcgZm9yDQo+aXRzDQo+Pj4gb3duDQo+Pj4+Pj4+IHNlY3VyaXR5IHNvbHV0aW9u LikNCj4+Pj4+Pg0KPj4+Pj4+IElmIHdlIGRvIG91ciBqb2IgaW4gdGhlIEFOSSBzbyBuaWNlbHkg d2l0aCBzZWN1cml0eSwgcGVvcGxlIHdvbid0IHNlZSBhDQo+Pj4gbmVlZCBmb3IgcHJvdG9jb2wg c3BlY2lmaWMgc2VjdXJpdHksIHN1Y2ggYXMgU05NUHYzLiBIb3dldmVyLCB0aGlzIHdpbGwgb25s eQ0KPj4+IGhhcHBlbiBpZiB0aGUgQU5JIGd1YXJhbnRlZXMgc2VjdXJpdHkuIFRoaXMgaXMgd2h5 IEknbSBoZXNpdGFudCBhYm91dA0KPj4+ICJkb3duZ3JhZGluZyIgc2VjdXJpdHkuDQo+Pj4+Pg0K Pj4+Pj4gSW5kZWVkLiBJdCB3b3VsZCBoYXZlIHRvIGJlIHZlcnkgY2FyZWZ1bC4gT25lIHBvc3Np YmxlIGNhc2Ugd291bGQgYmUgaWYNCj4+Pj4+IHR3byBvcGVyYXRvcnMgd2FudGVkIHRvIGFsbG93 IEFOIGFjcm9zcyB0aGVpciBtdXR1YWwgYm91bmRhcnksIGZvciBhDQo+Pj4gY2VydGFpbg0KPj4+ Pj4gcHVycG9zZSBvbmx5Lg0KPj4+Pg0KPj4+PiBJIHRoaW5rIHRoaXMgaXMgdGhlIHJpZ2h0IGFw cHJvYWNoOiB3aGF0IGFyZSB0aGUgY2FzZXMgZm9yDQo+Pj4+ICJkb3duZ3JhZGluZyBzZWN1cml0 eSI/ICBJIGFtIGFsc28gaGVzaXRhbnQgYWJvdXQgdGhpcy4NCj4+Pg0KPj4+IEluIG15IGV4YW1w bGUsIEFTQTEgaW4gSVNQMSBuZWVkcyBhIDE6MSB0cnVzdCByZWxhdGlvbnNoaXAgd2l0aA0KPj4+ IEFTQTIgaW4gSVNQMiwgYW5kIHRoYXQgaXMgcXVpdGUgZGlzdGluY3QgZnJvbSB0aGUgbXV0dWFs IHRydXN0DQo+Pj4gYmV0d2VlbiBhbGwgQVNBcyBpbnNpZGUgYSBzaW5nbGUgSVNQLg0KPj4NCj4+ IEkgZG9uJ3QgdGhpbmsgd2UgcHJvcGVybHkgZXhwbG9yZSB0aGUgYXJlYSByZWdhcmRpbmcgdG8g ZG9tYWluIGF0IGFsbC4gVXAgdG8NCj5ub3csIHdlIGhhdmUgYW4gYXNzdW1wdGlvbiB0aGF0IHdo ZW4gd2UgdGFsayBhYm91dCBhdXRvbm9taWMgbm9kZSwgaXQNCj5iZWxvbmdzIHRvIG9uZSBhbmQg b25seSBvbmUgZGVmYXVsdCBhdXRvbm9taWMgbmV0d29yayBkb21haW4uIFRoaXMgd291bGQNCj5i ZSBhIHJlYXNvbmFibGUgc3RhcnQgcG9pbnQgc2luY2Ugd2UgY291bGQgc29sdmUgYWxsIGNvbXBs ZXggaXNzdWVzIGZyb20gdGhlDQo+dmVyeSBiZWdpbm5pbmcuIEhvd2V2ZXIsIHJpZ2lkIHNpbmds ZSBkb21haW4gaXMgY2VydGFpbmx5IG5vdCBlbm91Z2ggdG8gaGFuZGxlDQo+dGhlc2UgY29tcGxp Y2F0ZWQgcmVhbCByZXF1aXJlbWVudHMuIFNvLCBtdWx0aXBsZSBkb21haW4gYW5kDQo+ZG9tYWlu LXJlbGV2YW50IG9wZXJhdGlvbiBpcyByZWFsbHkgd29ydGggb2YgZGVlcCBleHBsb3JpbmcuDQo+ DQo+QWdyZWVkLiBJIHN1cHBvc2UgaXQgaXMgb3V0IG9mIFdHIGNoYXJ0ZXIgc2NvcGUgYXQgdGhl IG1vbWVudCwNCj5idXQgd2UgbmVlZCB0byBiZSBzdXJlIHRoYXQgd2UgZG8gbm90IGJsb2NrIHRo ZXNlIHBvc3NpYmlsaXRpZXMNCj5pbiB0aGUgaW5pdGlhbCBkZXNpZ24uDQoNCkkgYmVsaWV2ZSBp dCBpcyBpbiB0aGUgV0cgc2NvcGUsIGJ1dCBub3QgaW4gdGhlIGN1cnJlbnQgY2hhcnRlciBhcyB3 b3JrIGl0ZW1zLiBXZSB3b3VsZCBiZSBwb3NzaWJsZSB0byBhZGQgaXQgaW50byBuZXh0IGNoYXJ0 ZXIsIGlmIHBlb3BsZSBhcmUgd2lsbGluZyB0byB3b3JrIG9uIGl0LiBZb3VyIGNvbmNlcm4gIm5v dCBibG9jayB0aGVzZSBwb3NzaWJpbGl0aWVzIGluIHRoZSBpbml0aWFsIGRlc2lnbiIgaXMgY2Vy dGFpbmx5IHZhbHVhYmxlLg0KDQpSZWdhcmRzLA0KDQpTaGVuZw0KDQo+ICAgQnJpYW4NCj4NCj4+ IFNoZW5nDQo+Pg0KPj4+ICAgIEJyaWFuDQo+Pj4NCj4+Pj4NCj4+Pj4+PiBMb3RzIG9mIGV4Y2Vw dGlvbnMgdG8gdGFrZSBjYXJlIG9mIGZvciBub3cgdGhvdWdoLCBmb3IgZXhhbXBsZSwgbWl4ZWQN Cj4+PiBBTi9ub24tQU4gZW52aXJvbm1lbnRzLg0KPj4+Pj4NCj4+Pj4+IEluZGVlZC4gVGhhdCBj YW4gY3JlYXRlIHdlYWsgcG9pbnRzLg0KPj4+Pj4NCj4+Pj4+IEZvciBub3cgcGVyaGFwcyB0aGVz ZSBpc3N1ZXMgYmVsb25nIGluIHRoZSBzZWN1cml0eSBzZWN0aW9uIG9mIHRoZQ0KPj4+IHJlZmVy ZW5jZSBtb2RlbD8NCj4+Pj4NCj4+Pj4gKzENCj4+Pj4NCj4+Pj4+ICAgICBCcmlhbg0KPj4+Pg0K Pj4NCg== From nobody Wed May 20 05:50:08 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0E11A0121 for ; Wed, 20 May 2015 05:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 x2zClVJDCCCi for ; Wed, 20 May 2015 05:50: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 34F301A0115 for ; Wed, 20 May 2015 05:50:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BST56477; Wed, 20 May 2015 12:50:02 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 May 2015 13:50:01 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.186]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 20 May 2015 20:49:49 +0800 From: "Liubing (Leo)" To: "Max Pritikin (pritikin)" , Sheng Jiang Thread-Topic: Credential and tokenization-//RE: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0f5PA1WqT30U2bo6CjYanqz517y8yAgAAPtoCAAAGGAIACjoyAgAAT9ACAAZdggIAAVlkAgAFb4YCAAwrxgA== Date: Wed, 20 May 2015 12:49:49 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45A67882EC@nkgeml506-mbx.china.huawei.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F5286DD@nkgeml512-mbx.china.huawei.com> <006C00B8-6483-4434-9683-7292B0446EDB@cisco.com> In-Reply-To: <006C00B8-6483-4434-9683-7292B0446EDB@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: =?iso-8859-1?Q?J=E9ferson_Campos_Nobre?= , Anima WG , John Strassner Subject: [Anima] Credential and tokenization-//RE: Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 20 May 2015 12:50:07 -0000 Hi Max, =20 > Secure bootstrapping requires an initial credential but I'd be open to th= e > idea that the existing credential could be either the initial device cred= ential > or a locally issued device credential.=20 [Bing] If we use locally issued device credential, then how to assure the l= ocal procedure to be secure? > Enrollment protocols should support > "higher requirements" such as two factor authentication. Also it makes > sense for the existing credential to be used to obtain a limited use (one= time?) > token that can be used for an enrollment. This provides methods for > virtualized ASA's to "inherit" the existing credential w/o expecting to > provide the necessary interfaces to use the device credential in real tim= e > during the enrollment. [Bing] This consideration makes a lot sense. It might be a bit too vulnerab= le to let the ASAs directly use the credential. So tokenization might even = be a requirement for ASAs inheriting the credential?=20 Best regards, Bing > - max >=20 >=20 > > > > Best regards, > > > > Sheng > > > >> Brian > >> > >>> Brian > >>>> > >>>> regards, > >>>> John > >>>> > >>>> On Thu, May 14, 2015 at 8:35 PM, Brian E Carpenter < > >>>> brian.e.carpenter@gmail.com> wrote: > >>>> > >>>>> On 15/05/2015 15:30, J=E9ferson Campos Nobre wrote: > >>>>>> Hi. > >>>>>> I think that all ASAs must use the same layer 3 address. > >>>>>> As a demux approach, a valid analogy is the presence of multiple > >>>>>> SNMP agents in a node. Thus, something like the > >>>>>> contextEngineID/snmpEngineID could be used. > >>>>> > >>>>> Actually we have a SessionID in the GDNP design. I will have to > >>>>> check, but I think that occurs in all cases where we would need to > demultiplex. > >>>>> As long as it is allocated uniquely per-node (rather than > >>>>> per-ASA), that would be enough. > >>>>> > >>>>> Brian > >>>>> > >>>>>> Best. > >>>>>> > >>>>>> J=E9ferson Campos Nobre > >>>>>> PhD Student > >>>>>> Computer Networks Group - Institute of Informatics Federal > >>>>>> University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre > >>>>>> > >>>>>> On Thu, May 14, 2015 at 11:34 PM, Sheng Jiang > >> > >>>>> wrote: > >>>>>>> In my opinion, addressing per ASA would be ideal. But it is too > >>>>>>> ideal > >>>>> to be taken as a common assumption. The signaling should be able > >>>>> to > >> support > >>>>> the scenario that ASAs share the same layer 3 address. One address > >>>>> per > >> ASA > >>>>> could be considered as a subset of it. I personally believe the > >>>>> current design has already support this. > >>>>>>> > >>>>>>> Sheng > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian > >>>>>>>> E Carpenter > >>>>>>>> Sent: Friday, May 15, 2015 9:19 AM > >>>>>>>> To: Anima WG > >>>>>>>> Subject: [Anima] Addressing ASAs or nodes? > >>>>>>>> > >>>>>>>> While doing some thinking in the context of the signaling > >>>>>>>> design team, I came upon another addressing question. > >>>>>>>> > >>>>>>>> A single physical node might contain several independent > >>>>>>>> autonomic service agents (ASAs) handling different resources. > >>>>>>>> > >>>>>>>> Will those ASAs all use the same layer 3 address, or will they > >>>>>>>> have an address each? > >>>>>>>> > >>>>>>>> This matters for the signaling design, because if they all have > >>>>>>>> the same address, it isn't clear how they could share a listen > >>>>>>>> port. At the least, it creates a complicated demultiplexing > >>>>>>>> requirement. (We have that anyway for incoming discovery > >>>>>>>> messages, but they are distinguished by an 'objective' > >>>>>>>> parameter.) > >>>>>>>> > >>>>>>>> draft-behringer-anima-autonomic-addressing-00 describes one > >>>>>>>> address per node, as far as I can tell. > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed May 20 22:24:00 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8F41A007A for ; Wed, 20 May 2015 22:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 4G7-3gTTIKGB for ; Wed, 20 May 2015 22:23:57 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (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 3BB7F1A006D for ; Wed, 20 May 2015 22:23:57 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so95248597pdb.0 for ; Wed, 20 May 2015 22:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gWHlC1TGKLDyWazW1zRPQsglXopOA08Xs2Mrmdn9/Hs=; b=oLAWML0rAp//muOeFijxONB4EF7TNwpEfc9gZHzkBGhtdE9aypQ2dRl+YBFnabir5e TP4U4xLbM0SawM4nqxyhZ5WtR4tDwy0h54XfOENJp/cbi16AVe2BERrRVgpkvfJHsfVp Fp7j2Pc7XiStqZuuAeAgXzp2xFDRhInA84jYWT1K8tqVOqybyBu4tvc2JPN4UtEUOdl9 ix2THhCpYkagMyiYZ2ZrliXh+fS9xk9H43PdZ+shE7k2umES09KKI8QKkV9znk4HCrRc fs/OYov7OUX7yvGnp2xKUiiscZKnmL8NxbBKdpitv59fpDPgCgoKh9mRGcee6lZPXoQK I1BQ== X-Received: by 10.68.195.2 with SMTP id ia2mr2036147pbc.33.1432185836639; Wed, 20 May 2015 22:23:56 -0700 (PDT) Received: from ?IPv6:2406:e007:5eca:1:28cc:dc4c:9703:6781? ([2406:e007:5eca:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id wt1sm17808576pbc.4.2015.05.20.22.23.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 22:23:55 -0700 (PDT) Message-ID: <555D6BED.9080505@gmail.com> Date: Thu, 21 May 2015 17:23:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Sheng Jiang , =?UTF-8?B?SsOpZmVyc29uIENhbXBvcyA=?= =?UTF-8?B?Tm9icmU=?= References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F53A9EA@nkgeml512-mbx.china.huawei.com> <555BEF7D.7060700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F53AB84@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F53AB84@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 05:23:58 -0000 On 20/05/2015 15:27, Sheng Jiang wrote: >>>>>>>> (Note however that SNMPv3 took a different approach by going for >> its >>>> own >>>>>>>> security solution.) >>>>>>> >>>>>>> If we do our job in the ANI so nicely with security, people won't see a >>>> need for protocol specific security, such as SNMPv3. However, this will only >>>> happen if the ANI guarantees security. This is why I'm hesitant about >>>> "downgrading" security. >>>>>> >>>>>> Indeed. It would have to be very careful. One possible case would be if >>>>>> two operators wanted to allow AN across their mutual boundary, for a >>>> certain >>>>>> purpose only. >>>>> >>>>> I think this is the right approach: what are the cases for >>>>> "downgrading security"? I am also hesitant about this. >>>> >>>> In my example, ASA1 in ISP1 needs a 1:1 trust relationship with >>>> ASA2 in ISP2, and that is quite distinct from the mutual trust >>>> between all ASAs inside a single ISP. >>> >>> I don't think we properly explore the area regarding to domain at all. Up to >> now, we have an assumption that when we talk about autonomic node, it >> belongs to one and only one default autonomic network domain. This would >> be a reasonable start point since we could solve all complex issues from the >> very beginning. However, rigid single domain is certainly not enough to handle >> these complicated real requirements. So, multiple domain and >> domain-relevant operation is really worth of deep exploring. >> >> Agreed. I suppose it is out of WG charter scope at the moment, >> but we need to be sure that we do not block these possibilities >> in the initial design. > > I believe it is in the WG scope, but not in the current charter as work items. We would be possible to add it into next charter, if people are willing to work on it. Your concern "not block these possibilities in the initial design" is certainly valuable. Indeed. What is a bit complicated is that it seems we will need partly overlapping trust domains. In the present protocol design we have no way to express that, but it would be quite easy to add a domain-related option to the messages later, if necessary. Brian > > Regards, > > Sheng > >> Brian >> >>> Sheng >>> >>>> Brian >>>> >>>>> >>>>>>> Lots of exceptions to take care of for now though, for example, mixed >>>> AN/non-AN environments. >>>>>> >>>>>> Indeed. That can create weak points. >>>>>> >>>>>> For now perhaps these issues belong in the security section of the >>>> reference model? >>>>> >>>>> +1 >>>>> >>>>>> Brian >>>>> >>> From nobody Wed May 20 23:02:02 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81871A016C for ; Wed, 20 May 2015 23:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 l6qSuXIFcqx2 for ; Wed, 20 May 2015 23:02:00 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311081A0162 for ; Wed, 20 May 2015 23:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1972; q=dns/txt; s=iport; t=1432188120; x=1433397720; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KYzZVwXvusBCA58A3hPhzHlPQ1DzbUebGt8c2nocBZY=; b=DR7AmAADNITL4KntaarRvlAZ9AEn8DiMXaBFzuKdwqbXlNBRbIvVYH41 QMHibTJ4wUSdHNu9T83cMzvTkh8ReDsKUl3gPSNmQGKwfaMfwJwIeP1TX 8gGivaX9HM56eSSgAHcvsCy1wiYHrWNzTyfYR0IMJz4vt05tHqSmAzzeu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AGBADUc11V/5xdJa1cgxCBOIMZv1lmCYdRAhyBJjgUAQEBAQEBAYEKhCMBAQQjET4HEAIBCBoCBiACAgIwFRACBAENDYgkq1ukBQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYoZhFQxB4JoL4EWAQSSd6IkI4FmghKCNYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,466,1427760000"; d="scan'208";a="152052997" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 21 May 2015 06:01:59 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4L61xhi032331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 May 2015 06:01:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 21 May 2015 01:01:59 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0ekFbLEiZNXEqa5tLuw2MAT518pbqAgAAPtoCAAAGFAIACjo2AgAAT9ACAAZdggIAAwrpwgADYJYCAAFc9QIABMLIAgAAKQoCAAEQTAIAAy5ng Date: Thu, 21 May 2015 06:01:58 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB4B88@xmb-rcd-x14.cisco.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> In-Reply-To: <555BD84C.2090406@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.68.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Sheng Jiang , Anima WG , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 06:02:02 -0000 PiA+Pj4gSWYgd2UgZG8gb3VyIGpvYiBpbiB0aGUgQU5JIHNvIG5pY2VseSB3aXRoIHNlY3VyaXR5 LCBwZW9wbGUgd29uJ3Qgc2VlIGENCj4gbmVlZCBmb3IgcHJvdG9jb2wgc3BlY2lmaWMgc2VjdXJp dHksIHN1Y2ggYXMgU05NUHYzLiBIb3dldmVyLCB0aGlzIHdpbGwgb25seQ0KPiBoYXBwZW4gaWYg dGhlIEFOSSBndWFyYW50ZWVzIHNlY3VyaXR5LiBUaGlzIGlzIHdoeSBJJ20gaGVzaXRhbnQgYWJv dXQNCj4gImRvd25ncmFkaW5nIiBzZWN1cml0eS4NCj4gPj4NCj4gPj4gSW5kZWVkLiBJdCB3b3Vs ZCBoYXZlIHRvIGJlIHZlcnkgY2FyZWZ1bC4gT25lIHBvc3NpYmxlIGNhc2Ugd291bGQgYmUNCj4g Pj4gaWYgdHdvIG9wZXJhdG9ycyB3YW50ZWQgdG8gYWxsb3cgQU4gYWNyb3NzIHRoZWlyIG11dHVh bCBib3VuZGFyeSwgZm9yDQo+ID4+IGEgY2VydGFpbiBwdXJwb3NlIG9ubHkuDQo+ID4NCj4gPiBJ IHRoaW5rIHRoaXMgaXMgdGhlIHJpZ2h0IGFwcHJvYWNoOiB3aGF0IGFyZSB0aGUgY2FzZXMgZm9y DQo+ID4gImRvd25ncmFkaW5nIHNlY3VyaXR5Ij8gIEkgYW0gYWxzbyBoZXNpdGFudCBhYm91dCB0 aGlzLg0KPiANCj4gSW4gbXkgZXhhbXBsZSwgQVNBMSBpbiBJU1AxIG5lZWRzIGEgMToxIHRydXN0 IHJlbGF0aW9uc2hpcCB3aXRoDQo+IEFTQTIgaW4gSVNQMiwgYW5kIHRoYXQgaXMgcXVpdGUgZGlz dGluY3QgZnJvbSB0aGUgbXV0dWFsIHRydXN0IGJldHdlZW4gYWxsDQo+IEFTQXMgaW5zaWRlIGEg c2luZ2xlIElTUC4NCg0KQnJpYW4sIA0KDQpUaGlzIGlzIG5vdCB0b28gZGlmZmljdWx0LCB3ZSBj YW4gbWFrZSB0aGlzIHdvcmsgcXVpdGUgZWFzaWx5LiANCi0gaWYgdHdvIG5vZGVzIGFyZSBpbiB0 aGUgc2FtZSBkb21haW4sIHRoZXkgdXNlIGEgZGVmYXVsdCBzZWN1cml0eSBtb2RlbCAod2hpY2gg SSBzdGlsbCBpbnNpc3Qgc2hvdWxkIGJlIGhpZ2gpDQotIGlmIHRoZXkgYXJlIGluIGRpZmZlcmVu dCBkb21haW5zLCB0d28gc3ViIGNhc2VzOiAgIA0KICArIGNvbW1vbiB0cnVzdCBhbmNob3IgKGll LCBzdWItZG9tYWlucykNCiAgKyBubyBjb21tb24gdHJ1c3QgYW5jaG9yDQoNCklmIG5vIGNvbW1v biB0cnVzdCBhbmNob3IsIHRoZXkgaGF2ZSB0byBleGNoYW5nZSByb290IGNlcnRzIGluIHNvbWUg d2F5LiBUaGVuLCBpbiBhbGwgY2FzZXMsIHRoZSBub2RlcyBjYW4gYXV0aGVudGljYXRlIGVhY2gg b3RoZXIuIA0KRm9yIGF1dGhvcml6YXRpb24sIGluIHRoZSB0d28gY2FzZXMgd2l0aCBkaWZmZXJl bnQgZG9tYWlucywgaW50ZW50IHNheXMgd2hhdCB0byBkby4gDQoNCkNvbmNyZXRlIGV4YW1wbGU6 IA0KSW50ZW50IGluIFNQIDE6ICJUcnVzdCBCR1Agc3BlYWtlcnMgZnJvbSBTUCAyIHdpdGggcm9v dCBjZXJ0IHggZm9yOiBCR1AgYXV0aGVudGljYXRpb24uIE5vIEFDUCwgbm90aGluZyBlbHNlIi4g DQoNCk1pY2hhZWwNCg== From nobody Thu May 21 13:09:15 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF711A8A16 for ; Thu, 21 May 2015 13:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 XXwJ5MlB3wGD for ; Thu, 21 May 2015 13:09:13 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 B163E1A7022 for ; Thu, 21 May 2015 13:09:13 -0700 (PDT) Received: by pabru16 with SMTP id ru16so116277801pab.1 for ; Thu, 21 May 2015 13:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ed2KX/p1LMyj7aKSwOUXiKJPsp7dUIgdXLIWoefHXZo=; b=TDvZ/YJ8UZaUK0wnprLX2ez9tLDEjlTjzMYQY55vQJ7uzBXS4Kl44mgSjHtjjcCPZY gon92SGKbD2fxqNiQ9627QyvgJCIqIHEbpkPfIglB/12tIcJ/6aGqZbF12cN6FvCh7qJ VBLVpD7QsxR4wSK4gUXXU9NmJaR+InQzDYf9LZ8bVA2HVR15P/MwqYElXTVeavDnaVs5 t4m13rjzd+B6VpHbc4CfAZVEAP5MLFHoDGmDm+NNc6eFDiS35tdPxBV9IVF42nE+Nwcq dadNKDmo+8hjwJFumuuLcVqfCG9T6KgaFbCSR19tt0VBOTiI5EwDC/6psj3TTC/wxdnB aBDw== X-Received: by 10.68.131.65 with SMTP id ok1mr4260571pbb.16.1432238953423; Thu, 21 May 2015 13:09:13 -0700 (PDT) Received: from ?IPv6:2406:e007:78f3:1:28cc:dc4c:9703:6781? ([2406:e007:78f3:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id bx6sm20074825pdb.39.2015.05.21.13.09.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 13:09:12 -0700 (PDT) Message-ID: <555E3B6C.5070306@gmail.com> Date: Fri, 22 May 2015 08:09:16 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , =?UTF-8?B?SsOpZmU=?= =?UTF-8?B?cnNvbiBDYW1wb3MgTm9icmU=?= References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB4B88@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB4B88@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Sheng Jiang , Anima WG , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 20:09:14 -0000 Hi Michael, On 21/05/2015 18:01, Michael Behringer (mbehring) wrote: >>>>> If we do our job in the ANI so nicely with security, people won't see a >> need for protocol specific security, such as SNMPv3. However, this will only >> happen if the ANI guarantees security. This is why I'm hesitant about >> "downgrading" security. >>>> >>>> Indeed. It would have to be very careful. One possible case would be >>>> if two operators wanted to allow AN across their mutual boundary, for >>>> a certain purpose only. >>> >>> I think this is the right approach: what are the cases for >>> "downgrading security"? I am also hesitant about this. >> >> In my example, ASA1 in ISP1 needs a 1:1 trust relationship with >> ASA2 in ISP2, and that is quite distinct from the mutual trust between all >> ASAs inside a single ISP. > > Brian, > > This is not too difficult, we can make this work quite easily. > - if two nodes are in the same domain, they use a default security model (which I still insist should be high) > - if they are in different domains, two sub cases: > + common trust anchor (ie, sub-domains) > + no common trust anchor > > If no common trust anchor, they have to exchange root certs in some way. Then, in all cases, the nodes can authenticate each other. > For authorization, in the two cases with different domains, intent says what to do. > > Concrete example: > Intent in SP 1: "Trust BGP speakers from SP 2 with root cert x for: BGP authentication. No ACP, nothing else". I agree, conceptually it is very possible. Would you engineer this as an extension to the ACP model? How do you think the writer of an ASA would see this, a special security API? Brian > > Michael > From nobody Sat May 23 07:57:21 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06E21A005F for ; Sat, 23 May 2015 07:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WowHkFNyCRch for ; Sat, 23 May 2015 07:57:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D4B1A00B0 for ; Sat, 23 May 2015 07:57:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 694BE200A1; Sat, 23 May 2015 11:10:34 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4263564880; Sat, 23 May 2015 10:57:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 27F516487F; Sat, 23 May 2015 10:57:14 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-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 Sender: mcr@sandelman.ca Archived-At: Cc: "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 14:57:20 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: >> (Note however that SNMPv3 took a different approach by going for its own >> security solution.) > If we do our job in the ANI so nicely with security, people won't see a > need for protocol specific security, such as SNMPv3. However, this will > only happen if the ANI guarantees security. This is why I'm hesitant > about "downgrading" security. ANI = Autonomic Network Infrastructure? I don't see how IP-layer security (as we normally practice it) can provide for role-based access control into the "routers". Sure, we could provide 5-tuple based IPsec or TLS security that would permit roles to be communicated, but that seems like a big stretch. Maybe I mis-understand. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVWCVSYCLcPvd0N1lAQJNigf/aZtho+A8o/V10P2pb/zDty/NVEQSptcM +5K/6im+wnDrqKS+3Dj9yL3nuALdIuVu2YEM311JKYo1SNBzjgwxhKNLPDYMQmP7 RXT8MDmzkMPzF5WMlkHkr+f0xEvcIe0ohiGPlk0kikB+N+cLQ5BPfymwvO5fhdGv 27HfzGRSdBWHqJu2yXLdpCoKQNf+APKKmYlZyymAJvOw8JeU2KeiuHMi4WVWpzZd R8/p1836yqI6XsMvixejIvFvWg6SNgzkAR0b+sr7+HSkQoV9KUcdsmfj9lTBB9IO YbgNtx17YaVJ51CLMNZ7fmzOKNfVOp1GrO22ByfLiIaSuH3MLnSeQQ== =SoUP -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat May 23 08:03:50 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51AE1A008F for ; Sat, 23 May 2015 08:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_44=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ayhhAiPNsR2x for ; Sat, 23 May 2015 08:03:47 -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 4EF171A0076 for ; Sat, 23 May 2015 08:03:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A4F0200A1 for ; Sat, 23 May 2015 11:16:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4336164880; Sat, 23 May 2015 11:03:25 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 357836487F for ; Sat, 23 May 2015 11:03:25 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F53A9EA@nkgeml512-mbx.china.huawei.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F53A9EA@nkgeml512-mbx.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.3-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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 15:03:48 -0000 --=-=-= Content-Type: text/plain Sheng Jiang wrote: >> In my example, ASA1 in ISP1 needs a 1:1 trust relationship with >> ASA2 in ISP2, and that is quite distinct from the mutual trust >> between all ASAs inside a single ISP. > I don't think we properly explore the area regarding to domain at > all. Up to now, we have an assumption that when we talk about autonomic > node, it belongs to one and only one default autonomic network > domain. This would be a reasonable start point since we could solve all > complex issues from the very beginning. However, rigid single domain is > certainly not enough to handle these complicated real requirements. So, > multiple domain and domain-relevant operation is really worth of deep > exploring. I think that the AN gives us a number of important things that can be *leveraged* to provide ISP1<->ASA2. 1) ISP1 and ISP2 now have a domain. (we might want to consider interactions, aka "bridge CA"s into the SIDR space...) 2) all the devices in ISP1 and ISP2's domains all have locally relevant identities. So, ISP1 and ISP2 don't need to try to trust Verisign or self-signed-certificate#4 (with all the legal and operations issues involved), they can now much more easily write a bilateral trust agreement. So ASA2 can be explicitely configured as to what it authorizes ISP1 to do to it. Perhaps that can be autonomically configured if some higher level intent says, "cooperate with ISP1, including providing ISP1 with FOOBAR access", then the the FOOBAR authorization could be configured autonomically on the machine(s) that are providing the FOOBAR service. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVWCWvICLcPvd0N1lAQK58Af/e1m3HcTSiXEfGbt+R5wAF2zlVcRzD4ab d5hpB09KS+noRupesmpPTafh7eA50DbmvodKp3/E9EEzmEjNl1t9OYYdJSGnDjKD Eq+EsUbK/2+uIQJhV2tSJgwdrcLe1wQ2sG8idEqZWX+jmuFxGAZfY7ubNbWD1ZKf UU0PyX0WyloYRhYh2Xbdon80jtR+yYCLpPC1ZMiyPoI4wDyXd1n3ZcjGQCBAk43x R/ba9W76cpoxugO6ybxKmuiTqP738nVEKDmpKxSi62yqguQkCLcSmF9e1zhTRJGb mNFiQK+SvZyraGGmtAEW9kPAGn7XDr0ACeyF06FQ77kTR+qpXFtDwg== =IWk2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat May 23 14:00:11 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2251B1A8775 for ; Sat, 23 May 2015 14:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, J_BACKHAIR_44=1, SPF_PASS=-0.001] autolearn=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 EGAIfBrGptHC for ; Sat, 23 May 2015 14:00:09 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (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 B04071A876F for ; Sat, 23 May 2015 14:00:09 -0700 (PDT) Received: by pdea3 with SMTP id a3so43617803pde.2 for ; Sat, 23 May 2015 14:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uyM+WDulwHXSVsbI+4Moj8uYxI8Q1Tz8JY6YmSMo4mw=; b=XVurYqzOkyb93ZSQKVBiqcBspXaKBy649Sr8O9X/oUbB76vbHt6aAk/W/YSNJu+H1l Fq6syNGT7RowfJ0YXZLKyQ0C+1AD2M4/9Ej0uuiyZ9Gtxku72+qx89koau/9at94rQdS 7smkDPy1LjWjKxD/Ap9iWu46Nq1cIWtt+jwvdBjTQ/wasglCCvPuByw7sfrt9KDLIQZa F4T4ysp7YuY6AEfUkYlZ2eMXkbtiOE7BR0GhIQqVf8wc5WVZyo0l3O3ijpaAcNjmN1TC VMY3D6ClJJvXAM4F3UDuAQpy8pklRCQgdvmsQHYcNA2xosagzrYRlxoQL7oY/IKupA/T +bVg== X-Received: by 10.66.102.37 with SMTP id fl5mr27183114pab.88.1432414809341; Sat, 23 May 2015 14:00:09 -0700 (PDT) Received: from ?IPv6:2406:e007:6af4:1:28cc:dc4c:9703:6781? ([2406:e007:6af4:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id j7sm5715426pbq.35.2015.05.23.14.00.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 May 2015 14:00:08 -0700 (PDT) Message-ID: <5560EA53.1000602@gmail.com> Date: Sun, 24 May 2015 09:00:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Richardson , Anima WG References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F53A9EA@nkgeml512-mbx.china.huawei.com> <30797.1432393405@sandelman.ca> In-Reply-To: <30797.1432393405@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 21:00:11 -0000 On 24/05/2015 03:03, Michael Richardson wrote: > > Sheng Jiang wrote: > >> In my example, ASA1 in ISP1 needs a 1:1 trust relationship with > >> ASA2 in ISP2, and that is quite distinct from the mutual trust > >> between all ASAs inside a single ISP. > > > I don't think we properly explore the area regarding to domain at > > all. Up to now, we have an assumption that when we talk about autonomic > > node, it belongs to one and only one default autonomic network > > domain. This would be a reasonable start point since we could solve all > > complex issues from the very beginning. However, rigid single domain is > > certainly not enough to handle these complicated real requirements. So, > > multiple domain and domain-relevant operation is really worth of deep > > exploring. > > I think that the AN gives us a number of important things that can be > *leveraged* to provide ISP1<->ASA2. > 1) ISP1 and ISP2 now have a domain. > (we might want to consider interactions, aka "bridge CA"s into the SIDR > space...) > > 2) all the devices in ISP1 and ISP2's domains all have locally relevant > identities. > > So, ISP1 and ISP2 don't need to try to trust Verisign or > self-signed-certificate#4 (with all the legal and operations issues > involved), they can now much more easily write a bilateral trust agreement. > So ASA2 can be explicitely configured as to what it authorizes ISP1 > to do to it. Perhaps that can be autonomically configured if some higher > level intent says, "cooperate with ISP1, including providing ISP1 with > FOOBAR access", then the the FOOBAR authorization could be configured > autonomically on the machine(s) that are providing the FOOBAR service. Let me equate FOOBAR with an Anima objective (i.e. a specific parameter that we are trying to manage, where the parameter could be single-valued or a more complex data structure). Then yes, my idea is that trust and authorization should be possible at that granularity. This might be bundled up rather like an Android app: An ASA, when it joins a domain, says "I want to be trusted for the following list of objectives:....". Then the bilateral trust agreement would be manifested as a special domain with a very restricted set of available objectives. Brian From nobody Mon May 25 09:15:09 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC201AC3B3 for ; Mon, 25 May 2015 09:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 KPIKzkxA9EGa for ; Mon, 25 May 2015 09:15:04 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2FC1AC3AC for ; Mon, 25 May 2015 09:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1813; q=dns/txt; s=iport; t=1432570503; x=1433780103; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EWUmih113WW7uIQQbsUHX53mrLpd+k+bW4GB1E8Ppl4=; b=f6pTAZ/lKMpydyu7SiJa8EnSlRop0+5gPOxo8EVh1CCKpT9geQwqaM0i qAs59ZB1gMoHShXBdjdul16tRUi8tWhcaThzpg5eUov0Y6Ga9T+3cr0bJ S1ZSw32mzuMJ9AULDAwGQYeS3xSsdU3Opl48G03yONwoe1+0CMt5lBtmk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B6BAA3SWNV/4YNJK1cgxCBMgbCVWYJh1ACgTM4FAEBAQEBAQGBCoQiAQEBAwE6RAcEAgEIEQQBAQEKFAkHMhQJCAIEARIIE4gJCNJlAQEBAQEBAQEBAQEBAQEBAQEBAQEYizqEGBQoOAaDEYEWBZMIoj4jg3hvgQMJFyOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,492,1427760000"; d="scan'208";a="153199122" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 25 May 2015 16:15:03 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4PGF3aY002464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 May 2015 16:15:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 25 May 2015 11:15:03 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , Anima WG Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0ekFbLEiZNXEqa5tLuw2MAT518pbqAgAAPtoCAAAGFAIACjo2AgAAT9ACAAZdggIAAwrpwgADYJYCAAFc9QIAHJQcAgALkn3A= Date: Mon, 25 May 2015 16:15:02 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB8237@xmb-rcd-x14.cisco.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <29428.1432393034@sandelman.ca> In-Reply-To: <29428.1432393034@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 25 May 2015 16:15:08 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: 23 May 2015 16:57 > To: Anima WG > Cc: Michael Behringer (mbehring) > Subject: Re: [Anima] Addressing ASAs or nodes? >=20 >=20 > Michael Behringer (mbehring) wrote: > >> (Note however that SNMPv3 took a different approach by going for i= ts > own > >> security solution.) >=20 > > If we do our job in the ANI so nicely with security, people won't s= ee a > > need for protocol specific security, such as SNMPv3. However, this = will > > only happen if the ANI guarantees security. This is why I'm hesitan= t > > about "downgrading" security. >=20 > ANI =3D Autonomic Network Infrastructure? Yes. Sorry for the acronym...=20 =20 > I don't see how IP-layer security (as we normally practice it) can provid= e > for role-based access control into the "routers". Sure, we could provid= e > 5-tuple based IPsec or TLS security that would permit roles to be > communicated, but that seems like a big stretch. >=20 > Maybe I mis-understand. Not sure we're on the same page either, so let me expand:=20 The Autonomic Control Plane (ACP) gives you by default protection against "= the outside", the channels are encrypted and the messages are authenticated= as coming from a node from the same trust group.=20 Roles come into play in two flavours here:=20 - SSH / telnet / etc access to devices, with AAA allows for role based auth= orization. This is for the "things" accessing nodes.=20 - Nodes themselves can have a role, which can be attested in their certific= ate. Autonomic functions can therefore be limited to nodes with certain rol= es.=20 Does this shoot in the right direction?=20 Michael From nobody Mon May 25 09:30:35 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8561A1B96 for ; Mon, 25 May 2015 09:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 lIomQoGEsQnU for ; Mon, 25 May 2015 09:30:30 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F961AC422 for ; Mon, 25 May 2015 09:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4110; q=dns/txt; s=iport; t=1432571430; x=1433781030; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kJLwQbJdpy+qdfZJHaHJrf6X4Z+X+3Kw2HiTq6P0W3E=; b=bru3iC7eMOlQR3BwKsfNEveotwUCBS9EzvJey5DJw2oT6X5sYAN5gKpk Z8/riv2PF8RaJNqsrag7dO+OyQ/KLoYeCCN3UZSPT/3zZCxdwDu/b5xnY qyS/MvSFYqQt7l2SoWOvV9GUFmoalUjlaUMqyVg/TVGKocLS/N3KiYVdT Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CvBQD/TGNV/5RdJa1cgxCBMgaDGb88iD8CHIEXTAEBAQEBAYELhCIBAQEDASMRPgcFBwQCAQgRBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIiA8DCgivFZ49DYUGAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhihmCTYFgJxYbBwaCYi+BFgWTCIk2kgWHAyOBZikXgVJvAYEDQoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,492,1427760000"; d="scan'208";a="422424927" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 25 May 2015 16:30:29 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4PGUThD024416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 May 2015 16:30:29 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Mon, 25 May 2015 11:30:28 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0ekFbLEiZNXEqa5tLuw2MAT518pbqAgAAPtoCAAAGFAIACjo2AgAAT9ACAAZdggIAAwrpwgADYJYCAAFc9QIABMLIAgAAKQoCAAEQTAIAAy5nggAIM7ACABbQvsA== Date: Mon, 25 May 2015 16:30:28 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB82AE@xmb-rcd-x14.cisco.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB4B88@xmb-rcd-x14.cisco.com> <555E3B6C.5070306@gmail.com> In-Reply-To: <555E3B6C.5070306@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Sheng Jiang , Anima WG , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 25 May 2015 16:30:34 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gRSBDYXJwZW50 ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6IDIxIE1heSAy MDE1IDIyOjA5DQo+IFRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBKw6lmZXJzb24g Q2FtcG9zIE5vYnJlDQo+IENjOiBKb2huIFN0cmFzc25lcjsgQW5pbWEgV0c7IFNoZW5nIEppYW5n DQo+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIEFkZHJlc3NpbmcgQVNBcyBvciBub2Rlcz8NCj4gDQo+ IEhpIE1pY2hhZWwsDQo+IE9uIDIxLzA1LzIwMTUgMTg6MDEsIE1pY2hhZWwgQmVocmluZ2VyICht YmVocmluZykgd3JvdGU6DQo+ID4+Pj4+IElmIHdlIGRvIG91ciBqb2IgaW4gdGhlIEFOSSBzbyBu aWNlbHkgd2l0aCBzZWN1cml0eSwgcGVvcGxlIHdvbid0DQo+ID4+Pj4+IHNlZSBhDQo+ID4+IG5l ZWQgZm9yIHByb3RvY29sIHNwZWNpZmljIHNlY3VyaXR5LCBzdWNoIGFzIFNOTVB2My4gSG93ZXZl ciwgdGhpcw0KPiA+PiB3aWxsIG9ubHkgaGFwcGVuIGlmIHRoZSBBTkkgZ3VhcmFudGVlcyBzZWN1 cml0eS4gVGhpcyBpcyB3aHkgSSdtDQo+ID4+IGhlc2l0YW50IGFib3V0ICJkb3duZ3JhZGluZyIg c2VjdXJpdHkuDQo+ID4+Pj4NCj4gPj4+PiBJbmRlZWQuIEl0IHdvdWxkIGhhdmUgdG8gYmUgdmVy eSBjYXJlZnVsLiBPbmUgcG9zc2libGUgY2FzZSB3b3VsZA0KPiA+Pj4+IGJlIGlmIHR3byBvcGVy YXRvcnMgd2FudGVkIHRvIGFsbG93IEFOIGFjcm9zcyB0aGVpciBtdXR1YWwNCj4gPj4+PiBib3Vu ZGFyeSwgZm9yIGEgY2VydGFpbiBwdXJwb3NlIG9ubHkuDQo+ID4+Pg0KPiA+Pj4gSSB0aGluayB0 aGlzIGlzIHRoZSByaWdodCBhcHByb2FjaDogd2hhdCBhcmUgdGhlIGNhc2VzIGZvcg0KPiA+Pj4g ImRvd25ncmFkaW5nIHNlY3VyaXR5Ij8gIEkgYW0gYWxzbyBoZXNpdGFudCBhYm91dCB0aGlzLg0K PiA+Pg0KPiA+PiBJbiBteSBleGFtcGxlLCBBU0ExIGluIElTUDEgbmVlZHMgYSAxOjEgdHJ1c3Qg cmVsYXRpb25zaGlwIHdpdGgNCj4gPj4gQVNBMiBpbiBJU1AyLCBhbmQgdGhhdCBpcyBxdWl0ZSBk aXN0aW5jdCBmcm9tIHRoZSBtdXR1YWwgdHJ1c3QNCj4gPj4gYmV0d2VlbiBhbGwgQVNBcyBpbnNp ZGUgYSBzaW5nbGUgSVNQLg0KPiA+DQo+ID4gQnJpYW4sDQo+ID4NCj4gPiBUaGlzIGlzIG5vdCB0 b28gZGlmZmljdWx0LCB3ZSBjYW4gbWFrZSB0aGlzIHdvcmsgcXVpdGUgZWFzaWx5Lg0KPiA+IC0g aWYgdHdvIG5vZGVzIGFyZSBpbiB0aGUgc2FtZSBkb21haW4sIHRoZXkgdXNlIGEgZGVmYXVsdCBz ZWN1cml0eSBtb2RlbA0KPiAod2hpY2ggSSBzdGlsbCBpbnNpc3Qgc2hvdWxkIGJlIGhpZ2gpDQo+ ID4gLSBpZiB0aGV5IGFyZSBpbiBkaWZmZXJlbnQgZG9tYWlucywgdHdvIHN1YiBjYXNlczoNCj4g PiAgICsgY29tbW9uIHRydXN0IGFuY2hvciAoaWUsIHN1Yi1kb21haW5zKQ0KPiA+ICAgKyBubyBj b21tb24gdHJ1c3QgYW5jaG9yDQo+ID4NCj4gPiBJZiBubyBjb21tb24gdHJ1c3QgYW5jaG9yLCB0 aGV5IGhhdmUgdG8gZXhjaGFuZ2Ugcm9vdCBjZXJ0cyBpbiBzb21lIHdheS4NCj4gVGhlbiwgaW4g YWxsIGNhc2VzLCB0aGUgbm9kZXMgY2FuIGF1dGhlbnRpY2F0ZSBlYWNoIG90aGVyLg0KPiA+IEZv ciBhdXRob3JpemF0aW9uLCBpbiB0aGUgdHdvIGNhc2VzIHdpdGggZGlmZmVyZW50IGRvbWFpbnMs IGludGVudCBzYXlzDQo+IHdoYXQgdG8gZG8uDQo+ID4NCj4gPiBDb25jcmV0ZSBleGFtcGxlOg0K PiA+IEludGVudCBpbiBTUCAxOiAiVHJ1c3QgQkdQIHNwZWFrZXJzIGZyb20gU1AgMiB3aXRoIHJv b3QgY2VydCB4IGZvcjogQkdQDQo+IGF1dGhlbnRpY2F0aW9uLiBObyBBQ1AsIG5vdGhpbmcgZWxz ZSIuDQo+IA0KPiBJIGFncmVlLCBjb25jZXB0dWFsbHkgaXQgaXMgdmVyeSBwb3NzaWJsZS4gV291 bGQgeW91IGVuZ2luZWVyIHRoaXMgYXMgYW4NCj4gZXh0ZW5zaW9uIHRvIHRoZSBBQ1AgbW9kZWw/ IA0KDQpOby4gVGhlIEFDUCBpcyBvbmx5IG9uZSB3YXkgYXV0b25vbWljIG5vZGVzIGludGVyYWN0 LiBJbnNpZGUgYSB0cnVzdGVkIGRvbWFpbiBpdCdzIHRoZSBkZWZhdWx0IG1vZGUuIA0KDQpOb2Rl cyBuZWdvdGlhdGUgc29tZXRoaW5nIEkgd291bGQgY2FsbCAiaW50ZXJhY3Rpb24gc2NoZW1hdGEi LiBUaGlzIGNvdWxkIGJlIGEgY29sbGVjdGlvbiBvZiBwcm90b2NvbHMgYW5kIHNlY3VyaXR5IG1l Y2hhbmlzbXMgYXNzb2NpYXRlZCB3aXRoIGEgdHlwZSBvZiAicGVlcmluZyIgYmV0d2VlbiBub2Rl cy4gVGhlIHNpbXBsZXN0IG9uZSBpcyB0byBicmluZyB1cCB0aGUgQUNQLiANCg0KRm9yIGV4YW1w bGUsIGFuIFNQIFBFIHJvdXRlciBjb3VsZCBoYXZlIGEgc3BlY2lmaWMgc2NoZW1hIGZvciB0aGF0 IHBlZXJpbmcgdHlwZS4gSXQgY291bGQgYnJpbmcgdXAgc29tZSBkZWZhdWx0IHJvdXRpbmcsIHNl Y3VyZSBpdCBhdXRvbWF0aWNhbGx5LCBwb3NzaWJseSBhc3NpZ24gYWRkcmVzcyBzcGFjZSB0byB0 aGUgQ0UsIGV0Yy4gDQoNCkludGVudCBzYXlzICJ3aXRoIGFueSBub2RlIGZyb20gZG9tYWluIHgg KHNheSBhIGN1c3RvbWVyKSwgZG86IHVzZSBhdXRoZW50aWNhdGVkIE9TUEYsIGJyaW5nIGludG8g VlBOIG9mIDxjdXN0b21lcj4sIFNMQSB0cmFja2luZyB0ZW1wbGF0ZSA8eD4iLiAgKG5vdGUgeW91 IG5lZWQgdGhlIHRydXN0IGFuY2hvciBmcm9tIDxjdXN0b21lcj4gZm9yIHRoaXMgdG8gd29yayku IA0KDQo+IEhvdyBkbyB5b3UgdGhpbmsgdGhlIHdyaXRlciBvZiBhbiBBU0Egd291bGQNCj4gc2Vl IHRoaXMsIGEgc3BlY2lhbCBzZWN1cml0eSBBUEk/DQoNCkFuIEFTQSBuZWVkcyB0byAidW5kZXJz dGFuZCIgaXRzIHJvbGUgaW4gdGhlIHN5c3RlbSwgYW5kIGJlIGFibGUgdG8gaW50ZXJwcmV0IGlu dGVudC4gTGlrZWx5LCB3ZSdsbCBwcm92aWRlIHRoZSBwb3NzaWJpbGl0eSB0byBsaW1pdCB0aGUg Y2FwYWJpbGl0aWVzIG9mIEFTQXMuIA0KDQpNaWNoYWVsDQoNCg== From nobody Tue May 26 10:11:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E5C1A92E4 for ; Tue, 26 May 2015 10:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 z7vQ-gFHRqNr for ; Tue, 26 May 2015 10:11:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4806A1A9025 for ; Tue, 26 May 2015 10:11:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D19E520012; Tue, 26 May 2015 13:24:39 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 244396489A; Tue, 26 May 2015 13:11:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 12EF364899; Tue, 26 May 2015 13:11:09 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <5560EA53.1000602@gmail.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F53A9EA@nkgeml512-mbx.china.huawei.com> <30797.1432393405@sandelman.ca> <5560EA53.1000602@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-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 Sender: mcr@sandelman.ca Archived-At: Cc: Anima WG Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 May 2015 17:11:13 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> So, ISP1 and ISP2 don't need to try to trust Verisign or >> self-signed-certificate#4 (with all the legal and operations issues >> involved), they can now much more easily write a bilateral trust agreement. >> So ASA2 can be explicitely configured as to what it authorizes ISP1 >> to do to it. Perhaps that can be autonomically configured if some higher >> level intent says, "cooperate with ISP1, including providing ISP1 with >> FOOBAR access", then the the FOOBAR authorization could be configured >> autonomically on the machine(s) that are providing the FOOBAR service. > Let me equate FOOBAR with an Anima objective (i.e. a specific parameter > that we are trying to manage, where the parameter could be single-valued > or a more complex data structure). Then yes, my idea is that trust and > authorization should be possible at that granularity. This might be > bundled up rather like an Android app: An ASA, when it joins a domain, > says "I want to be trusted for the following list of objectives:....". > Then the bilateral trust agreement would be manifested as a special > domain with a very restricted set of available objectives. Let me turn FOOBAR service a concrete example, so that I'm sure that I know what kinds of things you are talking about. Let's say ISPA and ISPB have a peering. They run DIFFSERV... Let FOOBAR == service that transforms high-level signed SLA statement into DSCP. So, ISPA needs to discover that ISPB runs the FOOBAR service for peering point X, on device Y. This is why ISP1 needs to interact with the FOOBAR service on ISP2. Brian, Is this the kind of thing that you are thinking about? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVWSpLICLcPvd0N1lAQLCTwf/cREDEM/Ubyyy6IwZNTo5GrVr5xSQoeLZ EeUKo7LhxB0zFnhnUfh7Q7WyuI5ssxYnS34LVl/JJKGJU2qbE+pkbcYJ3owdM+G2 aGUvZ9JmR7Mt7qfVsof+K0+lbSAV8kOZoqe8E3tvHwhkoBs8f8jeTgQo2PGBzB5q +tSwtJ6fjQJ89NRYR0kx9eCUbaqE2CECXh28kPte//ijg66OyOPK0XvhLEQ9JPLU tx2wCJ4UKaPHpGVcTRHeYSh+OToFxvShMTAGp+jDtzBCcsg93eQRwiDOnX4Lgofp LeZmxrWF0QvzfgOV3J+Pi8Y7OChvMDXccB9FfUxhvWs6iAj5E8VHYw== =V3DY -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 26 13:31:10 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CBC1B3138 for ; Tue, 26 May 2015 13:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 sxyNcBNQKUmz for ; Tue, 26 May 2015 13:31:07 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E4D1B3135 for ; Tue, 26 May 2015 13:31:07 -0700 (PDT) Received: by paza2 with SMTP id a2so91748555paz.3 for ; Tue, 26 May 2015 13:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2/ZpaszIdYeoyCaBtHh82/TEburmkHhsJpp8GR0zRH0=; b=kiaSvQ/ei545aH4oFpu06t/ybbSiYrdZPX38Rvei8E6pV8UP7R1C2byhyPcRMPJ205 2cE1CND2LsjYA+4dXs8LHGjpy1BIrn/VK9ENnCH2AFxm31y7xNs+f5mH4NCc2NYKuqxU 4TaK70fDIXDey3brWSwLEjs/yu6oEdpjsqMkdvJ/gBizQIsHPyY/9l0AwOODqQXRpWVM PIvxKIc46VGsTqBNmBVFj/M/b3BX+YRqzbdm61JqhzHoE1R5JP/O8GSZ6nKayLmZeJls XTXunG4Z5raLWlUdYYRhlYl5tG/llSu11RWl/HmGx7BGxkMzLi8uK6xTgWA4X1DZuioV JxjQ== X-Received: by 10.70.125.129 with SMTP id mq1mr52643994pdb.19.1432672266886; Tue, 26 May 2015 13:31:06 -0700 (PDT) Received: from ?IPv6:2406:e007:7cbe:1:28cc:dc4c:9703:6781? ([2406:e007:7cbe:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id l10sm13889280pbq.87.2015.05.26.13.31.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 13:31:05 -0700 (PDT) Message-ID: <5564D80A.3030306@gmail.com> Date: Wed, 27 May 2015 08:31:06 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Richardson References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F53A9EA@nkgeml512-mbx.china.huawei.com> <30797.1432393405@sandelman.ca> <5560EA53.1000602@gmail.com> <19555.1432660269@sandelman.ca> In-Reply-To: <19555.1432660269@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 May 2015 20:31:08 -0000 On 27/05/2015 05:11, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> So, ISP1 and ISP2 don't need to try to trust Verisign or > >> self-signed-certificate#4 (with all the legal and operations issues > >> involved), they can now much more easily write a bilateral trust agreement. > >> So ASA2 can be explicitely configured as to what it authorizes ISP1 > >> to do to it. Perhaps that can be autonomically configured if some higher > >> level intent says, "cooperate with ISP1, including providing ISP1 with > >> FOOBAR access", then the the FOOBAR authorization could be configured > >> autonomically on the machine(s) that are providing the FOOBAR service. > > > > Let me equate FOOBAR with an Anima objective (i.e. a specific parameter > > that we are trying to manage, where the parameter could be single-valued > > or a more complex data structure). Then yes, my idea is that trust and > > authorization should be possible at that granularity. This might be > > bundled up rather like an Android app: An ASA, when it joins a domain, > > says "I want to be trusted for the following list of objectives:....". > > > Then the bilateral trust agreement would be manifested as a special > > domain with a very restricted set of available objectives. > > Let me turn FOOBAR service a concrete example, so that I'm sure that I > know what kinds of things you are talking about. > > Let's say ISPA and ISPB have a peering. They run DIFFSERV... > Let FOOBAR == service that transforms high-level signed SLA statement > into DSCP. So, ISPA needs to discover that ISPB runs the FOOBAR service > for peering point X, on device Y. > This is why ISP1 needs to interact with the FOOBAR service on ISP2. > > Brian, Is this the kind of thing that you are thinking about? I would dig a couple of millimetres deeper and suggest that FOOBAR as a technical objective would be a mapping of SLA parameters into a set of diffserv code points. So it would actually be a data structure mapping items like 'jitter<100' into 'EF' (that's still over-simplified, of course). So ASA1 would discover that ASA2 supports the FOOBAR objective, and could then negotiate jitter targets etc and the corresponding DSCP values. And that reqires to be mutually authorized in both domains. Brian From nobody Tue May 26 18:51:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5B71B33A8 for ; Tue, 26 May 2015 18:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 h7jcNlXnBX2N for ; Tue, 26 May 2015 18:51:44 -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 7D79A1B3380 for ; Tue, 26 May 2015 18:51:44 -0700 (PDT) Received: by pabru16 with SMTP id ru16so106155689pab.1 for ; Tue, 26 May 2015 18:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6vsmwmkNq6SvKTKo63PCONih9jcOovjnYnFtA42poXU=; b=WIDSvU8vDKn2Z8rX13yY8npcbMMdHds3llcvb2lf4NTSwPqkn3oTRhJN28wbKzVvvb KZnRqK2AKXrXZfOxGO3CBAJE3dEIvXzB4eK+k3Rqz2MtLZCYfcIzvAYFpuPQAQHAz0FG OGptqmbcAh/XjWrmaYV/NScDuy3TR5pINIyUrB5k8CZKnXzB4aMvlN2g3XjcyA8WjX97 7NUNjBrKMWFVj/CE3APBZ6PKui7fQaqbw3Hb5NN+oI8y63rEK/u8h5UvjwjGHIRLP6Mv 12SaexOvhL5PxSpd9syNGeGQV/xxBg1HUs6SNg/xTG+ZZ3hPWE2p1q83whKnngAUxOFy uS8A== X-Received: by 10.68.131.225 with SMTP id op1mr53948177pbb.86.1432691504195; Tue, 26 May 2015 18:51:44 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id j7sm14302129pbq.35.2015.05.26.18.51.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 18:51:42 -0700 (PDT) Message-ID: <5565232E.6040008@gmail.com> Date: Wed, 27 May 2015 13:51:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , =?UTF-8?B?SsOpZmU=?= =?UTF-8?B?cnNvbiBDYW1wb3MgTm9icmU=?= References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB4B88@xmb-rcd-x14.cisco.com> <555E3B6C.5070306@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB82AE@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB82AE@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Sheng Jiang , Anima WG , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 27 May 2015 01:51:45 -0000 Back to this thread after a few days... On 26/05/2015 04:30, Michael Behringer (mbehring) wrote: >=20 >=20 >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 21 May 2015 22:09 >> To: Michael Behringer (mbehring); J=C3=A9ferson Campos Nobre >> Cc: John Strassner; Anima WG; Sheng Jiang >> Subject: Re: [Anima] Addressing ASAs or nodes? >> >> Hi Michael, >> On 21/05/2015 18:01, Michael Behringer (mbehring) wrote: >>>>>>> If we do our job in the ANI so nicely with security, people won't= >>>>>>> see a >>>> need for protocol specific security, such as SNMPv3. However, this >>>> will only happen if the ANI guarantees security. This is why I'm >>>> hesitant about "downgrading" security. >>>>>> >>>>>> Indeed. It would have to be very careful. One possible case would >>>>>> be if two operators wanted to allow AN across their mutual >>>>>> boundary, for a certain purpose only. >>>>> >>>>> I think this is the right approach: what are the cases for >>>>> "downgrading security"? I am also hesitant about this. >>>> >>>> In my example, ASA1 in ISP1 needs a 1:1 trust relationship with >>>> ASA2 in ISP2, and that is quite distinct from the mutual trust >>>> between all ASAs inside a single ISP. >>> >>> Brian, >>> >>> This is not too difficult, we can make this work quite easily. >>> - if two nodes are in the same domain, they use a default security mo= del >> (which I still insist should be high) >>> - if they are in different domains, two sub cases: >>> + common trust anchor (ie, sub-domains) >>> + no common trust anchor >>> >>> If no common trust anchor, they have to exchange root certs in some w= ay. >> Then, in all cases, the nodes can authenticate each other. >>> For authorization, in the two cases with different domains, intent sa= ys >> what to do. >>> >>> Concrete example: >>> Intent in SP 1: "Trust BGP speakers from SP 2 with root cert x for: B= GP >> authentication. No ACP, nothing else". >> >> I agree, conceptually it is very possible. Would you engineer this as = an >> extension to the ACP model?=20 >=20 > No. The ACP is only one way autonomic nodes interact. Inside a trusted = domain it's the default mode.=20 OK, so we could for example assume that two ASAs in different admin domai= ns could communicate 1:1 via TLS, using a public CA. We still need to see how authorization works in such a case. >=20 > Nodes negotiate something I would call "interaction schemata". This cou= ld be a collection of protocols and security mechanisms associated with a= type of "peering" between nodes. The simplest one is to bring up the ACP= =2E=20 >=20 > For example, an SP PE router could have a specific schema for that peer= ing type. It could bring up some default routing, secure it automatically= , possibly assign address space to the CE, etc.=20 >=20 > Intent says "with any node from domain x (say a customer), do: use auth= enticated OSPF, bring into VPN of , SLA tracking template ".= (note you need the trust anchor from for this to work).=20 >=20 >> How do you think the writer of an ASA would >> see this, a special security API? >=20 > An ASA needs to "understand" its role in the system, and be able to int= erpret intent. Likely, we'll provide the possibility to limit the capabil= ities of ASAs.=20 That can only be done by intent, I think, because that's supposed to be the only source of human input. Brian From nobody Fri May 29 06:59:37 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2331A9024 for ; Fri, 29 May 2015 06:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 lRzh5o--KXTU for ; Fri, 29 May 2015 06:59:35 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27301A901E for ; Fri, 29 May 2015 06:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2328; q=dns/txt; s=iport; t=1432907975; x=1434117575; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KC57RN8kNYv6y1d+pgwMxbVtpp1UvRo83vE1XjGI9XI=; b=WhgKygX6Gy5UlKqyWTH9BWI9vV6CCrY2gkBAIlnLBCRG06FHNnJXxizm H7R/iPfjUCGB5Cu22OaBZCbYGtIcA91m0rlVKOp9HbtVnjLxyqsw3GL7K qZwGyuKqBRJsX8WCkeZNT70NroDQ2L17daSUh2v5/AiNazghNvC4ZKKM8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A0BADIb2hV/49dJa1cgxCBOIMYuhtmCYdRAhyBKTgUAQEBAQEBAYEKhCIBAQEDASMRRRACAQgaAgYgAgICMBUQAgQBDQ2IHQiwfaQKAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiiKELicxB4JoL4EWAQSTCqJEI4IPF4FSgXNCgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,517,1427760000"; d="scan'208";a="154439978" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP; 29 May 2015 13:59:34 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t4TDxYmF013891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 13:59:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 29 May 2015 08:59:34 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= Thread-Topic: [Anima] Addressing ASAs or nodes? Thread-Index: AQHQjq0ekFbLEiZNXEqa5tLuw2MAT518pbqAgAAPtoCAAAGFAIACjo2AgAAT9ACAAZdggIAAwrpwgADYJYCAAFc9QIABMLIAgAAKQoCAAEQTAIAAy5nggAIM7ACABbQvsIAChyUAgAObX5A= Date: Fri, 29 May 2015 13:59:33 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FBE2C4@xmb-rcd-x14.cisco.com> References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB4B88@xmb-rcd-x14.cisco.com> <555E3B6C.5070306@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB82AE@xmb-rcd-x14.cisco.com> <5565232E.6040008@gmail.com> In-Reply-To: <5565232E.6040008@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Sheng Jiang , Anima WG , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 May 2015 13:59:36 -0000 PiA+IE5vLiBUaGUgQUNQIGlzIG9ubHkgb25lIHdheSBhdXRvbm9taWMgbm9kZXMgaW50ZXJhY3Qu IEluc2lkZSBhIHRydXN0ZWQNCj4gZG9tYWluIGl0J3MgdGhlIGRlZmF1bHQgbW9kZS4NCj4gDQo+ IE9LLCBzbyB3ZSBjb3VsZCBmb3IgZXhhbXBsZSBhc3N1bWUgdGhhdCB0d28gQVNBcyBpbiBkaWZm ZXJlbnQgYWRtaW4NCj4gZG9tYWlucyBjb3VsZCBjb21tdW5pY2F0ZSAxOjEgdmlhIFRMUywgdXNp bmcgYSBwdWJsaWMgQ0EuIFdlIHN0aWxsIG5lZWQgdG8NCj4gc2VlIGhvdyBhdXRob3JpemF0aW9u IHdvcmtzIGluIHN1Y2ggYSBjYXNlLg0KDQpZb3Ugc3RpbGwgdXNlIHRoZSBjZXJ0cywgYnV0IGlu IHRoaXMgY2FzZSB5b3UgbmVlZCB0byBoYXZlIHRoZSB0cnVzdCBhbmNob3Igb2YgdGhlIG90aGVy IGRvbWFpbi4gDQogDQo+ID4gTm9kZXMgbmVnb3RpYXRlIHNvbWV0aGluZyBJIHdvdWxkIGNhbGwg ImludGVyYWN0aW9uIHNjaGVtYXRhIi4gVGhpcyBjb3VsZA0KPiBiZSBhIGNvbGxlY3Rpb24gb2Yg cHJvdG9jb2xzIGFuZCBzZWN1cml0eSBtZWNoYW5pc21zIGFzc29jaWF0ZWQgd2l0aCBhIHR5cGUN Cj4gb2YgInBlZXJpbmciIGJldHdlZW4gbm9kZXMuIFRoZSBzaW1wbGVzdCBvbmUgaXMgdG8gYnJp bmcgdXAgdGhlIEFDUC4NCj4gPg0KPiA+IEZvciBleGFtcGxlLCBhbiBTUCBQRSByb3V0ZXIgY291 bGQgaGF2ZSBhIHNwZWNpZmljIHNjaGVtYSBmb3IgdGhhdCBwZWVyaW5nDQo+IHR5cGUuIEl0IGNv dWxkIGJyaW5nIHVwIHNvbWUgZGVmYXVsdCByb3V0aW5nLCBzZWN1cmUgaXQgYXV0b21hdGljYWxs eSwNCj4gcG9zc2libHkgYXNzaWduIGFkZHJlc3Mgc3BhY2UgdG8gdGhlIENFLCBldGMuDQo+ID4N Cj4gPiBJbnRlbnQgc2F5cyAid2l0aCBhbnkgbm9kZSBmcm9tIGRvbWFpbiB4IChzYXkgYSBjdXN0 b21lciksIGRvOiB1c2UNCj4gYXV0aGVudGljYXRlZCBPU1BGLCBicmluZyBpbnRvIFZQTiBvZiA8 Y3VzdG9tZXI+LCBTTEEgdHJhY2tpbmcgdGVtcGxhdGUNCj4gPHg+Ii4gIChub3RlIHlvdSBuZWVk IHRoZSB0cnVzdCBhbmNob3IgZnJvbSA8Y3VzdG9tZXI+IGZvciB0aGlzIHRvIHdvcmspLg0KPiA+ DQo+ID4+IEhvdyBkbyB5b3UgdGhpbmsgdGhlIHdyaXRlciBvZiBhbiBBU0Egd291bGQgc2VlIHRo aXMsIGEgc3BlY2lhbA0KPiA+PiBzZWN1cml0eSBBUEk/DQo+ID4NCj4gPiBBbiBBU0EgbmVlZHMg dG8gInVuZGVyc3RhbmQiIGl0cyByb2xlIGluIHRoZSBzeXN0ZW0sIGFuZCBiZSBhYmxlIHRvDQo+ IGludGVycHJldCBpbnRlbnQuIExpa2VseSwgd2UnbGwgcHJvdmlkZSB0aGUgcG9zc2liaWxpdHkg dG8gbGltaXQgdGhlIGNhcGFiaWxpdGllcw0KPiBvZiBBU0FzLg0KPiANCj4gVGhhdCBjYW4gb25s eSBiZSBkb25lIGJ5IGludGVudCwgSSB0aGluaywgYmVjYXVzZSB0aGF0J3Mgc3VwcG9zZWQgdG8g YmUgdGhlDQo+IG9ubHkgc291cmNlIG9mIGh1bWFuIGlucHV0Lg0KDQpUaGUgbm9kZSAqa25vd3Mq IGl0J3MgYW4gZUJHUCBzcGVha2VyLCBwZWVyaW5nIHdpdGggQVMgeC4gVGhpcyBpcyBzZWxmLWtu b3dsZWRnZS4gSW50ZW50IHdpbGwgc2F5ICJhbnlvbmUgcGVlcmluZyB3aXRoIEFTIHg6IGF1dGhl bnRpY2F0ZSBCR1AgYXV0b25vbWljYWxseSIuICBJIGd1ZXNzIHRoaXMgaXMgd2hhdCB5b3UgbWVh bnQsIGp1c3QgdG8gYmUgMTAwJSBjbGVhci4gOi0pIA0KDQpNaWNoYWVsDQoNCg== From nobody Fri May 29 13:04:26 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97261A711A for ; Fri, 29 May 2015 13:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 KRAhACw19AtE for ; Fri, 29 May 2015 13:04:25 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43E51A702C for ; Fri, 29 May 2015 13:04:24 -0700 (PDT) Received: by pacrp13 with SMTP id rp13so21046270pac.2 for ; Fri, 29 May 2015 13:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=68lgQQ7tMDSKBoUhm8c5aU9zZo75UYupzMGrf39Vmog=; b=ks3CxKGWaXpJZMmNLxob7Za68HJyXP2m1ltYszA2zKsfB8zwrcQMB9uC6jWfu7a3d7 1aITfqSkhztjM43Rw98xmNeIg0JEhRD/D67+9CLLEUTRYweCW6VimIsRZezZoh9YFYct k/f/WU7/b47UdoRI62EyFTUi9B2ZBlhar0ywy8BWNyibs4CxGa3uLeuHI0yzn6wScw7K hV53LZGX4SCyyZpKAe+7DqD9nKMWscE744QEJEEx+HwXDjcrtz7W4VtD43HGAt4yHwiZ TPS7IoPXNsdzylkIjD3r6NQoHAfIq4Gv4kPU4rxWvDlEFhKN8794ooSbD4KK4j8+bUBC FVtA== X-Received: by 10.68.195.2 with SMTP id ia2mr17894951pbc.33.1432929864499; Fri, 29 May 2015 13:04:24 -0700 (PDT) Received: from ?IPv6:2406:e007:751b:1:28cc:dc4c:9703:6781? ([2406:e007:751b:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id fi10sm6457825pac.35.2015.05.29.13.04.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2015 13:04:23 -0700 (PDT) Message-ID: <5568C64A.1000705@gmail.com> Date: Sat, 30 May 2015 08:04:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , =?UTF-8?B?SsOpZmU=?= =?UTF-8?B?cnNvbiBDYW1wb3MgTm9icmU=?= References: <5555497F.3070700@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50D844@nkgeml512-mbx.china.huawei.com> <5555699A.9010605@gmail.com> <55579F6A.9030802@gmail.com> <5558F525.4060000@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB06B7@xmb-rcd-x14.cisco.com> <555A4DCF.8060100@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB1F43@xmb-rcd-x14.cisco.com> <555B9696.7070002@gmail.com> <555BD84C.2090406@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB4B88@xmb-rcd-x14.cisco.com> <555E3B6C.5070306@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FB82AE@xmb-rcd-x14.cisco.com> <5565232E.6040008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FBE2C4@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FBE2C4@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Sheng Jiang , Anima WG , John Strassner Subject: Re: [Anima] Addressing ASAs or nodes? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 May 2015 20:04:26 -0000 On 30/05/2015 01:59, Michael Behringer (mbehring) wrote: >>> No. The ACP is only one way autonomic nodes interact. Inside a trusted >> domain it's the default mode. >> >> OK, so we could for example assume that two ASAs in different admin >> domains could communicate 1:1 via TLS, using a public CA. We still need to >> see how authorization works in such a case. > > You still use the certs, but in this case you need to have the trust anchor of the other domain. > >>> Nodes negotiate something I would call "interaction schemata". This could >> be a collection of protocols and security mechanisms associated with a type >> of "peering" between nodes. The simplest one is to bring up the ACP. >>> >>> For example, an SP PE router could have a specific schema for that peering >> type. It could bring up some default routing, secure it automatically, >> possibly assign address space to the CE, etc. >>> >>> Intent says "with any node from domain x (say a customer), do: use >> authenticated OSPF, bring into VPN of , SLA tracking template >> ". (note you need the trust anchor from for this to work). >>> >>>> How do you think the writer of an ASA would see this, a special >>>> security API? >>> >>> An ASA needs to "understand" its role in the system, and be able to >> interpret intent. Likely, we'll provide the possibility to limit the capabilities >> of ASAs. >> >> That can only be done by intent, I think, because that's supposed to be the >> only source of human input. > > The node *knows* it's an eBGP speaker, peering with AS x. This is self-knowledge. Intent will say "anyone peering with AS x: authenticate BGP autonomically". I guess this is what you meant, just to be 100% clear. :-) Yes, exactly. (The intent "language" will need to be pretty flexible, I can see.) Brian