From nobody Mon Dec 1 05:46:26 2014 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 D4EFB1A1BC2 for ; Mon, 1 Dec 2014 05:46:24 -0800 (PST) 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 BAGweqXYbgaE for ; Mon, 1 Dec 2014 05:46:19 -0800 (PST) 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 72F711A1BBF for ; Mon, 1 Dec 2014 05:46:19 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A55220012 for ; Mon, 1 Dec 2014 08:49:31 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 43538637F5; Mon, 1 Dec 2014 08:46:18 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2A19F637F4 for ; Mon, 1 Dec 2014 08:46:18 -0500 (EST) From: Michael Richardson To: anima In-Reply-To: <547BC1C3.2010704@gmail.com> References: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> <547A16A2.9030904@gmail.com> <26092.1417370244@sandelman.ca> <547B6B1D.9090003@gmail.com> <25412.1417388863@sandelman.ca> <547BC1C3.2010704@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/anima/KFcuLlM2BZFHYHXa3yJWmacRaHY Subject: Re: [Anima] eckert-anima-stable-connectivity 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, 01 Dec 2014 13:46:25 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> (I will claim: more than you many people), but I do not think the u= pper >> 64-bits of an address can be private. Remember: the traffic isn't = going >> anywhere: BCP38 filtering at some point will kill it outbound, and t= here can >> never be any inbound traffic responding.=20=20 > Exactly, and site egresses should stop it even before it hits any BCP= 38 filters. > So I have never had any real level of concern about ULA leakage; I do= n't > really see why it's going to happen more than say Net 10 leakage does > today. I agree that it's on the same scale as net 10 leakage, but I expect it to be slightly worse scale if systems are auto-generating ULAs a lot.=20=20=20 net 10 leakage is already a big deal in some places: IPv6 ULAs have the advantage that when that winXP box bridges two "net 10" zones unintentional= ly, the odds of overlap are very low. This kind of event seems to happen essen= tially daily on the university campus where the CREDIL office lives...=20 >> A BCP38-related question about Anima Control Plane would be: what ki= nd of >> filtering is appropriate. Consider two networks which merge... does= one >> renumber?=20 > Yes, both splits and merges are an issue. In the "professionally mana= ged" > networks that anima is scoped for, hopefully there will not be unplan= ned > merges, but we do need to consider these issues. I'm thinking about an ISP who connects to IXs. The actual hour/minute when the fiber gets plugged in is often not known. If ANIMA is going to be able to manage equipment at the far end of one of those links, my understanding = is that the ACP network might come "up" even when the link is administratively "down". In ISP networks I'm familiar with, IX connects/disconnects/fiber-moves occur several times a week. >> I propose that we adopt some terminology from chemistry for our netw= orks. >>=20 >> Individual ANIMA entites are atoms... they can form bonds to other a= toms to >> form molecules. Molecules may coalese to form bigger molecules. >>=20 >> A molecule (can become)/is "grounded" (a RPL term) to a substrate >> (i.e. a NOC). We may have a use for the various kinds of bonds (co= valent, >> ionic, hydrogen, van-der-Walls)... I would claim that molecules th= at >> spontaneously form should use ULA-R until such time as they become g= rounded, >> at which point they would adopt the numbering from the NOC (which I = suggest >> should be NCN or ULA-C).=20=20 > But there's no such thing as ULA-C. Also, the way enterprise networks > are extended is a bit different from IoT or homenets in this respect.= I think > the model needs to be flexible on what kind of prefix is used. I do a= gree > with your implication that renumbering of the ACP needs to be regarded > as a routine event (e.g., assume renumbering might happen after every > significant outage and again after the outage is fixed). Node identit= ies > should matter a lot more than node addresses. a) I think that perhaps defining ULA-C could be in scope.=20=20 (If we are using RPL with /128 routes, we might need a single /64 for th= e ACP) I really want a stable, identifiable numbering space for the ACP, and I really think it should be distinct from the enterprise/ISP 's GUA.=20=20 Being distinct just makes ACLs, etc. SO MUCH easier for humans to unders= tand. b) what do you think of the atom/molecule and bond terminology? c) I don't think renumbering might occur due to outages; I think that is probably wrong. Okay, the machine that was off might generate a new ULA when it turns back on and hasn't got connectivity... but I'm suggesting that it would renumber again as soon as it forms a bond. Since the NOC would never renumber, once things connect to the NOC, the original numbering would resume. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVHxxJ4CLcPvd0N1lAQIWcQf/SCWcNEAIQeMaFSuHX/7HFkmnWz2Uco3U r1Qne9x2Ie2TJ7iECVz0G/NGcurjwsqbI28zO4/IvO+2O3hUKv0KPL5x4K5a3g9p 07Y3V08XAStaISuS1FiF/LJy98rvlouR0zoqf5PWChoACa4tKVAYQgrnEsDTZgzY YYUEvH82Jl/M1ZUJE/CW5ZOjANoeGUj0HMnmM6midf787Qxq14lhKSZN4sOxLvIE 4a6R0OQzpBNc/yn7L7uQ4jtesjzZpNMRREzdEYH27N3hq+WCImDRCASU1Y7WC70R sR+wBs4BsRZIuZ6S7bQu0Ezkg1t2EJj9XFa0ofJfX5LRolrxngrHnQ== =nUpM -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 1 11:32:50 2014 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 1574B1A8A25 for ; Mon, 1 Dec 2014 11:32:47 -0800 (PST) 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 LNSTHblHs2nN for ; Mon, 1 Dec 2014 11:32:45 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674191A8A86 for ; Mon, 1 Dec 2014 11:31:29 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id w10so11388753pde.24 for ; Mon, 01 Dec 2014 11:31:28 -0800 (PST) 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=Df+Z8OQS8EKyMUblPj5sM+lY+h6HgXdOzxAj2KaF0o0=; b=sWS4nL8Ey6CRTDTRLiXLMqU1qaguR/yZESDvfMk3EYdjDTDWE4CtNAvd5EZUs6dDPN 9C30yUxERhuN1ClJHsck/H9e6iuBIAf2dkwF7IOfhBGcU5fA1a/nOkQZ8LxkzciMm1oU 5RvInJgEGOK7vG4GaYpoGVzu8fBkQXxyJOoMudAkJQtutHQOlpdNsUr+9DXYkfN1nsNX sj1yNWe1EjV4Uhg3jfkeiCnZTAjg04pkveyaMdlpMBimqsDElFrg4z1ukz58lrNxbykI nl+Y9ReR6o//8uNPeMoFfZE4DE0Fprpu0qQbK2zPyeBb99PjSR29G2C3YZ4R0FfYVgX3 rC7g== X-Received: by 10.66.242.1 with SMTP id wm1mr34543857pac.18.1417462288559; Mon, 01 Dec 2014 11:31:28 -0800 (PST) Received: from [192.168.178.26] (225.197.69.111.dynamic.snap.net.nz. [111.69.197.225]) by mx.google.com with ESMTPSA id wf5sm13098163pab.40.2014.12.01.11.31.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 11:31:27 -0800 (PST) Message-ID: <547CC20E.7080100@gmail.com> Date: Tue, 02 Dec 2014 08:31:26 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> <547A16A2.9030904@gmail.com> <26092.1417370244@sandelman.ca> <547B6B1D.9090003@gmail.com> <25412.1417388863@sandelman.ca> <547BC1C3.2010704@gmail.com> <11068.1417441578@sandelman.ca> In-Reply-To: <11068.1417441578@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/qUCM35PTLHbnj4E-Xp5eB6NlVKI Cc: anima Subject: Re: [Anima] eckert-anima-stable-connectivity 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, 01 Dec 2014 19:32:47 -0000 Hi Michael, On 02/12/2014 02:46, Michael Richardson wrote: > Brian E Carpenter wrote: > >> (I will claim: more than you many people), but I do not think the upper > >> 64-bits of an address can be private. Remember: the traffic isn't going > >> anywhere: BCP38 filtering at some point will kill it outbound, and there can > >> never be any inbound traffic responding. > > > Exactly, and site egresses should stop it even before it hits any BCP38 filters. > > So I have never had any real level of concern about ULA leakage; I don't > > really see why it's going to happen more than say Net 10 leakage does > > today. > > I agree that it's on the same scale as net 10 leakage, but I expect it to be > slightly worse scale if systems are auto-generating ULAs a lot. > > net 10 leakage is already a big deal in some places: IPv6 ULAs have the > advantage that when that winXP box bridges two "net 10" zones unintentionally, > the odds of overlap are very low. This kind of event seems to happen essentially > daily on the university campus where the CREDIL office lives... > > >> A BCP38-related question about Anima Control Plane would be: what kind of > >> filtering is appropriate. Consider two networks which merge... does one > >> renumber? > > > Yes, both splits and merges are an issue. In the "professionally managed" > > networks that anima is scoped for, hopefully there will not be unplanned > > merges, but we do need to consider these issues. > > I'm thinking about an ISP who connects to IXs. The actual hour/minute when > the fiber gets plugged in is often not known. If ANIMA is going to be able > to manage equipment at the far end of one of those links, my understanding is > that the ACP network might come "up" even when the link is administratively > "down". > In ISP networks I'm familiar with, IX connects/disconnects/fiber-moves occur > several times a week. That's an interesting use case, indeed. I assume the ISP's device would have a secure identity (as far as the ISP is concerned), but would it come up with a link local address first? If so, it would need to be bootstrapped into the ACP using that address. > > >> I propose that we adopt some terminology from chemistry for our networks. > >> > >> Individual ANIMA entites are atoms... they can form bonds to other atoms to > >> form molecules. Molecules may coalese to form bigger molecules. > >> > >> A molecule (can become)/is "grounded" (a RPL term) to a substrate > >> (i.e. a NOC). We may have a use for the various kinds of bonds (covalent, > >> ionic, hydrogen, van-der-Walls)... I would claim that molecules that > >> spontaneously form should use ULA-R until such time as they become grounded, > >> at which point they would adopt the numbering from the NOC (which I suggest > >> should be NCN or ULA-C). > > > But there's no such thing as ULA-C. Also, the way enterprise networks > > are extended is a bit different from IoT or homenets in this respect. I think > > the model needs to be flexible on what kind of prefix is used. I do agree > > with your implication that renumbering of the ACP needs to be regarded > > as a routine event (e.g., assume renumbering might happen after every > > significant outage and again after the outage is fixed). Node identities > > should matter a lot more than node addresses. > > a) I think that perhaps defining ULA-C could be in scope. > (If we are using RPL with /128 routes, we might need a single /64 for the ACP) > I really want a stable, identifiable numbering space for the ACP, and I > really think it should be distinct from the enterprise/ISP 's GUA. > Being distinct just makes ACLs, etc. SO MUCH easier for humans to understand. Well yes. But you haven't persuaded me about ULA-C. > b) what do you think of the atom/molecule and bond terminology? It's a nice analogy. Whether we actually need the terminology is a bit less clear to me. Maybe the ACP/stable connectivity authors have an opinion... > > c) I don't think renumbering might occur due to outages; I think that is > probably wrong. Okay, the machine that was off might generate a new ULA > when it turns back on and hasn't got connectivity... but I'm suggesting > that it would renumber again as soon as it forms a bond. Since the NOC > would never renumber, once things connect to the NOC, the original > numbering would resume. You could make it a matter of definition that the NOC never renumbers, but after a power fail, every device that lost all its state will be effectively renumbered anyway. I think that's why Fred Baker says from time to time that the real problem is numbering, not re-numbering. But you're right, if there is a regional failure, the region will probably reboot itself until it succeeds in rejoining the ACP and NOC, and will then have to renumber. Brian From nobody Mon Dec 1 14:23:17 2014 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 8F65A1AC528 for ; Mon, 1 Dec 2014 14:23:15 -0800 (PST) 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 oHC0gEaxrwdo for ; Mon, 1 Dec 2014 14:23:13 -0800 (PST) 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 65E4D1AC82C for ; Mon, 1 Dec 2014 14:23:13 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 67F732002A; Mon, 1 Dec 2014 17:26:26 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1B805637F5; Mon, 1 Dec 2014 17:23:12 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0751D637EA; Mon, 1 Dec 2014 17:23:12 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <547CC20E.7080100@gmail.com> References: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> <547A16A2.9030904@gmail.com> <26092.1417370244@sandelman.ca> <547B6B1D.9090003@gmail.com> <25412.1417388863@sandelman.ca> <547BC1C3.2010704@gmail.com> <11068.1417441578@sandelman.ca> <547CC20E.7080100@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/anima/R63YRApE8env5LXjf3WdcnlvyeA Cc: anima Subject: Re: [Anima] eckert-anima-stable-connectivity 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, 01 Dec 2014 22:23:15 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> I'm thinking about an ISP who connects to IXs. The actual hour/minu= te when >> the fiber gets plugged in is often not known. If ANIMA is going to = be able >> to manage equipment at the far end of one of those links, my underst= anding is >> that the ACP network might come "up" even when the link is administr= atively >> "down". >> In ISP networks I'm familiar with, IX connects/disconnects/fiber-mov= es occur >> several times a week. > That's an interesting use case, indeed. I assume the ISP's device wou= ld > have a secure identity (as far as the ISP is concerned), but would it= come > up with a link local address first? If so, it would need to be bootst= rapped > into the ACP using that address. (Just be clear: a single fiber doesn't move several times a week, I'm saying that some fiber in some IX goes up/down each time. Perhaps root operators have more connects/disconnects than others though) The ISP's device might already be secure and connected via another path, and so yet, it would already have a local identity. Or it could be a totally fresh device just shipped from the factory. And also remember that in these days of SDN, it isn't brand-name dedicated router equipment that does routing.. the target device could be a 1U box with an ILOM... >> a) I think that perhaps defining ULA-C could be in scope.=20=20 >> (If we are using RPL with /128 routes, we might need a single /64 fo= r the ACP) >> I really want a stable, identifiable numbering space for the ACP, an= d I >> really think it should be distinct from the enterprise/ISP 's GUA.= =20=20 >> Being distinct just makes ACLs, etc. SO MUCH easier for humans to un= derstand. > Well yes. But you haven't persuaded me about ULA-C. It's not ULA-C per-se, that I care about.=20=20 (Vixie has a draft, long expired) It's using a /64 which is not part of the enterprise GUA that I care about. Do we agree on that? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVHzqTICLcPvd0N1lAQKgJwf/eVYtJdhF6ZUqcJuxaJY/u6GJvy2A32Rj pHy/F8eC3bkKn9GzRnt+idd+Yi4yInKDXqaShD9X6U/4rngAziPlOzdwFehbBKYP 40LDoQzBEzslJTi8U+x5M+JRaXrOXU8UrzoK7SKd+9TmzZS0uoUZMc/64a1rWDvb biW8qJH3eHLM0T10gtDDoxsZAubepoyy3qq5wmlUM7Wu8RUn7ditbAXLO62x3A6a vCk+ciHiGmHPAFxVEtfGTKoclF8XFx5kI7tw0FnIbEtmNKTn9Nbb6+jJZZnKGhxn hTpAqgA6f1gClfeMfWJuPElaDqt2PP3gnDUS2lmcODqk9+hZC0M2lA== =GRv+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 1 14:34:06 2014 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 F26361ACD4E for ; Mon, 1 Dec 2014 14:34:02 -0800 (PST) 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 ydyrhpDUZrcB for ; Mon, 1 Dec 2014 14:34:01 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176A71ACD4C for ; Mon, 1 Dec 2014 14:34:01 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id et14so11996878pad.31 for ; Mon, 01 Dec 2014 14:34:00 -0800 (PST) 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=B5C1zGzZuLLMc7DX1joegS9vW3obt2IntLdn1456Krs=; b=xF6k592CRB1LOG26mAGIDX4QiwQERCf3J2c7URWtO4Bej+S18i4SPxridN1hIq1mHZ JN+Rsx6RR8la6nnF9vVJtknC1+hNGWbIl7+181YKOp8erkqapY27BoNzeE8X9IM16ogd mBKoP69BHGqHEigUgCHjdbC4RphVK2mcqZimRTtx7KffiDTQvKe5sY99UW4KVEXe7E6V PLwdpCUPKcZC9PWeLiyT87HDXklKAAGbPNL4Dna9gwRom0qa9dxkDv3glxY8E1SHX+l0 sewCfEwvvhnO/hkUzPiQbDHYaE67tfZ0HMTISdO8lJiRGD/HIfViRwFFbSkDTs2ujTsV FTDw== X-Received: by 10.68.227.104 with SMTP id rz8mr253051pbc.4.1417473240305; Mon, 01 Dec 2014 14:34:00 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id 1sm18456844pdw.87.2014.12.01.14.33.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 14:33:59 -0800 (PST) Message-ID: <547CECD7.2090507@gmail.com> Date: Tue, 02 Dec 2014 11:33:59 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> <547A16A2.9030904@gmail.com> <26092.1417370244@sandelman.ca> <547B6B1D.9090003@gmail.com> <25412.1417388863@sandelman.ca> <547BC1C3.2010704@gmail.com> <11068.1417441578@sandelman.ca> <547CC20E.7080100@gmail.com> <19248.1417472592@sandelman.ca> In-Reply-To: <19248.1417472592@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/qKXd-orxUSEYCt3jMxli2pzvH8o Cc: anima Subject: Re: [Anima] eckert-anima-stable-connectivity 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, 01 Dec 2014 22:34:03 -0000 On 02/12/2014 11:23, Michael Richardson wrote: > Brian E Carpenter wrote: > >> I'm thinking about an ISP who connects to IXs. The actual hour/minute when > >> the fiber gets plugged in is often not known. If ANIMA is going to be able > >> to manage equipment at the far end of one of those links, my understanding is > >> that the ACP network might come "up" even when the link is administratively > >> "down". > >> In ISP networks I'm familiar with, IX connects/disconnects/fiber-moves occur > >> several times a week. > > > That's an interesting use case, indeed. I assume the ISP's device would > > have a secure identity (as far as the ISP is concerned), but would it come > > up with a link local address first? If so, it would need to be bootstrapped > > into the ACP using that address. > > (Just be clear: a single fiber doesn't move several times a week, I'm saying > that some fiber in some IX goes up/down each time. Perhaps root operators > have more connects/disconnects than others though) > > The ISP's device might already be secure and connected via another path, and > so yet, it would already have a local identity. Or it could be a totally > fresh device just shipped from the factory. And also remember that in these > days of SDN, it isn't brand-name dedicated router equipment that does > routing.. the target device could be a 1U box with an ILOM... Of course. But in any case, the question of how a new box gets its secure identity is a separate one that may turn out to have several solutions. (Not so different from the problem of how software SIMs will become trusted.) > >> a) I think that perhaps defining ULA-C could be in scope. > >> (If we are using RPL with /128 routes, we might need a single /64 for the ACP) > >> I really want a stable, identifiable numbering space for the ACP, and I > >> really think it should be distinct from the enterprise/ISP 's GUA. > >> Being distinct just makes ACLs, etc. SO MUCH easier for humans to understand. > > > Well yes. But you haven't persuaded me about ULA-C. > > It's not ULA-C per-se, that I care about. > (Vixie has a draft, long expired) > It's using a /64 which is not part of the enterprise GUA that I care about. > > Do we agree on that? I think that would be what I would choose to do, but I'm not convinced we need to make it a MUST. Brian From nobody Fri Dec 5 07:30:47 2014 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 812A91ACEB7 for ; Fri, 5 Dec 2014 07:30:45 -0800 (PST) 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 3NPcIEXz-ZiK for ; Fri, 5 Dec 2014 07:30:44 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210191ACE9C for ; Fri, 5 Dec 2014 07:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=324; q=dns/txt; s=iport; t=1417793444; x=1419003044; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=PlXX+6X4wjunSAZ8Ce5Gw5UlwuDqHufGvo/dtszeGQM=; b=HNFoJQ+vrt9l0T4BWey/k/FVGikNrxwsGyWqDZ5kUZM+Hn5/AkgIT8lu uoChCMFN1fdMiYMFEf+kUNdSx5NfQJ3Nex4z0E6h6yDNjVpaPF7+zdcwc rt7AsrwsonTr1LqMkY5LtWIg+aOUg+P2eEAmjyIt3sNNdULmFcIX4Hn5r w=; X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="257776792" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 05 Dec 2014 15:30:42 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB5FUgWE001049; Fri, 5 Dec 2014 15:30:42 GMT Message-ID: <5481CFA2.1060408@cisco.com> Date: Fri, 05 Dec 2014 16:30:42 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "anima@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/aRuxM53Qy1KgsK6zBSdG_uYolsc Cc: Nancy Cam-Winget , "" Subject: [Anima] Nancy Cam-Winget as Security Advisor 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, 05 Dec 2014 15:30:45 -0000 Dear all, There is, in ANIMA, an important security component. In coordination with the security ADs, we would like to introduce Nancy Cam-Winget as your ANIMA security advisor. Nancy will make sure (along with the rest of the community), that the ANIMA security aspects are correctly covered. Regards, Benoit From nobody Sat Dec 6 09:08:30 2014 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 808A91A1B34 for ; Sat, 6 Dec 2014 09:08:29 -0800 (PST) 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 vD2TyA34Vvyb for ; Sat, 6 Dec 2014 09:08:28 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA3E1A0183 for ; Sat, 6 Dec 2014 09:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=682; q=dns/txt; s=iport; t=1417885708; x=1419095308; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=tXTVz4M5T/mwqoq5OZYCjRyFsRhWAPX4kpp6JaTTXwM=; b=VdsdVDTIJilMctFpq29izDUasQjCAcYi9FVSV0kuZF1cTZ5SILebNGML puJlB0gpvcEiR7NahOOKV3WAggipUcV0UbOsGWUny6ddepAgCy/IvMQi3 ctDssudvwS3oXs9KunCsFCmu9H5X1xnDDCWZyKUushmzhIShvgwVCk9su Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAM42g1StJA2L/2dsb2JhbABZgmQigSoExDOIOQKBEhYBAQEBAX2EAwIEeRIBCHglAgQBDQUUiCcB1FYBAQEBAQEBAQEBAQEBAQEBAQEBGZBPB4Q2AQSPRooZgSKDEoJgiEmDYoNvb4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,529,1413244800"; d="scan'208";a="378079973" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP; 06 Dec 2014 17:08:27 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB6H8R37009568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Dec 2014 17:08:27 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Sat, 6 Dec 2014 11:08:27 -0600 From: "Nancy Cam-Winget (ncamwing)" To: "Benoit Claise (bclaise)" , "anima@ietf.org" Thread-Topic: Nancy Cam-Winget as Security Advisor Thread-Index: AQHQEKBvqJhpm+DgTUqx4mY+ljHNSZyCq7aA Date: Sat, 6 Dec 2014 17:08:26 +0000 Message-ID: In-Reply-To: <5481CFA2.1060408@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.100.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8360C85521B1CA4199AA042143F62648@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/vzDVfGTCkd1c2u5VQ1ujGmHcrx0 Cc: "" Subject: Re: [Anima] Nancy Cam-Winget as Security Advisor 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, 06 Dec 2014 17:08:29 -0000 Thanks Benoit=8A..I=B9m looking forward to helping the group. I=B9ll read the drafts and charter more thoroughly and provide comments and feed back. If there are particular areas of concern that I should review more closely, do please let me know. Regards, Nancy On 12/5/14, 7:30 AM, "Benoit Claise (bclaise)" wrote: >Dear all, > >There is, in ANIMA, an important security component. >In coordination with the security ADs, we would like to introduce Nancy >Cam-Winget as your ANIMA security advisor. Nancy will make sure (along >with the rest of the community), that the ANIMA security aspects are >correctly covered. > >Regards, Benoit From nobody Sun Dec 7 17:44:17 2014 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 424F31A1B40 for ; Sun, 7 Dec 2014 17:44:15 -0800 (PST) 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 xFnaqrbcbUkL for ; Sun, 7 Dec 2014 17:44:14 -0800 (PST) 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 6A72A1A1B42 for ; Sun, 7 Dec 2014 17:44:13 -0800 (PST) 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 BMO59290; Mon, 08 Dec 2014 01:44:12 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 8 Dec 2014 01:44:11 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 8 Dec 2014 09:44:01 +0800 From: Sheng Jiang To: Benoit Claise , "anima@ietf.org" Thread-Topic: [Anima] Nancy Cam-Winget as Security Advisor Thread-Index: AQHQEKB0+VPopQtMcEOSRVdoDHw3DZyE597Q Date: Mon, 8 Dec 2014 01:44:00 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AFDA398@nkgeml512-mbx.china.huawei.com> References: <5481CFA2.1060408@cisco.com> In-Reply-To: <5481CFA2.1060408@cisco.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.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/VINBt2LfTY2rZCykhbo71GPXEvo Cc: Nancy Cam-Winget , "" Subject: Re: [Anima] Nancy Cam-Winget as Security Advisor 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, 08 Dec 2014 01:44:15 -0000 VGhhbmtzIEJlbm9pdCBmb3IgdGhpcyBhcnJhbmdlbWVudC4gU2VjdXJpdHkgaXMgYW4gaW1wb3J0 YW50IHByZWNvbmRpdGlvbiBhbmQgY29tcG9uZW50IGZvciB0aGUgQXV0b25vbWljIE5ldHdvcmsu IFRoZSBBdXRvbm9taWMgTmV0d29yayBzaG91bGQgaGF2ZSBtdWNoIGhpZ2hlciBzZWN1cml0eSBi YXIgdGhhbiBhbnkgb3RoZXIgc29sdXRpb24vcHJvdG9jb2wsIEJlY2F1c2UgQU4gbm9kZXMgd291 bGQgaGF2ZSBtdWNoIG1vcmUgY29udHJvbCBwb3dlciB0aGFuIHRyYWRpdGlvbmFsIG5vZGVzLCBh biBhdHRhY2tlciB3aG8gbWFuYWdlZCB0byBicm9rZSBpbiBjb3VsZCBtYWtlIG11Y2ggYmlnZ2Vy IGRhbWFnZS4NCg0KVGhhbmtzIGFuZCB3ZWxjb21lIHRvIE5hbmN5LiBXaXRoIHlvdXIgaGVscCwg d2UgY291bGQgbWFrZSBBTklNQSBzZWN1cml0eSBhc3BlY3RzIGNvcnJlY3QuDQoNCkJlc3QgcmVn YXJkcywNCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQW5p bWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVub2l0IENs YWlzZQ0KPlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgMTE6MzEgUE0NCj5UbzogYW5p bWFAaWV0Zi5vcmcNCj5DYzogTmFuY3kgQ2FtLVdpbmdldDsgPHNlYy1hZHNAdG9vbHMuaWV0Zi5v cmc+DQo+U3ViamVjdDogW0FuaW1hXSBOYW5jeSBDYW0tV2luZ2V0IGFzIFNlY3VyaXR5IEFkdmlz b3INCj4NCj5EZWFyIGFsbCwNCj4NCj5UaGVyZSBpcywgaW4gQU5JTUEsIGFuIGltcG9ydGFudCBz ZWN1cml0eSBjb21wb25lbnQuDQo+SW4gY29vcmRpbmF0aW9uIHdpdGggdGhlIHNlY3VyaXR5IEFE cywgd2Ugd291bGQgbGlrZSB0byBpbnRyb2R1Y2UgTmFuY3kNCj5DYW0tV2luZ2V0IGFzIHlvdXIg QU5JTUEgc2VjdXJpdHkgYWR2aXNvci4gTmFuY3kgd2lsbCBtYWtlIHN1cmUgKGFsb25nDQo+d2l0 aCB0aGUgcmVzdCBvZiB0aGUgY29tbXVuaXR5KSwgdGhhdCB0aGUgQU5JTUEgc2VjdXJpdHkgYXNw ZWN0cyBhcmUNCj5jb3JyZWN0bHkgY292ZXJlZC4NCj4NCj5SZWdhcmRzLCBCZW5vaXQNCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkFuaW1hIG1h aWxpbmcgbGlzdA0KPkFuaW1hQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hbmltYQ0K From nobody Mon Dec 8 00:16:38 2014 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 9BB921A7012 for ; Mon, 8 Dec 2014 00:16:30 -0800 (PST) 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 iohPaTxbcINY for ; Mon, 8 Dec 2014 00:16:28 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801641A1ADB for ; Mon, 8 Dec 2014 00:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1621; q=dns/txt; s=iport; t=1418026586; x=1419236186; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=m7ff7GkuD0vEBMlvi8k4PSTYlanv7kxnnJ/morlmzCc=; b=ZoRmIa0NGkNrxJds+luKfiLZFG1A012Vdc1Ms+Kk4lh9ybDjEmQclPdR B3NgxZ1Lc6uRQnh4BDQYBakq8CYev8J9jQbyzbEZiAhUR1NQL4MKh6+3V a+tqUGTvsapn80EM3VVMxsa1ktvl5fJ8MMRR264SANAhvW9iROHfMF7jt Y=; X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="261286161" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Dec 2014 08:16:24 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB88GOpp026737; Mon, 8 Dec 2014 08:16:24 GMT Message-ID: <54855E58.2000203@cisco.com> Date: Mon, 08 Dec 2014 09:16:24 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Sheng Jiang , "anima@ietf.org" References: <5481CFA2.1060408@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AFDA398@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AFDA398@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/BAexEXe-_OyAZAyTSAKgd3EpewY Cc: Nancy Cam-Winget , "" Subject: Re: [Anima] Nancy Cam-Winget as Security Advisor 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, 08 Dec 2014 08:16:30 -0000 On 08/12/2014 02:44, Sheng Jiang wrote: > Thanks Benoit for this arrangement. To be candid, I haven't done much except requesting a tech advisor from the Security ADs. And they selected Nancy to help us. Thanks for that. Regards, Benoit > Security is an important precondition and component for the Autonomic Network. The Autonomic Network should have much higher security bar than any other solution/protocol, Because AN nodes would have much more control power than traditional nodes, an attacker who managed to broke in could make much bigger damage. > > Thanks and welcome to Nancy. With your help, we could make ANIMA security aspects correct. > > Best regards, > > Sheng > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Benoit Claise >> Sent: Friday, December 05, 2014 11:31 PM >> To: anima@ietf.org >> Cc: Nancy Cam-Winget; >> Subject: [Anima] Nancy Cam-Winget as Security Advisor >> >> Dear all, >> >> There is, in ANIMA, an important security component. >> In coordination with the security ADs, we would like to introduce Nancy >> Cam-Winget as your ANIMA security advisor. Nancy will make sure (along >> with the rest of the community), that the ANIMA security aspects are >> correctly covered. >> >> Regards, Benoit >> >> _______________________________________________ >> 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 Dec 8 02:14:27 2014 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 74A081A89FE for ; Mon, 8 Dec 2014 02:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 RJFnSBxyC-na for ; Mon, 8 Dec 2014 02:14:20 -0800 (PST) Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A12D1A89FD for ; Mon, 8 Dec 2014 02:14:20 -0800 (PST) Received: from Vanguard ([84.92.149.4]) by avasout01 with smtp id QyEG1p00305w0Nk01yEHhj; Mon, 08 Dec 2014 10:14:18 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZZGTN6lA c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=6bkCdLdQAAAA:8 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=2oeSqxxVzlsA:10 a=48vgC7mUAAAA:8 a=Wzxw0eko2m6ny5bzZPgA:9 a=hl1ftyl3-A3_u7US:21 a=G3qtkQQFZK5LCLFD:21 a=CjuIK1q_8ugA:10 a=2mLzDuUFM-0A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=9eeZKOKkyon1yu1jA3AA:9 a=k5sT1AKsWeLPJoVj:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 From: "Jonathan Hansford" To: "'Michael Behringer \(mbehring\)'" , References: <20141017123010.13535.51699.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C816CE@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21C816CE@xmb-rcd-x14.cisco.com> Date: Mon, 8 Dec 2014 10:14:18 -0000 Message-ID: <113f01d012cf$badb0330$30910990$@hansfords.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1140_01D012CF.BADC62C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHhQX/gR+EwHTlU4Bax9iEvvh8oigFVf12pnFhbX1A= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/anima/91vYuGh4rax7NmzPJ8iecsXpbWM Subject: Re: [Anima] FW: New Version Notification for draft-behringer-anima-reference-model-00.txt 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, 08 Dec 2014 10:14:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1140_01D012CF.BADC62C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I know you are looking for high level comments, but I'm just getting my head round the goals of anima and have some low level editorial comments. Hope you don't mind: * Section 2, MASA: o Is MASA an acronym? I assume the ASA stands for Autonomic Service Agent, but I could be wrong. o s/The MASA is service/The MASA is a service * Section 3: I just don't understand the 2nd sentence. Is it trying to say that section 2 describes the "boxes"? If so, wouldn't it be better to say 'Section 2, The Network View, describes the "boxes".'? Or are you trying to say section 3 describes the boxes identified in section 2? Is the intent to have a diagram in section 2 that has boxes, lines and arrows (see section 7)? * Section 3.1: o This states there are two levels inside an autonomic node but then only appears to mention one: 'the level of autonomic service agents'. Is the other level the autonomic networking infrastructure? If so, perhaps it could say 'Fundamentally, there are two levels inside an autonomic node: that of the autonomic service agents and that of the autonomic networking infrastructure, with the former using the functions of the latter.' o Though "Intent" is capitalised in this section, it isn't anywhere else (figure 1 and section 7.3). I presume in each case this is a reference to Intent as defined in draft-irtf-nmrg-autonomic-network-definitions, in which case drawing the definition through and capitalising throughout might be a good idea. * Section 7: o Again, a confusing reference to section 2. o Do you mean the "summary" of autonomic interactions forms the ACP? Summary doesn't feel like the right word. Might "totality" be better? * Section 7.1: o You identify information as being provided through configuration or northbound interfaces and indicate autonomic functions should only minimally rely on the interfaces. Does that imply a greater reliance on configuration, or should it minimally rely on both configuration and the interfaces? o s/neigbhour/neighbour * Section 9.1: s/in theory by attempted/in theory be attempted Jonathan > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Behringer (mbehring) > Sent: 17 October 2014 13:32 > To: anima@ietf.org > Subject: [Anima] FW: New Version Notification for draft-behringer-anima- > reference-model-00.txt > > Here the first version of the reference draft. The sections need a lot more > work, but the structure should be a good starting point. Before diving into > the details (where we'll have no doubt lots of detailed comments), I'd like to > ask specifically about high level comments regarding structure, what is > missing, etc. > > Michael > > > > -----Original Message----- > > From: internet-drafts@ietf.org [ mailto:internet-drafts@ietf.org] > > Sent: 17 October 2014 14:30 > > To: Michael Behringer (mbehring); Brian E. Carpenter; Michael > > Behringer (mbehring); Toerless Eckert (eckert); Brian Carpenter; > > Toerless Eckert > > (eckert) > > Subject: New Version Notification for draft-behringer-anima-reference- > > model-00.txt > > > > > > A new version of I-D, draft-behringer-anima-reference-model-00.txt > > has been successfully submitted by Michael H. Behringer and posted to > > the IETF repository. > > > > Name: draft-behringer-anima-reference-model > > Revision: 00 > > Title: A Reference Model for Autonomic Networking > > Document date: 2014-10-17 > > Group: Individual Submission > > Pages: 9 > > URL: http://www.ietf.org/internet-drafts/draft-behringer-anima- > > reference-model-00.txt > > Status: https://datatracker.ietf.org/doc/draft-behringer-anima- > > reference-model/ > > Htmlized: http://tools.ietf.org/html/draft-behringer-anima-reference- > > model-00 > > > > > > Abstract: > > This document describes a reference model for Autonomic Networking. > > The goal is to define how the various elements in an autonomic > > context work together, to describe their interfaces and relations. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ------=_NextPart_000_1140_01D012CF.BADC62C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I know = you are looking for high level comments, but I’m just getting my = head round the goals of anima and have some low level editorial = comments. Hope you don’t mind:

·         = Section 2, MASA:

o   Is MASA an = acronym? I assume the ASA stands for Autonomic Service Agent, but I = could be wrong.

o   s/The MASA is = service/The MASA is a service

·         = Section 3: I just don’t understand = the 2nd sentence. Is it trying to say that section 2 = describes the “boxes”? If so, wouldn’t it be better to = say ‘Section 2, The Network View, describes the = “boxes”.‘? Or are you trying to say section 3 = describes the boxes identified in section 2? Is the intent to have a = diagram in section 2 that has boxes, lines and arrows (see section = 7)?

·         = Section 3.1:

o   This states = there are two levels inside an autonomic node but then only appears to = mention one: ‘the level of autonomic service agents’. Is the = other level the autonomic networking infrastructure? If so, perhaps it = could say ‘Fundamentally, there are two levels inside an autonomic = node: that of the autonomic service agents and that of the autonomic = networking infrastructure, with the former using the functions of the = latter.’

o   Though = “Intent” is capitalised in this section, it isn’t = anywhere else (figure 1 and section 7.3). I presume in each case this is = a reference to Intent as defined in = draft-irtf-nmrg-autonomic-network-definitions, in which case drawing the = definition through and capitalising throughout might be a good = idea.

·         = Section 7:

o   Again, a = confusing reference to section 2.

o   Do you mean the = “summary” of autonomic interactions forms the ACP? Summary = doesn’t feel like the right word. Might “totality” be = better?

·         = Section 7.1:

o   You identify = information as being provided through configuration or northbound = interfaces and indicate autonomic functions should only minimally rely = on the interfaces. Does that imply a greater reliance on configuration, = or should it minimally rely on both configuration and the interfaces? =

o   = s/neigbhour/neighbour

·         = Section 9.1: s/in theory by attempted/in = theory be attempted

 

Jonathan

 

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

> From: Anima = [mailto:anima-bounces@ietf.org] On Behalf Of Michael

> Behringer (mbehring)

> Sent: 17 October 2014 = 13:32

> To: anima@ietf.org

> Subject: [Anima] FW: New Version = Notification for draft-behringer-anima-

> reference-model-00.txt

>

> Here the = first version of the reference draft. The sections need a lot more

> work, but the structure should be a good = starting point. Before diving into

> the = details (where we'll have no doubt lots of detailed comments), I'd like = to

> ask specifically about high level = comments regarding structure, what is

> = missing, etc.

>

> Michael

>

>

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

> > From: internet-drafts@ietf.org<= /span> [mailto:internet-drafts@ie= tf.org]

> > Sent: 17 October = 2014 14:30

> > To: Michael Behringer = (mbehring); Brian E. Carpenter; Michael

> = > Behringer (mbehring); Toerless Eckert (eckert); Brian = Carpenter;

> > Toerless Eckert

> > (eckert)

> = > Subject: New Version Notification for = draft-behringer-anima-reference-

> > = model-00.txt

> >

> >

> > A = new version of I-D, draft-behringer-anima-reference-model-00.txt

> > has been successfully submitted by = Michael H. Behringer and posted to

> > = the IETF repository.

> >

> > = Name:           &n= bsp;           &nb= sp;   draft-behringer-anima-reference-model

> > Revision:      = 00

> > = Title:           &= nbsp;           &n= bsp;       A Reference Model for Autonomic = Networking

> > Document = date:        2014-10-17

> > = Group:           &= nbsp;           &n= bsp;  Individual Submission

> > = Pages:           &= nbsp;           &n= bsp;   9

> > = URL:            = http://www.ietf.org/inter= net-drafts/draft-behringer-anima-

> > reference-model-00.txt

> > = Status:         https://datatracker.ietf.= org/doc/draft-behringer-anima-

> > reference-model/

> > = Htmlized:       http://tools.ietf.org/htm= l/draft-behringer-anima-reference-

> > model-00

> = >

> >

> > Abstract:

> = >    This document describes a reference model for = Autonomic Networking.

> = >    The goal is to define how the various elements in = an autonomic

> >    = context work together, to describe their interfaces and relations.

> >

> = >

> >

> >

> > = Please note that it may take a couple of minutes from the time of

> > submission until the htmlized version and = diff are available at tools.ietf.org.

> = >

> > The IETF Secretariat

>

> = _______________________________________________

> Anima mailing list

> Anima@ietf.org=

> https://www.ietf.org/mail= man/listinfo/anima

------=_NextPart_000_1140_01D012CF.BADC62C0-- From nobody Mon Dec 8 10:43:30 2014 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 E4DBC1ACD68 for ; Mon, 8 Dec 2014 10:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_61=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=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 8sBKuevM1dVy for ; Mon, 8 Dec 2014 10:43:29 -0800 (PST) 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 D86A21ACD87 for ; Mon, 8 Dec 2014 10:43:28 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D40CB20098; Mon, 8 Dec 2014 13:47:05 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 61C0B637F5; Mon, 8 Dec 2014 13:43:27 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4BA3B637F4; Mon, 8 Dec 2014 13:43:27 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <547259BD.90105@gmail.com> References: <29308.1416777150@sandelman.ca> <547259BD.90105@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/anima/IV3mxE_IGHFxBCatm1vNdM6WhTE Cc: anima@ietf.org Subject: Re: [Anima] comments on prefix delegation and GDN protocol document 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, 08 Dec 2014 18:43:30 -0000 --=-=-= Brian E Carpenter wrote: >> wrt: the GDN protocol and requirements: >> >> 5.2.1: why does the GDN protocol need to run over IPv4? >> I would agree that it might need to configure IPv4 services, but I can't >> see a reason why it should be complicated by the need to support legacy >> 32-bit stuff. > Because the context is the whole Internet, and although my instinct is > the same as yours, I don't think it's realistic for the next ten or twenty > years to assume IPv6 transport everywhere. I said: no IPv4, only IPv6, you understood the opposite. I didn't think that GDN needed to run other than across layer-2 fabrics (single hops). I didn't think it needed to across the Internet. >> 5.2.3.1: algorithm agility, you can't say: don't fallback to an algorithm >> considered weak. If the software author knew the algorithm was >> weak at the time the code was written, the algorithm would >> not have been included. That's the whole problem here: you need to >> be able to incrementally deploy new algorithms, so you need an >> upgrade mechanism, and you *have to* fallback when the other node >> does not support stronger algorithm, and the attacker will >> convince you... >> >> The only out is that you can do something in the certificates >> that says what ought to be supported. > We've also got policy intent in the future too, like an intent that > says "Don't accept algorithm X any more." > (Doesn't putting it in the cert mean that you need to be very sure that > certificate revocation will work? Well, I guess that needs to work > anyway.) If a hash algorithm is weak/defeated, then in effect, all of the certificates that signed with that algorithm are weak. It's easier to say, signed{I support SHA2} than it is to say the opposite. >> While we pretend via Layer-2 devices that ethernet is >> still made up of broadcast coax cables, except for wifi, there are probably >> only two devices connected at each end of the cable. >> So I suggest that while a multicast based discovery protocol is appropriate >> (and why not use DHCPv6 or RPL), once the end point is discovered, it seems >> that one should run GNDP over point to point DLTS or IPsec. > Yes, once you have identified the counterpart it should be unicast > and secure. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVIXxTICLcPvd0N1lAQJOPwf/W1z8ylodl0lwsJxxTqBBekrecGIOmuGy UxhjNSDgy5y8jLGnBpj9C0/HUhUOScA+n3B4LnLgtjp1AS9Q+L4IGYBuV4WaP48A 8BIHSiD3y2Etb7svrcidUapB3PTp7atZwmtFe6Hdiw3hcV3h66Y1B+WqNS4WPhk/ NxIsosrpKHfpeyTTBOEYNXR54zW66/pFMKOIivwNeSz2K44jCWmC1GTPg8gzpNH7 0GSEnbQ9m68zB6B5eZKp80SlzVrsErLHg+EcWUSrBacFiMRVWYnqUJVmUDgBNlS9 klKCGaLKsqbvmCTfvc3yoYrpERU7PQ6y/QHbZuNTQEwKBObMOsr22Q== =sdUs -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 8 10:45:07 2014 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 595E61ACD8C for ; Mon, 8 Dec 2014 10:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=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 y5CPdDuiP8_f for ; Mon, 8 Dec 2014 10:45:05 -0800 (PST) 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 A05811ACD68 for ; Mon, 8 Dec 2014 10:45:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2A91D20098; Mon, 8 Dec 2014 13:48:43 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id ECC57637F5; Mon, 8 Dec 2014 13:45:04 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D1EE6637F4; Mon, 8 Dec 2014 13:45:04 -0500 (EST) From: Michael Richardson To: Sheng Jiang In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF9BF48@nkgeml512-mbx.china.huawei.com> References: <29308.1416777150@sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B923AF9BF48@nkgeml512-mbx.china.huawei.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/anima/zkzJe-hFEyLw_FKnoa5ayMeZTPI Cc: "anima@ietf.org" Subject: Re: [Anima] comments on prefix delegation and GDN protocol document 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, 08 Dec 2014 18:45:06 -0000 --=-=-= Sheng Jiang wrote: > Thanks for your comments. The replies in lines. > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael >> Richardson >> >> section 3.1 >> why send a GDN discovery message asking for a Prefix Option, instead of just >> sending a DHCPv6 Discovery message with PD as a request? > The DHCPv6 PD does not work with DHCPv6 discovery message, by > definition. RFC3633 (DHCPv6 PD) is actually working between routers, > rather than traditional DHCPv6 server/client. So, DHCPv6 PD is based on > the assumption, the requesting router already know the request router, > that's where to send the prefix pd request. Section 3.1 describes a > behavior to discover the request router using GDN protocol. Uhm, can't I say, in a DHCPv6 Discovery message, that I'm interested in replies from a DHCPv6 server that is willing to provide me with Option X, and I can set X=PD? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVIXxrYCLcPvd0N1lAQJAbwf/an6KObYkpdksHPMRuT6/O50AkzyuS5fe KRaN9HfbLHHaAWDQ5DaHHooWSiUkwpFkwpv/kzPoVNEzhA/O8To6zXqur9bHylOr P4kfezFN6wgQmmRNxpVBwFz49+YABOwvq2auUwhw+ctXL77Qd77uqDXVGF9THooY Iyc9U14OJeeP05aUaLTFljlltcw1EufmAYC1/n6fXoBbPEosuBJ2rgk/XaDEgrJL xzUf3Z+Fa3XJEOUkNoubdLnr4v6/Hg/p2id+S2QVCRf4nKlXQpU8JOyvkn8mQ/ke svv7joisJPRmGNSxq4nYMSsmR2g5AwD+4VJPoNOSCo9Rxssc/+sFsQ== =jCp1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 8 11:02:54 2014 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 5312F1ACC82 for ; Mon, 8 Dec 2014 11:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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_CHICKENPOX_61=0.6, 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 8WpOIhxKaf9N for ; Mon, 8 Dec 2014 11:02:52 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080971AC3C0 for ; Mon, 8 Dec 2014 11:02:51 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id rd3so5746245pab.14 for ; Mon, 08 Dec 2014 11:02:51 -0800 (PST) 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=xggy+2VwsL5zxgMcUrfGMWFv8hnfIuADGiyt/SRHtIk=; b=LFVtHRvRdpZUoREjch36dmB2k7fVPB+KTLFYYk8lKmvwutwo7wXlHrRIWmApQqM/0J 45SpgYSm57QS9CXFWQliSD72KPUyqsNyCNeu4E6smUcUNLyDwxcs0cVPGwVnazs+V6ZN deX095C+sOHYiVSiMaXm0Y4lI07ML9BmQcg5qrvIk3JmmIr7sFjeZoxWHPkl1HrXBrUP uVBFn9g9Y0j/iOC+2Z3O32upJ606CCVTxrT9Ft6VQKlZoTY1Pm/IgGBAofjFYC2mfOY9 3kJClpLYm9eQeyJXhiEt1E2PWo0zyUijD40hfVGFVVa/uEEQeOonKfjr2h+ztuIhALxi RBtw== X-Received: by 10.66.155.225 with SMTP id vz1mr54900555pab.133.1418065371126; Mon, 08 Dec 2014 11:02:51 -0800 (PST) Received: from [192.168.178.26] (220.227.69.111.dynamic.snap.net.nz. [111.69.227.220]) by mx.google.com with ESMTPSA id bb3sm36972156pbc.15.2014.12.08.11.02.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 11:02:50 -0800 (PST) Message-ID: <5485F5D5.2090809@gmail.com> Date: Tue, 09 Dec 2014 08:02:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <29308.1416777150@sandelman.ca> <547259BD.90105@gmail.com> <6938.1418064207@sandelman.ca> In-Reply-To: <6938.1418064207@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/vuwTajTZgWRbsI6W6gUbLK1azis Cc: anima@ietf.org Subject: Re: [Anima] comments on prefix delegation and GDN protocol document 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, 08 Dec 2014 19:02:53 -0000 On 09/12/2014 07:43, Michael Richardson wrote: > Brian E Carpenter wrote: > >> wrt: the GDN protocol and requirements: > >> > >> 5.2.1: why does the GDN protocol need to run over IPv4? > >> I would agree that it might need to configure IPv4 services, but I can't > >> see a reason why it should be complicated by the need to support legacy > >> 32-bit stuff. > > > Because the context is the whole Internet, and although my instinct is > > the same as yours, I don't think it's realistic for the next ten or twenty > > years to assume IPv6 transport everywhere. > > I said: no IPv4, only IPv6, you understood the opposite. > I didn't think that GDN needed to run other than across layer-2 fabrics > (single hops). I didn't think it needed to across the Internet. It needs to run across a whole administrative domain; there is no restriction to a single layer 2 link. Maybe we need to make that more clear at the beginning. Certainly there will be use cases confined to a single link, but if you are managing a resource that is network-wide, you need to negotiate with counterparts anywhere in the network. > > >> 5.2.3.1: algorithm agility, you can't say: don't fallback to an algorithm > >> considered weak. If the software author knew the algorithm was > >> weak at the time the code was written, the algorithm would > >> not have been included. That's the whole problem here: you need to > >> be able to incrementally deploy new algorithms, so you need an > >> upgrade mechanism, and you *have to* fallback when the other node > >> does not support stronger algorithm, and the attacker will > >> convince you... I think that's exactly the point. You might install a new network-wide policy that says NEVER accept single DES - simply abandon communication with a node that can only do single DES. If that's the policy, the legacy nodes will fall off the network, and that is the desired result. > >> > >> The only out is that you can do something in the certificates > >> that says what ought to be supported. > > > We've also got policy intent in the future too, like an intent that > > says "Don't accept algorithm X any more." > > > (Doesn't putting it in the cert mean that you need to be very sure that > > certificate revocation will work? Well, I guess that needs to work > > anyway.) > > If a hash algorithm is weak/defeated, then in effect, all of the certificates > that signed with that algorithm are weak. It's easier to say, signed{I support SHA2} > than it is to say the opposite. Indeed. Brian > > >> While we pretend via Layer-2 devices that ethernet is > >> still made up of broadcast coax cables, except for wifi, there are probably > >> only two devices connected at each end of the cable. > > >> So I suggest that while a multicast based discovery protocol is appropriate > >> (and why not use DHCPv6 or RPL), once the end point is discovered, it seems > >> that one should run GNDP over point to point DLTS or IPsec. > > > Yes, once you have identified the counterpart it should be unicast > > and secure. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon Dec 8 17:45:26 2014 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 2E2CF1A1A69 for ; Mon, 8 Dec 2014 17:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, 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 xugnCOQK78qg for ; Mon, 8 Dec 2014 17:45:21 -0800 (PST) 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 7BBBE1A03A5 for ; Mon, 8 Dec 2014 17:45:21 -0800 (PST) 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 BPV24034; Tue, 09 Dec 2014 01:45:20 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 9 Dec 2014 01:45:19 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 9 Dec 2014 09:45:15 +0800 From: Sheng Jiang To: Michael Richardson Thread-Topic: [Anima] comments on prefix delegation and GDN protocol document Thread-Index: AQHQB2I3Sfw2I+WNPEyDG0xA5b+q5ZxvAAuwgBaZPACAAO0b4A== Date: Tue, 9 Dec 2014 01:45:14 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AFE5AC1@nkgeml512-mbx.china.huawei.com> References: <29308.1416777150@sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B923AF9BF48@nkgeml512-mbx.china.huawei.com> <7591.1418064304@sandelman.ca> In-Reply-To: <7591.1418064304@sandelman.ca> 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.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/BqXbZj6nlnAOQ7cUlC-02HvKF0A Cc: "anima@ietf.org" Subject: Re: [Anima] comments on prefix delegation and GDN protocol document 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, 09 Dec 2014 01:45:23 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbWNyQHNhbmRlbG1hbi5jYSBbbWFp bHRvOm1jckBzYW5kZWxtYW4uY2FdIE9uIEJlaGFsZiBPZiBNaWNoYWVsDQo+UmljaGFyZHNvbg0K PiAgICA+IEZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIE1pY2hhZWwNCj4gICAgPj4gUmljaGFyZHNvbg0KPiAgICA+Pg0KPiAgICA+PiBzZWN0 aW9uIDMuMQ0KPiAgICA+PiB3aHkgc2VuZCBhIEdETiBkaXNjb3ZlcnkgbWVzc2FnZSBhc2tpbmcg Zm9yIGEgUHJlZml4IE9wdGlvbiwgaW5zdGVhZA0KPm9mIGp1c3QNCj4gICAgPj4gc2VuZGluZyBh IERIQ1B2NiBEaXNjb3ZlcnkgbWVzc2FnZSB3aXRoIFBEIGFzIGEgcmVxdWVzdD8NCj4NCj4gICAg PiBUaGUgREhDUHY2IFBEIGRvZXMgbm90IHdvcmsgd2l0aCBESENQdjYgZGlzY292ZXJ5IG1lc3Nh Z2UsIGJ5DQo+ICAgID4gZGVmaW5pdGlvbi4gUkZDMzYzMyAoREhDUHY2IFBEKSBpcyBhY3R1YWxs eSB3b3JraW5nIGJldHdlZW4gcm91dGVycywNCj4gICAgPiByYXRoZXIgdGhhbiB0cmFkaXRpb25h bCBESENQdjYgc2VydmVyL2NsaWVudC4gU28sIERIQ1B2NiBQRCBpcyBiYXNlZA0KPm9uDQo+ICAg ID4gdGhlIGFzc3VtcHRpb24sIHRoZSByZXF1ZXN0aW5nIHJvdXRlciBhbHJlYWR5IGtub3cgdGhl IHJlcXVlc3Qgcm91dGVyLA0KPiAgICA+IHRoYXQncyB3aGVyZSB0byBzZW5kIHRoZSBwcmVmaXgg cGQgcmVxdWVzdC4gU2VjdGlvbiAzLjEgZGVzY3JpYmVzIGENCj4gICAgPiBiZWhhdmlvciB0byBk aXNjb3ZlciB0aGUgcmVxdWVzdCByb3V0ZXIgdXNpbmcgR0ROIHByb3RvY29sLg0KPg0KPlVobSwg Y2FuJ3QgSSBzYXksIGluIGEgREhDUHY2IERpc2NvdmVyeSBtZXNzYWdlLCB0aGF0IEknbSBpbnRl cmVzdGVkIGluDQo+cmVwbGllcyBmcm9tIGEgREhDUHY2IHNlcnZlciB0aGF0IGlzIHdpbGxpbmcg dG8gcHJvdmlkZSBtZSB3aXRoIE9wdGlvbiBYLA0KPmFuZCBJIGNhbiBzZXQgWD1QRD8NCg0KSGks IE1pY2hhZWwsDQoNCkJ5IGRlZmluaXRpb24gb2YgcHJvdG9jb2wsIHllcywgaXQgaXMgcG9zc2li bGUuIEJ1dCwgaW4gdGhlIHJlYWwgZGVwbG95bWVudCwgdGhpcyBoYXMgdG8gZGVwZW5kIG9uIGEg cHJlY29uZGl0aW9uIHRoYXQgdGhlIHJlcXVlc3Rpbmcgcm91dGVyIGFuZCB0aGUgZGVsZWdhdGlu ZyByb3V0ZXIgYXJlIGRpcmVjdGx5IGNvbm5lY3RlZCBhbmQgdGhlcmUgaXMgbm8gb3RoZXIgcGF0 aC4gKFRoZSBESENQdjYgRGlzY292ZXJ5IG1lY2hhbmlzbSBjYW4gZGlzY292ZXJ5IERIQ1B2NiBz ZXJ2ZXIgdXNpbmcgcHJlY29uZmlndXJlZCBESENQdjYgcmVsYXksIGJ1dCB0aGlzIG1lY2hhbmlz bSBkb2VzIG5vdCBzdWl0YWJsZSB0byBkaXNjb3ZlcnkgdGhlIHJlcXVlc3Rpbmcgcm91dGVyLikg SW4gb3RoZXIgd29yZCwgdGhlIERIQ1B2NiBEaXNjb3ZlcnkgbWVjaGFuaXNtIGRvZXMgbm90IHN1 cHBvcnQgYXV0b25vbWljIGRpc2NvdmVyeSByZXF1ZXN0aW5nIHJvdXRlcnMgaW4gYSBmbGV4aWJs ZSB0b3BvbG9neSBlbnZpcm9ubWVudCwgd2hpY2ggaXMgdGhlIGVzc2VuY2Ugb2YgYXV0b25vbWlj IG5ldHdvcmsuIFRoZXJlZm9yZSwgd2UgbmVlZCBhIEdETiBkaXNjb3ZlcnkgbWVzc2FnZSB3aXRo IGl0cyBhc3NvY2lhdGVkIGRpc2NvdmVyeSBtZWNoYW5pc20sIHdoaWNoIGNhbiB3b3JrIGluIHZh cmlvdXMgdG9wb2xvZ3kgbmV0d29ya3MsIHRvIGZpbmQgb3V0IHRoZSBkZWxlZ2F0aW5nIHJvdXRl ci4gT25seSBhZnRlciB0aGVuLCBpdCBpcyBwb3NzaWJsZSB0byByZXF1ZXN0IGEgcHJlZml4LiBX aGV0aGVyIGl0IHVzZXMgREhDUHY2IFBEIG9yIGEgbmV3IG9wdGlvbiBpbiBHRE4gaXMgYW5vdGhl ciBkaXNjdXNzaW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLQ0KPk1pY2hhZWwg UmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdv cmtzDQo+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4NCj4NCg0K From nobody Wed Dec 10 03:06:19 2014 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 DB4901A0099 for ; Wed, 10 Dec 2014 03:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_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 lm1ZWrpvoyZl for ; Wed, 10 Dec 2014 03:06:06 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2081A6FEA for ; Wed, 10 Dec 2014 03:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32162; q=dns/txt; s=iport; t=1418209565; x=1419419165; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cDJg71aI0hw4NNdjMxKpviuQ7AGIACkW1qsPi4PClMc=; b=KL1RK0fipHDhey+UDvTEmr1ibTTO5u/2KqkFbWtkaGKHTyFurYxtDT5h nYhtGKudyFDPhsOFVlKhjvk6Lq3VKORvxI4sU0gOJmi5aapJmwZYG4Rk9 m82wnQJ3cLd2MG+bYIsXp1qO0TFUuTCdEPUYjo9Wrq31kCcXsM6jLIWQQ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYHAOUniFStJV2U/2dsb2JhbABPCoJDQ1Jcw2I8gV8BCYVuAoEWFgEBAQEBfYQCAQEBAwEBAQEqQQQFBwcEAgEIEQQBAQsWAQYHJwsUCAEIAgQBEggBiCcIDdcRAQEBAQEBAQEBAQEBAQEBAQEBAQEBF48gBystCgEGgxuBFQWOAoNAhj0wgiyKE4NfgjCBPm6BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208,217";a="379071443" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP; 10 Dec 2014 11:05:48 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sBAB5md7002623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Dec 2014 11:05:48 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.121]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 05:05:47 -0600 From: "Michael Behringer (mbehring)" To: Jonathan Hansford , "anima@ietf.org" Thread-Topic: [Anima] FW: New Version Notification for draft-behringer-anima-reference-model-00.txt Thread-Index: AQHP6gYZB9uNzRaalkiKtw9phnM8u5w0OEMggFH3uQCAAs5UEA== Date: Wed, 10 Dec 2014 11:05:47 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21D0A7F0@xmb-rcd-x14.cisco.com> References: <20141017123010.13535.51699.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C816CE@xmb-rcd-x14.cisco.com> <113f01d012cf$badb0330$30910990$@hansfords.net> In-Reply-To: <113f01d012cf$badb0330$30910990$@hansfords.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.116.97] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21D0A7F0xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/lUWHYLfEuR85grFxX7MFxbDnxzE Subject: Re: [Anima] FW: New Version Notification for draft-behringer-anima-reference-model-00.txt 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, 10 Dec 2014 11:06:11 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21D0A7F0xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jonathan, Thanks a lot for your review. I'll incorporate your comments into the next = version. Michael From: Jonathan Hansford [mailto:jonathan@hansfords.net] Sent: 08 December 2014 11:14 To: Michael Behringer (mbehring); anima@ietf.org Subject: RE: [Anima] FW: New Version Notification for draft-behringer-anima= -reference-model-00.txt Hi, I know you are looking for high level comments, but I'm just getting my hea= d round the goals of anima and have some low level editorial comments. Hope= you don't mind: * Section 2, MASA: o Is MASA an acronym? I assume the ASA stands for Autonomic Service Agent= , but I could be wrong. o s/The MASA is service/The MASA is a service * Section 3: I just don't understand the 2nd sentence. Is it trying= to say that section 2 describes the "boxes"? If so, wouldn't it be better = to say 'Section 2, The Network View, describes the "boxes".'? Or are you tr= ying to say section 3 describes the boxes identified in section 2? Is the i= ntent to have a diagram in section 2 that has boxes, lines and arrows (see = section 7)? * Section 3.1: o This states there are two levels inside an autonomic node but then only= appears to mention one: 'the level of autonomic service agents'. Is the ot= her level the autonomic networking infrastructure? If so, perhaps it could = say 'Fundamentally, there are two levels inside an autonomic node: that of = the autonomic service agents and that of the autonomic networking infrastru= cture, with the former using the functions of the latter.' o Though "Intent" is capitalised in this section, it isn't anywhere else = (figure 1 and section 7.3). I presume in each case this is a reference to I= ntent as defined in draft-irtf-nmrg-autonomic-network-definitions, in which= case drawing the definition through and capitalising throughout might be a= good idea. * Section 7: o Again, a confusing reference to section 2. o Do you mean the "summary" of autonomic interactions forms the ACP? Summ= ary doesn't feel like the right word. Might "totality" be better? * Section 7.1: o You identify information as being provided through configuration or nor= thbound interfaces and indicate autonomic functions should only minimally r= ely on the interfaces. Does that imply a greater reliance on configuration,= or should it minimally rely on both configuration and the interfaces? o s/neigbhour/neighbour * Section 9.1: s/in theory by attempted/in theory be attempted Jonathan > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Behringer (mbehring) > Sent: 17 October 2014 13:32 > To: anima@ietf.org > Subject: [Anima] FW: New Version Notification for draft-behringer-anima- > reference-model-00.txt > > Here the first version of the reference draft. The sections need a lot mo= re > work, but the structure should be a good starting point. Before diving in= to > the details (where we'll have no doubt lots of detailed comments), I'd li= ke to > ask specifically about high level comments regarding structure, what is > missing, etc. > > Michael > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto= :internet-drafts@ietf.org] > > Sent: 17 October 2014 14:30 > > To: Michael Behringer (mbehring); Brian E. Carpenter; Michael > > Behringer (mbehring); Toerless Eckert (eckert); Brian Carpenter; > > Toerless Eckert > > (eckert) > > Subject: New Version Notification for draft-behringer-anima-reference- > > model-00.txt > > > > > > A new version of I-D, draft-behringer-anima-reference-model-00.txt > > has been successfully submitted by Michael H. Behringer and posted to > > the IETF repository. > > > > Name: draft-behringer-anima-reference-model > > Revision: 00 > > Title: A Reference Model for Autonomic Ne= tworking > > Document date: 2014-10-17 > > Group: Individual Submission > > Pages: 9 > > URL: http://www.ietf.org/internet-drafts/draft-behringer-ani= ma- > > reference-model-00.txt > > Status: https://datatracker.ietf.org/doc/draft-behringer-anima- > > reference-model/ > > Htmlized: http://tools.ietf.org/html/draft-behringer-anima-refere= nce- > > model-00 > > > > > > Abstract: > > This document describes a reference model for Autonomic Networking. > > The goal is to define how the various elements in an autonomic > > context work together, to describe their interfaces and relations. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > The IETF Secretariat > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21D0A7F0xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Jonathan,

=  

= Thanks a lot for your review= . I’ll incorporate your comments into the next version.

=  

= Michael

=  

From:<= /b> Jonathan Hansford [mailto:jonathan@hansfords.net]
Sent: 08 December 2014 11:14=
To: Michael Behringer (mbehr= ing); anima@ietf.org
Subject: RE: [Anima] FW: New= Version Notification for draft-behringer-anima-reference-model-00.txt=

 

Hi,

 

I know you are looking for high level comments, but IR= 17;m just getting my head round the goals of anima and have some low level = editorial comments. Hope you don’t mind:

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 2, MASA:

= o   Is MASA an acronym? I assume the ASA stands for Autonomic Ser= vice Agent, but I could be wrong.

= o   s/The MASA is service/The MASA is a service

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 3: I just don’t understand the 2nd s= entence. Is it trying to say that section 2 describes the “boxes̶= 1;? If so, wouldn’t it be better to say ‘Section 2, The Network= View, describes the “boxes”.‘? Or are you trying to say = section 3 describes the boxes identified in section 2? Is the intent to have a dia= gram in section 2 that has boxes, lines and arrows (see section 7)?

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 3.1:

= o   This states there are two levels inside an autonomic node but= then only appears to mention one: ‘the level of autonomic service ag= ents’. Is the other level the autonomic networking infrastructure? If= so, perhaps it could say ‘Fundamentally, there are two levels inside an autonomic node: that of the autonomic service age= nts and that of the autonomic networking infrastructure, with the former us= ing the functions of the latter.’

= o   Though “Intent” is capitalised in this section, i= t isn’t anywhere else (figure 1 and section 7.3). I presume in each c= ase this is a reference to Intent as defined in draft-irtf-nmrg-autonomic-n= etwork-definitions, in which case drawing the definition through and capitalising throughout might be a good idea.

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 7:

= o   Again, a confusing reference to section 2.

= o   Do you mean the “summary” of autonomic interactio= ns forms the ACP? Summary doesn’t feel like the right word. Might = 220;totality” be better?

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 7.1:

= o   You identify information as being provided through configurat= ion or northbound interfaces and indicate autonomic functions should only m= inimally rely on the interfaces. Does that imply a greater reliance on conf= iguration, or should it minimally rely on both configuration and the interfaces?

= o   s/neigbhour/neighbour

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 9.1: s/in theory by attempted/in theory be attempted<= o:p>

 

Jonathan

 

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

> Fro= m: Anima [mailto:anima-bounces@ie= tf.org] On Behalf Of Michael

> Beh= ringer (mbehring)

> Sen= t: 17 October 2014 13:32

> To:= anima@ietf.org

> Sub= ject: [Anima] FW: New Version Notification for draft-behringer-anima-

> ref= erence-model-00.txt

>

> Here the first version of the reference draft. The s= ections need a lot more

> work, but the structure should be a good starting po= int. Before diving into

> the details (where we'll have no doubt lots of detai= led comments), I'd like to

> ask specifically about high level comments regarding= structure, what is

> missing, etc.

>

> Michael

>

>

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

> > From: internet-drafts@ietf.org [mailto:internet-= drafts@ietf.org]

> > Sent: 17 October 2014 14:30

> > To: Michael Behringer (mbehring); Brian E. Carp= enter; Michael

> > Behringer (mbehring); Toerless Eckert (eckert);= Brian Carpenter;

> > Toerless Eckert

> > (eckert)

> > Subject: New Version Notification for draft-beh= ringer-anima-reference-

> > model-00.txt

> >

> >

> > A new version of I-D, draft-behringer-anima-ref= erence-model-00.txt

> > has been successfully submitted by Michael H. B= ehringer and posted to

> > the IETF repository.

> >

> > Name:       =             &nb= sp;       draft-behringer-anima-reference-mod= el

> > Revision:      00=

> > Title:       = ;            &n= bsp;           A Referenc= e Model for Autonomic Networking

> > Document date:     &nb= sp;  2014-10-17

> > Group:       = ;            &n= bsp;      Individual Submission<= /font>

> > Pages:       = ;            &n= bsp;       9

> > URL:       &= nbsp;    htt= p://www.ietf.org/internet-drafts/draft-behringer-anima-

> > reference-model-00.txt=

> > Status:      &nbs= p;  https:= //datatracker.ietf.org/doc/draft-behringer-anima-

> > reference-model/

> > Htmlized:       ht= tp://tools.ietf.org/html/draft-behringer-anima-reference-=

> > model-00

> >

> >

> > Abstract:

> >    This document describes a ref= erence model for Autonomic Networking.

> >    The goal is to define how the= various elements in an autonomic

> >    context work together, to des= cribe their interfaces and relations.

> >

> >

> >

> >

> > Please note that it may take a couple of minute= s from the time of

> > submission until the htmlized version and diff = are available at tools.ietf.org.

> >

> > The IETF Secretariat

>

> _______________________________________________=

> Anima mailing list

> Anima@ietf.org

> https://www.ietf.o= rg/mailman/listinfo/anima

--_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21D0A7F0xmbrcdx14ciscoc_-- From nobody Fri Dec 12 12:00:57 2014 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 4FB261ACFA0 for ; Fri, 12 Dec 2014 12:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=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 h00n5kMh01F3 for ; Fri, 12 Dec 2014 12:00:52 -0800 (PST) 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 257711ACF8D for ; Fri, 12 Dec 2014 12:00:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A5D5E203AF; Fri, 12 Dec 2014 15:04:35 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 28C60637F5; Fri, 12 Dec 2014 15:00:43 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0ED0463745; Fri, 12 Dec 2014 15:00:43 -0500 (EST) From: Michael Richardson To: Sheng Jiang In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AFE5AC1@nkgeml512-mbx.china.huawei.com> References: <29308.1416777150@sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B923AF9BF48@nkgeml512-mbx.china.huawei.com> <7591.1418064304@sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B923AFE5AC1@nkgeml512-mbx.china.huawei.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/anima/ZpncyUUJABWArTqggevn6gTMqRA Cc: "anima@ietf.org" Subject: Re: [Anima] comments on prefix delegation and GDN protocol document 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, 12 Dec 2014 20:00:56 -0000 --=-=-= Sheng Jiang wrote: > By definition of protocol, yes, it is possible. But, in the real > deployment, this has to depend on a precondition that the requesting > router and the delegating router are directly connected and there is no > other path. (The DHCPv6 Discovery mechanism can discovery DHCPv6 server I'm trying to understand the situation where GDN isn't run hop-by-hop. Perhaps I missed this part. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVItJaICLcPvd0N1lAQJ5/gf/QzFIFV23sVABXuDS1lM4i/dsyWPad2l8 +a5ReHQD6fE4FgEWCoEbakTkd8PXPkAdwBftEJPtnh9keP5Bu6aUS3u5OgoVkVK1 LxYQyGp+88bSZbLMpk9dbkd0wlsAEQouFdGVocR+si4doWRnaZCghTbEohe2PK33 4aQYuky4sIRIRdtCmqlfNoA3ntDzkx8jEyF1lBR6LcpwlBoNJsiywckHMa2SIONz BG+pEcqyzQsfWIuhAMwCyufFd97ZCZkFKTVV3IhNwoOzZurGdPmyK8brZ8+X3WfU twG3SUr0r5GcMriRY6MKcXnRnWhRgpB3mmgS+v7UsXnq0MKWcom2GA== =XtVF -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 12 14:21:07 2014 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 0BCBA1AD056 for ; Fri, 12 Dec 2014 14:21:03 -0800 (PST) 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 UsDOdY3CwsO4 for ; Fri, 12 Dec 2014 14:21:01 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814661AD052 for ; Fri, 12 Dec 2014 14:21:00 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id g10so5986428pdj.20 for ; Fri, 12 Dec 2014 14:20:59 -0800 (PST) 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=6HMTP96wXuxL2GTzZVoeIrfHg1yoAWWDG44uD54kW0o=; b=r65aXmlNGvI8ITO++P7D1XBb0zI4RDknRH5mHp9p+XpFy7Tx7t394ekLOEdDc4uw/X rb3qlWYcZZ7uUdT8AnLWElARTlpm5zGrRNrOfcdE8Gj72dq4dMO7K1amZipoz+B1C+mk y6pxneglt2vEIauMJfY90plzQwKYsI9yCyTUNMDue+4f3O9dDcMTG7tM9qC/V9CN897s qYdFzgBAETmZuGcjNIj1OhXSbp27j7zyLGkSeBygtIRskjbbu6LLmqBxtC1CNbrjis8U mA6QNhLqCm67m96Cdf0DNc9SEYei0009FRV8xcPZKnqe6orR/TspdV/USlQ2vjuyU564 rtVQ== X-Received: by 10.68.68.130 with SMTP id w2mr30477893pbt.167.1418422859831; Fri, 12 Dec 2014 14:20:59 -0800 (PST) Received: from [192.168.178.26] (235.231.69.111.dynamic.snap.net.nz. [111.69.231.235]) by mx.google.com with ESMTPSA id oz7sm2425584pbb.14.2014.12.12.14.20.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 14:20:58 -0800 (PST) Message-ID: <548B6A56.1010008@gmail.com> Date: Sat, 13 Dec 2014 11:21:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <29308.1416777150@sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B923AF9BF48@nkgeml512-mbx.china.huawei.com> <7591.1418064304@sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B923AFE5AC1@nkgeml512-mbx.china.huawei.com> <27721.1418414443@sandelman.ca> In-Reply-To: <27721.1418414443@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/EVLwX4i_ZUGsashkWiGhCJpyQrY Cc: "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] comments on prefix delegation and GDN protocol document 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, 12 Dec 2014 22:21:03 -0000 On 13/12/2014 09:00, Michael Richardson wrote: > Sheng Jiang wrote: > > By definition of protocol, yes, it is possible. But, in the real > > deployment, this has to depend on a precondition that the requesting > > router and the delegating router are directly connected and there is no > > other path. (The DHCPv6 Discovery mechanism can discovery DHCPv6 server > > I'm trying to understand the situation where GDN isn't run hop-by-hop. > Perhaps I missed this part. That's the Divert mechanism. We'll try to make it clearer in the next version of the draft (which will be very different, hence it's taking time to get it ready). For now: GDN is peer-to-peer, but the peer could be anywhere within the same administrative+security domain. (This is a significant difference from HNCP, or at least from HNCP as currently described). Brian Brian