From nobody Fri Jan 5 10:23:38 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ED7129C6E; Fri, 5 Jan 2018 10:23:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-anima-stable-connectivity@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> Date: Fri, 05 Jan 2018 10:23:36 -0800 Archived-At: Subject: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?anima-stable-connectivity-07=3A_=28with_DISCUSS=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 18:23:36 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-anima-stable-connectivity-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2.1.5 talks about use of MPTCP: "DNS naming is set up to provide the ACP IPv6 address of network devices. Unbeknownst to the application, MPTCP is used. MPTCP mutually discovers between the NOC and network device the data-plane address and caries all traffic across it when that MPTCP subflow across the data-plane can be built." However, I'm actually uncertain how this is supposed to work and what "Unbeknownst to the application" should mean. If another address should be signaled to the other host, this needs to be indicated by the application or at least some kind of policy framework above MPTCP. Also MPTCP will by default use both paths simultaneously while still looking like one connection to the application, meaning the application has no control which path is used for which traffic. I guess you can open a second subflow and then configure the first subflow as backup path but I'm not sure if that's what you want (given the application/policy framework will still not know which path is used)..? Please provide more information about what the expected usage scenario is here. From nobody Fri Jan 5 14:30:49 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927921277BB; Fri, 5 Jan 2018 14:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5VBlbuilwNx; Fri, 5 Jan 2018 14:30:40 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1673912D943; Fri, 5 Jan 2018 14:30:37 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 64C4420096; Fri, 5 Jan 2018 17:35:15 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9379A82E42; Fri, 5 Jan 2018 17:30:35 -0500 (EST) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3Fq=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= cc: "The IESG" , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com In-Reply-To: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-stable-connectivity-07=3A_=28with_DISCUSS=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 22:30:43 -0000 Mirja K=C3=BChlewind wrote: > "DNS naming is set up to provide the ACP IPv6 address of network > devices. Unbeknownst to the application, MPTCP is used. MPTCP > mutually discovers between the NOC and network device the data-plane > address and caries all traffic across it when that MPTCP subflow > across the data-plane can be built." Section 2.1.5 is discussion, it discusses ways in which the anticipated low performance (compared to what the box might do with its hardware accelerated forwarding). If we have an application that needs the bandwidth of the native hardware, the connection can be initated over the ACP (that's what would be in DNS). One presumes that an MPTCP layer could then enumerate the available IPs at each end and then start off additional flows on the other destinations. The application would have to include application security, since it would not be protected by the ACP. Perhaps MPTCP doesn't work this way. > However, I'm actually uncertain how this is supposed to work and what > "Unbeknownst to the application" should mean. If another address shou= ld be > signaled to the other host, this needs to be indicated by the applica= tion or at > least some kind of policy framework above MPTCP. Also MPTCP will by d= efault use > both paths simultaneously while still looking like one connection to = the > application, meaning the application has no control which path is use= d for > which traffic. I guess you can open a second subflow and then configu= re the > first subflow as backup path but I'm not sure if that's what you want= (given > the application/policy framework will still not know which path is us= ed)..? > Please provide more information about what the expected usage scenari= o is here. -- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- From nobody Fri Jan 5 16:21:48 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8FB1270AC; Fri, 5 Jan 2018 16:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7K8q0CcKedy; Fri, 5 Jan 2018 16:21:44 -0800 (PST) Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7EA1126B6E; Fri, 5 Jan 2018 16:21:44 -0800 (PST) Received: by mail-pl0-x242.google.com with SMTP id z5so4015068plo.10; Fri, 05 Jan 2018 16:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lYz5NOX1c9E4KAIcKm/QCAmjYCb/oDhd+JfGYcjai0c=; b=VhG8ncwtRtGa3IT8Wr0om2wY3eEsV35PXfSLklRfuNRfXikfZQIr1oiaX9zN917g2j u5XLWOu626DbS3qF6H25U1MHELTfIUstkC04rxqkTu2g8m0rS7/154lylM36U1SeTbDv wJmJcDvVUlj90eVFt+G9x5Xb1bxAzSdgTylWzSWs7qLaP1hTz7yAw+MGpEdc+eBlTDe+ jPIt1UNeM6ibCy/lJ+retix2u7WYOyX74g4mzu2aGxpEax7V7DWkfMp51dE4w75BgQKq ArxOiGpvMVpno4eSn8l+DF13QpzyRWwTgwnWlep++AkXEKMNTpf7qd5le7FzlTdqKVxa BMcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=lYz5NOX1c9E4KAIcKm/QCAmjYCb/oDhd+JfGYcjai0c=; b=fcrhUQ5GDV749lHO8djwhMGgYD5LbT2NRgGleLG8eB7Uq9Htgk2ycFqsyEfm/AmSBe XHw3VTnfRrU8DxgNRpnWcBz6y+B1rcGoCtNF1fMu4T0p0gOsW1pI0OMpT5PI+ihs3/rl Fh8VtVX3js7eFU+DA4Bkfhz2k3N4mkHoxs7HfaeEKEmvv7Ok2mlXrZJDD86+zyeUxjYh Q6FjtAGFKTRxRqKUH6WrGbsH4RNpuJYMmmxwdMc/OX894sOosgYp+9krhT2GB9/pe9bN ih9BJbOrEzxHf9B13I63FxR68sN2LFvfNeND07Ldu5PU84EU5x0erIJCCn4vto15rwxW 52Zg== X-Gm-Message-State: AKGB3mI5orqKzMz7J7UeIJB1WvE3/KIM3zFSxfmedjHyRADy0QOt/fJU buRJTx7iH2cqifS7enJ6T4w= X-Google-Smtp-Source: ACJfBosUpfAIn5k0z4Qta7MaHqfyT3fpN4jW85BTVaK5a/wAsb0K0K2udUsjo6euC4tgCa2P8usM6g== X-Received: by 10.84.139.195 with SMTP id 61mr645216plr.346.1515198104291; Fri, 05 Jan 2018 16:21:44 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a7sm11952749pgq.85.2018.01.05.16.21.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jan 2018 16:21:43 -0800 (PST) To: Michael Richardson , =?UTF-8?Q?Mirja_K=c3=bchlewind?= Cc: anima-chairs@ietf.org, draft-ietf-anima-stable-connectivity@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 6 Jan 2018 13:21:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5401.1515191435@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-stable-connectivity-07=3A_=28with_DISCUSS=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 00:21:46 -0000 I think Mirja is right. The current text doesn't really make sense, but I think it's mainly an issue of English. However, the notion that MPTCP might spontaneously and silently decide to bypass ACP security by adding a data plane address pair is a major issue that requires a very large red flag. Possibly even a MUST NOT? (Mirja suggested a policy framework above MPTCP. Is there any such framework defined? And in any case, do we want *autonomic* network management to be dependent on some external traditional policy mechanism? I don't think so.) Regards Brian On 06/01/2018 11:30, Michael Richardson wrote: >=20 > Mirja K=C3=BChlewind wrote: > > "DNS naming is set up to provide the ACP IPv6 address of network > > devices. Unbeknownst to the application, MPTCP is used. MPTCP > > mutually discovers between the NOC and network device the data-pl= ane > > address and caries all traffic across it when that MPTCP subflow > > across the data-plane can be built." >=20 > Section 2.1.5 is discussion, it discusses ways in which the > anticipated low performance (compared to what the box might do with its= > hardware accelerated forwarding). >=20 > If we have an application that needs the bandwidth of the native hardwa= re, > the connection can be initated over the ACP (that's what would be in DN= S). > One presumes that an MPTCP layer could then enumerate the available IPs= at > each end and then start off additional flows on the other destinations.= >=20 > The application would have to include application security, since it wo= uld > not be protected by the ACP. >=20 > Perhaps MPTCP doesn't work this way. >=20 > > However, I'm actually uncertain how this is supposed to work and = what > > "Unbeknownst to the application" should mean. If another address = should be > > signaled to the other host, this needs to be indicated by the app= lication or at > > least some kind of policy framework above MPTCP. Also MPTCP will = by default use > > both paths simultaneously while still looking like one connection= to the > > application, meaning the application has no control which path is= used for > > which traffic. I guess you can open a second subflow and then con= figure the > > first subflow as backup path but I'm not sure if that's what you = want (given > > the application/policy framework will still not know which path i= s used)..? > > Please provide more information about what the expected usage sce= nario is here. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Jan 8 02:33:59 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D33A1273B1 for ; Mon, 8 Jan 2018 02:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 HqP7czpLeJnX for ; Mon, 8 Jan 2018 02:33:54 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F21127369 for ; Mon, 8 Jan 2018 02:33:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=TuIGt1MGwOOB88tYff/zNvVG54dUv+ka31ZG4fWEJkGuRz+Zc7ib75O9ohZj+c5Bc9dFw6qX8ylA8JPs2LVFgn6xGBuAn4q9Yd/nE7bXGjPvLVPEArgjb3WR+ic/NLSVUaY0cVg3+1ss3is57uSsj6fH8cCixt9Y0Ot8FtTtgH4=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 26511 invoked from network); 8 Jan 2018 11:33:51 +0100 Received: from i59f723dc.versanet.de (HELO ?192.168.178.33?) (89.247.35.220) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Jan 2018 11:33:51 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Mon, 8 Jan 2018 11:33:49 +0100 Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20180108103351.26501.56349@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-stable-connectivity-07=3A_=28with_DISCUSS=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 10:33:57 -0000 Hi Brian, no there is no policy framework defined. There has be discussion about = path selection in the working group but often it really depends on the = application. Mirja > Am 06.01.2018 um 01:21 schrieb Brian E Carpenter = : >=20 > I think Mirja is right. The current text doesn't really make sense, > but I think it's mainly an issue of English. However, the notion > that MPTCP might spontaneously and silently decide to bypass ACP > security by adding a data plane address pair is a major issue that > requires a very large red flag. Possibly even a MUST NOT? >=20 > (Mirja suggested a policy framework above MPTCP. Is there any such > framework defined? And in any case, do we want *autonomic* network > management to be dependent on some external traditional policy > mechanism? I don't think so.) >=20 > Regards > Brian >=20 > On 06/01/2018 11:30, Michael Richardson wrote: >>=20 >> Mirja K=C3=BChlewind wrote: >>> "DNS naming is set up to provide the ACP IPv6 address of network >>> devices. Unbeknownst to the application, MPTCP is used. MPTCP >>> mutually discovers between the NOC and network device the data-plane >>> address and caries all traffic across it when that MPTCP subflow >>> across the data-plane can be built." >>=20 >> Section 2.1.5 is discussion, it discusses ways in which the >> anticipated low performance (compared to what the box might do with = its >> hardware accelerated forwarding). >>=20 >> If we have an application that needs the bandwidth of the native = hardware, >> the connection can be initated over the ACP (that's what would be in = DNS). >> One presumes that an MPTCP layer could then enumerate the available = IPs at >> each end and then start off additional flows on the other = destinations. >>=20 >> The application would have to include application security, since it = would >> not be protected by the ACP. >>=20 >> Perhaps MPTCP doesn't work this way. >>=20 >>> However, I'm actually uncertain how this is supposed to work and = what >>> "Unbeknownst to the application" should mean. If another address = should be >>> signaled to the other host, this needs to be indicated by the = application or at >>> least some kind of policy framework above MPTCP. Also MPTCP will by = default use >>> both paths simultaneously while still looking like one connection to = the >>> application, meaning the application has no control which path is = used for >>> which traffic. I guess you can open a second subflow and then = configure the >>> first subflow as backup path but I'm not sure if that's what you = want (given >>> the application/policy framework will still not know which path is = used)..? >>> Please provide more information about what the expected usage = scenario is here. >>=20 >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >>=20 >>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 From nobody Mon Jan 8 02:50:42 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BBA127342 for ; Mon, 8 Jan 2018 02:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 ij8RaG1zu1JW for ; Mon, 8 Jan 2018 02:50:37 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6B21273E2 for ; Mon, 8 Jan 2018 02:50:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=F0Uhj7inMGhbjEev0mpx6pMh+Jb4kN0D1Mw4+fMwMxiKGlnS8IFpIW+NradErSRheR7Ze2PTYOvjVb+rXoUavevkOX/ttbyLH72is3z23K8choA9XPghbRzCiq2VpL5Uw0nqTQ5TmTjhchUDak7Hgh4f6CU4tjCdl2Hf82CCuOM=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 26362 invoked from network); 8 Jan 2018 11:30:32 +0100 Received: from i59f723dc.versanet.de (HELO ?192.168.178.33?) (89.247.35.220) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Jan 2018 11:30:32 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <5401.1515191435@obiwan.sandelman.ca> Date: Mon, 8 Jan 2018 11:30:30 +0100 Cc: anima-chairs@ietf.org, draft-ietf-anima-stable-connectivity@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20180108103032.26353.22055@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-stable-connectivity-07=3A_=28with_DISCUSS=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 10:50:38 -0000 Hi Micheal, to clarify one part below:=20 > Am 05.01.2018 um 23:30 schrieb Michael Richardson = : >=20 >=20 > Mirja K=C3=BChlewind wrote: >> "DNS naming is set up to provide the ACP IPv6 address of network >> devices. Unbeknownst to the application, MPTCP is used. MPTCP >> mutually discovers between the NOC and network device the data-plane >> address and caries all traffic across it when that MPTCP subflow >> across the data-plane can be built." >=20 > Section 2.1.5 is discussion, it discusses ways in which the > anticipated low performance (compared to what the box might do with = its > hardware accelerated forwarding). >=20 > If we have an application that needs the bandwidth of the native = hardware, > the connection can be initated over the ACP (that's what would be in = DNS). > One presumes that an MPTCP layer could then enumerate the available = IPs at > each end and then start off additional flows on the other = destinations. MPTCP adda an additional TCP flow but for the application that still = looks like one flow. As I said I=E2=80=99m not sure if that is what you = want. Mirja >=20 > The application would have to include application security, since it = would > not be protected by the ACP. >=20 > Perhaps MPTCP doesn't work this way. >=20 >> However, I'm actually uncertain how this is supposed to work and what >> "Unbeknownst to the application" should mean. If another address = should be >> signaled to the other host, this needs to be indicated by the = application or at >> least some kind of policy framework above MPTCP. Also MPTCP will by = default use >> both paths simultaneously while still looking like one connection to = the >> application, meaning the application has no control which path is = used for >> which traffic. I guess you can open a second subflow and then = configure the >> first subflow as backup path but I'm not sure if that's what you want = (given >> the application/policy framework will still not know which path is = used)..? >> Please provide more information about what the expected usage = scenario is here. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Mon Jan 8 07:47:39 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6F12D72F; Mon, 8 Jan 2018 07:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzODCIVsYgRV; Mon, 8 Jan 2018 07:47:34 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F1F12D574; Mon, 8 Jan 2018 07:47:30 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8971958C4EB; Mon, 8 Jan 2018 16:47:25 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 703DEB0D6B2; Mon, 8 Jan 2018 16:47:25 +0100 (CET) Date: Mon, 8 Jan 2018 16:47:25 +0100 From: Toerless Eckert To: "Mirja Kuehlewind (IETF)" Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com Message-ID: <20180108154725.GA25025@faui40p.informatik.uni-erlangen.de> References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja K?hlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 15:47:38 -0000 Let me know what you think: >> 2.5.1 third to last paragraph:... >> For example, a set-up for non-MPTCP aware applications could be as follows: >> >> Suggested replacement text last two paragraphs of 2.1.5: A (shim) library for aplications maps TCP connections to MPTCP without the applications having to be aware of it. Names in DNS use only the ACP IPv6 addresses of network devices. Thererefore, the initial MPTCP subflow will use the ACP. After it is operating, the shim libraries on both ends add their data-plane address (MPTCP ADD_ADDR) and attempt to build a new subflow between those addresses. If that (data plane) subflow is successfully built, the shim libraries could shift all traffic over this subflow which should be forwarded hardware accelerated by the network - and use the ACP subflow across the ACP solely for signaling - beause it is most resilient against failure. This MPTCP approach is only an outline and would need to be fully speficied for interoperable implementations. It may also require extensions to MP-TCP. This mechanism must not be used without providing for encryption of subflows not running across the ACP. >> Brian: ... can not use capital MUST NOT in an information draft (i think) >> Cheers Toerless On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind (IETF) wrote: > Hi Micheal, > > to clarify one part below: > > > Am 05.01.2018 um 23:30 schrieb Michael Richardson : > > > > > > Mirja Kühlewind wrote: > >> "DNS naming is set up to provide the ACP IPv6 address of network > >> devices. Unbeknownst to the application, MPTCP is used. MPTCP > >> mutually discovers between the NOC and network device the data-plane > >> address and caries all traffic across it when that MPTCP subflow > >> across the data-plane can be built." > > > > Section 2.1.5 is discussion, it discusses ways in which the > > anticipated low performance (compared to what the box might do with its > > hardware accelerated forwarding). > > > > If we have an application that needs the bandwidth of the native hardware, > > the connection can be initated over the ACP (that's what would be in DNS). > > One presumes that an MPTCP layer could then enumerate the available IPs at > > each end and then start off additional flows on the other destinations. > > MPTCP adda an additional TCP flow but for the application that still looks like one flow. As I said I???m not sure if that is what you want. > > Mirja > > > > > > The application would have to include application security, since it would > > not be protected by the ACP. > > > > Perhaps MPTCP doesn't work this way. > > > >> However, I'm actually uncertain how this is supposed to work and what > >> "Unbeknownst to the application" should mean. If another address should be > >> signaled to the other host, this needs to be indicated by the application or at > >> least some kind of policy framework above MPTCP. Also MPTCP will by default use > >> both paths simultaneously while still looking like one connection to the > >> application, meaning the application has no control which path is used for > >> which traffic. I guess you can open a second subflow and then configure the > >> first subflow as backup path but I'm not sure if that's what you want (given > >> the application/policy framework will still not know which path is used)..? > >> Please provide more information about what the expected usage scenario is here. > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Jan 8 08:19:03 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9F812D72F for ; Mon, 8 Jan 2018 08:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 qwZbJ9uTj3gR for ; Mon, 8 Jan 2018 08:18:58 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B231126579 for ; Mon, 8 Jan 2018 08:18:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=ar1GL9478+wayXnaDEnuDejmqIsL2XALH/eIpXMXM8K1d5E2JWxHIxB4Cny0WoleOKq8VNzZZ+EvvxTylZL0sN2hpLOFqrrfLxCTtcB9RebwEa5mdAXNgd8NI2ko/UEae8hvnVcFRNAsyYnOmY6tT3dhVyuqJaoIAkw94c6zAig=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 15542 invoked from network); 8 Jan 2018 17:18:55 +0100 Received: from i59f723dc.versanet.de (HELO ?192.168.178.33?) (89.247.35.220) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Jan 2018 17:18:55 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20180108154725.GA25025@faui40p.informatik.uni-erlangen.de> Date: Mon, 8 Jan 2018 17:18:54 +0100 Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: <29E8737B-D0BA-431C-ABD6-9A79CDB4C094@kuehlewind.net> References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> <20180108154725.GA25025@faui40p.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20180108161855.15532.92892@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja K?hlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 16:19:01 -0000 Hi Toerless, I don=E2=80=99t think that=E2=80=99s how MPTCP works. See blow. > Am 08.01.2018 um 16:47 schrieb Toerless Eckert : >=20 > Let me know what you think: >=20 >>> 2.5.1 third to last paragraph:... >>> For example, a set-up for non-MPTCP aware applications could be as = follows: >>>=20 >>> Suggested replacement text last two paragraphs of 2.1.5: >=20 > A (shim) library for aplications maps TCP connections to MPTCP without = the applications having to be aware of it. It=E2=80=99s not the (shim) library/policy framework that opens/maps the = TCP connection. MPTCP itself opens eventually multiple connections but = exposes only one connection to the layer above. That means everything = above MPTCP does not have any real control about which data is send over = which connection. A policy shim layer could only implement rules about which new subflows = should be established when and what the priority is over which subflow = data should be sent but it generally does not control which data is send = of which flow. You can=E2=80=99t say I want this data to be sent over = subflow one and this data to be sent over sub flow two. I think what you want is actually a view on the different TCP = connections and you try to use MPTCP only for announcing the other IP = address but that is not what MPTCP meant to be. Mirja > Names in DNS use only the ACP IPv6 addresses of network devices. = Thererefore, the initial MPTCP subflow will use the ACP. After it is = operating, the shim libraries on both ends add their data-plane address = (MPTCP ADD_ADDR) and attempt to build a new subflow between those = addresses. If that (data plane) subflow is successfully built, the shim = libraries could shift all traffic over this subflow which should be = forwarded hardware accelerated by the network - and use the ACP subflow = across the ACP solely for signaling - beause it is most resilient = against failure. >=20 > This MPTCP approach is only an outline and would need to be fully = speficied for interoperable implementations. It may also require = extensions to MP-TCP. This mechanism must not be used without providing = for encryption of subflows not running across the ACP. >=20 >>> Brian: ... can not use capital MUST NOT in an information draft (i = think) >>>=20 >=20 > Cheers > Toerless >=20 > On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind (IETF) = wrote: >> Hi Micheal, >>=20 >> to clarify one part below:=20 >>=20 >>> Am 05.01.2018 um 23:30 schrieb Michael Richardson = : >>>=20 >>>=20 >>> Mirja K=C3=BChlewind wrote: >>>> "DNS naming is set up to provide the ACP IPv6 address of network >>>> devices. Unbeknownst to the application, MPTCP is used. MPTCP >>>> mutually discovers between the NOC and network device the = data-plane >>>> address and caries all traffic across it when that MPTCP subflow >>>> across the data-plane can be built." >>>=20 >>> Section 2.1.5 is discussion, it discusses ways in which the >>> anticipated low performance (compared to what the box might do with = its >>> hardware accelerated forwarding). >>>=20 >>> If we have an application that needs the bandwidth of the native = hardware, >>> the connection can be initated over the ACP (that's what would be in = DNS). >>> One presumes that an MPTCP layer could then enumerate the available = IPs at >>> each end and then start off additional flows on the other = destinations. >>=20 >> MPTCP adda an additional TCP flow but for the application that still = looks like one flow. As I said I???m not sure if that is what you want. >>=20 >> Mirja >>=20 >>=20 >>>=20 >>> The application would have to include application security, since it = would >>> not be protected by the ACP. >>>=20 >>> Perhaps MPTCP doesn't work this way. >>>=20 >>>> However, I'm actually uncertain how this is supposed to work and = what >>>> "Unbeknownst to the application" should mean. If another address = should be >>>> signaled to the other host, this needs to be indicated by the = application or at >>>> least some kind of policy framework above MPTCP. Also MPTCP will by = default use >>>> both paths simultaneously while still looking like one connection = to the >>>> application, meaning the application has no control which path is = used for >>>> which traffic. I guess you can open a second subflow and then = configure the >>>> first subflow as backup path but I'm not sure if that's what you = want (given >>>> the application/policy framework will still not know which path is = used)..? >>>> Please provide more information about what the expected usage = scenario is here. >>>=20 >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > --=20 > --- > tte@cs.fau.de From nobody Mon Jan 8 09:09:42 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E451270FC; Mon, 8 Jan 2018 09:09:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUCi5ipMwTSp; Mon, 8 Jan 2018 09:09:33 -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 5433A127010; Mon, 8 Jan 2018 09:09:33 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8442420091; Mon, 8 Jan 2018 12:14:20 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A8FDA827D4; Mon, 8 Jan 2018 12:09:30 -0500 (EST) From: Michael Richardson To: "Mirja Kuehlewind \(IETF\)" cc: anima-chairs@ietf.org, draft-ietf-anima-stable-connectivity@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com In-Reply-To: References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-stable-connectivity-07=3A_=28with_DISCUSS=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 17:09:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mirja Kuehlewind (IETF) wrote: >> Am 05.01.2018 um 23:30 schrieb Michael Richardson : >> >> >> Mirja K=C3=BChlewind wrote: >>> "DNS naming is set up to provide the ACP IPv6 address of network >>> devices. Unbeknownst to the application, MPTCP is used. MPTCP >>> mutually discovers between the NOC and network device the data-plane >>> address and caries all traffic across it when that MPTCP subflow >>> across the data-plane can be built." >> >> Section 2.1.5 is discussion, it discusses ways in which the >> anticipated low performance (compared to what the box might do with = its >> hardware accelerated forwarding). >> >> If we have an application that needs the bandwidth of the native har= dware, >> the connection can be initated over the ACP (that's what would be in= DNS). >> One presumes that an MPTCP layer could then enumerate the available = IPs at >> each end and then start off additional flows on the other destinatio= ns. > MPTCP adda an additional TCP flow but for the application that still > looks like one flow. As I said I=E2=80=99m not sure if that is what y= ou want. I think that this might be exactly what the application might want. As stable-connectivity doesn't detail the requirements of the application, the point of this section is to point out that the bandwidth limitations of the ACP need not be a constraint when the network is healthy. If you feel that 2.1.5 doesn't explain this well, then please say so. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpTpckACgkQgItw+93Q 3WXkpggAwMTvaUYLnvmXHn6Ynpp3o0TLwU+mNB9PdKSVMtEGVGknZvjpg+Qa+JCf 3CyuoPLoxtuMuQIiv2re0eEEVVfCOl2a57CbcKViLsQoeSOUY0VpOXBN7oiVESig cc9g9Fjw6W14LQpywMT4sJB9i2ChtlSj+/9b+EGgS4OuTCcf1Y+UPKIQXweltWOe f6ThxkWpajvQwgd1R0k57tkB0UWi27lIuD/QNLgGp3VvqFdc2czz72eB0oorq1Kh 0m9dD4e2Sv920fCFaeO2lQPrEyQEOh8ZXa/Uxfd9TDPgNBfesxZN0oBu78rUsVQ7 zHRqVRX2PyUlnJGjF9b2JgUA3iwGHQ== =PlLK -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 8 10:30:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9824E12D7E9 for ; Mon, 8 Jan 2018 10:30:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0p3ajvSHUf7 for ; Mon, 8 Jan 2018 10:30:08 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDDC126D46 for ; Mon, 8 Jan 2018 10:30:08 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id d23so6549182pfe.9 for ; Mon, 08 Jan 2018 10:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JKrKXF5bwDb3pEMhKO7xkYYSZHchDoIlJ01lFRhLx7Y=; b=q2WBk7cV6L0wr6NYqqlbzTMzJYXJeJHP7wvEQaQf3T2KRPFuGDb5zq0gD4nwTMqT0L q4qV+NnqRBnkL5C5Yarzn1AqCGbv8uw/aINR4Ahux8Artou8mkdR6gADI+Laixw0cyDi RJLlDimohpuXzPb2r6W5ax7uOmeMpHtwve7rSjwmztiY6h+Q5ujrGs6YerWK2vR4e+rq tzss8IgDm5y1YSD/a04TXzLBhCGyAUTf59j498xLc87pqIPtO7/HGrLw5Rilvwac0Ero eVwi4++ec1b+uBSQrRBBvSAhFb2E9LSBmlv/feJRzhNhJZz5Ai+VrUvgW/e7FFnZJgca 2pIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=JKrKXF5bwDb3pEMhKO7xkYYSZHchDoIlJ01lFRhLx7Y=; b=FHVa+bZCa86HhQtCI/wg9bIMmNLbpUqbPRyx0xy03XEAJFjZoznufCr8Z7AwbA5rwh iaj1TRh5OELPUKD6N/+4i/TJHPn8atLRmviJkXhPageKtEFofAwGU6wrw5Uqgb4HWA7d m2ecwkPSnyK0YJZ7Y4TkdbRywFxfIqQ54VodwlJEcM68eW/gHfIuZOph83K/H8O1rbDL ZBrE0rqNw2BArcZwe/Nv+hcZUd/An4QE8PHuO0lWcHILqdjK8jIIik20p+/zFbjaJu0i 1XtlDCSrkBVoGlAmloQqoOIbTivJz7o9+icexixvN7+lFnoktbdveELPMWKc0vBu7DcW of5Q== X-Gm-Message-State: AKGB3mIf3K9aZywpWLcf4hE7vVGvuqV8cMv3PsOGiRtvVRYJVHyFsj2o rlfQEH9bHo9S0jWbmLesWC1Lmw== X-Google-Smtp-Source: ACJfBotFQhEG0knGI3L0QazcEeuMWEMhCIdAxylzV60p9+mjbDwY5r6hGdg+sYDxL8izuRLaDcgk+g== X-Received: by 10.84.251.134 with SMTP id w6mr12704813pll.230.1515436207241; Mon, 08 Jan 2018 10:30:07 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q74sm27000759pfd.134.2018.01.08.10.30.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jan 2018 10:30:06 -0800 (PST) To: anima@ietf.org References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> <1703.1515431370@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <64bbee71-1421-c726-91fd-b01c2bce5e78@gmail.com> Date: Tue, 9 Jan 2018 07:30:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1703.1515431370@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-stable-connectivity-07=3A_=28with_DISCUSS=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 18:30:13 -0000 On 09/01/2018 06:09, Michael Richardson wrote: >=20 > Mirja Kuehlewind (IETF) wrote: > >> Am 05.01.2018 um 23:30 schrieb Michael Richardson : > >> > >> > >> Mirja K=C3=BChlewind wrote: > >>> "DNS naming is set up to provide the ACP IPv6 address of networ= k > >>> devices. Unbeknownst to the application, MPTCP is used. MPTCP= > >>> mutually discovers between the NOC and network device the data-= plane > >>> address and caries all traffic across it when that MPTCP subflo= w > >>> across the data-plane can be built." > >> > >> Section 2.1.5 is discussion, it discusses ways in which the > >> anticipated low performance (compared to what the box might do w= ith its > >> hardware accelerated forwarding). > >> > >> If we have an application that needs the bandwidth of the native= hardware, > >> the connection can be initated over the ACP (that's what would b= e in DNS). > >> One presumes that an MPTCP layer could then enumerate the availa= ble IPs at > >> each end and then start off additional flows on the other destin= ations. >=20 > > MPTCP adda an additional TCP flow but for the application that st= ill > > looks like one flow. As I said I=E2=80=99m not sure if that is wh= at you want. >=20 > I think that this might be exactly what the application might want. > As stable-connectivity doesn't detail the requirements of the applicati= on, > the point of this section is to point out that the bandwidth limitation= s of > the ACP need not be a constraint when the network is healthy. But that ducks the security issue. I don't think that's OK. Since the ACP= secures connections *below* TCP and MPTCP allows paths that bypass the AC= P, this is a security hole you can drive a large truck through. Brian >=20 > If you feel that 2.1.5 doesn't explain this well, then please say so. >=20 > -- > ] Never tell me the odds! | ipv6 mesh net= works [ > ] Michael Richardson, Sandelman Software Works | network archi= tect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rai= ls [ >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Jan 8 12:19:04 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDCE126BFD for ; Mon, 8 Jan 2018 12:19:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rspleDOydYvf for ; Mon, 8 Jan 2018 12:19:01 -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 6B5E51241F5 for ; Mon, 8 Jan 2018 12:19:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8632520091; Mon, 8 Jan 2018 15:23:50 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 82A0E83159; Mon, 8 Jan 2018 15:19:00 -0500 (EST) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-Reply-To: <64bbee71-1421-c726-91fd-b01c2bce5e78@gmail.com> References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> <1703.1515431370@obiwan.sandelman.ca> <64bbee71-1421-c726-91fd-b01c2bce5e78@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-stable-connectivity-07=3A_=28with_DISCUSS=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 20:19:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> > MPTCP adda an additional TCP flow but for the application that sti= ll >> > looks like one flow. As I said I=E2=80=99m not sure if that is wha= t you want. >> >> I think that this might be exactly what the application might want. >> As stable-connectivity doesn't detail the requirements of the applic= ation, >> the point of this section is to point out that the bandwidth limitat= ions of >> the ACP need not be a constraint when the network is healthy. > But that ducks the security issue. I don't think that's OK. Since the= ACP > secures connections *below* TCP and MPTCP allows paths that bypass th= e ACP, > this is a security hole you can drive a large truck through. Yes, AFAIK, MPTCP doesn't just appear without awareness of the application. Use of MPTCP implies application layer security if there are non-ACP paths. I think that 95% of ASAs will live in a container/network-namespace/VRF that sees ACP interfaces only. Those that do not need to take care anyway. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpT0jQACgkQgItw+93Q 3WVSkwf+KUnJw7lyNpdvOC7a0TfjLfdhaVnLC4NSKZ8x40JBx1EGVR7aYx/bHTBE 3jdztj4JkwLDnoGz+64Yfzou1qtxL8PePDXrdb319IdmHDsfCDAWV4zwIzorULwV ZklypdaZWOKcX91Ei3cAwS7aNsMqXSSuNP+1vFCL5/BeH2KPUF2schVw60u35UfC ezbuZ6WBkQnp5pH2n+L0RYj+UQ6BsCdVlsbSRfwcanX7ArI2dy1pMGeFPmJDZiB3 ySFAmZr+3TpL1dOHkLbqENi8K7aXKaVifbf8zfPTXnwgZJ+FtVnHxjO8uiEP54K1 ahYJlVUT7WXKz9E1MS9PTx+aCpTm0Q== =K5Tg -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 8 13:06:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A3112D7EB; Mon, 8 Jan 2018 13:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vdn9qtFKaoWs; Mon, 8 Jan 2018 13:06:22 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9C2124205; Mon, 8 Jan 2018 13:06:22 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EC42558C4B5; Mon, 8 Jan 2018 22:06:17 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D2D96B0D6C4; Mon, 8 Jan 2018 22:06:17 +0100 (CET) Date: Mon, 8 Jan 2018 22:06:17 +0100 From: Toerless Eckert To: "Mirja Kuehlewind (IETF)" Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com Message-ID: <20180108210617.GA2411@faui40p.informatik.uni-erlangen.de> References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> <20180108154725.GA25025@faui40p.informatik.uni-erlangen.de> <29E8737B-D0BA-431C-ABD6-9A79CDB4C094@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <29E8737B-D0BA-431C-ABD6-9A79CDB4C094@kuehlewind.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja K?hlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 21:06:25 -0000 Thanks, Mirja (a) If the systems socket API does not transparently make TCP sockets to use MPTCP, then you would want a shim library. According to draft-hesmans-mptcp-socket, this is be the case on Apple (iOS). (b) Making the ACP subflow not carry traffic after establishing the data plane subflow should easily be possible possible by setting its MP_PRIO to backup. (c) How exactly to specify or implement the desired policy of only establishing a subflow between the ACP addresses and the data plane addresses (but not full-mesh) seem to be a subject for further spec work. It could be defined as a specific in-MPTCP policy, or it could be done via a shim library (orthogonal to (a)). draft-hesmans-mptcp-socket might be sufficient. But in general: i would like for this (informational!) draft to just motivate the concept and not specify the solution: MPTCP would be a simple way to make "TCP" applications automatically "upgrade" from ACP to a data-plane path and switch back when data-plane fails... because MP-TCP can signal the additional data-plane addresses, establish transparently another subflow and switch traffic between the subflows - all by using the right shim-library+API or in-MP-TCP address/subflow policies - and the ability to establish subflows across two VRFs. Cheers Toerless On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind (IETF) wrote: > >>> Suggested replacement text last two paragraphs of 2.1.5: > > > > A (shim) library for aplications maps TCP connections to MPTCP without the applications having to be aware of it. > > It???s not the (shim) library/policy framework that opens/maps the TCP connection. MPTCP itself opens eventually multiple connections but exposes only one connection to the layer above. That means everything above MPTCP does not have any real control about which data is send over which connection. > > A policy shim layer could only implement rules about which new subflows should be established when and what the priority is over which subflow data should be sent but it generally does not control which data is send of which flow. You can???t say I want this data to be sent over subflow one and this data to be sent over sub flow two. > > I think what you want is actually a view on the different TCP connections and you try to use MPTCP only for announcing the other IP address but that is not what MPTCP meant to be. > > Mirja > > > > Names in DNS use only the ACP IPv6 addresses of network devices. Thererefore, the initial MPTCP subflow will use the ACP. After it is operating, the shim libraries on both ends add their data-plane address (MPTCP ADD_ADDR) and attempt to build a new subflow between those addresses. If that (data plane) subflow is successfully built, the shim libraries could shift all traffic over this subflow which should be forwarded hardware accelerated by the network - and use the ACP subflow across the ACP solely for signaling - beause it is most resilient against failure. > > > > This MPTCP approach is only an outline and would need to be fully speficied for interoperable implementations. It may also require extensions to MP-TCP. This mechanism must not be used without providing for encryption of subflows not running across the ACP. > > > >>> Brian: ... can not use capital MUST NOT in an information draft (i think) > >>> > > > > Cheers > > Toerless > > > > On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind (IETF) wrote: > >> Hi Micheal, > >> > >> to clarify one part below: > >> > >>> Am 05.01.2018 um 23:30 schrieb Michael Richardson : > >>> > >>> > >>> Mirja Kühlewind wrote: > >>>> "DNS naming is set up to provide the ACP IPv6 address of network > >>>> devices. Unbeknownst to the application, MPTCP is used. MPTCP > >>>> mutually discovers between the NOC and network device the data-plane > >>>> address and caries all traffic across it when that MPTCP subflow > >>>> across the data-plane can be built." > >>> > >>> Section 2.1.5 is discussion, it discusses ways in which the > >>> anticipated low performance (compared to what the box might do with its > >>> hardware accelerated forwarding). > >>> > >>> If we have an application that needs the bandwidth of the native hardware, > >>> the connection can be initated over the ACP (that's what would be in DNS). > >>> One presumes that an MPTCP layer could then enumerate the available IPs at > >>> each end and then start off additional flows on the other destinations. > >> > >> MPTCP adda an additional TCP flow but for the application that still looks like one flow. As I said I???m not sure if that is what you want. > >> > >> Mirja > >> > >> > >>> > >>> The application would have to include application security, since it would > >>> not be protected by the ACP. > >>> > >>> Perhaps MPTCP doesn't work this way. > >>> > >>>> However, I'm actually uncertain how this is supposed to work and what > >>>> "Unbeknownst to the application" should mean. If another address should be > >>>> signaled to the other host, this needs to be indicated by the application or at > >>>> least some kind of policy framework above MPTCP. Also MPTCP will by default use > >>>> both paths simultaneously while still looking like one connection to the > >>>> application, meaning the application has no control which path is used for > >>>> which traffic. I guess you can open a second subflow and then configure the > >>>> first subflow as backup path but I'm not sure if that's what you want (given > >>>> the application/policy framework will still not know which path is used)..? > >>>> Please provide more information about what the expected usage scenario is here. > >>> > >>> > >>> -- > >>> Michael Richardson , Sandelman Software Works > >>> -= IPv6 IoT consulting =- > >>> > >>> > >>> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Mon Jan 8 22:19:33 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9874712025C; Mon, 8 Jan 2018 22:19:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: anima-chairs@ietf.org, bclaise@cisco.com, anima@ietf.org, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151547877157.9516.14821824963028292962.idtracker@ietfa.amsl.com> Date: Mon, 08 Jan 2018 22:19:31 -0800 Archived-At: Subject: [Anima] anima - New Meeting Session Request for IETF 101 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 06:19:32 -0000 A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man Second Priority: roll v6ops dhc homenet netconf Third Priority: cfrg saag intarea opsarea People who must be present: Toerless Eckert Benoit Claise Sheng Jiang Terry Manderson Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Mon Jan 8 22:26:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFAB1243F3; Mon, 8 Jan 2018 22:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bag5eM-WVES; Mon, 8 Jan 2018 22:26:12 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A1112025C; Mon, 8 Jan 2018 22:26:12 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 063D2EBFB5E23; Tue, 9 Jan 2018 06:26:08 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 9 Jan 2018 06:26:08 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Tue, 9 Jan 2018 14:26:03 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 Thread-Index: AdOJEiPxBjmGgiajRyCx9CbcS+aTGw== Date: Tue, 9 Jan 2018 06:26:03 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B928180BE62NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 06:26:14 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B928180BE62NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This message starts the two-week ANIMA Working Group Last Call to advance d= raft-ietf-anima-reference-model-05, A Reference Model for Autonomic Network= ing. This document's intended status is Informational. At present, there is= no IPR file against this document. Please send your comments by January 22nd, 2018. If you do not feel this do= cument should advance, please state your reasons why. Sheng JIANG is the assigned document shepherd. Regards, Sheng (co-chair, Toerless who as a co-author stayed neutral on the content = side) --_000_5D36713D8A4E7348A7E10DF7437A4B928180BE62NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

 <= o:p>

This message starts the two-week ANIMA Working Group Last Call to a= dvance draft-ietf-anima-reference-model-05, A Reference Model for Autonomic= Networking. This document's intended status is Informational. At present, there is no IPR file against this doc= ument.

 <= o:p>

Please send your comments by January 22nd, 2018. If you do not feel= this document should advance, please state your reasons why.

 <= o:p>

Sheng JIANG is the assigned document shepherd.

 <= o:p>

Regards,

 

Sheng (co-chair, Toerless who as a co-author stayed neutral on the = content side)

 

--_000_5D36713D8A4E7348A7E10DF7437A4B928180BE62NKGEML515MBXchi_-- From nobody Tue Jan 9 00:31:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44F12D7EB for ; Tue, 9 Jan 2018 00:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04MDWfHHOubU for ; Tue, 9 Jan 2018 00:31:10 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655C5126D74 for ; Tue, 9 Jan 2018 00:31:10 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7ABDA58C4F7; Tue, 9 Jan 2018 09:31:01 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 68FF0B0D6CC; Tue, 9 Jan 2018 09:31:01 +0100 (CET) Date: Tue, 9 Jan 2018 09:31:01 +0100 From: Toerless Eckert To: Michael Richardson Cc: Brian E Carpenter , anima@ietf.org Message-ID: <20180109083101.GB2411@faui40p.informatik.uni-erlangen.de> References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> <1703.1515431370@obiwan.sandelman.ca> <64bbee71-1421-c726-91fd-b01c2bce5e78@gmail.com> <15055.1515442740@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15055.1515442740@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja K?hlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 08:31:12 -0000 On Mon, Jan 08, 2018 at 03:19:00PM -0500, Michael Richardson wrote: > Yes, AFAIK, MPTCP doesn't just appear without awareness of hearsay from folks i talked to and e.g.: the intro of draft-hesmans-mptcp-socket, and that states for example that MP-TCP in linux kernel does seem to work without knowledge of the (TCP) app. Time to enable MP-TCP myself and play around with it ;-)) > Use of MPTCP implies application layer security if there are non-ACP paths. Right. I did include that based on Brians comment into the proposed text in my last email to Mirja. > I think that 95% of ASAs will live in a container/network-namespace/VRF that > sees ACP interfaces only. Those that do not need to take care anyway. Good question... Need to design more example ASA to know which of them would need access to data-plane. Certainly the ones that want to monitor the data-plane (IP-SLA like ASA). Cheers Toerless From nobody Tue Jan 9 05:57:18 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5417F12D851 for ; Tue, 9 Jan 2018 05:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMVBRmadUjrs for ; Tue, 9 Jan 2018 05:57:15 -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 A6A21120713 for ; Tue, 9 Jan 2018 05:57:15 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 175D820091; Tue, 9 Jan 2018 09:02:07 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8345683673; Tue, 9 Jan 2018 08:57:14 -0500 (EST) From: Michael Richardson To: Toerless Eckert cc: Brian E Carpenter , anima@ietf.org In-Reply-To: <20180109083101.GB2411@faui40p.informatik.uni-erlangen.de> References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> <1703.1515431370@obiwan.sandelman.ca> <64bbee71-1421-c726-91fd-b01c2bce5e78@gmail.com> <15055.1515442740@obiwan.sandelman.ca> <20180109083101.GB2411@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Mirja K?hlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 13:57:17 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: >> I think that 95% of ASAs will live in a container/network-namespace/VRF that >> sees ACP interfaces only. Those that do not need to take care anyway. > Good question... Need to design more example ASA to know which of them > would need access to data-plane. Certainly the ones that want to monitor the > data-plane (IP-SLA like ASA). Depends upon what kind of monitoring; it could all be available via counters and controls which are "remote" a la SNMP. I think that a lot depends upon the router OS. I agree that we need more examples. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpUyjkACgkQgItw+93Q 3WWdngf9HbPw2loRPcdK9RnKivYvFszX4ImidwJwwIneOkeo+opDuz/R3AC0Yljg ecgZxIPnexAO12I374EdYMwskhGli60Tm+xTod4ffR/YREfiaCjfL1y2LofhLBZ8 IKyQvLfXhFlqW2DlTyPIxTGn1iKKm7vIxAvYYPOQAu5gQQxrrw2G4u+0+bohtwMP ytEup/J92Tn9ZiLalsVLe/VfQl9jRQlHQZ6ptDw3PLhtcfiA/eWJfo07XZCDXSNN Cuml3sq7r10vkKRpSeRFwqmbqTMNyZWT3Ds4H6P2ANnGwDwf+YGidnbQR6lXRA30 U+zsVe+z8QHUOdsr/ubAUn4eI8WFhg== =fiEG -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 9 13:02:09 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A691126BFD; Tue, 9 Jan 2018 13:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mtK6TuT_CxH; Tue, 9 Jan 2018 13:02: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 5F7FE126BF6; Tue, 9 Jan 2018 13:02:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1D5B220091; Tue, 9 Jan 2018 16:06:48 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7AD6F80667; Tue, 9 Jan 2018 16:01:54 -0500 (EST) From: Michael Richardson To: Toerless Eckert cc: "Mirja Kuehlewind \(IETF\)" , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com In-Reply-To: <20180108210617.GA2411@faui40p.informatik.uni-erlangen.de> References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> <20180108154725.GA25025@faui40p.informatik.uni-erlangen.de> <29E8737B-D0BA-431C-ABD6-9A79CDB4C094@kuehlewind.net> <20180108210617.GA2411@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Mirja K?hlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 21:02:07 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > But in general: i would like for this (informational!) draft to just motivate > the concept and not specify the solution: MPTCP would be a simple way to > make "TCP" applications automatically "upgrade" from ACP to a data-plane path > and switch back when data-plane fails... because MP-TCP can signal the > additional data-plane addresses, establish transparently another subflow and switch > traffic between the subflows - all by using the right shim-library+API or > in-MP-TCP address/subflow policies - and the ability to establish subflows > across two VRFs. Perhaps we need some examples to motivate why the ACP wouldn't be enough. Some obvious ones to me are: a) firmware updates b) transfering VM images onto the target equipment --- the ASA is a priviledged domain in a hypervisor system. c) things like mirror port/captures that need to be offloaded quickly as they can not be stored. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpVLcIACgkQgItw+93Q 3WU+Lwf9GjSymI/RXMl8Ju5Eth9Ix0zAg7Om5hRV00sTgU9Sh9M0E8PXf6K15byf 0FPkrUIFQ90qg6z3s+rihaUvYXM79vOv0YkyOTw4HTkTmsFjR7LFjR9IC78QAtU5 qDqhp6vDj1RtBKPyw1gkQdonnw/UoUlBmW2KSe6q56HVLOtEG8dQuSd/8/oSKMjA Y42+NR94MIM52w62qz39/es9Pcs81QK1d+jny5//RpOZmbZDA1jRfx0bBqDwcwMc BRNUuYonSURuYw6cVOPt9t5gwc0YeDevUGkvm2gIxLl6jlD29HyCLEvnVbP3yZj6 N1fkRvNFYRsMLDU8B3nqnvkdSCwrAg== =tGnT -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 9 13:32:57 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D71127735; Tue, 9 Jan 2018 13:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLpzyeiqmLaO; Tue, 9 Jan 2018 13:32:54 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B921275C5; Tue, 9 Jan 2018 13:32:54 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id q12so8875728pgt.7; Tue, 09 Jan 2018 13:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vopClsrPyDBHDkz05KroedhSb4vSHaKpm6Cqom4QuVk=; b=aGgTiFJi4Z3NrdV4kx0Qg0iYsjihuaLtKlU5xRaz5xRvi28H6pc6WnqU4XzqsFEE+A r6rjimLzyqB1ilLCXMIP5cOB7LUacXtPyDUqvBSMgvxsgfBn5PwLcvv7RNgdCvKqxo6b HZUAqS0xaoO+m/0/rKgnbgZ56jqpdCaz+HpiEcYhTY/9SNCgz2I+HNAqPYOTcIecgs9N KJwF74FAC6slXbLID4z0r33kRACK/VHPT+DNZK3u5WpjXeG2p5Bg1FSZUQoGNxzv2TTd YVrQLCyBEmwV2mJWin8HvRbyX9TXXJjW3uQyeI+Vx9DtGbJy5IP9JDcTqL6JcpdSpYR0 BU9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=vopClsrPyDBHDkz05KroedhSb4vSHaKpm6Cqom4QuVk=; b=gxynITbbs8GemmVnib3FzL5wYdb+A/ErvP0ojN9RCLBXVWQSdtsMRvcl/Hs18GwTlg myn7QJRgC0/IVj223AI6mNBnG3xham4+2ZzR/7XZmyC8wKFd6GZJoZsq+iieiqcvLb5J mEHCjzF/cgjjqUtGV8PwJ4Eu2HqnYJ59ctaN0bMDc0vU6/b9cGKe5btXLedxg/FL25xl pByKNLbhYJLPIh3CKsvSyoGuXxhHf4nkmHyLb0KIeJqwcNBsftsv/w0nfWOO9FnCtZGc w8g2tFwu65mT2GTGIeixZHV0xZqXn8GdwF2jp0vUljVgh1r548sHDV/eR0ryyNdbyDts XDiA== X-Gm-Message-State: AKGB3mK9Pr8fLZ3QmiGpGyVhgl7y6WIn41Hh8l82/JKjRseOsVmXWvbp f5VVYGbwT+ItecLSgZgutPPivg== X-Google-Smtp-Source: ACJfBovbDVTQKoUXJfSsjGShd2SEh+Dqhc4sCQwbzjHsv0kYxKdChm0wPaZ0bnFhBjeW3zB+wQvyqA== X-Received: by 10.101.75.5 with SMTP id r5mr13432391pgq.215.1515533573776; Tue, 09 Jan 2018 13:32:53 -0800 (PST) Received: from [130.216.38.150] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.150]) by smtp.gmail.com with ESMTPSA id l64sm9641876pfi.46.2018.01.09.13.32.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 13:32:52 -0800 (PST) To: Sheng Jiang , "anima@ietf.org" Cc: "anima-chairs@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 10 Jan 2018 10:32:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 21:32:56 -0000 Hi, I am a co-author of this draft. I do believe that it is ready to advance, and that it's useful to get it published soon so that it can indeed act as a reference model. We know that a second edition will probably be needed to include future work. (At least one minor correction is pending in the XML source: https://github.com/mbehring/ANIMA-Reference-Model/commit/163999c1d03599 ) Regards Brian Carpenter On 09/01/2018 19:26, Sheng Jiang wrote: > Hi all, > > This message starts the two-week ANIMA Working Group Last Call to advance draft-ietf-anima-reference-model-05, A Reference Model for Autonomic Networking. This document's intended status is Informational. At present, there is no IPR file against this document. > > Please send your comments by January 22nd, 2018. If you do not feel this document should advance, please state your reasons why. > > Sheng JIANG is the assigned document shepherd. > > Regards, > > Sheng (co-chair, Toerless who as a co-author stayed neutral on the content side) > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jan 9 14:29:48 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E3A12D7E3; Tue, 9 Jan 2018 14:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrttvFjyLznU; Tue, 9 Jan 2018 14:29:45 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB6012773A; Tue, 9 Jan 2018 14:29:44 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id k19so2545816pfj.5; Tue, 09 Jan 2018 14:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yM31coqaUmGbttr/bn6Goyg216zO21W++/dXgsHgOUw=; b=Ns4KNm3IRy6d+S+6RxumnStHEazKlrue45IuPfNjirP1Z+NhCG8NC8qjIGZtR99JsL A9X56UNZAzLI0FjjVjQgw7MtjJk1hZ4i2Ysqwzj+ajhFcV4qaGKZc7Pinjek3VzfXutF D7KGWsM/rgEYtCjqQA1PjGRgiuNfL+SdYfXug15Op+52eiuf1LjiV3nYbAyVk1B2+SOz +ogU63djIxu5qSGOnzYj/nqrpehF7uxeW359qv/x4aO+kzoBn8OxSGTwDQUFcFXLlEaL l8PkcjCsdosJaBUM3oX33fOWsdVignSWetORxWuo2MIZ8jFfNi9hscdrX5BkdX9oWdUy GJTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=yM31coqaUmGbttr/bn6Goyg216zO21W++/dXgsHgOUw=; b=diPJhnk/UW4M0+BjTvMtldfYMCFtNdeZ4WBddwPUSXTDSe1rSlXHpNyMekvajGiQAA RQBN0k/JTMOP2RZfEtx3yYeVdN7ZfrjRBXAEjIvisPg5IfaiAMrGADXMYH/v14iA+2IV X/jCyz0d7FaoaCcGO9KeX9xZDAXN5/MzLcU85dDIyN0YQXCkaqV3nmnKBSybgA21A926 o45bSCeoFcMsO/zi2MG1bOsTW7y/OCm6j37+wH0iIeUVmPNu3yOtRdziVricwqWO4O/q pp43VWMF6VDxvtA43mv5GMq32rxK2Pydx8oIo9F1XWT/82RUgbi15MTO7uC1SJTEHe0e X7Zg== X-Gm-Message-State: AKGB3mLuqANbrOPpX6XNHm7TbZmQtqznJbyyVNV1+2r2+an4oqhKI1Xj 23VfOpV5pts+6n70bSdW2d4= X-Google-Smtp-Source: ACJfBosSC70ywhkEVtbpjeDW516oUT4sIGuOPJBzO1Px/RAR/ijQot5sHxksC1XOtuIgoj2IQa/yaQ== X-Received: by 10.159.242.199 with SMTP id x7mr8756056plw.94.1515536984443; Tue, 09 Jan 2018 14:29:44 -0800 (PST) Received: from [130.216.38.150] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.150]) by smtp.gmail.com with ESMTPSA id q17sm3939110pfh.16.2018.01.09.14.29.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 14:29:43 -0800 (PST) To: Michael Richardson , Toerless Eckert Cc: draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, "Mirja Kuehlewind (IETF)" , The IESG , anima@ietf.org, jiangsheng@huawei.com References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> <20180108154725.GA25025@faui40p.informatik.uni-erlangen.de> <29E8737B-D0BA-431C-ABD6-9A79CDB4C094@kuehlewind.net> <20180108210617.GA2411@faui40p.informatik.uni-erlangen.de> <12310.1515531714@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4dca3682-cfd5-c5d9-3cf8-c527c6a21e6e@gmail.com> Date: Wed, 10 Jan 2018 11:29:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <12310.1515531714@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Mirja K?hlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 22:29:46 -0000 On 10/01/2018 10:01, Michael Richardson wrote: > > Toerless Eckert wrote: > > But in general: i would like for this (informational!) draft to just motivate > > the concept and not specify the solution: MPTCP would be a simple way to > > make "TCP" applications automatically "upgrade" from ACP to a data-plane path > > and switch back when data-plane fails... because MP-TCP can signal the > > additional data-plane addresses, establish transparently another subflow and switch > > traffic between the subflows - all by using the right shim-library+API or > > in-MP-TCP address/subflow policies - and the ability to establish subflows > > across two VRFs. > > Perhaps we need some examples to motivate why the ACP wouldn't be enough. > Some obvious ones to me are: > a) firmware updates > b) transfering VM images onto the > target equipment --- the ASA is a priviledged domain in a hypervisor > system. > c) things like mirror port/captures that need to be offloaded quickly > as they can not be stored. Isn't that discussion broader in scope than the stable-connectivity draft? Brian From nobody Tue Jan 9 15:31:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6CA1241F5; Tue, 9 Jan 2018 15:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3joNHztYUDa; Tue, 9 Jan 2018 15:31:47 -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 A7A70120713; Tue, 9 Jan 2018 15:31:47 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6862220091; Tue, 9 Jan 2018 18:36:40 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 84ADD80667; Tue, 9 Jan 2018 18:31:46 -0500 (EST) From: Michael Richardson To: Brian E Carpenter cc: Toerless Eckert , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, "Mirja Kuehlewind \(IETF\)" , The IESG , anima@ietf.org, jiangsheng@huawei.com In-Reply-To: <4dca3682-cfd5-c5d9-3cf8-c527c6a21e6e@gmail.com> References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> <20180108154725.GA25025@faui40p.informatik.uni-erlangen.de> <29E8737B-D0BA-431C-ABD6-9A79CDB4C094@kuehlewind.net> <20180108210617.GA2411@faui40p.informatik.uni-erlangen.de> <12310.1515531714@obiwan.sandelman.ca> <4dca3682-cfd5-c5d9-3cf8-c527c6a21e6e@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Mirja K?hlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 23:31:49 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Toerless Eckert wrote: >> > But in general: i would like for this (informational!) draft to just motivate >> > the concept and not specify the solution: MPTCP would be a simple way to >> > make "TCP" applications automatically "upgrade" from ACP to a data-plane path >> > and switch back when data-plane fails... because MP-TCP can signal the >> > additional data-plane addresses, establish transparently another subflow and switch >> > traffic between the subflows - all by using the right shim-library+API or >> > in-MP-TCP address/subflow policies - and the ability to establish subflows >> > across two VRFs. >> Perhaps we need some examples to motivate why the ACP wouldn't be enough. >> Some obvious ones to me are: >> a) firmware updates >> b) transfering VM images onto the >> target equipment --- the ASA is a priviledged domain in a hypervisor >> system. >> c) things like mirror port/captures that need to be offloaded quickly >> as they can not be stored. > Isn't that discussion broader in scope than the stable-connectivity draft? Maybe.... I am suggesting that maybe the motivation would help explain the utility of the connectivity. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpVUOIACgkQgItw+93Q 3WXojgf+NCeSn+eHH7C5EiZIu0n8DrZ/AYOxfr8V2cG3D/ux2Ln+4sbCz1ib6vii Jdrv+QyuX3b3+XSUxo/Ij/ECYsNcjINe5MaKmWLxkOW1XKwjqnAuhPVeZ6tp5d1Q 70zozELzeb1sCelBcjsp36u04yz5SylUM6mXh0wgPTTkSUFrGV5u0NtOh8GG0sMV 2luag/u+HJLyYxiB1IE5OEdm78SKdsgZugcO2rokxtBeRQPBmjvcEUCf2Qds2dKm sWiO5MbaD6HUSAVENP4gGFW6xcEi2NpMaM7iE7yRASdkKRzJ8Hib03FAaWUJa1LM rUgZSf6Q4SLR3/enERQWZrmQqT6J4g== =ADWi -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 9 17:37:28 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6FD12711D; Tue, 9 Jan 2018 17:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ_Q6DhUmRJ6; Tue, 9 Jan 2018 17:37:23 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9F26124C27; Tue, 9 Jan 2018 17:37:22 -0800 (PST) Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2EE062782B3; Wed, 10 Jan 2018 10:37:19 +0900 (JST) Received: by mail-wm0-f48.google.com with SMTP id f140so23982255wmd.2; Tue, 09 Jan 2018 17:37:19 -0800 (PST) X-Gm-Message-State: AKGB3mIRue/1hCncHpPbRPPC87geHo75YzeYqqifJXHheAAdhS2YvfsX Z47/156RiMOGzlZqVI7B53LLn0YqhveYePWA3vI= X-Google-Smtp-Source: ACJfBou5LIsoA5jVL18fVOYNKBGkJhCgGfan3FzOCAKu0Te2ohvZDqgmgHAYmnji5+74Tn8YYZ3mouGgkgNuWltNWeI= X-Received: by 10.28.50.67 with SMTP id y64mr13363201wmy.145.1515548237128; Tue, 09 Jan 2018 17:37:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.147.199 with HTTP; Tue, 9 Jan 2018 17:37:16 -0800 (PST) From: Yoshifumi Nishida Date: Tue, 9 Jan 2018 17:37:16 -0800 X-Gmail-Original-Message-ID: Message-ID: To: dreft-ietf-anima-stable-connectivity@ietf.org, tsv-art@ietf.org, anima@ietf.org Content-Type: multipart/alternative; boundary="001a11412d7450699805626212c5" Archived-At: Subject: [Anima] TSV-ART telechat review of draft-ietf-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 01:37:26 -0000 --001a11412d7450699805626212c5 Content-Type: text/plain; charset="UTF-8" I've reviewed this document as part of TSV-ART's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised.When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art @ietf.org if you reply to or forward this review. Summary: This document is almost ready for publication, but several points need to be clarified or updated. 1: In Section 2.1.5 " MPTCP (Multipath TCP -see [RFC6824]) is a very attractive candidate to automate the use of both data-plane and ACP and minimize or fully avoid the need for the above mentioned logical names to pre-set the desired connectivity (data-plane-only, ACP only, both). For example, a set-up for non MPTCP aware applications would be as follows: DNS naming is set up to provide the ACP IPv6 address of network devices. Unbeknownst to the application, MPTCP is used. MPTCP mutually discovers between the NOC and network device the data-plane address and caries all traffic across it when that MPTCP subflow across the data-plane can be built. " It's not very clear to me how to archive this feature. I think more explanation will be required. As MPTCP resides in transport layer, I think it will be very tricky to know which endpoint is used for ACP or for data-plane. Also, although MPTCP can transmit application data to multiple destinations, it cannot identify which part of data is for ACP or for data-plane as it doesn't parse app data. 2: in Section 2.1.8 " Leverage and as necessary enhance MPTCP with automatic dual- connectivity: If an MPTCP unaware application is using ACP connectivity, the policies used should add subflow(s) via the data-plane and prefer them. " I think functions like controlling policies should be designed outside of MPTCP such as middleware between applications and transport layer, but the text is unclear about how to enhance MPTCP. Thanks, -- Yoshi --001a11412d7450699805626212c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I&#= 39;ve reviewed this document as part of=C2=A0= TSV-= ART's ongoing effort to review= key IETF documents. These comments were written primarily for the transpor= t area directors, but are copied to the document's authors for their in= formation and to allow them to address any issues raised.When done at the t= ime of IETF Last Call, the authors should consider this review together wit= h any other last-call comments they receive. Please always CC=C2=A0<= a href=3D"mailto:tsv-art@ietf.org" style=3D"font-family:arial,helvetica,san= s-serif" target=3D"_blank">tsv-art@ietf.org=C2=A0if you reply to or forward this review.

Summary= :=C2=A0This document is almost ready for publication, but several points ne= ed to be clarified or updated.

1: In Se= ction 2.1.5
"
=C2=A0 MPTCP (Multipath TCP -see [RFC6824]) is a very attractive candidat= e
=C2=A0 to automate the use of both data-plane and AC= P and minimize or fully
=C2=A0 avoid the need for the = above mentioned logical names to pre-set the
=C2=A0 de= sired connectivity (data-plane-only, ACP only, both).=C2=A0 For example,
=C2=A0 a set-up for non MPTCP aware applications would b= e as follows:

=C2=A0 DNS nam= ing is set up to provide the ACP IPv6 address of network
=C2=A0 devices.=C2=A0 Unbeknownst to the application, MPTCP is used.=C2= =A0 MPTCP
=C2=A0 mutually discovers between the NOC an= d network device the data-plane
=C2=A0 address and car= ies all traffic across it when that MPTCP subflow
=C2= =A0 across the data-plane can be built.
"

It's not very clear to me how t= o archive this feature.
I think more explanation will = be required.
As MPTCP resides in transport layer, I th= ink it will be very tricky to know
which endpoint is u= sed for ACP or for data-plane. Also, although MPTCP
ca= n transmit application data to multiple destinations, it cannot
identify which part of data is for ACP or for data-plane as it do= esn't parse app data.

2:= in Section 2.1.8

"
=C2=A0 Leverage and as necessary enhance MPTCP with autom= atic dual-
=C2=A0 connectivity: If an MPTCP unaware ap= plication is using ACP
=C2=A0 connectivity, the polici= es used should add subflow(s) via the
=C2=A0 data-plan= e and prefer them.
"

I think functions like controlling policies should be de= signed outside of MPTCP such as middleware=C2=A0
betwe= en applications and transport layer, but the text is unclear about how to e= nhance MPTCP.

Thanks,
<= div style=3D"">--
Yoshi

--001a11412d7450699805626212c5-- From nobody Wed Jan 10 12:41:27 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC52212DDD2; Wed, 10 Jan 2018 12:41:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Martinez To: Cc: ietf@ietf.org, anima@ietf.org, draft-ietf-anima-stable-connectivity.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151561686872.26690.9031629570082529218@ietfa.amsl.com> Date: Wed, 10 Jan 2018 12:41:08 -0800 Archived-At: Subject: [Anima] Opsdir last call review of draft-ietf-anima-stable-connectivity-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 20:41:09 -0000 Reviewer: Carlos Martinez Review result: Ready Reviewer: Carlos Martinez Review Result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I found this document well-written, informative and easy to read. I believe it to be READY for publication as an informational document. >From an editorial pov tt does have numerous typos and sometimes uses colloquial language which IMO would be best if changed into more formal prose. Other reviewers have already pointed this out as well. >From a technical point of view, the only aspect that I feel could be worth reconsidering is whether considering very complex use cases involving IPv4-to-IPv6 conversions really makes sense. Such complexity could very well offset the advantages obtained from applying the ACP to the particular problem of network management. Again, this is not an "issue" in the document since it's more related to my opinion on the matter. My thanks go to the authors for a very informative and nice to read document. /Carlos From nobody Wed Jan 10 13:06:25 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C02112D7E2; Wed, 10 Jan 2018 13:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXmF4cC3vmVq; Wed, 10 Jan 2018 13:06:22 -0800 (PST) Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0D01273E2; Wed, 10 Jan 2018 13:06:21 -0800 (PST) Received: by mail-lf0-f52.google.com with SMTP id j143so400230lfg.0; Wed, 10 Jan 2018 13:06:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A/P37rW8dL8S0UArbIA0zszRHUR+uHOceluYjYS2/C4=; b=lm2EjubCwMNh3xh812ryOu53+28gYCHgifG8Wf6CwdbDzN+nssGje8KN34+EqSWCeM FdSSZRv9m9KreNfxNSzgfWJZQ0FJ3SOM9c+33i4u0inLupnrzSS4V3HqGlaDa+zIsSTz DX2eW6rRT89GI+TIHF8q43gtz/tWeN5kbF3CWeLFrdw5PguJ1/LwvcgErVwNZwwXzUXH 5T+u4SeYwLpfodBYr/ig5XY5KrwujjLvSrOTZ1T0ZL7QYnoltwSbulvYAMDUBKwSNyuu eL/aTVXpzCV4I+GOH46yKsqgO/Y1oCjbqVmuFSYF5+ESfUKFEbP9zoFetXeyhcdlpsuA aE5Q== X-Gm-Message-State: AKGB3mKCZjEqNrigMOEwKgaQV3/gJelHx0tJVRRZufh/bJSLO84aqpY5 3PMVx7eP/UhLgo00ZvotufFtPfPWOJzl+D4NAQ== X-Google-Smtp-Source: ACJfBouzNQBhQMtdlIkYhTTSLNMn7eb+UA2UVR8HJrBKzCXpTdhrxeBSbhXY3Esyc4cRK3J/2V4LrJfaFoZ2z1G035s= X-Received: by 10.46.14.25 with SMTP id 25mr11360995ljo.43.1515618379845; Wed, 10 Jan 2018 13:06:19 -0800 (PST) MIME-Version: 1.0 References: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> In-Reply-To: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Wed, 10 Jan 2018 21:06:08 +0000 Message-ID: To: Brian E Carpenter Cc: Sheng Jiang , "anima@ietf.org" , "anima-chairs@ietf.org" Content-Type: multipart/alternative; boundary="f403045ea60825561d05627267c1" Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 21:06:24 -0000 --f403045ea60825561d05627267c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Anima. I am also a co-author of this draft and I think it is in a good shape to advance. Besides that, I believe the publication of the reference model is an important step for the WG. Best. J=C3=A9ferson Em ter, 9 de jan de 2018 =C3=A0s 19:32, Brian E Carpenter < brian.e.carpenter@gmail.com> escreveu: > Hi, > > I am a co-author of this draft. I do believe that it is ready to advance, > and that it's useful to get it published soon so that it can indeed act a= s > a reference model. We know that a second edition will probably be needed = to > include future work. > > (At least one minor correction is pending in the XML source: > https://github.com/mbehring/ANIMA-Reference-Model/commit/163999c1d03599 ) > > Regards > Brian Carpenter > > On 09/01/2018 19:26, Sheng Jiang wrote: > > Hi all, > > > > This message starts the two-week ANIMA Working Group Last Call to > advance draft-ietf-anima-reference-model-05, A Reference Model for > Autonomic Networking. This document's intended status is Informational. A= t > present, there is no IPR file against this document. > > > > Please send your comments by January 22nd, 2018. If you do not feel thi= s > document should advance, please state your reasons why. > > > > Sheng JIANG is the assigned document shepherd. > > > > Regards, > > > > Sheng (co-chair, Toerless who as a co-author stayed neutral on the > content side) > > > > > > > > > > _______________________________________________ > > 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 > --f403045ea60825561d05627267c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Anima.
I am also a co-author of this draft and I = think it is in a good shape to advance. Besides that, I believe the publica= tion of the reference model is an important step for the WG.
Best= .
J=C3=A9ferson

Em ter, 9 de jan de 2018 =C3=A0s 19:32, Brian E Carpenter <brian.e.carpenter@gmail.com> esc= reveu:
Hi,

I am a co-author of this draft. I do believe that it is ready to advance, a= nd that it's useful to get it published soon so that it can indeed act = as a reference model. We know that a second edition will probably be needed= to include future work.

(At least one minor correction is pending in the XML source:
https://github.com/mbehring/A= NIMA-Reference-Model/commit/163999c1d03599 )

Regards
=C2=A0 =C2=A0Brian Carpenter

On 09/01/2018 19:26, Sheng Jiang wrote:
> Hi all,
>
> This message starts the two-week ANIMA Working Group Last Call to adva= nce draft-ietf-anima-reference-model-05, A Reference Model for Autonomic Ne= tworking. This document's intended status is Informational. At present,= there is no IPR file against this document.
>
> Please send your comments by January 22nd, 2018. If you do not feel th= is document should advance, please state your reasons why.
>
> Sheng JIANG is the assigned document shepherd.
>
> Regards,
>
> Sheng (co-chair, Toerless who as a co-author stayed neutral on the con= tent side)
>
>
>
>
> _______________________________________________
> 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
--f403045ea60825561d05627267c1-- From nobody Wed Jan 10 13:07:47 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70B01273E2 for ; Wed, 10 Jan 2018 13:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oijtmSKx_c6 for ; Wed, 10 Jan 2018 13:07:43 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68ACA12D950 for ; Wed, 10 Jan 2018 13:07:42 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id 81so3521364wmb.1 for ; Wed, 10 Jan 2018 13:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=4bAKeQMU4HRAdUrpxNNf4owzODawr8liuGVNB2z7IDE=; b=T9AbLXYoYiE145XxvnwE6MzBs12qBxIrmVnd/lVMdEFEtRAZ+E7mG0n49cCx/z9rgY O9NDlDGYwftWEfuOQT+FzD96psX1aL9P3W4hnR042W2cTb0m7h6phqF0OpBcG0p0uq9k 5SKqbzzSWYgbhOijS1YKF5BVFOzihzFnoVbEtmlUqFz4ZhDWcbM0cyh4bAYA4OULCAXb qYZW/awsUYwA3KZxnwyrVbYvdNamLalDjTdNjSqJ9xa63eljhpiAKvVSJ3mA1hYJIFYQ 5dpST5rsE9LvOIab5aKDYliC/BvJUI4Ju5DeK7cdfKkgwEJLRJZhjoyKVoKWYfiZElbB Nclw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4bAKeQMU4HRAdUrpxNNf4owzODawr8liuGVNB2z7IDE=; b=JPuuETX5J4cZgYd1pFKinv7z/geWjX/BigHwopxyh5ybZQa8i0cdG1esFXWmH7STKs xMHmNBCnMvdPT4eMv0ojMZivX4qcZChnwmG/oXE13zmhfQv/Ia7hXTDRpdOq1ICRDTZX QD7C/uJxJU3pe68uwfP1ZsaebiIvDvobwkUc/oA3CtEnmFi3j+WMmypQ874VTfB56dLP vzoQmWbUREmfwTeKhEN2M4nZcTtw8oGim4dt20+9w2Qgps0uzMuUTC1mtdJckcjBDseg 5BB55UPCL911pB60qQl3Bgq5v5ui3sewRjkW26n3TpfAxBy+XmggAtQKrYFgh+hYA1UO HZEg== X-Gm-Message-State: AKwxytes3fiaNPJIcXGvaGCjWgjnW7anTFcV29okQwX3zFIbQFKI2AHJ b4PohFPP6VfPbk8JwCSrxY/AbEfg X-Google-Smtp-Source: ACJfBotsV5UExunwPz7DZzJDA4LFUXePCaKTdcC0b1v/eQCNTLq4Lv7Ji/jXZ0vJWyo4am+ZRcKXYw== X-Received: by 10.28.197.201 with SMTP id v192mr5356942wmf.53.1515618460727; Wed, 10 Jan 2018 13:07:40 -0800 (PST) Received: from [192.168.1.25] (ANice-652-1-48-127.w86-219.abo.wanadoo.fr. [86.219.99.127]) by smtp.gmail.com with ESMTPSA id p10sm3712822wrh.61.2018.01.10.13.07.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2018 13:07:40 -0800 (PST) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> Message-ID: <453adcde-4f26-2fa8-62cc-bcd66e3df1a5@gmail.com> Date: Wed, 10 Jan 2018 22:07:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=utf-8 Content-Language: fr-classic Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 21:07:45 -0000
I guess I've made my point before, but just in case: I'm also co-author, and also think this doc is ready to move forward.

Michael

On 10/01/18 22:06, Jéferson Campos Nobre wrote:
Dear Anima.
I am also a co-author of this draft and I think it is in a good shape to advance. Besides that, I believe the publication of the reference model is an important step for the WG.
Best.
Jéferson

Em ter, 9 de jan de 2018 às 19:32, Brian E Carpenter <brian.e.carpenter@gmail.com> escreveu:
Hi,

I am a co-author of this draft. I do believe that it is ready to advance, and that it's useful to get it published soon so that it can indeed act as a reference model. We know that a second edition will probably be needed to include future work.

(At least one minor correction is pending in the XML source:
https://github.com/mbehring/ANIMA-Reference-Model/commit/163999c1d03599 )

Regards
   Brian Carpenter

On 09/01/2018 19:26, Sheng Jiang wrote:
> Hi all,
>
> This message starts the two-week ANIMA Working Group Last Call to advance draft-ietf-anima-reference-model-05, A Reference Model for Autonomic Networking. This document's intended status is Informational. At present, there is no IPR file against this document.
>
> Please send your comments by January 22nd, 2018. If you do not feel this document should advance, please state your reasons why.
>
> Sheng JIANG is the assigned document shepherd.
>
> Regards,
>
> Sheng (co-chair, Toerless who as a co-author stayed neutral on the content side)
>
>
>
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>

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


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

From nobody Wed Jan 10 15:08:52 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20AA12D7E8 for ; Wed, 10 Jan 2018 15:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6wpyY2smBQT for ; Wed, 10 Jan 2018 15:08:48 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2766129C6A for ; Wed, 10 Jan 2018 15:08:47 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1FA6358C57F; Thu, 11 Jan 2018 00:08:43 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id F2DF3B0D701; Thu, 11 Jan 2018 00:08:42 +0100 (CET) Date: Thu, 11 Jan 2018 00:08:42 +0100 From: Toerless Eckert To: "Michael H. Behringer" Cc: anima@ietf.org Message-ID: <20180110230842.GA5290@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> <453adcde-4f26-2fa8-62cc-bcd66e3df1a5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <453adcde-4f26-2fa8-62cc-bcd66e3df1a5@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 23:08:50 -0000 As another co-author i agree to everything Michael said except that it should be said without HTML obfuscating it ;-) Cheers Toerless On Wed, Jan 10, 2018 at 10:07:39PM +0100, Michael H. Behringer wrote: > > > > > >
I guess I've made my point before, but > just in case: I'm also co-author, and also think this doc is ready > to move forward.
>
> Michael
>
> On 10/01/18 22:06, Jéferson Campos Nobre wrote:
>
>
cite="mid:CABv6xLvgxLh1izs2ZAVCTY-h13oqaYDoFQ3bRPrKfRMuGv6+jw@mail.gmail.com"> >
Dear Anima. >
I am also a co-author of this draft and I think it is in a > good shape to advance. Besides that, I believe the publication > of the reference model is an important step for the WG.
>
Best.
>
Jéferson
>
>
>
Em ter, 9 de jan de 2018 às 19:32, Brian E > Carpenter < moz-do-not-send="true">brian.e.carpenter@gmail.com> > escreveu:
>
>
Hi,
>
> I am a co-author of this draft. I do believe that it is > ready to advance, and that it's useful to get it published > soon so that it can indeed act as a reference model. We > know that a second edition will probably be needed to > include future work.
>
> (At least one minor correction is pending in the XML > source:
> href="https://github.com/mbehring/ANIMA-Reference-Model/commit/163999c1d03599" > rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/mbehring/ANIMA-Reference-Model/commit/163999c1d03599 > )
>
> Regards
>    Brian Carpenter
>
> On 09/01/2018 19:26, Sheng Jiang wrote:
> > Hi all,
> >
> > This message starts the two-week ANIMA Working Group > Last Call to advance draft-ietf-anima-reference-model-05, > A Reference Model for Autonomic Networking. This > document's intended status is Informational. At present, > there is no IPR file against this document.
> >
> > Please send your comments by January 22nd, 2018. If > you do not feel this document should advance, please state > your reasons why.
> >
> > Sheng JIANG is the assigned document shepherd.
> >
> > Regards,
> >
> > Sheng (co-chair, Toerless who as a co-author stayed > neutral on the content side)
> >
> >
> >
> >
> > _______________________________________________
> > Anima mailing list
> > moz-do-not-send="true">Anima@ietf.org
> > href="https://www.ietf.org/mailman/listinfo/anima" > rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.ietf.org/mailman/listinfo/anima
> >
>
> _______________________________________________
> Anima mailing list
> moz-do-not-send="true">Anima@ietf.org
> rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.ietf.org/mailman/listinfo/anima
>
>
>
>
>
>
>
> 
_______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
>
>
> > > From nobody Wed Jan 10 16:03:21 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2104128C0A; Wed, 10 Jan 2018 16:03:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-anima-stable-connectivity@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151562899665.15876.3762205729160423887.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 16:03:16 -0800 Archived-At: Subject: [Anima] Ben Campbell's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 00:03:17 -0000 Ben Campbell has entered the following ballot position for draft-ietf-anima-stable-connectivity-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am skeptical that there are no normative references at all. Is it reasonable that a reader could skip all the references and still fully understand this document? From nobody Wed Jan 10 16:36:46 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DDF12D84B; Wed, 10 Jan 2018 16:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_Om1WpQKSTN; Wed, 10 Jan 2018 16:36:38 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B87126BF7; Wed, 10 Jan 2018 16:36:38 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D06A258C584; Thu, 11 Jan 2018 01:36:33 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id B4290B0D6FC; Thu, 11 Jan 2018 01:36:33 +0100 (CET) Date: Thu, 11 Jan 2018 01:36:33 +0100 From: Toerless Eckert To: Ben Campbell Cc: The IESG , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com Message-ID: <20180111003633.GB5290@faui40p.informatik.uni-erlangen.de> References: <151562899665.15876.3762205729160423887.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151562899665.15876.3762205729160423887.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 00:36:41 -0000 Thanks, Ben Pls. check the reply i sent to Alvaro i just sent. It tackles the issue of whether ACP should be a normative reference. Your comment makes me more confused about the exact rules for what makes a reference normative. Initially (when i wrote the stable connectivity draft) i thought an informational doc should not have normative references because it did itself not have MUST/SHOULD requirements that could have dependencies. Later Brian Carpenter i think explained to me this i was wrong, but since then my understanding is "Reference must be normative if you must support/implement it to implement/support the current document". Your comment makes it sound more like "if you must read/understand a reference then it must be normative". Is that true ? Which RFC/section says so ? Cheers Toerless On Wed, Jan 10, 2018 at 04:03:16PM -0800, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-anima-stable-connectivity-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am skeptical that there are no normative references at all. Is it reasonable > that a reader could skip all the references and still fully understand this > document? > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jan 10 16:49:57 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7912C12422F for ; Wed, 10 Jan 2018 16:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWRBYrE-tis4 for ; Wed, 10 Jan 2018 16:49:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131A8120713 for ; Wed, 10 Jan 2018 16:49:53 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0B0nonE085422 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jan 2018 18:49:51 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Toerless Eckert , Ben Campbell Cc: anima-chairs@ietf.org, draft-ietf-anima-stable-connectivity@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com References: <151562899665.15876.3762205729160423887.idtracker@ietfa.amsl.com> <20180111003633.GB5290@faui40p.informatik.uni-erlangen.de> From: Adam Roach Message-ID: <9b9e039d-1a76-0a1a-66a2-9713a6c13636@nostrum.com> Date: Wed, 10 Jan 2018 18:49:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180111003633.GB5290@faui40p.informatik.uni-erlangen.de> Content-Type: multipart/alternative; boundary="------------1134E9AC6E60D61D27DBF321" Content-Language: en-US Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 00:49:55 -0000 This is a multi-part message in MIME format. --------------1134E9AC6E60D61D27DBF321 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/10/18 6:36 PM, Toerless Eckert wrote: > Thanks, Ben > > Pls. check the reply i sent to Alvaro i just sent. It tackles the > issue of whether ACP should be a normative reference. > > Your comment makes me more confused about the exact rules for what makes > a reference normative. Initially (when i wrote the stable connectivity draft) > i thought an informational doc should not have normative references because > it did itself not have MUST/SHOULD requirements that could have dependencies. > > Later Brian Carpenter i think explained to me this i was wrong, but since then > my understanding is "Reference must be normative if you must support/implement > it to implement/support the current document". > > Your comment makes it sound more like "if you must read/understand a reference > then it must be normative". Is that true ? Which RFC/section says so ? That's true. You're looking for https://tools.ietf.org/html/rfc7322#section-4.8.6 Reference lists must indicate whether each reference is normative or informative, where normative references are essential to implementing or understanding the content of the RFC and informative references provide additional information. The IESG's guidance on this topic is posted here, and it provides some additional rationale for these criteria: https://www.ietf.org/iesg/statement/normative-informative.html /a --------------1134E9AC6E60D61D27DBF321 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 1/10/18 6:36 PM, Toerless Eckert wrote:
Thanks, Ben

Pls. check the reply i sent to Alvaro i just sent. It tackles the
issue of whether ACP should be a normative reference.

Your comment makes me more confused about the exact rules for what makes
a reference normative. Initially (when i wrote the stable connectivity draft)
i thought an informational doc should not have normative references because
it did itself not have MUST/SHOULD requirements that could have dependencies.

Later Brian Carpenter i think explained to me this i was wrong, but since then
my understanding is "Reference must be normative if you must support/implement
it to implement/support the current document".

Your comment makes it sound more like "if you must read/understand a reference
then it must be normative". Is that true ? Which RFC/section says so ?

That's true. You're looking for https://tools.ietf.org/html/rfc7322#section-4.8.6

   Reference lists must indicate whether each reference is normative or
   informative, where normative references are essential to implementing
   or understanding the content of the RFC and informative references
   provide additional information.

The IESG's guidance on this topic is posted here, and it provides some additional rationale for these criteria: https://www.ietf.org/iesg/statement/normative-informative.html

/a
--------------1134E9AC6E60D61D27DBF321-- From nobody Wed Jan 10 17:52:03 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC2412D890; Wed, 10 Jan 2018 17:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHSC7XqvGvQ0; Wed, 10 Jan 2018 17:52:00 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4B212DA6E; Wed, 10 Jan 2018 17:51:59 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id ABBBF58C584; Thu, 11 Jan 2018 02:51:55 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9031DB0D703; Thu, 11 Jan 2018 02:51:55 +0100 (CET) Date: Thu, 11 Jan 2018 02:51:55 +0100 From: Toerless Eckert To: Adam Roach Cc: Ben Campbell , anima-chairs@ietf.org, draft-ietf-anima-stable-connectivity@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com Message-ID: <20180111015155.GC5290@faui40p.informatik.uni-erlangen.de> References: <151562899665.15876.3762205729160423887.idtracker@ietfa.amsl.com> <20180111003633.GB5290@faui40p.informatik.uni-erlangen.de> <9b9e039d-1a76-0a1a-66a2-9713a6c13636@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b9e039d-1a76-0a1a-66a2-9713a6c13636@nostrum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 01:52:02 -0000 Thanks, Adam, i had overlooked the "or understandding the content" first time i've been round the block! In any case, see reply to Alvaros original DISCUS why i think ACP does not need to be normative reference, and that IMHO also applies to the "understanding" part. Cheers Toerless On Wed, Jan 10, 2018 at 06:49:45PM -0600, Adam Roach wrote: > On 1/10/18 6:36 PM, Toerless Eckert wrote: > >Thanks, Ben > > > >Pls. check the reply i sent to Alvaro i just sent. It tackles the > >issue of whether ACP should be a normative reference. > > > >Your comment makes me more confused about the exact rules for what makes > >a reference normative. Initially (when i wrote the stable connectivity draft) > >i thought an informational doc should not have normative references because > >it did itself not have MUST/SHOULD requirements that could have dependencies. > > > >Later Brian Carpenter i think explained to me this i was wrong, but since then > >my understanding is "Reference must be normative if you must support/implement > >it to implement/support the current document". > > > >Your comment makes it sound more like "if you must read/understand a reference > >then it must be normative". Is that true ? Which RFC/section says so ? > > That's true. You're looking for > https://tools.ietf.org/html/rfc7322#section-4.8.6 > > Reference lists must indicate whether each reference is normative or > informative, where normative references are essential to implementing > or understanding the content of the RFC and informative references > provide additional information. > > > The IESG's guidance on this topic is posted here, and it provides > some additional rationale for these criteria: > https://www.ietf.org/iesg/statement/normative-informative.html > > /a From nobody Wed Jan 10 18:43:02 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D94F12DB6D; Wed, 10 Jan 2018 18:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1XZhcCWpZPv; Wed, 10 Jan 2018 18:42:59 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE388126E64; Wed, 10 Jan 2018 18:42:59 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0B2gmrR097302 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jan 2018 20:42:49 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: <61BC408B-22B8-41A2-89DF-5CBC3AAC875E@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DD7B5D04-BFFC-4765-93B0-968EA950F51F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 10 Jan 2018 20:42:24 -0600 In-Reply-To: <20180111015155.GC5290@faui40p.informatik.uni-erlangen.de> Cc: Adam Roach , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com To: Toerless Eckert References: <151562899665.15876.3762205729160423887.idtracker@ietfa.amsl.com> <20180111003633.GB5290@faui40p.informatik.uni-erlangen.de> <9b9e039d-1a76-0a1a-66a2-9713a6c13636@nostrum.com> <20180111015155.GC5290@faui40p.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 02:43:01 -0000 --Apple-Mail=_DD7B5D04-BFFC-4765-93B0-968EA950F51F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 10, 2018, at 7:51 PM, Toerless Eckert wrote: >=20 > Thanks, Adam, i had overlooked the "or understandding the content" = first > time i've been round the block! Thanks also to Adam for explaining my point before I got to it :-) A sometimes useful thought experiment is whether you think a normal = reader would fully understand the points you are making if they didn=E2=80= =99t read the cited reference. >=20 > In any case, see reply to Alvaros original DISCUS why i think ACP does = not > need to be normative reference, and that IMHO also applies to the = "understanding" > part. I wasn=E2=80=99t picking on that (or any other) reference in particular; = just the fact there were no normative references. It=E2=80=99s certainly = possible that none of them should be normative, but that would be an = unusual case. Thanks! Ben. >=20 > Cheers > Toerless >=20 > On Wed, Jan 10, 2018 at 06:49:45PM -0600, Adam Roach wrote: >> On 1/10/18 6:36 PM, Toerless Eckert wrote: >>> Thanks, Ben >>>=20 >>> Pls. check the reply i sent to Alvaro i just sent. It tackles the >>> issue of whether ACP should be a normative reference. >>>=20 >>> Your comment makes me more confused about the exact rules for what = makes >>> a reference normative. Initially (when i wrote the stable = connectivity draft) >>> i thought an informational doc should not have normative references = because >>> it did itself not have MUST/SHOULD requirements that could have = dependencies. >>>=20 >>> Later Brian Carpenter i think explained to me this i was wrong, but = since then >>> my understanding is "Reference must be normative if you must = support/implement >>> it to implement/support the current document". >>>=20 >>> Your comment makes it sound more like "if you must read/understand a = reference >>> then it must be normative". Is that true ? Which RFC/section says so = ? >>=20 >> That's true. You're looking for >> https://tools.ietf.org/html/rfc7322#section-4.8.6 >>=20 >> Reference lists must indicate whether each reference is normative = or >> informative, where normative references are essential to = implementing >> or understanding the content of the RFC and informative references >> provide additional information. >>=20 >>=20 >> The IESG's guidance on this topic is posted here, and it provides >> some additional rationale for these criteria: >> https://www.ietf.org/iesg/statement/normative-informative.html >>=20 >> /a >=20 --Apple-Mail=_DD7B5D04-BFFC-4765-93B0-968EA950F51F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpWzxAACgkQgFZKbJXz 1A2HAhAAkv1WiJyxJOKLHgPv1LrARESxYPyrWC4zqs5um1/ZEjjKgAy75BHacRbX ZDcpCKBv6p4aJax4ENin+ps+N4pTvJQfmpPjxbPdCQ5Hz7kPCfATetYvLvoa7G/g m0VyyKQ8K89+mxFbnmV6GeUW52cBBjtuxhRx0aVFDfYPQel68vJgatCJWGaCVuea eVT8xHisNV261V/jONI/h5OFCIA1lKy1D2h2fnQSipjOPXGJ7BRMxhVHPZ7z7kOc O3Sv93ThMC2xlMaUuIvZJfovYmDpbM48/sETauf03MRjZ0sKEL3LF5jzurIp5QjJ FbFWrOoT4oSzyzax7WrN6Dyb3xkYuG9AWHtCtaY6jhdbh7UmhuKHS+zIljoUatsP Bqg+tMxcdeBUSSSMbL0ENL7kAEawUzHR/HjYiJvMiarOZvB4kU9uBJn72tYxQQKh t1JXRmnORvGPsDiVEOUEx7PEUys1ZLgkkUskMLl8Co8mhC1PNX5FupnmZW49k1ll OIGzXRjmgPpjdOrKgEtWLjrdSpjOpDpFfRcTwaXXIHRprXC+189QWXTy18edJqJ3 0AanGpFsedXCARITBkIOZ/K3QSaoEZqIIqCWeiEzfGJT/YxFCZTmQgGmgn4stdGK ia0BFaam45yZjjwwgbx3xWLKaYdkpybILw4kJnDpcRBMHB4upwU= =46JS -----END PGP SIGNATURE----- --Apple-Mail=_DD7B5D04-BFFC-4765-93B0-968EA950F51F-- From nobody Wed Jan 10 19:20:13 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC82012E855; Wed, 10 Jan 2018 19:20:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-anima-stable-connectivity@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151564081176.8304.13253757891345258555.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 19:20:11 -0800 Archived-At: Subject: [Anima] Suresh Krishnan's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 03:20:12 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-anima-stable-connectivity-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * The first paragraph of Section 2.1.4. is extremely difficult to read and the sentences seem incomplete/malformed. Please consider rewording " ACP does not support IPv4: Single stack IPv6 management of the network via ACP and (as needed) data plane. Independent of whether the data plane is dual-stack, has IPv4 as a service or is single stack IPv6. Dual plane management, IPv6 for ACP, IPv4 for the data plane is likewise an architecturally simple option." From nobody Wed Jan 10 19:31:44 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3AE12E852; Wed, 10 Jan 2018 19:31:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-anima-stable-connectivity@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151564150183.11232.5234107897547990840.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 19:31:41 -0800 Archived-At: Subject: [Anima] Eric Rescorla's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 03:31:42 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-anima-stable-connectivity-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- secure ACP was extendable via untrusted routers then it would be a lot more verify the secure domain assertion. Therefore the ACP edge devices are not supposed to redistribute routes from non-ACP routers There's something grammatically wrong here and I can't make sense of this sentence. TLS/DTLS ([RFC5246])/([RFC6347]) with mutual AN-domain certificate authentication - and does not incur new key management. This isn't entirely clear to me. What are the identities that these devices are using to talk to each other? Are they always FQDNs? into IPv4 support for ACP will have a longer term benefit or enough critical short-term use-cases. Support for IPv4-only for ACP is purely a strategic choice to focus on the known important long term I think this probably should say IPv6 only address collision even though there is no central assignment authority. This is helped by the expectation, that ACPs are never expected to connect all together, but only few ACPs may ever need to Nit: no comma between "expectation" and "that" ACP packets can be recognized to come from you, you may need to list your prefixes in multiple of those sites. As I read this, it helps others to list, not yourself, right? Any current and future protocols must rely on secure end-to-end communications (TLS/DTLS) and identification and authentication via This looks normative. Should it be MUST? From nobody Thu Jan 11 06:35:43 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CA612EB84; Thu, 11 Jan 2018 06:35:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-anima-stable-connectivity@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151568134166.29576.6912836639703769699.idtracker@ietfa.amsl.com> Date: Thu, 11 Jan 2018 06:35:41 -0800 Archived-At: Subject: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 14:35:42 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-anima-stable-connectivity-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Gen-ART reviewer identified a bunch of nits that should be addressed. From nobody Thu Jan 11 06:36:41 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F5112EB95; Thu, 11 Jan 2018 06:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=HSFndVlM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o4pBIWaq 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 SKgqiPV_bd8K; Thu, 11 Jan 2018 06:36:36 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4048A12EB84; Thu, 11 Jan 2018 06:36:36 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 810DA20DC6; Thu, 11 Jan 2018 09:36:35 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 11 Jan 2018 09:36:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=JUzL5pHEJBDojE87Vpi3RkN5w+I0Q YdfmOIx2Ojpk+Y=; b=HSFndVlMN4j42VQylik4DfpCDuhbLt+hOV3gpQRazLPsh CaCYxr7YLX2i4gqr+WGCW6PA4llY1Vo+ZMXDV7Xv0o9eAHn2TgoxIq3Izd6MYAHN L3h+8hTUZ3d/D+kcnXbix/aAhiw7DZDZBmaG1OcXgh+LdQ9sQCjQpvofxhieFx+m Cw007R4UBVF9Rbl+PU2ub5wXmVA0lQtGkErcE0bn5WdHzcTBd4AzdyTRgRcnGHPp WxHFXnbFz+E+N0yIrB2fzuoo0fOVu6WjnUFy1IVnm+uhoHRdR1H8/mf8Zef3ujcR bzPfJI9bR3F5Nnpbp6utxu9wrbEu1sPbllFn8/Ibw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=JUzL5p HEJBDojE87Vpi3RkN5w+I0QYdfmOIx2Ojpk+Y=; b=o4pBIWaqDoKN28x4vQdB6h BeQZpWQNG95HBfKP9SOn7CqNFrOok/4q70/+RswrFg1djWxKWldGSjTNKc86pDDS 62EyanZzJ7KXHAo8Y/MSKcvkkkcaKiD0cZq6uP49/d5N1hwd+DoblyRz81JzJZXs 16r1qhWPZ77AMROMqJrf6czmHIV3joYtgeLgkon78OFOfrn7EBUjiG+rWbOOS38C mfoFwzf7J6ppOqD3pXMT8WsM2vFo9/A8P9T3f8rBbWxMdH7rtERJ04znV+sxlXXA wnmiyiozQJObfWcLw4HA876sbMKrH7DztRzxXBUe5faBZ5xzhAW+smVOeN9XdRPA == X-ME-Sender: Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.179]) by mail.messagingengine.com (Postfix) with ESMTPA id 7EA2A24599; Thu, 11 Jan 2018 09:36:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <151172929363.16112.9800241520992164052@ietfa.amsl.com> Date: Thu, 11 Jan 2018 09:36:32 -0500 Cc: gen-art , anima@ietf.org, draft-ietf-anima-stable-connectivity.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2AAF0CB9-E081-40EB-ACC5-C752708BFCD1@cooperw.in> References: <151172929363.16112.9800241520992164052@ietfa.amsl.com> To: Matthew Miller X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Anima] [Gen-art] Genart last call review of draft-ietf-anima-stable-connectivity-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 14:36:38 -0000 Matt, thanks for your review. I have entered a No Objection ballot and = asked for your nits to be addressed. Alissa > On Nov 26, 2017, at 3:48 PM, Matthew Miller = wrote: >=20 > Reviewer: Matthew Miller > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-anima-stable-connectivity-07 > Reviewer: Matthew A. Miller > Review Date: 2017-11-26 > IETF LC End Date: 2017-11-26 > IESG Telechat date: N/A >=20 > Summary: >=20 > This document is ready to be published as informational, but there are > a number of nits that ought be addressed before final publication. >=20 > Overall, the document is=20 >=20 > Major issues: NONE >=20 > Minor issues: NONE >=20 > Nits/editorial comments: >=20 > * Throughout, there is a mix of the term "data plane" and = "data-plane". > One form should be chosen and the rest corrected to match. >=20 > * In Section 1.2. "Data Communications Networks (DCNs)", first > paragraph; "'th" should be "'s" (or just "s"): "In the late > 1990'th and ..." should be "In the late 1990s and ...". >=20 > * In Section 1.2. "Data Communications Networks (DCNs)", first > paragraph; the word "where" should be "were" in the fragment > "These where (and still are) ...". >=20 > * In Section 1.2. "Data Communications Networks (DCNs)", first > paragraph; there is a missing "a" between "are" and "separate" in > the fragment "they are separate network entirely". >=20 > * In Section 2.1.1. "Simple Connectivity for Non-ACP capable NMS > Hosts", first paragraph; there is a mismatch in plurality in the > third sentence; instead of: >=20 > """ > They acts as the default router to those NMS hosts and provide them > with IPv6 connectivity into the ACP. > """ >=20 > it should be: >=20 > """ > They act as the default routers to those NMS hosts and provide them > with IPv6 connectivity into the ACP. > """ >=20 > * In Section 2.1.3. "Simultaneous ACP and Data Plane Connectivity", > last paragraph; the following sentence seems to be missing a word > or two: >=20 > """ > If the secure ACP was extendable via untrusted routers then it would > be a lot more verify the secure domain assertion. > """ >=20 > * In Section 2.1.4. "IPv4-only NMS Hosts", second paragraph after the > ordered list; the word "thought" should be "through" in the fragment > "... be reachable thought the IPv6/IPv4 ...". >=20 > * In Section 2.1.5. "Path Selection Policies", fourth paragraph from > the section's end; there is an extra "of" between "shaping" and "at": >=20 > """ > Traffic policing and/or shaping of at the ACP edge in the NOC can be > used to throttle applications such as software download into the ACP. > """ >=20 > * In Section 2.2. "Stable Connectivity for Distributed Network/OAM", > second paragraph; there is a missing "to" between "start" and > "provide" in the fragment "... tried to start provide common ...". >=20 > * In Section 2.2. "Stable Connectivity for Distributed Network/OAM", > second paragraph; the word "applicable" should be "applied" in the > fragment "... how ell it applicable to a ...". >=20 > * In Section 3.1. "No IPv4 for ACP", third paragraph; the word "as" > should be "to" in the fragment "... from a native transport as just > a service on the edge." >=20 > * In Section 3.1. "No IPv4 for ACP", last paragraph; the word "type" > should be "types" in the fragment "In other type of networks as > well, ...". >=20 > * In Section 3.1. "No IPv4 for ACP", last paragraph; the word = "support" > should be "supported" in the fragment "... family will be support so > all use...". >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Jan 11 06:43:02 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D2212EB84 for ; Thu, 11 Jan 2018 06:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 8z9P5fRbO0L8 for ; Thu, 11 Jan 2018 06:42:56 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2401312EB9C for ; Thu, 11 Jan 2018 06:42:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=hAjmwbpYxQGrOeYkuKFQFu5tquXbUGVCqFsaKF0uXkFRJXrbBjYnSnq9mv80Xo3SqzjkFXL3rDwCgPZZByedIbbf9YhfT9xqOJQfc++6/i4iOhzbBxLTAbBDYKmIU23GZ32wR4mTKgRZRsu+3QXyswVmxkJ14mcwtGc7kVIGi3w=; h=Received:Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 28061 invoked from network); 11 Jan 2018 15:42:53 +0100 Received: from nb-10688.ethz.ch (HELO ?82.130.103.20?) (82.130.103.20) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 11 Jan 2018 15:42:53 +0100 To: Toerless Eckert Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com References: <151517661652.14702.17669603601514442397.idtracker@ietfa.amsl.com> <5401.1515191435@obiwan.sandelman.ca> <20180108154725.GA25025@faui40p.informatik.uni-erlangen.de> <29E8737B-D0BA-431C-ABD6-9A79CDB4C094@kuehlewind.net> <20180108210617.GA2411@faui40p.informatik.uni-erlangen.de> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <2fec5e70-3677-4380-ae11-0ab499062ea7@kuehlewind.net> Date: Thu, 11 Jan 2018 15:42:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180108210617.GA2411@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-PPP-Message-ID: <20180111144253.28051.37492@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja K?hlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 14:43:00 -0000 Hi Toerless, the point I'm wondering about is your point (b) below. Yes, you can set the ACP subflow to backup but that would still mean that if the other link fails, it would automatically switch over to the ACP subflow (without exposing this to the upper layer). Is that what you want? Because my understanding was rather that there are cases where you'd probably would like to know over which link the OAM packets where actually sent...? Mirja On 08.01.2018 22:06, Toerless Eckert wrote: > Thanks, Mirja > > (a) If the systems socket API does not transparently make TCP sockets > to use MPTCP, then you would want a shim library. According to > draft-hesmans-mptcp-socket, this is be the case on Apple (iOS). > > (b) Making the ACP subflow not carry traffic after establishing the > data plane subflow should easily be possible possible by setting its MP_PRIO > to backup. > > (c) How exactly to specify or implement the desired policy of only > establishing a subflow between the ACP addresses and the data plane addresses > (but not full-mesh) seem to be a subject for further spec work. It could > be defined as a specific in-MPTCP policy, or it could be done via a shim > library (orthogonal to (a)). draft-hesmans-mptcp-socket might be sufficient. > > But in general: i would like for this (informational!) draft to just motivate > the concept and not specify the solution: MPTCP would be a simple way to > make "TCP" applications automatically "upgrade" from ACP to a data-plane path > and switch back when data-plane fails... because MP-TCP can signal the > additional data-plane addresses, establish transparently another subflow and switch > traffic between the subflows - all by using the right shim-library+API or > in-MP-TCP address/subflow policies - and the ability to establish subflows > across two VRFs. > > Cheers > Toerless > > On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind (IETF) wrote: >>>>> Suggested replacement text last two paragraphs of 2.1.5: >>> A (shim) library for aplications maps TCP connections to MPTCP without the applications having to be aware of it. >> It???s not the (shim) library/policy framework that opens/maps the TCP connection. MPTCP itself opens eventually multiple connections but exposes only one connection to the layer above. That means everything above MPTCP does not have any real control about which data is send over which connection. >> >> A policy shim layer could only implement rules about which new subflows should be established when and what the priority is over which subflow data should be sent but it generally does not control which data is send of which flow. You can???t say I want this data to be sent over subflow one and this data to be sent over sub flow two. >> >> I think what you want is actually a view on the different TCP connections and you try to use MPTCP only for announcing the other IP address but that is not what MPTCP meant to be. >> >> Mirja >> >> >>> Names in DNS use only the ACP IPv6 addresses of network devices. Thererefore, the initial MPTCP subflow will use the ACP. After it is operating, the shim libraries on both ends add their data-plane address (MPTCP ADD_ADDR) and attempt to build a new subflow between those addresses. If that (data plane) subflow is successfully built, the shim libraries could shift all traffic over this subflow which should be forwarded hardware accelerated by the network - and use the ACP subflow across the ACP solely for signaling - beause it is most resilient against failure. >>> >>> This MPTCP approach is only an outline and would need to be fully speficied for interoperable implementations. It may also require extensions to MP-TCP. This mechanism must not be used without providing for encryption of subflows not running across the ACP. >>> >>>>> Brian: ... can not use capital MUST NOT in an information draft (i think) >>>>> >>> Cheers >>> Toerless >>> >>> On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind (IETF) wrote: >>>> Hi Micheal, >>>> >>>> to clarify one part below: >>>> >>>>> Am 05.01.2018 um 23:30 schrieb Michael Richardson : >>>>> >>>>> >>>>> Mirja Kühlewind wrote: >>>>>> "DNS naming is set up to provide the ACP IPv6 address of network >>>>>> devices. Unbeknownst to the application, MPTCP is used. MPTCP >>>>>> mutually discovers between the NOC and network device the data-plane >>>>>> address and caries all traffic across it when that MPTCP subflow >>>>>> across the data-plane can be built." >>>>> Section 2.1.5 is discussion, it discusses ways in which the >>>>> anticipated low performance (compared to what the box might do with its >>>>> hardware accelerated forwarding). >>>>> >>>>> If we have an application that needs the bandwidth of the native hardware, >>>>> the connection can be initated over the ACP (that's what would be in DNS). >>>>> One presumes that an MPTCP layer could then enumerate the available IPs at >>>>> each end and then start off additional flows on the other destinations. >>>> MPTCP adda an additional TCP flow but for the application that still looks like one flow. As I said I???m not sure if that is what you want. >>>> >>>> Mirja >>>> >>>> >>>>> The application would have to include application security, since it would >>>>> not be protected by the ACP. >>>>> >>>>> Perhaps MPTCP doesn't work this way. >>>>> >>>>>> However, I'm actually uncertain how this is supposed to work and what >>>>>> "Unbeknownst to the application" should mean. If another address should be >>>>>> signaled to the other host, this needs to be indicated by the application or at >>>>>> least some kind of policy framework above MPTCP. Also MPTCP will by default use >>>>>> both paths simultaneously while still looking like one connection to the >>>>>> application, meaning the application has no control which path is used for >>>>>> which traffic. I guess you can open a second subflow and then configure the >>>>>> first subflow as backup path but I'm not sure if that's what you want (given >>>>>> the application/policy framework will still not know which path is used)..? >>>>>> Please provide more information about what the expected usage scenario is here. >>>>> >>>>> -- >>>>> Michael Richardson , Sandelman Software Works >>>>> -= IPv6 IoT consulting =- >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>> -- >>> --- >>> tte@cs.fau.de From nobody Tue Jan 16 13:26:14 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A114212EB2B for ; Tue, 16 Jan 2018 13:26:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3_OPK6kJL7j for ; Tue, 16 Jan 2018 13:25:53 -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 75E6612EB24 for ; Tue, 16 Jan 2018 13:25:49 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AD78C200E1 for ; Tue, 16 Jan 2018 16:31:06 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9BD3A80653 for ; Tue, 16 Jan 2018 16:25:48 -0500 (EST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] constrained voucher document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jan 2018 21:26:13 -0000 --=-=-= Content-Type: text/plain ANIMA WG chairs, I'd like to ask the WG to consider adopting: > https://datatracker.ietf.org/doc/draft-richardson-anima-ace-constrained-voucher/ This document is an evolution of the draft-ietf-anima-voucher document which is now having final touches put to it. Over in 6tisch, I thought we could handle the constrained voucher format ourselves, but it turns out that we can not because there are too many variations desired. Does it fit into ANIMA? I'm conflicted, but it seems like the best place. There are some BCC's which I hope will result in some discussion. We wound up creating the following chart to explain things: http://www.sandelman.ca/tmp/technology-components-v2.svg The above document represents the "constrained voucher (CBOR)" document which lives in the yellow and pink headings. It might be signed by COSE (in 6tisch), or by CMS (in ACE and other places). It this duality which forces us to write a more generic document. The above document is extracted from already well edited text. I would like to transform the above diagram into a roadmap document, perhaps under the IOT-DIR that explains how the various enrollment processes work. I think that such a document could be AD-sponsored. I think that I can write the document pretty quickly as it just an informational document that explains what's in each box. (Will I use SVG art in the roadmap document? Probably not, because colour is not accepted, so there is little to be gained over ascii art version) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpebdwACgkQgItw+93Q 3WVsvwf/TKQE7hsrGFdPc453aojelIfSGcY2dvQ788Nx8xnx3lanTosFOvde2SFX +Hu5BkU2gewZS2TqLA2++AC14msvB/McqHRtsctj4e1q+0PphIwJk6VylYb0qRAY r6HtTOzOQPpsz76GmTtyM8OoYXs6/3j53cMZwynXlaC+4l5MJTlLodiRyNrnEOjP cui8aGzQl0aOM1qnJoncDJI9CEVoi52DZSCdUcBGGDOfP3TN/m+bGLy7TZVTOaIY IvLoveMbFi7VzPAo4Lz4cc8eXP7zS9SdvUsSGD4Jn+/nxEDSj4JlVkH8cW8XTffr LIh2SDV6DMsCYIMHI5ophLx325jY4w== =TBI3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 16 18:31:01 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4476412D93E; Tue, 16 Jan 2018 18:30:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151615625922.15661.2613282023939835944@ietfa.amsl.com> Date: Tue, 16 Jan 2018 18:30:59 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-stable-connectivity-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2018 02:30:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Using Autonomic Control Plane for Stable Connectivity of Network OAM Authors : Toerless Eckert Michael H. Behringer Filename : draft-ietf-anima-stable-connectivity-08.txt Pages : 24 Date : 2018-01-16 Abstract: OAM (Operations, Administration and Maintenance - as per BCP161, (RFC6291) processes for data networks are often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on, changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to aforementioned circular dependencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-stable-connectivity-08 https://datatracker.ietf.org/doc/html/draft-ietf-anima-stable-connectivity-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-stable-connectivity-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 16 18:32:50 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB46812D93E; Tue, 16 Jan 2018 18:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyanZa2hFhte; Tue, 16 Jan 2018 18:32:47 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE59E12EC0E; Tue, 16 Jan 2018 18:32:46 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8A39458C5A1; Wed, 17 Jan 2018 03:32:41 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6C723B0D79D; Wed, 17 Jan 2018 03:32:41 +0100 (CET) Date: Wed, 17 Jan 2018 03:32:41 +0100 From: Toerless Eckert To: Alvaro Retana Cc: anima-chairs@ietf.org, Sheng Jiang , The IESG , draft-ietf-anima-stable-connectivity@ietf.org, anima@ietf.org Message-ID: <20180117023241.GA26571@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Alvaro Retana's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jan 2018 02:32:50 -0000 Thanks, Alvaro I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt I have modified the verbage in -08 according to your suggestions. A) GACP Section 1.3 now introduces the four core design constraints of a generic ACP (GACP) (VRF isolation, IPv6 only, NOC connectivity and Group Security) which are the basis for the (existing/unchanged) discussion in the document. The rest of the document has no semantic/content changes just textual changes for ACP -> GACP. There are two places where the text still refers to ACP specific examples and that is accordingly highlighted. B) Normative references I went through the references and made those normative where i thought rfc7322#section-4.8.6 "are essential to ... understanding the content" applies. This set is of course somewhat subjective. Eg.: there is nothing special to know about RFC6434, so its kept informational. On the other hand, if you're a poor enterprise requiring to use any of the nasty NAT options mentioned, you really want to read up on SIIT (RFC7915), so i made that normative. Most customers i talked to did not know ULA (rfc4193), so i made it normative. For fairness so then did the same for rfc1918. The diffs regarding your DISCUSS are here (using the github commits before/after): http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/d26df831da2953779c3b3ac41ec118cbbe43373e/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/f2d8a85c2cc65ca7f823abac0f57d19c744f9b65/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt I hope this resolves your discuss. I am answering to the discus/comments raised by others during IESG review separately. Cheers Toerless On Thu, Jan 11, 2018 at 06:09:22AM -0800, Alvaro Retana wrote: > Toerless: > > Hi! > > Hmmm???. I see your point, but that is not what the document says. Not only > does it specifically point at the ACP anima draft ("ACP as defined in > [I-D.ietf-anima-autonomic-control-plane]???), but it is hard to ignore the > work done in the WG. > > I think that if you clearly explained the characterization of *an autonomic > control plane* and mention *the ACP* > [I-D.ietf-anima-autonomic-control-plane] as an example of that, then we > would be ok. Please then also call it something else (GACP = > Generic/Generalized, or anything else that clearly makes people think > you???re not explicitly talking about *the ACP*). > > Thanks! > > Alvaro. > > On January 10, 2018 at 7:29:33 PM, Toerless Eckert (tte@cs.fau.de) wrote: > > Thanks, Alvarao > > I wuld like to persuade you that ACP is not a normative reference for > stable > connectivity: > > a) Stable connectivity doc does not depend on the > details of how the ACP is built. It only assumes the following: > > - There is an autonomously build managemenet network (that we call ACP) > - The OAM functions of network nodes are able to use this ACP > to reach each other. > - Some "ACP-edge-devices" can connect NOC equipment into the ACP. > - ACP only supports IPv6 > - The ACP address space is disjoint from the address space of the data > plane > > I could come up with a lot of ways how to build an ACP that matches these > expectations. Heck: Most of the stable connectivity text would equally be > valid if you > would use an IPv6 only DCN (external physcial manaement network). Aka: > this doc is about the value of an ACP for the use-case (inband, autonomic) > and the problems of how to deal on NOC equipment with dual connectivity and > IPv6 only for that managemeent plane. > > b) stable connectivity was specifically targeted in the WG charter as a > validation document for ACP. To me this means it is somewhat of a > predecessor or > use-case to ACP: > > "If the WG manages to define an ACP that is built autonomically and that > can be characterized by the simple behavior listed in a), then this > stable-connectivity document explains that/how it can be leveraged wfor the > stable-connectibity use-case".... and therefore justifies the work on ACP > for the WG. > > Let me know if these argument are appropriate to characterize the ACP > draft as an informative reference. Otherwise i will change it to normative. > > Of course, i would be happy to improve the text to highlight this > relationship > better in the text because i also do not think that the intro tries to > really explain this well (but i did not want to try write it up before i am > clear that it would resolve your discus). > > Thanks > Toerless > > On Thu, Jan 04, 2018 at 09:28:10PM -0800, Alvaro Retana wrote: > > Alvaro Retana has entered the following ballot position for > > draft-ietf-anima-stable-connectivity-07: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I like this document, and look forward to it being published. However, it > > caught my attention that there are no Normative References. > > > > It seems clear to me that (at least) an understanding of the ACP is > necessary > > to properly achieve the objective of the document: "how to integrate OAM > > processes with the autonomic control plane (ACP) in Autonomic Networks > (AN) in > > order to provide stable and secure connectivity for those OAM processes." > I > > then think that the reference to I-D.ietf-anima-autonomic-control-plane > should > > be Normative. > > > > > > > > -- > --- > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Tue Jan 16 18:33:33 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9085712EC36; Tue, 16 Jan 2018 18:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94dYJw54ukH1; Tue, 16 Jan 2018 18:33:26 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EEA12EC37; Tue, 16 Jan 2018 18:33:15 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9B81D58C5A1; Wed, 17 Jan 2018 03:33:11 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 81E75B0D79D; Wed, 17 Jan 2018 03:33:11 +0100 (CET) Date: Wed, 17 Jan 2018 03:33:11 +0100 From: Toerless Eckert To: Ben Campbell Cc: The IESG , draft-ietf-anima-stable-connectivity@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20180117023311.GA26617@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151562899665.15876.3762205729160423887.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jan 2018 02:33:27 -0000 Thanks, Ben I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt Wrt. your comment. I did create for -08 a section of normative references. IN reply to Alvaros DISCUSS i wrote: > I went through the references and made those normative where i thought > rfc7322#section-4.8.6 "are essential to ... understanding the content" > applies. > > This set is of course somewhat subjective. Eg.: there is nothing special > to know about RFC6434, so its kept informational. On the other hand, if > you're a poor enterprise requiring to use any of the nasty NAT options > mentioned, you really want to read up on SIIT (RFC7915), so i made that > normative. Most customers i talked to did not know ULA (rfc4193), so i made it > normative. For fairness so then did the same for rfc1918. I hope this addresses your comment. Cheers toerless On Wed, Jan 10, 2018 at 04:03:16PM -0800, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-anima-stable-connectivity-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am skeptical that there are no normative references at all. Is it reasonable > that a reader could skip all the references and still fully understand this > document? > -- --- tte@cs.fau.de From nobody Tue Jan 16 18:33:54 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF9312EC31; Tue, 16 Jan 2018 18:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxchOv72tfmA; Tue, 16 Jan 2018 18:33:51 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED6B12D948; Tue, 16 Jan 2018 18:33:46 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 97AE558C5A1; Wed, 17 Jan 2018 03:33:42 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 88168B0D79D; Wed, 17 Jan 2018 03:33:42 +0100 (CET) Date: Wed, 17 Jan 2018 03:33:42 +0100 From: Toerless Eckert To: Suresh Krishnan Cc: The IESG , draft-ietf-anima-stable-connectivity@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20180117023342.GA26631@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151564081176.8304.13253757891345258555.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Suresh Krishnan's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jan 2018 02:33:52 -0000 Tahnk you, Suresh I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt The paragraph in question was changed as follows for -08: | One architectural expectation for the GACP as described in | is that all devices that want to use the | GACP do support IPv6. Including NMS hosts Note that this expectation | does not imply any requirements against the data-plane, especially no | need to support IPv6 in it. The data-plane could be IPv4 only, IPv6 only, | dual stack or it may not need to have any IP host stack on the network | devices. I hope this resolves your comment. Cheers Toerless P.S.: Note that in response to Alvaros DISCUSS, the document now uses the term "GACP" (generalized ACP) and defines in the architectural expectations (constraints) for GACPs. The reason for this was to make it clear that this document is not specifically discussing only the ACP as it finally will come out of the ANIMA WG (hopefully ;-) but any type of solution that is an automatically built, isolated, secured (VRF) for inband management network with IPv6 only - connecting to NOC/NMS. [ The reason why i think this will help the document is that it a lot more clearly distinguishes between the principles under which the stable-connectivity document applies and the details in the ACP spec. And it may be useful also when variations of the ACP may get defined - this stable connectivity is then still applicable. ] On Wed, Jan 10, 2018 at 07:20:11PM -0800, Suresh Krishnan wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-anima-stable-connectivity-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * The first paragraph of Section 2.1.4. is extremely difficult to read and the > sentences seem incomplete/malformed. Please consider rewording > > " ACP does not support IPv4: Single stack IPv6 management of the > network via ACP and (as needed) data plane. Independent of whether > the data plane is dual-stack, has IPv4 as a service or is single > stack IPv6. Dual plane management, IPv6 for ACP, IPv4 for the data > plane is likewise an architecturally simple option." > From nobody Tue Jan 16 18:36:14 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308C712EC37; Tue, 16 Jan 2018 18:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-bPy82fcej6; Tue, 16 Jan 2018 18:36:10 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D785812EC34; Tue, 16 Jan 2018 18:36:09 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A131758C5A1; Wed, 17 Jan 2018 03:36:05 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 881A3B0D79D; Wed, 17 Jan 2018 03:36:05 +0100 (CET) Date: Wed, 17 Jan 2018 03:36:05 +0100 From: Toerless Eckert To: Alissa Cooper Cc: Matthew Miller , gen-art , anima@ietf.org, draft-ietf-anima-stable-connectivity.all@ietf.org Message-ID: <20180117023605.GA26656@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2AAF0CB9-E081-40EB-ACC5-C752708BFCD1@cooperw.in> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] [Gen-art] Genart last call review of draft-ietf-anima-stable-connectivity-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jan 2018 02:36:12 -0000 Thanks a lot Matthew, Alissa I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt All nits fixed. Diff here: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/9bff109281e8b3c22522c3144cbf0f13e5000498/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt > """ > If the secure ACP was extendable via untrusted routers then it would > be a lot more verify the secure domain assertion. > """ Was fixed to "...more difficult to verify..." via earlier fix for another reviewer, so it does not show up in diff above. > > * In Section 2.2. "Stable Connectivity for Distributed Network/OAM", > > second paragraph; the word "applicable" should be "applied" in the > > fragment "... how ell it applicable to a ...". Actually fixed to "how well it _is_ applicable" Hope this resolves your concerns. Cheers Toerless On Thu, Jan 11, 2018 at 09:36:32AM -0500, Alissa Cooper wrote: > Matt, thanks for your review. I have entered a No Objection ballot and asked for your nits to be addressed. > > Alissa > > > On Nov 26, 2017, at 3:48 PM, Matthew Miller wrote: > > > > Reviewer: Matthew Miller > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > . > > > > Document: draft-ietf-anima-stable-connectivity-07 > > Reviewer: Matthew A. Miller > > Review Date: 2017-11-26 > > IETF LC End Date: 2017-11-26 > > IESG Telechat date: N/A > > > > Summary: > > > > This document is ready to be published as informational, but there are > > a number of nits that ought be addressed before final publication. > > > > Overall, the document is > > > > Major issues: NONE > > > > Minor issues: NONE > > > > Nits/editorial comments: > > > > * Throughout, there is a mix of the term "data plane" and "data-plane". > > One form should be chosen and the rest corrected to match. > > > > * In Section 1.2. "Data Communications Networks (DCNs)", first > > paragraph; "'th" should be "'s" (or just "s"): "In the late > > 1990'th and ..." should be "In the late 1990s and ...". > > > > * In Section 1.2. "Data Communications Networks (DCNs)", first > > paragraph; the word "where" should be "were" in the fragment > > "These where (and still are) ...". > > > > * In Section 1.2. "Data Communications Networks (DCNs)", first > > paragraph; there is a missing "a" between "are" and "separate" in > > the fragment "they are separate network entirely". > > > > * In Section 2.1.1. "Simple Connectivity for Non-ACP capable NMS > > Hosts", first paragraph; there is a mismatch in plurality in the > > third sentence; instead of: > > > > """ > > They acts as the default router to those NMS hosts and provide them > > with IPv6 connectivity into the ACP. > > """ > > > > it should be: > > > > """ > > They act as the default routers to those NMS hosts and provide them > > with IPv6 connectivity into the ACP. > > """ > > > > * In Section 2.1.3. "Simultaneous ACP and Data Plane Connectivity", > > last paragraph; the following sentence seems to be missing a word > > or two: > > > > """ > > If the secure ACP was extendable via untrusted routers then it would > > be a lot more verify the secure domain assertion. > > """ > > > > * In Section 2.1.4. "IPv4-only NMS Hosts", second paragraph after the > > ordered list; the word "thought" should be "through" in the fragment > > "... be reachable thought the IPv6/IPv4 ...". > > > > * In Section 2.1.5. "Path Selection Policies", fourth paragraph from > > the section's end; there is an extra "of" between "shaping" and "at": > > > > """ > > Traffic policing and/or shaping of at the ACP edge in the NOC can be > > used to throttle applications such as software download into the ACP. > > """ > > > > * In Section 2.2. "Stable Connectivity for Distributed Network/OAM", > > second paragraph; there is a missing "to" between "start" and > > "provide" in the fragment "... tried to start provide common ...". > > > > * In Section 2.2. "Stable Connectivity for Distributed Network/OAM", > > second paragraph; the word "applicable" should be "applied" in the > > fragment "... how ell it applicable to a ...". > > > > * In Section 3.1. "No IPv4 for ACP", third paragraph; the word "as" > > should be "to" in the fragment "... from a native transport as just > > a service on the edge." > > > > * In Section 3.1. "No IPv4 for ACP", last paragraph; the word "type" > > should be "types" in the fragment "In other type of networks as > > well, ...". > > > > * In Section 3.1. "No IPv4 for ACP", last paragraph; the word "support" > > should be "supported" in the fragment "... family will be support so > > all use...". > > > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jan 16 18:37:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ECF12EC3D; Tue, 16 Jan 2018 18:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBHgJ6gNPx9L; Tue, 16 Jan 2018 18:37:00 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D9A12D940; Tue, 16 Jan 2018 18:36:59 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6F62658C5A1; Wed, 17 Jan 2018 03:36:55 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5E7BDB0D79D; Wed, 17 Jan 2018 03:36:55 +0100 (CET) Date: Wed, 17 Jan 2018 03:36:55 +0100 From: Toerless Eckert To: Mirja Kuehlewind Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com Message-ID: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2fec5e70-3677-4380-ae11-0ab499062ea7@kuehlewind.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jan 2018 02:37:03 -0000 Mirja, Yoshifumi I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt I have reworked the MPTCP text based on your threads feedback with the intention to fix errors and have it answer the questions/concerns raised, but without otherwise changing the scope of it: - What are they key features making MPTCP interesting - How could it be used to solve the stable-connectivity issue - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK beyond the scope of this document - Describe the areas of specification work required - API/policy, control by apps - dealing with dual VRF addresses Please check diff in this URL (not complete diff of -08, just fix for your discuss/comment): http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt I hope this resolves your DISCUSS/comments. Note that the term ACP was changed in the doc to GACP based on resolving Alvaros discus. See: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt Thank you Toerless On Thu, Jan 11, 2018 at 03:42:53PM +0100, Mirja K?hlewind wrote: > Hi Toerless, > > the point I'm wondering about is your point (b) below. Yes, you can > set the ACP subflow to backup but that would still mean that if the > other link fails, it would automatically switch over to the ACP > subflow (without exposing this to the upper layer). Is that what you > want? Because my understanding was rather that there are cases where > you'd probably would like to know over which link the OAM packets > where actually sent...? > > Mirja > > On 08.01.2018 22:06, Toerless Eckert wrote: > >Thanks, Mirja > > > >(a) If the systems socket API does not transparently make TCP sockets > >to use MPTCP, then you would want a shim library. According to > >draft-hesmans-mptcp-socket, this is be the case on Apple (iOS). > > > >(b) Making the ACP subflow not carry traffic after establishing the > >data plane subflow should easily be possible possible by setting its MP_PRIO > >to backup. > > > >(c) How exactly to specify or implement the desired policy of only > >establishing a subflow between the ACP addresses and the data plane addresses > >(but not full-mesh) seem to be a subject for further spec work. It could > >be defined as a specific in-MPTCP policy, or it could be done via a shim > >library (orthogonal to (a)). draft-hesmans-mptcp-socket might be sufficient. > > > >But in general: i would like for this (informational!) draft to just motivate > >the concept and not specify the solution: MPTCP would be a simple way to > >make "TCP" applications automatically "upgrade" from ACP to a data-plane path > >and switch back when data-plane fails... because MP-TCP can signal the > >additional data-plane addresses, establish transparently another subflow and switch > >traffic between the subflows - all by using the right shim-library+API or > >in-MP-TCP address/subflow policies - and the ability to establish subflows > >across two VRFs. > > > >Cheers > > Toerless > > > >On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind (IETF) wrote: > >>>>>Suggested replacement text last two paragraphs of 2.1.5: > >>>A (shim) library for aplications maps TCP connections to MPTCP without the applications having to be aware of it. > >>It???s not the (shim) library/policy framework that opens/maps the TCP connection. MPTCP itself opens eventually multiple connections but exposes only one connection to the layer above. That means everything above MPTCP does not have any real control about which data is send over which connection. > >> > >>A policy shim layer could only implement rules about which new subflows should be established when and what the priority is over which subflow data should be sent but it generally does not control which data is send of which flow. You can???t say I want this data to be sent over subflow one and this data to be sent over sub flow two. > >> > >>I think what you want is actually a view on the different TCP connections and you try to use MPTCP only for announcing the other IP address but that is not what MPTCP meant to be. > >> > >>Mirja > >> > >> > >>>Names in DNS use only the ACP IPv6 addresses of network devices. Thererefore, the initial MPTCP subflow will use the ACP. After it is operating, the shim libraries on both ends add their data-plane address (MPTCP ADD_ADDR) and attempt to build a new subflow between those addresses. If that (data plane) subflow is successfully built, the shim libraries could shift all traffic over this subflow which should be forwarded hardware accelerated by the network - and use the ACP subflow across the ACP solely for signaling - beause it is most resilient against failure. > >>> > >>>This MPTCP approach is only an outline and would need to be fully speficied for interoperable implementations. It may also require extensions to MP-TCP. This mechanism must not be used without providing for encryption of subflows not running across the ACP. > >>> > >>>>>Brian: ... can not use capital MUST NOT in an information draft (i think) > >>>>> > >>>Cheers > >>> Toerless > >>> > >>>On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind (IETF) wrote: > >>>>Hi Micheal, > >>>> > >>>>to clarify one part below: > >>>> > >>>>>Am 05.01.2018 um 23:30 schrieb Michael Richardson : > >>>>> > >>>>> > >>>>>Mirja Kühlewind wrote: > >>>>>>"DNS naming is set up to provide the ACP IPv6 address of network > >>>>>>devices. Unbeknownst to the application, MPTCP is used. MPTCP > >>>>>>mutually discovers between the NOC and network device the data-plane > >>>>>>address and caries all traffic across it when that MPTCP subflow > >>>>>>across the data-plane can be built." > >>>>>Section 2.1.5 is discussion, it discusses ways in which the > >>>>>anticipated low performance (compared to what the box might do with its > >>>>>hardware accelerated forwarding). > >>>>> > >>>>>If we have an application that needs the bandwidth of the native hardware, > >>>>>the connection can be initated over the ACP (that's what would be in DNS). > >>>>>One presumes that an MPTCP layer could then enumerate the available IPs at > >>>>>each end and then start off additional flows on the other destinations. > >>>>MPTCP adda an additional TCP flow but for the application that still looks like one flow. As I said I???m not sure if that is what you want. > >>>> > >>>>Mirja > >>>> > >>>> > >>>>>The application would have to include application security, since it would > >>>>>not be protected by the ACP. > >>>>> > >>>>>Perhaps MPTCP doesn't work this way. > >>>>> > >>>>>>However, I'm actually uncertain how this is supposed to work and what > >>>>>>"Unbeknownst to the application" should mean. If another address should be > >>>>>>signaled to the other host, this needs to be indicated by the application or at > >>>>>>least some kind of policy framework above MPTCP. Also MPTCP will by default use > >>>>>>both paths simultaneously while still looking like one connection to the > >>>>>>application, meaning the application has no control which path is used for > >>>>>>which traffic. I guess you can open a second subflow and then configure the > >>>>>>first subflow as backup path but I'm not sure if that's what you want (given > >>>>>>the application/policy framework will still not know which path is used)..? > >>>>>>Please provide more information about what the expected usage scenario is here. > >>>>> > >>>>>-- > >>>>>Michael Richardson , Sandelman Software Works > >>>>>-= IPv6 IoT consulting =- > >>>>> > >>>>> > >>>>> > >>>>_______________________________________________ > >>>>Anima mailing list > >>>>Anima@ietf.org > >>>>https://www.ietf.org/mailman/listinfo/anima > >>>-- > >>>--- > >>>tte@cs.fau.de -- --- tte@cs.fau.de From nobody Tue Jan 16 18:37:47 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD2212D940; Tue, 16 Jan 2018 18:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BLrktgaCyvl; Tue, 16 Jan 2018 18:37:43 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88D712EC42; Tue, 16 Jan 2018 18:37:33 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C4A9158C5A1; Wed, 17 Jan 2018 03:37:29 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id B1AFBB0D79D; Wed, 17 Jan 2018 03:37:29 +0100 (CET) Date: Wed, 17 Jan 2018 03:37:29 +0100 From: Toerless Eckert To: Yoshifumi Nishida Cc: dreft-ietf-anima-stable-connectivity@ietf.org, tsv-art@ietf.org, anima@ietf.org Message-ID: <20180117023729.GA26735@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] TSV-ART telechat review of draft-ietf-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jan 2018 02:37:45 -0000 Mirja, Yoshifumi I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt I have reworked the MPTCP text based on your threads feedback with the intention to fix errors and have it answer the questions/concerns raised, but without otherwise changing the scope of it: - What are they key features making MPTCP interesting - How could it be used to solve the stable-connectivity issue - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK beyond the scope of this document - Describe the areas of specification work required - API/policy, control by apps - dealing with dual VRF addresses Please check diff in this URL (not complete diff of -08, just fix for your discuss/comment): http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt I hope this resolves your DISCUSS/comments. Note that the term ACP was changed in the doc to GACP based on resolving Alvaros discus. See: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt Thank you Toerless On Tue, Jan 09, 2018 at 05:37:16PM -0800, Yoshifumi Nishida wrote: > I've reviewed this document as part of TSV-ART's ongoing effort to review > key IETF documents. These comments were written primarily for the transport > area directors, but are copied to the document's authors for their > information and to allow them to address any issues raised.When done at the > time of IETF Last Call, the authors should consider this review together > with any other last-call comments they receive. Please always CC tsv-art > @ietf.org if you reply to or forward this review. > > Summary: This document is almost ready for publication, but several points > need to be clarified or updated. > > 1: In Section 2.1.5 > " > MPTCP (Multipath TCP -see [RFC6824]) is a very attractive candidate > to automate the use of both data-plane and ACP and minimize or fully > avoid the need for the above mentioned logical names to pre-set the > desired connectivity (data-plane-only, ACP only, both). For example, > a set-up for non MPTCP aware applications would be as follows: > > DNS naming is set up to provide the ACP IPv6 address of network > devices. Unbeknownst to the application, MPTCP is used. MPTCP > mutually discovers between the NOC and network device the data-plane > address and caries all traffic across it when that MPTCP subflow > across the data-plane can be built. > " > > It's not very clear to me how to archive this feature. > I think more explanation will be required. > As MPTCP resides in transport layer, I think it will be very tricky to know > which endpoint is used for ACP or for data-plane. Also, although MPTCP > can transmit application data to multiple destinations, it cannot > identify which part of data is for ACP or for data-plane as it doesn't > parse app data. > > 2: in Section 2.1.8 > > " > Leverage and as necessary enhance MPTCP with automatic dual- > connectivity: If an MPTCP unaware application is using ACP > connectivity, the policies used should add subflow(s) via the > data-plane and prefer them. > " > > I think functions like controlling policies should be designed outside of > MPTCP such as middleware > between applications and transport layer, but the text is unclear about how > to enhance MPTCP. > > Thanks, > -- > Yoshi > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jan 16 18:38:28 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B2D12EC3D; Tue, 16 Jan 2018 18:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAVRpbvJafDm; Tue, 16 Jan 2018 18:38:19 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DFBF12EC47; Tue, 16 Jan 2018 18:38:03 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0FBD558C5A1; Wed, 17 Jan 2018 03:37:59 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id EABD9B0D79D; Wed, 17 Jan 2018 03:37:58 +0100 (CET) Date: Wed, 17 Jan 2018 03:37:58 +0100 From: Toerless Eckert To: Eric Rescorla Cc: The IESG , draft-ietf-anima-stable-connectivity@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20180117023758.GA26755@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151564150183.11232.5234107897547990840.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Eric Rescorla's No Objection on draft-ietf-anima-stable-connectivity-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jan 2018 02:38:22 -0000 Hi Eric, I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt I hope -08 of the draft resolves your comments: 1) > secure ACP was extendable via untrusted routers then it would be a > lot more verify the secure domain assertion. Therefore the ACP edge > devices are not supposed to redistribute routes from non-ACP routers > > There's something grammatically wrong here and I can't make sense of this > sentence. This was fixed through review by Matthew Miller to say: | If the secure GACP was extendable via untrusted routers then it would | be a lot more difficult to verify the secure domain assertion. [ Aka: This section is dealing with the problem of how to overcome the lack of cryptographic security on the legacy NOC devices (hopefully temporarily) with physical secured access to the trusted ACP edge device. So so we limit the options to build out that physcial security area to avoid the most common operator errors - messing up L3 routing/ leaking routes. ] 2) > TLS/DTLS ([RFC5246])/([RFC6347]) with mutual AN-domain certificate > authentication - and does not incur new key management. > This isn't entirely clear to me. What are the identities that these devices are > using to talk to each other? Are they always FQDNs? A bit of background to answer this question: As part of resolving Alvaro Retanas DISCUSS, i extended section 1.3 to explain that this document is not specific to the ACP (as specified in draft-ietf-anima-autonomic-control-plane) but rather any (similar) solution that meets contraints/requirements. And we call those GACP (generalized ACP). The ACP of course is the first instance of such a GACP that we want to standardize (via draft-ietf-anima-autonomic-control-plane). The security constraint is now defined to be as follows in -08: | Closed Group Security: GACP devices have cryptographic credentials | to mutually authenticate each other as members of a GACP. Traffic | across the GACP is authenticated with these credentials and then | encrypted. The only traffic permitted in & out of the GACP that | is not authenticated by these credentials is through explicit | configuration the traffic from/to the aforementioned non-GACP NOC | equipment with subnet connections to a GACP-edge device (as a | transition method). The text you where calling out is now: | In result, data-plane connectivity that | does support this can simply leverage TLS/DTLS | ([RFC5246])/([RFC6347]) with those GACP credentials for mutual | authentication - and does not incur new key management. Aka: for this stable-connectivity draft (informational), i changed the text from "certificates" to cryptographic credentials for authentication as a more generic term because some GACP in the IoT space may use non-certificate cryptographic security (but rather shared secrets). Note that in the case of the ACP, those credentials are of course certificates, the mutual authentication is specified in: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-13#section-6.1.2 Aka: the "closed group" is identified through the "domain" field in a new certificate element for the ACP (we can discuss more hopefully soon when we get to IESG review of the ACP document, and why we didn't rely on the existing domain field of "web" certificates). But the main point of this section in the stable-connectivity draft was really only the simple statement that devices already have their GACP credentials, so they can equally use them for end-to-end authentication via the data-plane. 3) > into IPv4 support for ACP will have a longer term benefit or enough > critical short-term use-cases. Support for IPv4-only for ACP is > purely a strategic choice to focus on the known important long term > I think this probably should say IPv6 only Good catch. Thanks! 4) > address collision even though there is no central assignment > authority. This is helped by the expectation, that ACPs are never > expected to connect all together, but only few ACPs may ever need to > Nit: no comma between "expectation" and "that" Thanks. 5) > ACP packets can be recognized to come from you, you may need to list > your prefixes in multiple of those sites. > As I read this, it helps others to list, not yourself, right? Yes... Paragraph changed as following to fix This. Also to include another update that i unfortunately noticed only just now ;-(: | To help diagnose packets that unexpectedly leaked for example from | another GACP (that was meant to be deployed separately), it can be | useful to voluntarily list your own the ULA GACP prefixes on some | site(s) on the Internet and hope that other users of GACPs do the | same so that you can look up unknown ULAprefix packets seen in your | network. Note that this does not constitute registration. | https://www.sixxs.net/tools/grh/ula/ was a site to list ULA | prefixes but it is not open for new listings anymore since the mid | of 2017. The authors are not aware of other active Internet sites to | list ULA use. 6) > Any current and future protocols must rely on secure end-to-end > communications (TLS/DTLS) and identification and authentication via > This looks normative. Should it be MUST? No RFC2119 disclaimer included. No capital MUST/SHOULD/MAY. This is an informational document that was put onto ANIMA charter to validate the work on draft-ietf-anima-autonomic-control-plane by discussing the stable-connectivity use-case. In the ACP drafts there is of course RFC2119 language also for these details. Hope for your review there to catch any missing capitalization. Hope these answers resolve your comments. Thanks & Cheers Toerless On Wed, Jan 10, 2018 at 07:31:41PM -0800, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-anima-stable-connectivity-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > secure ACP was extendable via untrusted routers then it would be a > lot more verify the secure domain assertion. Therefore the ACP edge > devices are not supposed to redistribute routes from non-ACP routers > There's something grammatically wrong here and I can't make sense of this > sentence. > > secure ACP was extendable via untrusted routers then it would be a > lot more verify the secure domain assertion. Therefore the ACP edge > devices are not supposed to redistribute routes from non-ACP routers > There's something grammatically wrong here and I can't make sense of this > sentence. > > TLS/DTLS ([RFC5246])/([RFC6347]) with mutual AN-domain certificate > authentication - and does not incur new key management. > This isn't entirely clear to me. What are the identities that these devices are > using to talk to each other? Are they always FQDNs? > > into IPv4 support for ACP will have a longer term benefit or enough > critical short-term use-cases. Support for IPv4-only for ACP is > purely a strategic choice to focus on the known important long term > I think this probably should say IPv6 only > > address collision even though there is no central assignment > authority. This is helped by the expectation, that ACPs are never > expected to connect all together, but only few ACPs may ever need to > Nit: no comma between "expectation" and "that" > > ACP packets can be recognized to come from you, you may need to list > your prefixes in multiple of those sites. > As I read this, it helps others to list, not yourself, right? > > Any current and future protocols must rely on secure end-to-end > communications (TLS/DTLS) and identification and authentication via > This looks normative. Should it be MUST? > -- --- tte@cs.fau.de From nobody Tue Jan 16 18:46:22 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1380E12D940; Tue, 16 Jan 2018 18:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOSpmXyq8xcT; Tue, 16 Jan 2018 18:46:19 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5326B12EC45; Tue, 16 Jan 2018 18:38:33 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 30B3358C5A1; Wed, 17 Jan 2018 03:38:29 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1753AB0D79D; Wed, 17 Jan 2018 03:38:29 +0100 (CET) Date: Wed, 17 Jan 2018 03:38:29 +0100 From: Toerless Eckert To: Carlos Martinez Cc: ops-dir@ietf.org, ietf@ietf.org, anima@ietf.org, draft-ietf-anima-stable-connectivity.all@ietf.org Message-ID: <20180117023828.GA26773@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151561686872.26690.9031629570082529218@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Opsdir last call review of draft-ietf-anima-stable-connectivity-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jan 2018 02:46:21 -0000 Carlos, I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt Inline On Wed, Jan 10, 2018 at 12:41:08PM -0800, Carlos Martinez wrote: > Reviewer: Carlos Martinez > Review result: Ready > > Reviewer: Carlos Martinez > Review Result: Ready > > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects of > the IETF drafts. Comments that are not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs should > treat these comments just like any other last call comments. > > I found this document well-written, informative and easy to read. I believe it > to be READY for publication as an informational document. > > >From an editorial pov tt does have numerous typos and sometimes uses colloquial > language which IMO would be best if changed into more formal prose. Other > reviewers have already pointed this out as well. I have done a more thorough spell check against -08 (converted to word to leverage MS words spell checking *sigh*). I also received a couple of explicit fixes from other reviewers that was included. I am not aware of specific colloquialisms in the text (standard disclaimer about english as a second language), but: i am happy to learn & improve my english, and the experience with the RFC editor fixing up lazy language was really excellent (just had another RFC published). So unless there are more specific suggestions for textual changes, i will simply wait until RFC editor takes over and ask him/her to beat us authors over the head / help formalize colloquialisms. > >From a technical point of view, the only aspect that I feel could be worth > reconsidering is whether considering very complex use cases involving > IPv4-to-IPv6 conversions really makes sense. Such complexity could very well > offset the advantages obtained from applying the ACP to the particular problem > of network management. Again, this is not an "issue" in the document since it's > more related to my opinion on the matter. Stable-connectivity was put onto the ANIMA charter to discuss one core use-case for the ACP and thereby justify work on the ACP - and help refine details of the ACP (draft ietf-anima-autonomic-control-plane). In the process of progressing both documents, i ended up moving a lot of the details about how to do the things we want to see happen from the informational stable-connectivity draft into the normative ACP draft because that made the work more useful because it created normative language (see evolution of ACP draft from ca. -08 to -13, especially section 8.1). In the end, stable-connectivity can appear to be left looking a bit like a https://en.wikipedia.org/wiki/Bad_bank - all the difficult bits not fit to standardize: transition work like NAT to overcome lack of IPv6 or cool future stuff like MPTCP. Great but more work needed to standardize. But: I have repeatedly defended during working group last call the sections about options of IPv4-IPv6 transition because i explicitly dealt with customers who had no other choice to get started and actually had me document similar level of details - if you look at IPv6 gap analyses, you should notice that networking equipment is a lot further ahead than the randomn NOC solution/applications. So, yes, i do agree that there is a risk to shy off possible adopters with these details, but i hope its actually more helpful than scary: Depending on familiarity with NAT, readers hopefully either decide to configure their NAT if necessary or speed up their plans to get IPv6 also into their NOC to be able to use an ACP. And not documenting this in detail is like a bad sales pitch - "oh, sure, this will work fine... go figure out yourself the details". Sorry for the rant ;-) > My thanks go to the authors for a very informative and nice to read document. > > /Carlos Thank you for the review and insightful comment! Cheers Toerless -- --- tte@cs.fau.de From nobody Thu Jan 18 00:59:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B7112EB18; Thu, 18 Jan 2018 00:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw15f-Y-0kyN; Thu, 18 Jan 2018 00:59:46 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01651200E5; Thu, 18 Jan 2018 00:59:45 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D0917885B6EFB; Thu, 18 Jan 2018 08:59:41 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 18 Jan 2018 08:59:42 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Thu, 18 Jan 2018 16:59:35 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 Thread-Index: AdOQOqjZa4fS/rQGRxGAbTN9FDz3cg== Date: Thu, 18 Jan 2018 08:59:35 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B92818111C7NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 08:59:50 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B92818111C7NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, authors of anima-reference-model, I have reviewed the draft as the document shepherd, see below comments. Ove= rall, I feel this document is very useful and it is almost ready for be pub= lished. Please properly address my comments together with other WGLC commen= ts you may receive. Another revised version of the document is needed to pr= ocess the document further if it passed the WGLC. General issues: 1. In section 3.1, it says "The Autonomic Control Plane (ACP) is the s= ummary of all interactions of the Autonomic Networking Infrastructure with = other nodes and services." I'm a bit confused by this statement. In my unde= rstanding, the ACP itself is mostly a "channel", although some ANI function= s (signaling, aggregated reporting etc.) are running within the channel, th= ey should be parallel with ACP function in the architecture view. At the same time, there are indeed some functions considered as sub-functio= ns of the ACP, e.g. the addressing and routing, which are necessary to make= the ACP runnable. So, my questions to the co-authors: 1) Do you see ACP as an individual function as I understood (mostly a = channel), or a summary of a suite of functions running inside the ACP? 2) What functions are sub-functions of ACP, and what are in parallel w= ith ACP? 2. I'm confused by the whole purpose of Section 3. The first sub-claus= e is describing the architecture of an Autonomic Network Element, while the= rest sub-clauses (adjacency table, state machine etc.) seems more like "im= plementation considerations" or "procedures". I think both are useful conte= nt, but they are in two different dimensions, maybe separate them into diff= erent sections? 3. Some texts (e.g. paragraph 4 of Section 1) are directly bind to the= WG's charter, I'm not sure it is a good approach that an RFC normatively r= efer the WG charter which is dynamically changed along with the work going = on in the WG. Maybe just simply re-phrase the "chartered work" as "Phase 1/= near term work", and "non-chartered" as "Phase 2 long-term"? 4. The whole Section 7 seems too theoretical and abstract. The describ= ed concepts are valuable, I'd suggest to have more texts mapping these conc= epts into the ANI/AN. Specific comments: Section 1 Introduction - Paragraph 3 claims "This reference model allows for this hybrid ap= proach." I think it would be better to explain in what degree the "hybrid" = could be. For example, the ANI actually doesn't support non-autonomic nodes= to join in the same domain with the autonomic nodes; thus, in this deploym= ent level, it is not "hybrid". - As said in the general issues, paragraph 4 seems binding with the = WG charter too much. Section 2 The Network View - In the figure, it seems the ASAs are hierarchical, but there is no= relevant texts. My understanding is that, it is reasonable to distinguish = layered ASAs, e.g., some ASAs might be very fundamental, and should be the = future work of the Anima WG; while most of the specific ASAs are service/sc= enario relevant, that might not be suitable to do them case by case in Anim= a. - "The current charter of the ANIMA WG is to specify the ANI, using = a few autonomic functions as use cases." Again, I'm not sure it is good to = bind the RFC to the WG charter. Section 3 The Autonomic Network Element - If Figure 1 means to make the ASAs hierarchical, then it is better= to be consistent in Figure 2. - Nits in Figure 2 Synchronization -> synchronization In the ANI part, the "Discovery, negotiation and synchronisation f= unctions" looks like a sub-item of "Autonomic Node Addressing", I guess it = should be typo? - Section 3.1 "The Autonomic Networking Infrastructure (ANI) is norm= ally built on a hop-by-hop basis." It is true for ACP, but I don't think it= applies for all the other ANI functions, e.g. negotiation/sync signaling. - Section 3.2, the first bullet point of paragraph 3 "link local dis= covery", it is ambiguous that what kind information is gathered through GRA= SP. I think there should be some basic information gathered through ND prot= ocol. - Section 3.2, the third bullet point: "Once the node is part of the= ACP of a domain, it will use GRASP discovery [I-D.ietf-anima-grasp] to fin= d Registrar(s) of its domain and potentially other services." The later ver= sion of BRSKI changed to use a GRASP Flood message to actively broadcast th= e registrar service by the proxies in their link-local scope. - Section 3.3.2, I think it would be good to briefly discuss the sit= uation that if an enrolled node re-boot from power cut or be attached to an= other network, how the transition state would be? Is it the same with "Fact= ory reset"? Section 4 The Autonomic Networking Infrastructure - Section 4.2 Addressing, there are a list of comprehensive requirem= ents of addressing, which are good content. It might be better if Section 4= .1 Naming also include such a requirement list? - Section 4.5 "All autonomic nodes in a domain must be able to commu= nicate with each other, and with autonomic nodes outside their own domain."= The cross-domain mechanism hasn't be covered yet, maybe it's better to not= e this feature is for "long term" work rather than "phase 1". - Section 4.6 "The totality of autonomic interactions forms the "Aut= onomic Control Plane". Again, it is the same as No.1 general issue as descr= ibed above. Section 5 Security and Trust Infrastructure - Section 5.2 describes domain certificate; I think the device certi= ficate, which is pre-set by the manufacture also needs to be mentioned. Section 6 Autonomic Service Agents (ASA) - It might be good to reference draft-carpenter-anima-asa-guidelines= ? - Section 6.3 is interesting, it actually unveils the ANI functions = (except GRASP) are yet ASAs. It is no problem for me, but I have a bit conc= ern that new readers might be confused about the "overlap/mixture" between = ANI and ASAs? Section 7 Managing a (Partially) Autonomic Network - Section 7.6 APIs: this section are too abstract for me, I just cou= ldn't really get the point. It seems like a general design pattern rather t= han specific mechanisms related to autonomic networks. - Section 7.7 Data Model has the similar issue as above. It explains= the concept but lacks essential content related to ANI. Thanks and regards, Sheng From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Tuesday, January 09, 2018 2:26 PM To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by J= anuary 22nd, 2018 Hi all, This message starts the two-week ANIMA Working Group Last Call to advance d= raft-ietf-anima-reference-model-05, A Reference Model for Autonomic Network= ing. This document's intended status is Informational. At present, there is= no IPR file against this document. Please send your comments by January 22nd, 2018. If you do not feel this do= cument should advance, please state your reasons why. Sheng JIANG is the assigned document shepherd. Regards, Sheng (co-chair, Toerless who as a co-author stayed neutral on the content = side) --_000_5D36713D8A4E7348A7E10DF7437A4B92818111C7NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, aut= hors of anima-reference-model,

&n= bsp;

I have = reviewed the draft as the document shepherd, see below comments. Overall, I= feel this document is very useful and it is almost ready for be published.= Please properly address my comments together with other WGLC comments you may receive. Another revised version of the d= ocument is needed to process the document further if it passed the WGLC.

&n= bsp;

General= issues:

1. = ;     In section 3.1, it says “The Autonomic Cont= rol Plane (ACP) is the summary of all interactions of the Autonomic Network= ing Infrastructure with other nodes and services.” I’m a bit co= nfused by this statement. In my understanding, the ACP itself is mostly a “= channel”, although some ANI functions (signaling, aggregated reportin= g etc.) are running within the channel, they should be parallel with ACP fu= nction in the architecture view.

At the = same time, there are indeed some functions considered as sub-functions of t= he ACP, e.g. the addressing and routing, which are necessary to make the AC= P runnable.

So, my = questions to the co-authors:

1) = ;     Do you see ACP as an individual function as I und= erstood (mostly a channel), or a summary of a suite of functions running in= side the ACP?

2) = ;     What functions are sub-functions of ACP, and what= are in parallel with ACP?

2. = ;     I’m confused by the whole purpose of Sectio= n 3. The first sub-clause is describing the architecture of an Autonomic Ne= twork Element, while the rest sub-clauses (adjacency table, state machine etc.) seems more like “implementation considerations” or ̶= 0;procedures”. I think both are useful content, but they are in two d= ifferent dimensions, maybe separate them into different sections?

3. = ;     Some texts (e.g. paragraph 4 of Section 1) are di= rectly bind to the WG’s charter, I’m not sure it is a good appr= oach that an RFC normatively refer the WG charter which is dynamically chan= ged along with the work going on in the WG. Maybe just simply re-phrase the &#= 8220;chartered work” as “Phase 1/near term work”, and = 220;non-chartered” as “Phase 2 long-term”?

4. = ;     The whole Section 7 seems too theoretical and abs= tract. The described concepts are valuable, I’d suggest to have more = texts mapping these concepts into the ANI/AN.

&n= bsp;

Specifi= c comments:

&n= bsp;

Section= 1 Introduction

- =        Paragraph 3 claims “This referen= ce model allows for this hybrid approach.” I think it would be better= to explain in what degree the “hybrid” could be. For example, = the ANI actually doesn’t support non-autonomic nodes to join in the same domain with the autonomic = nodes; thus, in this deployment level, it is not “hybrid”.=

- =        As said in the general issues, paragra= ph 4 seems binding with the WG charter too much.

&n= bsp;

Section= 2 The Network View

- =        In the figure, it seems the ASAs are h= ierarchical, but there is no relevant texts. My understanding is that, it i= s reasonable to distinguish layered ASAs, e.g., some ASAs might be very fun= damental, and should be the future work of the Anima WG; while most of the specific = ASAs are service/scenario relevant, that might not be suitable to do them c= ase by case in Anima.

- =        “The current charter of the ANIM= A WG is to specify the ANI, using a few autonomic functions as use cases.&#= 8221; Again, I’m not sure it is good to bind the RFC to the WG charte= r.

&n= bsp;

Section= 3 The Autonomic Network Element

- =        If Figure 1 means to make the ASAs hie= rarchical, then it is better to be consistent in Figure 2.

- =        Nits in Figure 2

 &= nbsp;       Synchronization -> synchroniza= tion

 &= nbsp;       In the ANI part, the “Disco= very, negotiation and synchronisation functions” looks like a sub-ite= m of “Autonomic Node Addressing”, I guess it should be typo?

- =        Section 3.1 “The Autonomic Netwo= rking Infrastructure (ANI) is normally built on a hop-by-hop basis.” = It is true for ACP, but I don’t think it applies for all the other AN= I functions, e.g. negotiation/sync signaling.

- =        Section 3.2, the first bullet point of= paragraph 3 “link local discovery”, it is ambiguous that what = kind information is gathered through GRASP. I think there should be some ba= sic information gathered through ND protocol.

- =        Section 3.2, the third bullet point: &= #8220;Once the node is part of the ACP of a domain, it will use GRASP disco= very [I-D.ietf-anima-grasp] to find Registrar(s) of its domain and potentia= lly other services.” The later version of BRSKI changed to use a GRASP F= lood message to actively broadcast the registrar service by the proxies in = their link-local scope.

- =        Section 3.3.2, I think it would be goo= d to briefly discuss the situation that if an enrolled node re-boot from po= wer cut or be attached to another network, how the transition state would be? Is it the same with “Factory reset”?

&n= bsp;

Section= 4 The Autonomic Networking Infrastructure

- =        Section 4.2 Addressing, there are a li= st of comprehensive requirements of addressing, which are good content. It = might be better if Section 4.1 Naming also include such a requirement list?=

- =        Section 4.5 “All autonomic nodes= in a domain must be able to communicate with each other, and with autonomi= c nodes outside their own domain.” The cross-domain mechanism hasn= 217;t be covered yet, maybe it’s better to note this feature is for “long term&= #8221; work rather than “phase 1”.

- =        Section 4.6 “The totality of aut= onomic interactions forms the "Autonomic Control Plane". Again, i= t is the same as No.1 general issue as described above.

&n= bsp;

Section= 5 Security and Trust Infrastructure

- =        Section 5.2 describes domain certifica= te; I think the device certificate, which is pre-set by the manufacture als= o needs to be mentioned.

&n= bsp;

Section= 6 Autonomic Service Agents (ASA)

- =        It might be good to reference draft-ca= rpenter-anima-asa-guidelines?

- =        Section 6.3 is interesting, it actuall= y unveils the ANI functions (except GRASP) are yet ASAs. It is no problem f= or me, but I have a bit concern that new readers might be confused about the “overlap/mixture” between ANI and ASAs?<= /p>

&n= bsp;

Section= 7 Managing a (Partially) Autonomic Network

- =        Section 7.6 APIs: this section are too= abstract for me, I just couldn’t really get the point. It seems like= a general design pattern rather than specific mechanisms related to autono= mic networks.

- =        Section 7.7 Data Model has the similar= issue as above. It explains the concept but lacks essential content relate= d to ANI.

&n= bsp;

Thanks = and regards,

&n= bsp;

Sheng

&n= bsp;

From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang
Sent: Tuesday, January 09, 2018 2:26 PM
To: anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respo= nd by January 22nd, 2018

 

Hi all,=

 <= o:p>

This message starts the two-week ANIMA Working Group Last Call to a= dvance draft-ietf-anima-reference-model-05, A Reference Model for Autonomic= Networking. This document's intended status is Informational. At present, there is no IPR file against this doc= ument.

 <= o:p>

Please send your comments by January 22nd, 2018. If you do not feel= this document should advance, please state your reasons why.

 <= o:p>

Sheng JIANG is the assigned document shepherd.

 <= o:p>

Regards,

 

Sheng (co-chair, Toerless who as a co-author stayed neutral on the = content side)

 

--_000_5D36713D8A4E7348A7E10DF7437A4B92818111C7NKGEML515MBXchi_-- From nobody Thu Jan 18 07:56:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E992812711D; Thu, 18 Jan 2018 07:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlIOHSekYPhg; Thu, 18 Jan 2018 07:56:00 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 362661270A0; Thu, 18 Jan 2018 07:56:00 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id p16so20492515otf.1; Thu, 18 Jan 2018 07:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=36LbIw5s5fp65uyMuF/1Jw22V9U/nRNue2rXCZ6TN1Q=; b=YdGrSNNdgV1sVBap2TNoPtO1U2zYCo5VkZW3y+3kxbzNOEmBtKEoa5+JQobITxhQPG AWSOUZB9oMVShc23FcL+3CFmYMJ59ulEnqhnGJWNn32LRFXrqx2T8khtMPMgxgXvgQGg 4e2UFOdtv7/IYXJjrICHbMe8cTFqyti7hf9XA5zupEs7aDFAvMYvaNP4JPCk6nQqwQoo tHh/udbl4NRaV0Nw1VGgDroRXDc2AfdwHbLR0vEFoa7D65mvnjd56hVoZR4zFACbujBb uNs1+apNJanVJo9UhRu9qtJtWjbahZSTORsiNzdxvsOKYVYu79lmg4ez+NlHCZ7K6f3U O5Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=36LbIw5s5fp65uyMuF/1Jw22V9U/nRNue2rXCZ6TN1Q=; b=ADBObLWsAF7j6y1OVUdmcaMPexwywTEuGmpA6mgoZjcX/58nkMNxKf4q357ynJz0+4 BCzOlKhYtRNcv6u6r0ZJILR2xFEXPTwOcjfP0zuj5HWNu8OjS06A0qWqbvCwZllbOKsi qMLB4gogK8NIMeOFJAL4b8r5nLc/f4ZfA08gDrudpCINrb5o5QjMOzw/WWMTXJexZ6JZ FliKZR6BODDydukGAn21a8hVsjkT8b5SiXLzSCXe9bKGNVnuuuEpRD5D/ZCD6RefUG1q ncHfKSowwTV/z6xW7woSRKgf3KVcsNCkpi/Gk1spmcDobI17mprhOHFo+MqFdE4ISnuA v6WA== X-Gm-Message-State: AKwxytcpRtOlrgVTVl9m8F4lWQ0cOFGQI06FB3GCu2XGJZqZ3sUgYfiT 1s8eMb28Ara5ipVEKstv3i4gJDmrVPGFrxXBcLg= X-Google-Smtp-Source: ACJfBoupDZR96E3n6Wu2vgyp2zvHFkunjMJ8IuhNEim5gw+b4a42Kd/ZTqGSTVVZcP7jzJUoNCK7X5fmjB/8fzfPliA= X-Received: by 10.157.34.196 with SMTP id y62mr3761260ota.307.1516290959483; Thu, 18 Jan 2018 07:55:59 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 18 Jan 2018 07:55:59 -0800 From: Alvaro Retana In-Reply-To: <20180117023241.GA26571@faui40p.informatik.uni-erlangen.de> References: <20180117023241.GA26571@faui40p.informatik.uni-erlangen.de> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 18 Jan 2018 07:55:59 -0800 Message-ID: To: Toerless Eckert Cc: anima-chairs@ietf.org, anima@ietf.org, Sheng Jiang , The IESG , draft-ietf-anima-stable-connectivity@ietf.org Content-Type: multipart/alternative; boundary="94eb2c04f8d60427ba05630f0094" Archived-At: Subject: Re: [Anima] Alvaro Retana's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 15:56:03 -0000 --94eb2c04f8d60427ba05630f0094 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Toerless: The changes work for me. I=E2=80=99ve cleared the DISCUSS. Thanks! Alvaro. On January 16, 2018 at 9:32:44 PM, Toerless Eckert (tte@cs.fau.de) wrote: Thanks, Alvaro I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt I have modified the verbage in -08 according to your suggestions. A) GACP Section 1.3 now introduces the four core design constraints of a generic ACP (GACP) (VRF isolation, IPv6 only, NOC connectivity and Group Security) which are the basis for the (existing/unchanged) discussion in the document. The rest of the document has no semantic/content changes just textual changes for ACP -> GACP. There are two places where the text still refers to ACP specific examples and that is accordingly highlighted. B) Normative references I went through the references and made those normative where i thought rfc7322#section-4.8.6 "are essential to ... understanding the content" applies. This set is of course somewhat subjective. Eg.: there is nothing special to know about RFC6434, so its kept informational. On the other hand, if you're a poor enterprise requiring to use any of the nasty NAT options mentioned, you really want to read up on SIIT (RFC7915), so i made that normative. Most customers i talked to did not know ULA (rfc4193), so i made it normative. For fairness so then did the same for rfc1918. The diffs regarding your DISCUSS are here (using the github commits before/after): http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.githubu= sercontent.com/anima-wg/autonomic-control-plane/d26df831da2953779c3b3ac41ec= 118cbbe43373e/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-= connectivity-08.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/auton= omic-control-plane/f2d8a85c2cc65ca7f823abac0f57d19c744f9b65/draft-ietf-anim= a-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt I hope this resolves your discuss. I am answering to the discus/comments raised by others during IESG review separately. Cheers Toerless On Thu, Jan 11, 2018 at 06:09:22AM -0800, Alvaro Retana wrote: > Toerless: > > Hi! > > Hmmm???. I see your point, but that is not what the document says. Not only > does it specifically point at the ACP anima draft ("ACP as defined in > [I-D.ietf-anima-autonomic-control-plane]???), but it is hard to ignore the > work done in the WG. > > I think that if you clearly explained the characterization of *an autonomic > control plane* and mention *the ACP* > [I-D.ietf-anima-autonomic-control-plane] as an example of that, then we > would be ok. Please then also call it something else (GACP =3D > Generic/Generalized, or anything else that clearly makes people think > you???re not explicitly talking about *the ACP*). > > Thanks! > > Alvaro. > > On January 10, 2018 at 7:29:33 PM, Toerless Eckert (tte@cs.fau.de) wrote: > > Thanks, Alvarao > > I wuld like to persuade you that ACP is not a normative reference for > stable > connectivity: > > a) Stable connectivity doc does not depend on the > details of how the ACP is built. It only assumes the following: > > - There is an autonomously build managemenet network (that we call ACP) > - The OAM functions of network nodes are able to use this ACP > to reach each other. > - Some "ACP-edge-devices" can connect NOC equipment into the ACP. > - ACP only supports IPv6 > - The ACP address space is disjoint from the address space of the data > plane > > I could come up with a lot of ways how to build an ACP that matches these > expectations. Heck: Most of the stable connectivity text would equally be > valid if you > would use an IPv6 only DCN (external physcial manaement network). Aka: > this doc is about the value of an ACP for the use-case (inband, autonomic) > and the problems of how to deal on NOC equipment with dual connectivity and > IPv6 only for that managemeent plane. > > b) stable connectivity was specifically targeted in the WG charter as a > validation document for ACP. To me this means it is somewhat of a > predecessor or > use-case to ACP: > > "If the WG manages to define an ACP that is built autonomically and that > can be characterized by the simple behavior listed in a), then this > stable-connectivity document explains that/how it can be leveraged wfor the > stable-connectibity use-case".... and therefore justifies the work on ACP > for the WG. > > Let me know if these argument are appropriate to characterize the ACP > draft as an informative reference. Otherwise i will change it to normative. > > Of course, i would be happy to improve the text to highlight this > relationship > better in the text because i also do not think that the intro tries to > really explain this well (but i did not want to try write it up before i am > clear that it would resolve your discus). > > Thanks > Toerless > > On Thu, Jan 04, 2018 at 09:28:10PM -0800, Alvaro Retana wrote: > > Alvaro Retana has entered the following ballot position for > > draft-ietf-anima-stable-connectivity-07: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I like this document, and look forward to it being published. However, it > > caught my attention that there are no Normative References. > > > > It seems clear to me that (at least) an understanding of the ACP is > necessary > > to properly achieve the objective of the document: "how to integrate OAM > > processes with the autonomic control plane (ACP) in Autonomic Networks > (AN) in > > order to provide stable and secure connectivity for those OAM processes." > I > > then think that the reference to I-D.ietf-anima-autonomic-control-plane > should > > be Normative. > > > > > > > > -- > --- > tte@cs.fau.de --=20 --- tte@cs.fau.de --94eb2c04f8d60427ba05630f0094 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi Toerless:

The changes work for me.=C2=A0 I=E2=80=99ve cleared the D= ISCUSS.

<= /div>
Thanks!
=

Alvaro.

On January 16, 2018 at 9:32:44 PM, Toerless Eckert (tte@cs.fau.de) wrote:

Thanks, Alvaro

I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-st= able-connectivity-08.txt

I have modified the verbage in -08 according to your suggestions.

A) GACP

Section 1.3 now introduces the four core design constraints of a
generic ACP (GACP) (VRF isolation, IPv6 only, NOC connectivity and Grou= p Security)
which are the basis for the (existing/unchanged) discussion in the docu= ment.

The rest of the document has no semantic/content changes just textual
changes for ACP -> GACP. There are two places where the text still
refers to ACP specific examples and that is accordingly highlighted. = =20

B) Normative references

I went through the references and made those normative where i thought
rfc7322#section-4.8.6 "are essential to ... understanding the cont= ent"
applies. =20

This set is of course somewhat subjective. Eg.: there is nothing specia= l
to know about RFC6434, so its kept informational. On the other hand, if
you're a poor enterprise requiring to use any of the nasty NAT opti= ons
mentioned, you really want to read up on SIIT (RFC7915), so i made that
normative. Most customers i talked to did not know ULA (rfc4193), so i = made it
normative. For fairness so then did the same for rfc1918.


The diffs regarding your DISCUSS are here (using the github commits
before/after):

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://= raw.githubusercontent.com/anima-wg/autonomic-control-plane/d26df831da295377= 9c3b3ac41ec118cbbe43373e/draft-ietf-anima-stable-connectivity/draft-ietf-an= ima-stable-connectivity-08.txt&url2=3Dhttps://raw.githubusercontent.com= /anima-wg/autonomic-control-plane/f2d8a85c2cc65ca7f823abac0f57d19c744f9b65/= draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-0= 8.txt


I hope this resolves your discuss.

I am answering to the discus/comments raised by others during IESG revi= ew separately.

Cheers
Toerless


On Thu, Jan 11, 2018 at 06:09:22AM -0800, Alvaro Retana wrote:
> Toerless:
> =20
> Hi!
> =20
> Hmmm???. I see your point, but that is not what the document says.= Not only
> does it specifically point at the ACP anima draft ("ACP as de= fined in
> [I-D.ietf-anima-autonomic-control-plane]???), but it is hard to ig= nore the
> work done in the WG.
> =20
> I think that if you clearly explained the characterization of *an = autonomic
> control plane* and mention *the ACP*
> [I-D.ietf-anima-autonomic-control-plane] as an example of that, th= en we
> would be ok. Please then also call it something else (GACP =3D
> Generic/Generalized, or anything else that clearly makes people th= ink
> you???re not explicitly talking about *the ACP*).
> =20
> Thanks!
> =20
> Alvaro.
> =20
> On January 10, 2018 at 7:29:33 PM, Toerless Eckert (tte@cs.fau.de) wrote:
> =20
> Thanks, Alvarao
> =20
> I wuld like to persuade you that ACP is not a normative reference = for
> stable
> connectivity:
> =20
> a) Stable connectivity doc does not depend on the
> details of how the ACP is built. It only assumes the following:
> =20
> - There is an autonomously build managemenet network (that we call= ACP)
> - The OAM functions of network nodes are able to use this ACP
> to reach each other.
> - Some "ACP-edge-devices" can connect NOC equipment into= the ACP.
> - ACP only supports IPv6
> - The ACP address space is disjoint from the address space of the = data
> plane
> =20
> I could come up with a lot of ways how to build an ACP that matche= s these
> expectations. Heck: Most of the stable connectivity text would equ= ally be
> valid if you
> would use an IPv6 only DCN (external physcial manaement network). = Aka:
> this doc is about the value of an ACP for the use-case (inband, au= tonomic)
> and the problems of how to deal on NOC equipment with dual connect= ivity and
> IPv6 only for that managemeent plane.
> =20
> b) stable connectivity was specifically targeted in the WG charter= as a
> validation document for ACP. To me this means it is somewhat of a
> predecessor or
> use-case to ACP:
> =20
> "If the WG manages to define an ACP that is built autonomical= ly and that
> can be characterized by the simple behavior listed in a), then thi= s
> stable-connectivity document explains that/how it can be leveraged= wfor the
> stable-connectibity use-case".... and therefore justifies the= work on ACP
> for the WG.
> =20
> Let me know if these argument are appropriate to characterize the = ACP
> draft as an informative reference. Otherwise i will change it to n= ormative.
> =20
> Of course, i would be happy to improve the text to highlight this
> relationship
> better in the text because i also do not think that the intro trie= s to
> really explain this well (but i did not want to try write it up be= fore i am
> clear that it would resolve your discus).
> =20
> Thanks
> Toerless
> =20
> On Thu, Jan 04, 2018 at 09:28:10PM -0800, Alvaro Retana wrote:
> > Alvaro Retana has entered the following ballot position for
> > draft-ietf-anima-stable-connectivity-07: Discuss
> >
> > When responding, please keep the subject line intact and repl= y to all
> > email addresses included in the To and CC lines. (Feel free t= o cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criter= ia.html
> > for more information about IESG DISCUSS and COMMENT positions= .
> >
> >
> > The document, along with other ballot positions, can be found= here:
> > https://datatracker.ietf.org/doc/draft-ietf-anima-sta= ble-connectivity/
> >
> >
> >
> > -------------------------------------------------------------= ---------
> > DISCUSS:
> > -------------------------------------------------------------= ---------
> >
> > I like this document, and look forward to it being published.= However, it
> > caught my attention that there are no Normative References.
> >
> > It seems clear to me that (at least) an understanding of the = ACP is
> necessary
> > to properly achieve the objective of the document: "how = to integrate OAM
> > processes with the autonomic control plane (ACP) in Autonomic= Networks
> (AN) in
> > order to provide stable and secure connectivity for those OAM= processes."
> I
> > then think that the reference to I-D.ietf-anima-autonomic-con= trol-plane
> should
> > be Normative.
> >
> >
> >
> =20
> -- =20
> ---
> tte@cs.fau.de

-- =20
---
tte@cs.fau.de
--94eb2c04f8d60427ba05630f0094-- From nobody Thu Jan 18 09:35:12 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0286F128954 for ; Thu, 18 Jan 2018 09:35:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpiZn44zebYe for ; Thu, 18 Jan 2018 09:35:09 -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 7A6AB128D2E for ; Thu, 18 Jan 2018 09:35:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5FC0520094; Thu, 18 Jan 2018 12:40:18 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E99FA8065B; Thu, 18 Jan 2018 12:34:53 -0500 (EST) From: Michael Richardson To: anima@ietf.org cc: Alvaro Retana In-Reply-To: <20180117023241.GA26571@faui40p.informatik.uni-erlangen.de> References: <20180117023241.GA26571@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Alvaro Retana's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 17:35:11 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > I just posted -08: > https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt > I have modified the verbage in -08 according to your suggestions. > A) GACP > Section 1.3 now introduces the four core design constraints of a > generic ACP (GACP) (VRF isolation, IPv6 only, NOC connectivity and > Group Security) which are the basis for the (existing/unchanged) > discussion in the document. > The rest of the document has no semantic/content changes just textual > changes for ACP -> GACP. There are two places where the text still > refers to ACP specific examples and that is accordingly highlighted. Does that change ACP->GACP have to go across all documents? Could you: s/ 1.3. Leveraging a generalized autonomic control plane / 1.3. Leveraging a generalized autonomic control plane (GACP)/g ? I think not, as I understand Alvaro's comments: >> Hmmm???. I see your point, but that is not what the document says. >> Not only does it specifically point at the ACP anima draft ("ACP as >> defined in [I-D.ietf-anima-autonomic-control-plane]???), but it is >> hard to ignore the work done in the WG. >> >> I think that if you clearly explained the characterization of *an >> autonomic control plane* and mention *the ACP* >> [I-D.ietf-anima-autonomic-control-plane] as an example of that, then >> we would be ok. Please then also call it something else (GACP = >> Generic/Generalized, or anything else that clearly makes people think >> you???re not explicitly talking about *the ACP*). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpg2r0ACgkQgItw+93Q 3WXbiwgAwzW+FEG4t6HRtBai5Mno0WzncjNXpRN+Jw3EbDkSDB45MrpIHWFCeXWg yJJa4aNUU3X6Q6bG3dS2T7nqoLb8ytuOeTlxQyLc2WfLnePnJVhfMAaYjeibbRMj doMYTrcan3pBrXu69s+RLoABZchxOl2beS1Y3qtwyq8It7TGZkXl+s2ILrUC/rNX JiInMkwkVOe7JwhmMVTT8doNaNXMrkxvevh+ltandgEEHtqIl07mLifmoFRaHjWD OBZh4CKSvM5Z8kooqMgYRcpUowjsLii1Ubo8y+CamkueKFkGSuy6x60sm0KdKnop 7mFVVmGJj5f/jYkBantahda/o+UkNg== =DwOL -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 18 10:34:33 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C6412D7F0 for ; Thu, 18 Jan 2018 10:34:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boDjVZE3cYIv for ; Thu, 18 Jan 2018 10:34:30 -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 A867B12D0C3 for ; Thu, 18 Jan 2018 10:34:26 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B2C3B20094 for ; Thu, 18 Jan 2018 13:39:49 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2197380AB4 for ; Thu, 18 Jan 2018 13:34:25 -0500 (EST) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 18:34:32 -0000 --=-=-= Content-Type: text/plain Sheng Jiang wrote: > Hi, authors of anima-reference-model, {contributor speaking} > General issues: > 1. In section 3.1, it says "The Autonomic Control Plane (ACP) is the > summary of all interactions of the Autonomic Networking Infrastructure > with other nodes and services. > In my understanding, the ACP itself is mostly a "channel", although > some ANI functions (signaling, aggregated reporting etc.) are running > within the channel, they should be parallel with ACP function in the > architecture view. I concur with you, I'm also confused by the word "summary" While we think of the ACP as the channel on which control functions occur, I can also see that more generically (at the Dilbert's boss' level), the ACP is the channel + all the interactions. Perhaps we need a new term. > 1) Do you see ACP as an individual function as I understood (mostly a > channel), or a summary of a suite of functions running inside the ACP? I also think it's worth thinking of the ACP as being a very special ASA that creates the secure channel. Maybe that's too recursive for some people, but I think that doing so will encourage us to design the right management functions for the ACP itself. > 2) What functions are sub-functions of ACP, and what are in parallel > with ACP? That's a good question. (/me looks distantly and tries to change the subject :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpg6LAACgkQgItw+93Q 3WVEYggAr+efAPybEq14rdzQH/D0nNGA3K1kKsSfli1pFqT2mwd96xgnox/+gK/u 5NuS1VmXDUD+kiQfXrPWeV4PFp5UBZNF34MRhfolwH9PmKPYTiFljQxzNIcHYoDj ZxrEiCIUZgGhA14E54H8FThIide9QDwEVQ18ZZfWB3xSRRiCkwQdyqjtgknqXRzP uwlCc1Blc2V8RkSp/sQThlmokqkoXFkKJXuc7a7YVDm/YD06zQ1tbVzJnUpu0zRU sM7BBTjhzbOQpA5kUIphispbbPC+0ZWNB/1Onep6+9U3XvQ2kTVFxv3Kf7fETvA1 Noz1Te6uUfxkmBrhsAb0JCf3cn4tNw== =wyv+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 18 10:47:07 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34C112D7EB for ; Thu, 18 Jan 2018 10:47:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NCYuT52ehIJ for ; Thu, 18 Jan 2018 10:47:04 -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 6AC6B12895E for ; Thu, 18 Jan 2018 10:46:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C17C1200C5 for ; Thu, 18 Jan 2018 13:52:16 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2C77E80AB4 for ; Thu, 18 Jan 2018 13:46:52 -0500 (EST) To: anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> From: Michael Richardson Message-ID: <8b80a2b3-0ab3-659d-158a-1caeab879ab1@sandelman.ca> Date: Thu, 18 Jan 2018 13:46:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MDbvgEEKADoFlpRVgcDx5SDKVxRFx7oEA" Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 18:47:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MDbvgEEKADoFlpRVgcDx5SDKVxRFx7oEA Content-Type: multipart/mixed; boundary="UC8VLqqnroAqA571dgA9F2DvSTr1eGlM2"; protected-headers="v1" From: Michael Richardson To: anima@ietf.org Message-ID: <8b80a2b3-0ab3-659d-158a-1caeab879ab1@sandelman.ca> Subject: Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 References: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> --UC8VLqqnroAqA571dgA9F2DvSTr1eGlM2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/09/18 01:26, Sheng Jiang wrote: > Hi all, >=20 > =20 >=20 > This message starts the two-week ANIMA Working Group Last Call to > advance draft-ietf-anima-reference-model-05, A Reference Model for > Autonomic Networking. This document's intended status is Informational.= > At present, there is no IPR file against this document. >=20 > =20 >=20 > Please send your comments by January 22nd, 2018. If you do not feel > this document should advance, please state your reasons why. I have read the -05 document. An -06 is needed which just tightens the text up slightly. I know that Toerless has put a lot of editing cycles on this document, I think that it needs a pass from another of the authors to tweak some thin= gs. --UC8VLqqnroAqA571dgA9F2DvSTr1eGlM2-- --MDbvgEEKADoFlpRVgcDx5SDKVxRFx7oEA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpg65sACgkQgItw+93Q 3WVP7gf/ZfqsnGQ1HPN2g1q6bVtmThNARp38DCErBF60cGfeepa6oqvx7lG/G5re SRQvcRRsxNT1XfFEfBDkKtVDM89NChb8yEL1jrRM4DuwPOwpCdleDrO2u7w+8ioa QAeI+vbcf1oFc46+VXLo4iuPeYt8cpTILHJl1cYZTZzqf5opPSlVtLOeWyCplL1T dW+aAqqWlK4wI1KOmso8s5d0c9Z+16Jo0JG7UArFyIA/xnFg9TfMR+9tjqfqwsDH xPUlh0D//pseioFCfw0QAajTZ1fPrJ3AtdYE/Q6A2FpXVGPS2TCtLKRrgV1jwHcm JEb/kH0z5++8k25y7mSr+FAYvbUrOg== =zTW/ -----END PGP SIGNATURE----- --MDbvgEEKADoFlpRVgcDx5SDKVxRFx7oEA-- From nobody Thu Jan 18 11:06:22 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113BE12D7F0 for ; Thu, 18 Jan 2018 11:06:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTnkrCBYyWn4 for ; Thu, 18 Jan 2018 11:06:17 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E1C12D7E5 for ; Thu, 18 Jan 2018 11:06:14 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id t12so15381875pfg.2 for ; Thu, 18 Jan 2018 11:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8SuQmocJz59ehQWs8RJb5chL1KOuA7wCZIWUKMPAudE=; b=r2JNU/s3/2lCaPd8pB4NWCVzdjPi9CU1HLuS1TmKWft3EWFTnfIvz4KZgFqWh7Mlp0 QmoSPKViSomum8a4hTkCOqro0CeUQLhY57guXXxcupWBenTqZvYLS2a2w3oN4+HdEwBA +pPOMiwkt+lveUSXcHhE6qkzIP1RY3vyvLSJ1rW1j2E0UO2nJ9/pjhVS9D4vz8QI7qxd 4g+tUypFce6pvND60NidNDdZm/Y2xybknKAbZBIcJBDh7qY6DMeXEHUYIm82kFS84ORl Rd5IdZiPcOH0nbt7VukFejNRSEWJJr73an8I4EjQb1eoSuxoTFvRtuj7LyOCxthbXahe LU/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=8SuQmocJz59ehQWs8RJb5chL1KOuA7wCZIWUKMPAudE=; b=gwBg2hPL9CEAGM/QWcCtl2X3Y/v4kFMiHz6HdppgPlOdZKPsSBvoSGbvXs4fyOtnc2 7msNf/gCK+KT/tTZ1hG42homCZmqItlacrI5kN6ntU2DClQQjq0JTWDY6nZCo5Q033Um Qh/40SGL3Z4BpXr8wa+Vj7+d3ykb0LASTeEgcgklRtEU0LOel5Pm0oaa/sqLXdEUk5Xi /vAY2LTIFGQMWgn28zdWzeXWUTRh075RnIjSAiUmWISoRM+QIAFE9rtX6RzVbMHY7Kxi TDWF8ZP4OLBmIVfW9TJgJfMg+BiRdAHE6s5LYyY0+uCB48ltR2ObxYmOQKegiFgh/+DF UeZQ== X-Gm-Message-State: AKwxytfH/BKMpG4hjpjxk9hDDR+a3CRtnbzur6pEzLLS2toOoW2nlJAK khhqxxEYBSj37uGIKEHadU+KDw== X-Google-Smtp-Source: ACJfBotAiJSTYEDf6hMfXGFKn2vh8gYJVfdpdeXI8KzsR4TEeQoVH0HL2PNeqnUdDwiQsQzAo8gQ8Q== X-Received: by 10.99.182.6 with SMTP id j6mr20826104pgf.221.1516302373589; Thu, 18 Jan 2018 11:06:13 -0800 (PST) Received: from ?IPv6:2406:e007:6dac:1:28cc:dc4c:9703:6781? ([2406:e007:6dac:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q67sm15234679pfi.164.2018.01.18.11.06.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jan 2018 11:06:12 -0800 (PST) To: anima@ietf.org References: <20180117023241.GA26571@faui40p.informatik.uni-erlangen.de> <30918.1516296893@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 19 Jan 2018 08:06:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <30918.1516296893@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alvaro Retana's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 19:06:21 -0000 On 19/01/2018 06:34, Michael Richardson wrote: > > Toerless Eckert wrote: > > I just posted -08: > > https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt > > > I have modified the verbage in -08 according to your suggestions. > > > A) GACP > > > Section 1.3 now introduces the four core design constraints of a > > generic ACP (GACP) (VRF isolation, IPv6 only, NOC connectivity and > > Group Security) which are the basis for the (existing/unchanged) > > discussion in the document. > > > The rest of the document has no semantic/content changes just textual > > changes for ACP -> GACP. There are two places where the text still > > refers to ACP specific examples and that is accordingly highlighted. > > Does that change ACP->GACP have to go across all documents? I don't think so. This does relate to one of the changes made to the GRASP draft after IESG review, where we made it clear that *the* ACP was the preferred substrate, but not the only possible substrate: A GRASP implementation will be part of the Autonomic Networking Infrastructure (ANI) in an autonomic node, which must also provide an appropriate security environment. In accordance with [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. ... GRASP does not specify transport security because it is meant to be adapted to different environments. Every solution adopting GRASP MUST specify a security and transport substrate used by GRASP in that solution. I don't think the "GACP" is any different, it's just a shorthand for the same point. (Probably we should also mention "GACP" in the reference model for consistency.) Brian > > Could you: > s/ 1.3. Leveraging a generalized autonomic control plane > / 1.3. Leveraging a generalized autonomic control plane (GACP)/g > ? > > I think not, as I understand Alvaro's comments: > > >> Hmmm???. I see your point, but that is not what the document says. > >> Not only does it specifically point at the ACP anima draft ("ACP as > >> defined in [I-D.ietf-anima-autonomic-control-plane]???), but it is > >> hard to ignore the work done in the WG. > >> > >> I think that if you clearly explained the characterization of *an > >> autonomic control plane* and mention *the ACP* > >> [I-D.ietf-anima-autonomic-control-plane] as an example of that, then > >> we would be ok. Please then also call it something else (GACP = > >> Generic/Generalized, or anything else that clearly makes people think > >> you???re not explicitly talking about *the ACP*). > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Jan 18 13:10:38 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E64512D867 for ; Thu, 18 Jan 2018 13:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7Z8okuw-Ona for ; Thu, 18 Jan 2018 13:10:34 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C8F12D7E6 for ; Thu, 18 Jan 2018 13:10:34 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7285058C4DB; Thu, 18 Jan 2018 22:10:28 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5400DB0D7B8; Thu, 18 Jan 2018 22:10:28 +0100 (CET) Date: Thu, 18 Jan 2018 22:10:28 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: anima@ietf.org Message-ID: <20180118211028.GA4763@faui40p.informatik.uni-erlangen.de> References: <20180117023241.GA26571@faui40p.informatik.uni-erlangen.de> <30918.1516296893@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Alvaro Retana's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 21:10:37 -0000 So... Welcome to the wonderful world of structuring our documents to meet the intent of our charter ;-)) IMHO, we should mention GACP in one sentence of the ACP spec where stable-connectivity is mentioned: "The ACP was designed to meets the constraints/functionality specified in [stable-connectivity] section 1.3, so it is a GACP in that documents terminology and can therefore support the stable-connectivity use case with all the considerations discussed in that document." I'd prefer to fix that sentence during IESG review, not wanting to shoot of another rev, but i'll let the the independent co-chair decide. The same type of language would IMHO be true for future docs defining variations of an ACP. Such variations would have to explain deltas if/where they exist. [ And redefine how they provide transport/security for GRASP as Brian mentioned. ] I see no other place in current documents where we would want to use the term GACP. The reference model specifically does not even refer to stable-connectivity because at it's core it is a non-AN use case, and the reference model is ONLY about AN. Just reviewing BRSKI, but don't think GACP should be mentioned there. IMHO we want to need to have a sentence there with a simple, broader statement about applicability of BRSKI beyond ACP to any type of network infra, as long as you figure out how start proxies and have then know about registrar(s). That expectations not defined in stable-connectivity at all. Cheers toerless On Fri, Jan 19, 2018 at 08:06:16AM +1300, Brian E Carpenter wrote: > On 19/01/2018 06:34, Michael Richardson wrote: > > > > Toerless Eckert wrote: > > > I just posted -08: > > > https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt > > > > > I have modified the verbage in -08 according to your suggestions. > > > > > A) GACP > > > > > Section 1.3 now introduces the four core design constraints of a > > > generic ACP (GACP) (VRF isolation, IPv6 only, NOC connectivity and > > > Group Security) which are the basis for the (existing/unchanged) > > > discussion in the document. > > > > > The rest of the document has no semantic/content changes just textual > > > changes for ACP -> GACP. There are two places where the text still > > > refers to ACP specific examples and that is accordingly highlighted. > > > > Does that change ACP->GACP have to go across all documents? > > I don't think so. This does relate to one of the changes made to the GRASP > draft after IESG review, where we made it clear that *the* ACP was the > preferred substrate, but not the only possible substrate: > > A GRASP implementation will be part of the Autonomic Networking > Infrastructure (ANI) in an autonomic node, which must also provide an > appropriate security environment. In accordance with > [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic > Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. > ... > GRASP does not specify transport security because it is meant to be > adapted to different environments. Every solution adopting GRASP > MUST specify a security and transport substrate used by GRASP in that > solution. > > I don't think the "GACP" is any different, it's just a shorthand for the > same point. (Probably we should also mention "GACP" in the reference model > for consistency.) > > Brian > > > > > Could you: > > s/ 1.3. Leveraging a generalized autonomic control plane > > / 1.3. Leveraging a generalized autonomic control plane (GACP)/g > > ? > > > > I think not, as I understand Alvaro's comments: > > > > >> Hmmm???. I see your point, but that is not what the document says. > > >> Not only does it specifically point at the ACP anima draft ("ACP as > > >> defined in [I-D.ietf-anima-autonomic-control-plane]???), but it is > > >> hard to ignore the work done in the WG. > > >> > > >> I think that if you clearly explained the characterization of *an > > >> autonomic control plane* and mention *the ACP* > > >> [I-D.ietf-anima-autonomic-control-plane] as an example of that, then > > >> we would be ok. Please then also call it something else (GACP = > > >> Generic/Generalized, or anything else that clearly makes people think > > >> you???re not explicitly talking about *the ACP*). > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Jan 19 00:24:37 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08756126B6E for ; Fri, 19 Jan 2018 00:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1riFLA_mrOr for ; Fri, 19 Jan 2018 00:24:31 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0090.outbound.protection.outlook.com [104.47.0.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A00120454 for ; Fri, 19 Jan 2018 00:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=45TTJ7HjrN54ciRex47pRzQ6MyjyK3seXVOOANL43aQ=; b=XibVtjL5nD2CDHIGs7eVsUK0kD0YeufaiXfAevmLNEFd54r9auXKC+0gmRc2MnEUjlBKd2CCBSx2bCy1shkH9N9aMEeIsFTLG9wo4EjGbfS1JgmSEXZH+bTCT3BTlW7ZvxAwUSyVrg0gEmMtvW1P1SEY7ZrJyuDZ8X2iA/VWYfE= Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com (10.168.36.134) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Fri, 19 Jan 2018 08:24:28 +0000 Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com ([fe80::9b8:9374:fee3:870c]) by HE1PR0701MB2203.eurprd07.prod.outlook.com ([fe80::9b8:9374:fee3:870c%15]) with mapi id 15.20.0428.014; Fri, 19 Jan 2018 08:24:28 +0000 From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" To: Toerless Eckert , "Michael H. Behringer" CC: "anima@ietf.org" Thread-Topic: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 Thread-Index: AdOJEiPxBjmGgiajRyCx9CbcS+aTGwAf0SIAADFbSgAAAA2QgAAEOkUAAaWZA6A= Date: Fri, 19 Jan 2018 08:24:27 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> <453adcde-4f26-2fa8-62cc-bcd66e3df1a5@gmail.com> <20180110230842.GA5290@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180110230842.GA5290@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.228.2.16] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB3002; 7:nAho7TfGon3Fe2bDqpZ1cHNPZRlw0zljwmWbXTUZboqWL7VvQDGhKwPgyylQmOf7KS+k7voruf68EoHyCyMuvnT2+7MbYngqyQP1Q+GiIKimSEXMM/NRxyDV0c6qHGgolv0vRfNfpkf15zIQ21MalpJB8BayShpQ3OznUh/QT44XXczq6rmlY4H1hz9V9rC2GgvCft2z4J4ivJ6WJe+r4viLNGFIFja/Z9UzushdEJyxUwF25JBQX4AT+gciUSTF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a9635734-8b44-4df8-5054-08d55f160e8c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:HE1PR0701MB3002; x-ms-traffictypediagnostic: HE1PR0701MB3002: authentication-results: spf=none (sender IP is ) smtp.mailfrom=laurent.ciavaglia@nokia-bell-labs.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040495)(2401047)(5005006)(8121501046)(3231046)(11241501184)(2400074)(944501161)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041282)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:HE1PR0701MB3002; x-forefront-prvs: 0557CBAD84 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(346002)(396003)(376002)(39860400002)(189003)(199004)(288314003)(53754006)(13464003)(606006)(2906002)(53936002)(3280700002)(26005)(2900100001)(3660700001)(68736007)(6116002)(3846002)(6306002)(6246003)(93886005)(9686003)(33656002)(97736004)(39060400002)(106356001)(55016002)(54896002)(4326008)(236005)(105586002)(66066001)(8676002)(25786009)(6436002)(5250100002)(478600001)(86362001)(102836004)(5660300001)(59450400001)(14454004)(53546011)(6506007)(7736002)(76176011)(81156014)(230783001)(7696005)(2950100002)(229853002)(966005)(74316002)(99286004)(8936002)(81166006)(316002)(110136005)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:HE1PR0701MB2203.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: uZNnhIw69iREVMY6DoDjRlNuPHKc3oFpJZdtxMx9yLWnjFheN9uhpQaV8dGBQXhb5ZBbsCwVHxB9KHk7TEjVYg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: a9635734-8b44-4df8-5054-08d55f160e8c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2018 08:24:27.9539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jan 2018 08:24:35 -0000 SGVsbG8sDQoNCkknbSBhIGNvLWF1dGhvciBvZiB0aGUgZHJhZnQuDQpJIGJlbGlldmUgdGhlIGRv Y3VtZW50IGlzIHJlYWR5IHRvIHByb2dyZXNzIGFuZCBzZXZlcmFsIGl0ZXJhdGlvbnMgb2YgdGhl IGRvY3VtZW50IGhhdmUgdHJpZWQgdG8gY2FwdHVyZSB0aGUgZXZvbHV0aW9uIG9mIHRoZSBvdGhl ciB0ZWNobmljYWwgd29yayBkb25lIGluIEFOSU1BLiANClRoZSBkb2N1bWVudCBmdWxmaWxscyBp dHMgaW50ZW50IPCfmIkgdG8gZXhwbGFpbiBob3cgdGhlIGRpZmZlcmVudCBjb21wb25lbnRzIG9m IEFOSU1BIGZpdHMgdG9nZXRoZXIsIGFuZCBpcyB0aHVzIHZlcnkgdXNlZnVsIGZvciB0aGUgZ2Vu ZXJhbCB1bmRlcnN0YW5kaW5nIGFyb3VuZCBhdXRvbm9taWMgbmV0d29ya2luZy4NCg0KQXMgbWVu dGlvbmVkIGJ5IEJyaWFuLCBmdXR1cmUgd29yayBpbiBBTklNQSBzaG91bGQgcHJvYmFibHkgYmUg cmVmbGVjdGVkIGluIGEgc2Vjb25kIGVkaXRpb24uDQoNCkJlc3QgcmVnYXJkcywgTGF1cmVudC4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFuaW1hIFttYWlsdG86YW5pbWEt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvZXJsZXNzIEVja2VydA0KU2VudDogVGh1 cnNkYXksIEphbnVhcnkgMTEsIDIwMTggMTI6MDkgQU0NClRvOiBNaWNoYWVsIEguIEJlaHJpbmdl ciA8bWljaGFlbC5oLmJlaHJpbmdlckBnbWFpbC5jb20+DQpDYzogYW5pbWFAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbQW5pbWFdIFdHTEMgb24gZHJhZnQtaWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9k ZWwtMDUgLSBSZXNwb25kIGJ5IEphbnVhcnkgMjJuZCwgMjAxOA0KDQpBcyBhbm90aGVyIGNvLWF1 dGhvciBpIGFncmVlIHRvIGV2ZXJ5dGhpbmcgTWljaGFlbCBzYWlkIGV4Y2VwdCB0aGF0IGl0IHNo b3VsZCBiZSBzYWlkIHdpdGhvdXQgSFRNTCBvYmZ1c2NhdGluZyBpdCA7LSkNCg0KQ2hlZXJzDQog ICAgVG9lcmxlc3MNCg0KT24gV2VkLCBKYW4gMTAsIDIwMTggYXQgMTA6MDc6MzlQTSArMDEwMCwg TWljaGFlbCBILiBCZWhyaW5nZXIgd3JvdGU6DQo+IDxodG1sPg0KPiAgIDxoZWFkPg0KPiAgICAg PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPiAgIDwvaGVhZD4NCj4gICA8Ym9keSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9y PSIjRkZGRkZGIj4NCj4gICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+SSBndWVzcyBJ J3ZlIG1hZGUgbXkgcG9pbnQgYmVmb3JlLCBidXQNCj4gICAgICAganVzdCBpbiBjYXNlOiBJJ20g YWxzbyBjby1hdXRob3IsIGFuZCBhbHNvIHRoaW5rIHRoaXMgZG9jIGlzIHJlYWR5DQo+ICAgICAg IHRvIG1vdmUgZm9yd2FyZC4gPGJyPg0KPiAgICAgICA8YnI+DQo+ICAgICAgIE1pY2hhZWw8YnI+ DQo+ICAgICAgIDxicj4NCj4gICAgICAgT24gMTAvMDEvMTggMjI6MDYsIErDqWZlcnNvbiBDYW1w b3MgTm9icmUgd3JvdGU6PGJyPg0KPiAgICAgPC9kaXY+DQo+ICAgICA8YmxvY2txdW90ZSB0eXBl PSJjaXRlIg0KPiBjaXRlPSJtaWQ6Q0FCdjZ4THZneExoMWl6czJaQVZDVFktaDEzb3FhWURvRlEz YlJQcktmUk11R3Y2K2p3QG1haWwuZ21haWwuY29tIj4NCj4gICAgICAgPGRpdiBkaXI9Imx0ciI+ RGVhciBBbmltYS4NCj4gICAgICAgICA8ZGl2PkkgYW0gYWxzbyBhIGNvLWF1dGhvciBvZiB0aGlz IGRyYWZ0IGFuZCBJIHRoaW5rIGl0IGlzIGluIGENCj4gICAgICAgICAgIGdvb2Qgc2hhcGUgdG8g YWR2YW5jZS4gQmVzaWRlcyB0aGF0LCBJIGJlbGlldmUgdGhlIHB1YmxpY2F0aW9uDQo+ICAgICAg ICAgICBvZiB0aGUgcmVmZXJlbmNlIG1vZGVsIGlzIGFuIGltcG9ydGFudCBzdGVwIGZvciB0aGUg V0cuPC9kaXY+DQo+ICAgICAgICAgPGRpdj5CZXN0LjwvZGl2Pg0KPiAgICAgICAgIDxkaXY+SsOp ZmVyc29uPGJyPg0KPiAgICAgICAgICAgPGJyPg0KPiAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPg0KPiAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj5FbSB0ZXIsIDkgZGUgamFu IGRlIDIwMTggw6BzIDE5OjMyLCBCcmlhbiBFDQo+ICAgICAgICAgICAgICAgQ2FycGVudGVyICZs dDs8YSBocmVmPSJtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tIg0KPiAgICAgICAg ICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5icmlhbi5lLmNhcnBlbnRlckBnbWFpbC5j b208L2E+Jmd0Ow0KPiAgICAgICAgICAgICAgIGVzY3JldmV1Ojxicj4NCj4gICAgICAgICAgICAg PC9kaXY+DQo+ICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMA0KPiAgICAgICAgICAgICAgIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+SGksPGJyPg0KPiAgICAgICAgICAgICAgIDxicj4N Cj4gICAgICAgICAgICAgICBJIGFtIGEgY28tYXV0aG9yIG9mIHRoaXMgZHJhZnQuIEkgZG8gYmVs aWV2ZSB0aGF0IGl0IGlzDQo+ICAgICAgICAgICAgICAgcmVhZHkgdG8gYWR2YW5jZSwgYW5kIHRo YXQgaXQncyB1c2VmdWwgdG8gZ2V0IGl0IHB1Ymxpc2hlZA0KPiAgICAgICAgICAgICAgIHNvb24g c28gdGhhdCBpdCBjYW4gaW5kZWVkIGFjdCBhcyBhIHJlZmVyZW5jZSBtb2RlbC4gV2UNCj4gICAg ICAgICAgICAgICBrbm93IHRoYXQgYSBzZWNvbmQgZWRpdGlvbiB3aWxsIHByb2JhYmx5IGJlIG5l ZWRlZCB0bw0KPiAgICAgICAgICAgICAgIGluY2x1ZGUgZnV0dXJlIHdvcmsuPGJyPg0KPiAgICAg ICAgICAgICAgIDxicj4NCj4gICAgICAgICAgICAgICAoQXQgbGVhc3Qgb25lIG1pbm9yIGNvcnJl Y3Rpb24gaXMgcGVuZGluZyBpbiB0aGUgWE1MDQo+ICAgICAgICAgICAgICAgc291cmNlOjxicj4N Cj4gICAgICAgICAgICAgICA8YQ0KPiBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbWJlaHJpbmcv QU5JTUEtUmVmZXJlbmNlLU1vZGVsL2NvbW1pdC8xNjM5OTljMWQwMzU5OSINCj4gICAgICAgICAg ICAgICAgIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSI+aHR0cHM6Ly9naXRodWIuY29tL21iZWhyaW5nL0FOSU1BLVJlZmVyZW5jZS1Nb2RlbC9j b21taXQvMTYzOTk5YzFkMDM1OTk8L2E+DQo+ICAgICAgICAgICAgICAgKTxicj4NCj4gICAgICAg ICAgICAgICA8YnI+DQo+ICAgICAgICAgICAgICAgUmVnYXJkczxicj4NCj4gICAgICAgICAgICAg ICDCoCDCoEJyaWFuIENhcnBlbnRlcjxicj4NCj4gICAgICAgICAgICAgICA8YnI+DQo+ICAgICAg ICAgICAgICAgT24gMDkvMDEvMjAxOCAxOToyNiwgU2hlbmcgSmlhbmcgd3JvdGU6PGJyPg0KPiAg ICAgICAgICAgICAgICZndDsgSGkgYWxsLDxicj4NCj4gICAgICAgICAgICAgICAmZ3Q7PGJyPg0K PiAgICAgICAgICAgICAgICZndDsgVGhpcyBtZXNzYWdlIHN0YXJ0cyB0aGUgdHdvLXdlZWsgQU5J TUEgV29ya2luZyBHcm91cA0KPiAgICAgICAgICAgICAgIExhc3QgQ2FsbCB0byBhZHZhbmNlIGRy YWZ0LWlldGYtYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA1LA0KPiAgICAgICAgICAgICAgIEEgUmVm ZXJlbmNlIE1vZGVsIGZvciBBdXRvbm9taWMgTmV0d29ya2luZy4gVGhpcw0KPiAgICAgICAgICAg ICAgIGRvY3VtZW50J3MgaW50ZW5kZWQgc3RhdHVzIGlzIEluZm9ybWF0aW9uYWwuIEF0IHByZXNl bnQsDQo+ICAgICAgICAgICAgICAgdGhlcmUgaXMgbm8gSVBSIGZpbGUgYWdhaW5zdCB0aGlzIGRv Y3VtZW50Ljxicj4NCj4gICAgICAgICAgICAgICAmZ3Q7PGJyPg0KPiAgICAgICAgICAgICAgICZn dDsgUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyBieSBKYW51YXJ5IDIybmQsIDIwMTguIElmDQo+ ICAgICAgICAgICAgICAgeW91IGRvIG5vdCBmZWVsIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGFkdmFu Y2UsIHBsZWFzZSBzdGF0ZQ0KPiAgICAgICAgICAgICAgIHlvdXIgcmVhc29ucyB3aHkuPGJyPg0K PiAgICAgICAgICAgICAgICZndDs8YnI+DQo+ICAgICAgICAgICAgICAgJmd0OyBTaGVuZyBKSUFO RyBpcyB0aGUgYXNzaWduZWQgZG9jdW1lbnQgc2hlcGhlcmQuPGJyPg0KPiAgICAgICAgICAgICAg ICZndDs8YnI+DQo+ICAgICAgICAgICAgICAgJmd0OyBSZWdhcmRzLDxicj4NCj4gICAgICAgICAg ICAgICAmZ3Q7PGJyPg0KPiAgICAgICAgICAgICAgICZndDsgU2hlbmcgKGNvLWNoYWlyLCBUb2Vy bGVzcyB3aG8gYXMgYSBjby1hdXRob3Igc3RheWVkDQo+ICAgICAgICAgICAgICAgbmV1dHJhbCBv biB0aGUgY29udGVudCBzaWRlKTxicj4NCj4gICAgICAgICAgICAgICAmZ3Q7PGJyPg0KPiAgICAg ICAgICAgICAgICZndDs8YnI+DQo+ICAgICAgICAgICAgICAgJmd0Ozxicj4NCj4gICAgICAgICAg ICAgICAmZ3Q7PGJyPg0KPiAgICAgICAgICAgICAgICZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo+ICAgICAgICAgICAgICAgJmd0OyBBbmlt YSBtYWlsaW5nIGxpc3Q8YnI+DQo+ICAgICAgICAgICAgICAgJmd0OyA8YSBocmVmPSJtYWlsdG86 QW5pbWFAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIg0KPiAgICAgICAgICAgICAgICAgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIj5BbmltYUBpZXRmLm9yZzwvYT48YnI+DQo+ICAgICAgICAgICAgICAg Jmd0OyA8YQ0KPiAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hbmltYSINCj4gICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hbmltYTwvYT48YnI+DQo+ICAgICAgICAgICAgICAgJmd0Ozxi cj4NCj4gICAgICAgICAgICAgICA8YnI+DQo+ICAgICAgICAgICAgICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo+ICAgICAgICAgICAgICAgQW5p bWEgbWFpbGluZyBsaXN0PGJyPg0KPiAgICAgICAgICAgICAgIDxhIGhyZWY9Im1haWx0bzpBbmlt YUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiDQo+ICAgICAgICAgICAgICAgICBtb3otZG8tbm90 LXNlbmQ9InRydWUiPkFuaW1hQGlldGYub3JnPC9hPjxicj4NCj4gICAgICAgICAgICAgICA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hIg0KPiAgICAg ICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hPC9h Pjxicj4NCj4gICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KPiAgICAgICAgICAgPC9kaXY+DQo+ ICAgICAgICAgPC9kaXY+DQo+ICAgICAgIDwvZGl2Pg0KPiAgICAgICA8YnI+DQo+ICAgICAgIDxm aWVsZHNldCBjbGFzcz0ibWltZUF0dGFjaG1lbnRIZWFkZXIiPjwvZmllbGRzZXQ+DQo+ICAgICAg IDxicj4NCj4gICAgICAgPHByZSB3cmFwPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiA8YSBjbGFzcz0ibW96 LXR4dC1saW5rLWFiYnJldmlhdGVkIiANCj4gaHJlZj0ibWFpbHRvOkFuaW1hQGlldGYub3JnIj5B bmltYUBpZXRmLm9yZzwvYT4NCj4gPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgDQo+ IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEiPmh0dHBz Oi8vd3d3LmlldGYub3INCj4gZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hPC9hPg0KPiA8L3ByZT4N Cj4gICAgIDwvYmxvY2txdW90ZT4NCj4gICAgIDxicj4NCj4gICA8L2JvZHk+DQo+IDwvaHRtbD4N Cj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpB bmltYSBtYWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Mon Jan 22 00:35:10 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50EC126BFD; Mon, 22 Jan 2018 00:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wktYWKrN08d; Mon, 22 Jan 2018 00:35:05 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DE4124BAC; Mon, 22 Jan 2018 00:35:04 -0800 (PST) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0C03A27831A; Mon, 22 Jan 2018 17:35:02 +0900 (JST) Received: by mail-wm0-f53.google.com with SMTP id r78so15093270wme.0; Mon, 22 Jan 2018 00:35:01 -0800 (PST) X-Gm-Message-State: AKwxytcN9MyHwg8Dn2QQH51W3sBNMO4+DaDWF/76YRJCGISlNqE/pYSH nvL4F/74yVCjvadVKwzgZkU4uxCVrBB0PZ/M4qU= X-Google-Smtp-Source: AH8x226DvOQJHoLgc7AMh9G4w7wA0WeB7g4Y1YiGeg/7XenZtivViFbpZVzkX+OkgndjfJUqcY0dr+BHKXCNATHBAA0= X-Received: by 10.28.150.209 with SMTP id y200mr4119992wmd.100.1516610100147; Mon, 22 Jan 2018 00:35:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.183.137 with HTTP; Mon, 22 Jan 2018 00:34:59 -0800 (PST) In-Reply-To: <20180117023729.GA26735@faui40p.informatik.uni-erlangen.de> References: <20180117023729.GA26735@faui40p.informatik.uni-erlangen.de> From: Yoshifumi Nishida Date: Mon, 22 Jan 2018 00:34:59 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Toerless Eckert Cc: Yoshifumi Nishida , tsv-art@ietf.org, dreft-ietf-anima-stable-connectivity@ietf.org, anima@ietf.org Content-Type: multipart/alternative; boundary="001a114b35dc483dc10563594e9a" Archived-At: Subject: Re: [Anima] [Tsv-art] TSV-ART telechat review of draft-ietf-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jan 2018 08:35:10 -0000 --001a114b35dc483dc10563594e9a Content-Type: text/plain; charset="UTF-8" Hi Toerless, Thanks for the updates. It looks better to me. Just one very minor comment.. "GACP and data-plane addresses exist in different VRFs. The MPTCP stack needs to be able to access multiple VRFs and know which local address is existing in which VRF. There also needs to be a logic to determine which peer address is expected to be reachable via which local VRF/address. Because the GACP is an isolated network, data- plane addresses are not reachable via the GACP therefore devices can determine if a peer address is a data-plane address." I personally think the logic to determine which peer is expected to be reachable doesn't need to be in MPTCP stack. Or, if a MPTCP stack tries all possible combinations of address pairs to establish subflows, we might not need to have such a logic. It may be redundant, though. Thanks, -- Yoshi On Tue, Jan 16, 2018 at 6:37 PM, Toerless Eckert wrote: > Mirja, Yoshifumi > > I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable- > connectivity-08.txt > > I have reworked the MPTCP text based on your threads feedback with > the intention to fix errors and have it answer the questions/concerns > raised, > but without otherwise changing the scope of it: > > - What are they key features making MPTCP interesting > - How could it be used to solve the stable-connectivity issue > - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK > beyond the scope of this document > - Describe the areas of specification work required > - API/policy, control by apps > - dealing with dual VRF addresses > > Please check diff in this URL (not complete diff of -08, just fix for your > discuss/comment): > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1= > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/ > 14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima- > stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2= > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/ > c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-anima- > stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt > > I hope this resolves your DISCUSS/comments. > > Note that the term ACP was changed in the doc to GACP based on resolving > Alvaros discus. See: > > https://raw.githubusercontent.com/anima-wg/autonomic- > control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro- > retana.txt > > Thank you > Toerless > > On Tue, Jan 09, 2018 at 05:37:16PM -0800, Yoshifumi Nishida wrote: > > I've reviewed this document as part of TSV-ART's ongoing effort to review > > key IETF documents. These comments were written primarily for the > transport > > area directors, but are copied to the document's authors for their > > information and to allow them to address any issues raised.When done at > the > > time of IETF Last Call, the authors should consider this review together > > with any other last-call comments they receive. Please always CC tsv-art > > @ietf.org if you reply to or forward this review. > > > > Summary: This document is almost ready for publication, but several > points > > need to be clarified or updated. > > > > 1: In Section 2.1.5 > > " > > MPTCP (Multipath TCP -see [RFC6824]) is a very attractive candidate > > to automate the use of both data-plane and ACP and minimize or fully > > avoid the need for the above mentioned logical names to pre-set the > > desired connectivity (data-plane-only, ACP only, both). For example, > > a set-up for non MPTCP aware applications would be as follows: > > > > DNS naming is set up to provide the ACP IPv6 address of network > > devices. Unbeknownst to the application, MPTCP is used. MPTCP > > mutually discovers between the NOC and network device the data-plane > > address and caries all traffic across it when that MPTCP subflow > > across the data-plane can be built. > > " > > > > It's not very clear to me how to archive this feature. > > I think more explanation will be required. > > As MPTCP resides in transport layer, I think it will be very tricky to > know > > which endpoint is used for ACP or for data-plane. Also, although MPTCP > > can transmit application data to multiple destinations, it cannot > > identify which part of data is for ACP or for data-plane as it doesn't > > parse app data. > > > > 2: in Section 2.1.8 > > > > " > > Leverage and as necessary enhance MPTCP with automatic dual- > > connectivity: If an MPTCP unaware application is using ACP > > connectivity, the policies used should add subflow(s) via the > > data-plane and prefer them. > > " > > > > I think functions like controlling policies should be designed outside of > > MPTCP such as middleware > > between applications and transport layer, but the text is unclear about > how > > to enhance MPTCP. > > > > Thanks, > > -- > > Yoshi > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > --001a114b35dc483dc10563594e9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Toerless,

Thanks for the updates. It= looks better to me.
Just one very minor comment..
&q= uot;GACP and data-plane addresses exist in different VRFs. The MPTCP stack needs to be able to access multiple VRFs and know which local address is existing in which VRF. There also needs to be a logic to determine which peer address is expected to be reachable via which local VRF/address. Because the GACP is an isolated network, data- plane addresses are not reachable via the GACP therefore devices can determine if a peer address is a data-plane address."

I personally think the logic to determ= ine which peer is expected to be reachable
doesn't need to be= in MPTCP stack. Or, if a MPTCP stack tries all possible combinations=C2=A0=
of address pairs to establish subflows, we might not need to hav= e such a logic. It may be=C2=A0
redundant, though.

=
Thanks,
--
Yoshi


On Tue, Jan 16, 2018 at 6:37 P= M, Toerless Eckert <tte@cs.fau.de> wrote:
Mirja, Yoshifumi

I just posted -08: https://tool= s.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt

I have reworked the MPTCP text based on your threads feedback with
the intention to fix errors and have it answer the questions/concerns raise= d,
but without otherwise changing the scope of it:

- What are they key features making MPTCP interesting
- How could it be used to solve the stable-connectivity issue
- Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK
=C2=A0 beyond the scope of this document
- Describe the areas of specification work required
=C2=A0 - API/policy, control by apps
=C2=A0 - dealing with dual VRF addresses

Please check diff in this URL (not complete diff of -08, just fix for your = discuss/comment):

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.githubusercontent.com/a= nima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anim= a-stable-connectivity-08.txt&url2=3Dhttps://raw.githubusercon= tent.com/anima-wg/autonomic-control-plane/c02252710fbd7aea15= aff550fb393eb36584658b/draft-ietf-anima-stable-connectivity/draft= -ietf-anima-stable-connectivity-08.txt

I hope this resolves your DISCUSS/comments.

Note that the term ACP was changed in the doc to GACP based on resolving Al= varos discus. See:

https://raw.githubusercontent.com/an= ima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt

Thank you
=C2=A0 =C2=A0 Toerless

On Tue, Jan 09, 2018 at 05:37:16PM -0800, Yoshifumi Nishida wrote:
> I've reviewed this document as part of TSV-ART's ongoing effor= t to review
> key IETF documents. These comments were written primarily for the tran= sport
> area directors, but are copied to the document's authors for their=
> information and to allow them to address any issues raised.When done a= t the
> time of IETF Last Call, the authors should consider this review togeth= er
> with any other last-call comments they receive. Please always CC tsv-a= rt
> @ietf.org if you reply to or forward this review.
>
> Summary: This document is almost ready for publication, but several po= ints
> need to be clarified or updated.
>
> 1: In Section 2.1.5
> "
>=C2=A0 =C2=A0MPTCP (Multipath TCP -see [RFC6824]) is a very attractive = candidate
>=C2=A0 =C2=A0to automate the use of both data-plane and ACP and minimiz= e or fully
>=C2=A0 =C2=A0avoid the need for the above mentioned logical names to pr= e-set the
>=C2=A0 =C2=A0desired connectivity (data-plane-only, ACP only, both).=C2= =A0 For example,
>=C2=A0 =C2=A0a set-up for non MPTCP aware applications would be as foll= ows:
>
>=C2=A0 =C2=A0DNS naming is set up to provide the ACP IPv6 address of ne= twork
>=C2=A0 =C2=A0devices.=C2=A0 Unbeknownst to the application, MPTCP is us= ed.=C2=A0 MPTCP
>=C2=A0 =C2=A0mutually discovers between the NOC and network device the = data-plane
>=C2=A0 =C2=A0address and caries all traffic across it when that MPTCP s= ubflow
>=C2=A0 =C2=A0across the data-plane can be built.
> "
>
> It's not very clear to me how to archive this feature.
> I think more explanation will be required.
> As MPTCP resides in transport layer, I think it will be very tricky to= know
> which endpoint is used for ACP or for data-plane. Also, although MPTCP=
> can transmit application data to multiple destinations, it cannot
> identify which part of data is for ACP or for data-plane as it doesn&#= 39;t
> parse app data.
>
> 2: in Section 2.1.8
>
> "
>=C2=A0 =C2=A0Leverage and as necessary enhance MPTCP with automatic dua= l-
>=C2=A0 =C2=A0connectivity: If an MPTCP unaware application is using ACP=
>=C2=A0 =C2=A0connectivity, the policies used should add subflow(s) via = the
>=C2=A0 =C2=A0data-plane and prefer them.
> "
>
> I think functions like controlling policies should be designed outside= of
> MPTCP such as middleware
> between applications and transport layer, but the text is unclear abou= t how
> to enhance MPTCP.
>
> Thanks,
> --
> Yoshi

> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima=

_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art<= br>

--001a114b35dc483dc10563594e9a-- From nobody Mon Jan 22 04:32:46 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB44124C27 for ; Mon, 22 Jan 2018 04:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 81qj4MRoMCSr for ; Mon, 22 Jan 2018 04:32:42 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0CC120454 for ; Mon, 22 Jan 2018 04:32:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=Ph+4hadxhdh2zUMwSu25XYC18XyX3r9+XldC77BDM+WCA+ekgu96Zl9iXRUe/ja9HkCga0bCj0v1rAdrfR3Ar7ZenqqPvj6ko3Hb6Qt9wuO+R6OFFY9vUf/gCMTH8fOl8g7AUzDeWlz3XTAhSYI+J7kaAWLKsMQ4skp4cCULcig=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 32476 invoked from network); 22 Jan 2018 13:25:58 +0100 Received: from mue-88-130-61-036.dsl.tropolys.de (HELO ?192.168.178.33?) (88.130.61.36) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 Jan 2018 13:25:58 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Mon, 22 Jan 2018 13:25:57 +0100 Cc: Toerless Eckert , tsv-art@ietf.org, dreft-ietf-anima-stable-connectivity@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6EEEE1A4-D653-4567-AC35-706EAA445BB6@kuehlewind.net> References: <20180117023729.GA26735@faui40p.informatik.uni-erlangen.de> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180122122558.32468.77463@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] [Tsv-art] TSV-ART telechat review of draft-ietf-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jan 2018 12:32:44 -0000 Hi Toerless, I agree with Yoshi here. I guess a quick fix is the following: s/The MPTCP stack/The endpoint/=20 I have one more comment that I will send in reply to your other mail. Mirja > Am 22.01.2018 um 09:34 schrieb Yoshifumi Nishida = : >=20 > Hi Toerless, >=20 > Thanks for the updates. It looks better to me. > Just one very minor comment.. > "GACP and data-plane addresses exist in different VRFs. The MPTCP > stack needs to be able to access multiple VRFs and know which local > address is existing in which VRF. There also needs to be a logic = to > determine which peer address is expected to be reachable via which > local VRF/address. Because the GACP is an isolated network, data- > plane addresses are not reachable via the GACP therefore devices = can > determine if a peer address is a data-plane address." >=20 >=20 > I personally think the logic to determine which peer is expected to be = reachable > doesn't need to be in MPTCP stack. Or, if a MPTCP stack tries all = possible combinations=20 > of address pairs to establish subflows, we might not need to have such = a logic. It may be=20 > redundant, though. >=20 > Thanks, > -- > Yoshi >=20 >=20 > On Tue, Jan 16, 2018 at 6:37 PM, Toerless Eckert = wrote: > Mirja, Yoshifumi >=20 > I just posted -08: = https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt >=20 > I have reworked the MPTCP text based on your threads feedback with > the intention to fix errors and have it answer the questions/concerns = raised, > but without otherwise changing the scope of it: >=20 > - What are they key features making MPTCP interesting > - How could it be used to solve the stable-connectivity issue > - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK > beyond the scope of this document > - Describe the areas of specification work required > - API/policy, control by apps > - dealing with dual VRF addresses >=20 > Please check diff in this URL (not complete diff of -08, just fix for = your discuss/comment): >=20 > = http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.github= usercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74a= d152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stab= le-connectivity-08.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/a= utonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf= -anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt >=20 > I hope this resolves your DISCUSS/comments. >=20 > Note that the term ACP was changed in the doc to GACP based on = resolving Alvaros discus. See: >=20 > = https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/= draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt >=20 > Thank you > Toerless >=20 > On Tue, Jan 09, 2018 at 05:37:16PM -0800, Yoshifumi Nishida wrote: > > I've reviewed this document as part of TSV-ART's ongoing effort to = review > > key IETF documents. These comments were written primarily for the = transport > > area directors, but are copied to the document's authors for their > > information and to allow them to address any issues raised.When done = at the > > time of IETF Last Call, the authors should consider this review = together > > with any other last-call comments they receive. Please always CC = tsv-art > > @ietf.org if you reply to or forward this review. > > > > Summary: This document is almost ready for publication, but several = points > > need to be clarified or updated. > > > > 1: In Section 2.1.5 > > " > > MPTCP (Multipath TCP -see [RFC6824]) is a very attractive = candidate > > to automate the use of both data-plane and ACP and minimize or = fully > > avoid the need for the above mentioned logical names to pre-set = the > > desired connectivity (data-plane-only, ACP only, both). For = example, > > a set-up for non MPTCP aware applications would be as follows: > > > > DNS naming is set up to provide the ACP IPv6 address of network > > devices. Unbeknownst to the application, MPTCP is used. MPTCP > > mutually discovers between the NOC and network device the = data-plane > > address and caries all traffic across it when that MPTCP subflow > > across the data-plane can be built. > > " > > > > It's not very clear to me how to archive this feature. > > I think more explanation will be required. > > As MPTCP resides in transport layer, I think it will be very tricky = to know > > which endpoint is used for ACP or for data-plane. Also, although = MPTCP > > can transmit application data to multiple destinations, it cannot > > identify which part of data is for ACP or for data-plane as it = doesn't > > parse app data. > > > > 2: in Section 2.1.8 > > > > " > > Leverage and as necessary enhance MPTCP with automatic dual- > > connectivity: If an MPTCP unaware application is using ACP > > connectivity, the policies used should add subflow(s) via the > > data-plane and prefer them. > > " > > > > I think functions like controlling policies should be designed = outside of > > MPTCP such as middleware > > between applications and transport layer, but the text is unclear = about how > > to enhance MPTCP. > > > > Thanks, > > -- > > Yoshi >=20 > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Mon Jan 22 04:44:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECAB120454 for ; Mon, 22 Jan 2018 04:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 1keLLF5-5c9f for ; Mon, 22 Jan 2018 04:44:46 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FD3126C2F for ; Mon, 22 Jan 2018 04:44:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=I6VUlarO/2V1dNwKdpgl+y4KSNoCtA/lfp4V8oyt5Ll+Bv25R1qcEg1n3GtCExvvCsA1fjfJqt5c6z3nycjsDbLzuOvCeZ/lKk9jUNxp8ZoybCfA/ssA/SXVFCk4khaxSWPlYs0s3PnlkUT+qBXOb5EWQR6bm1hvGD7uPlrLPB8=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1144 invoked from network); 22 Jan 2018 13:38:00 +0100 Received: from mue-88-130-61-036.dsl.tropolys.de (HELO ?192.168.178.33?) (88.130.61.36) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 Jan 2018 13:38:00 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> Date: Mon, 22 Jan 2018 13:37:58 +0100 Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180122123800.1134.67801@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jan 2018 12:44:49 -0000 Hi Toerless, thanks a lot for the updated text. I still have one little point I would = like to discuss a bit further on this text: "The above described behavior/policy for MPTCP must be controllable by=09= applications or libraries acting on behalf of applications. APIs=09 and/or data models for this control need to be defined. As outlined=09 above, applications for example may choose to only perform transfers=09 if the data-plane is actually available because of performance=09 limitations of the GACP, so the application needs to be made aware if=09= the setup of the data-plane subflow fails. Or transfers may want to=09 only use the GACP because the connection performs configuration=09 changes that are likely known to bring down the data-plane. It=09 should be sufficient to make these policies work on a per connection=09 basis, and not change during the lifetime of a connection for=09 different data items.=E2=80=9C The idea of MPTCP is really to use multiple network path without the = need for the high-layer to care about this. Yes, of course there are = cases where one or another path is preferred (e.g. because of cost) but = usually this is rather a preference than a hard requirement given = MPTCP's goal really is to keep connection up with the best performance = available.=20 When you say that there is a need for an application to send data only = on one path, today that=E2=80=99s not possible with MPTCP as you may = fallback to the other path silently during the transmission. Yes, of = course this could be changed and an extended interface could indicate = this. However, why don=E2=80=99t you just use two different TCP = connection in this case. You could use a (new) higher level protocol to = announce the second address over the first connection and then start a = second new TCP connection. Or you could potentially even use the MPTCP = option and expose that address to the application that then start a new = TCP connection but I=E2=80=99m not sure if that=E2=80=99s a clean = solution... So my question is still what the =E2=80=9Eonly=E2=80=9C really means in = this text. If you=E2=80=99d like to just indicate a preference that = might be okay. If you really want to rule out the possibility to = fallback to the other path, then I don=E2=80=99t think you need MPTCP = and two separate TCP connections would be the better option. Does that make sense to you? Mirja > Am 17.01.2018 um 03:36 schrieb Toerless Eckert : >=20 > Mirja, Yoshifumi >=20 > I just posted -08: = https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt >=20 > I have reworked the MPTCP text based on your threads feedback with > the intention to fix errors and have it answer the questions/concerns = raised, > but without otherwise changing the scope of it: >=20 > - What are they key features making MPTCP interesting=20 > - How could it be used to solve the stable-connectivity issue > - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK > beyond the scope of this document > - Describe the areas of specification work required > - API/policy, control by apps > - dealing with dual VRF addresses >=20 > Please check diff in this URL (not complete diff of -08, just fix for = your discuss/comment): >=20 > = http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.github= usercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74a= d152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stab= le-connectivity-08.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/a= utonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf= -anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt >=20 > I hope this resolves your DISCUSS/comments.=20 >=20 > Note that the term ACP was changed in the doc to GACP based on = resolving Alvaros discus. See: >=20 > = https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/= draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt >=20 > Thank you > Toerless >=20 > On Thu, Jan 11, 2018 at 03:42:53PM +0100, Mirja K?hlewind wrote: >> Hi Toerless, >>=20 >> the point I'm wondering about is your point (b) below. Yes, you can >> set the ACP subflow to backup but that would still mean that if the >> other link fails, it would automatically switch over to the ACP >> subflow (without exposing this to the upper layer). Is that what you >> want? Because my understanding was rather that there are cases where >> you'd probably would like to know over which link the OAM packets >> where actually sent...? >>=20 >> Mirja >>=20 >> On 08.01.2018 22:06, Toerless Eckert wrote: >>> Thanks, Mirja >>>=20 >>> (a) If the systems socket API does not transparently make TCP = sockets >>> to use MPTCP, then you would want a shim library. According to >>> draft-hesmans-mptcp-socket, this is be the case on Apple (iOS). >>>=20 >>> (b) Making the ACP subflow not carry traffic after establishing the >>> data plane subflow should easily be possible possible by setting its = MP_PRIO >>> to backup. >>>=20 >>> (c) How exactly to specify or implement the desired policy of only >>> establishing a subflow between the ACP addresses and the data plane = addresses >>> (but not full-mesh) seem to be a subject for further spec work. It = could >>> be defined as a specific in-MPTCP policy, or it could be done via a = shim >>> library (orthogonal to (a)). draft-hesmans-mptcp-socket might be = sufficient. >>>=20 >>> But in general: i would like for this (informational!) draft to just = motivate >>> the concept and not specify the solution: MPTCP would be a simple = way to >>> make "TCP" applications automatically "upgrade" from ACP to a = data-plane path >>> and switch back when data-plane fails... because MP-TCP can signal = the >>> additional data-plane addresses, establish transparently another = subflow and switch >>> traffic between the subflows - all by using the right = shim-library+API or >>> in-MP-TCP address/subflow policies - and the ability to establish = subflows >>> across two VRFs. >>>=20 >>> Cheers >>> Toerless >>>=20 >>> On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind (IETF) = wrote: >>>>>>> Suggested replacement text last two paragraphs of 2.1.5: >>>>> A (shim) library for aplications maps TCP connections to MPTCP = without the applications having to be aware of it. >>>> It???s not the (shim) library/policy framework that opens/maps the = TCP connection. MPTCP itself opens eventually multiple connections but = exposes only one connection to the layer above. That means everything = above MPTCP does not have any real control about which data is send over = which connection. >>>>=20 >>>> A policy shim layer could only implement rules about which new = subflows should be established when and what the priority is over which = subflow data should be sent but it generally does not control which data = is send of which flow. You can???t say I want this data to be sent over = subflow one and this data to be sent over sub flow two. >>>>=20 >>>> I think what you want is actually a view on the different TCP = connections and you try to use MPTCP only for announcing the other IP = address but that is not what MPTCP meant to be. >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>> Names in DNS use only the ACP IPv6 addresses of network devices. = Thererefore, the initial MPTCP subflow will use the ACP. After it is = operating, the shim libraries on both ends add their data-plane address = (MPTCP ADD_ADDR) and attempt to build a new subflow between those = addresses. If that (data plane) subflow is successfully built, the shim = libraries could shift all traffic over this subflow which should be = forwarded hardware accelerated by the network - and use the ACP subflow = across the ACP solely for signaling - beause it is most resilient = against failure. >>>>>=20 >>>>> This MPTCP approach is only an outline and would need to be fully = speficied for interoperable implementations. It may also require = extensions to MP-TCP. This mechanism must not be used without providing = for encryption of subflows not running across the ACP. >>>>>=20 >>>>>>> Brian: ... can not use capital MUST NOT in an information draft = (i think) >>>>>>>=20 >>>>> Cheers >>>>> Toerless >>>>>=20 >>>>> On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind (IETF) = wrote: >>>>>> Hi Micheal, >>>>>>=20 >>>>>> to clarify one part below: >>>>>>=20 >>>>>>> Am 05.01.2018 um 23:30 schrieb Michael Richardson = : >>>>>>>=20 >>>>>>>=20 >>>>>>> Mirja K=C3=83=C2=BChlewind wrote: >>>>>>>> "DNS naming is set up to provide the ACP IPv6 address of = network >>>>>>>> devices. Unbeknownst to the application, MPTCP is used. MPTCP >>>>>>>> mutually discovers between the NOC and network device the = data-plane >>>>>>>> address and caries all traffic across it when that MPTCP = subflow >>>>>>>> across the data-plane can be built." >>>>>>> Section 2.1.5 is discussion, it discusses ways in which the >>>>>>> anticipated low performance (compared to what the box might do = with its >>>>>>> hardware accelerated forwarding). >>>>>>>=20 >>>>>>> If we have an application that needs the bandwidth of the native = hardware, >>>>>>> the connection can be initated over the ACP (that's what would = be in DNS). >>>>>>> One presumes that an MPTCP layer could then enumerate the = available IPs at >>>>>>> each end and then start off additional flows on the other = destinations. >>>>>> MPTCP adda an additional TCP flow but for the application that = still looks like one flow. As I said I???m not sure if that is what you = want. >>>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>> The application would have to include application security, = since it would >>>>>>> not be protected by the ACP. >>>>>>>=20 >>>>>>> Perhaps MPTCP doesn't work this way. >>>>>>>=20 >>>>>>>> However, I'm actually uncertain how this is supposed to work = and what >>>>>>>> "Unbeknownst to the application" should mean. If another = address should be >>>>>>>> signaled to the other host, this needs to be indicated by the = application or at >>>>>>>> least some kind of policy framework above MPTCP. Also MPTCP = will by default use >>>>>>>> both paths simultaneously while still looking like one = connection to the >>>>>>>> application, meaning the application has no control which path = is used for >>>>>>>> which traffic. I guess you can open a second subflow and then = configure the >>>>>>>> first subflow as backup path but I'm not sure if that's what = you want (given >>>>>>>> the application/policy framework will still not know which path = is used)..? >>>>>>>> Please provide more information about what the expected usage = scenario is here. >>>>>>>=20 >>>>>>> -- >>>>>>> Michael Richardson , Sandelman Software = Works >>>>>>> -=3D IPv6 IoT consulting =3D- >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> Anima mailing list >>>>>> Anima@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>> --=20 >>>>> --- >>>>> tte@cs.fau.de >=20 > --=20 > --- > tte@cs.fau.de From nobody Mon Jan 22 10:43:24 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E59E127058; Mon, 22 Jan 2018 10:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M_s5Vd8g4fD; Mon, 22 Jan 2018 10:43:18 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E6012AF83; Mon, 22 Jan 2018 10:42:55 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3F21058C5BD; Mon, 22 Jan 2018 19:42:50 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 21149B0D815; Mon, 22 Jan 2018 19:42:50 +0100 (CET) Date: Mon, 22 Jan 2018 19:42:50 +0100 From: Toerless Eckert To: "Mirja Kuehlewind (IETF)" Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com Message-ID: <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jan 2018 18:43:22 -0000 Thanks, Mirja. Inline. On Mon, Jan 22, 2018 at 01:37:58PM +0100, Mirja Kuehlewind (IETF) wrote: > Hi Toerless, > > thanks a lot for the updated text. I still have one little point I would like to discuss a bit further on this text: > > "The above described behavior/policy for MPTCP must be controllable by > applications or libraries acting on behalf of applications. APIs > and/or data models for this control need to be defined. As outlined > above, applications for example may choose to only perform transfers > if the data-plane is actually available because of performance > limitations of the GACP, so the application needs to be made aware if > the setup of the data-plane subflow fails. Or transfers may want to > only use the GACP because the connection performs configuration > changes that are likely known to bring down the data-plane. It > should be sufficient to make these policies work on a per connection > basis, and not change during the lifetime of a connection for > different data items.??? > > > When you say that there is a need for an application to send data only on one path, today that???s not possible with MPTCP as you may fallback to the other path silently during the transmission. Yes, of course this could be changed and an extended interface could indicate this. > > So my question is still what the ???only??? really means in this text. If you???d like to just indicate a preference that might be okay. If you really want to rule out the possibility to fallback to the other path, then I don???t think you need MPTCP and two separate TCP connections would be the better option. > > Does that make sense to you? Not really, the goal is always to leverage existing MPTCP signaling of addresses, indicating backup for flows, etc. I think two TCP flows would never be better: The GACP address is the primary identifier of a device known in DNS. Data-Plane addresses can change over time subject to operator configuration and could also pose more of a security issue to be in DNS (GACP is isolated network). GACP performance may be quite low because some network device may route/forward it in software. data-plane routing/forwarding is expected to be fast/HW-accelerated. With MPTCP as suggested this gives for example: Initial subflow must use GACP because thats the only "known/stable address" in DNS Then MPTCP signaling is used to indicate mutually the data-plane addresses and make GACP subflow backup. Then you transfer lets say a few Gigabyte of data (e.g.: firmware update) which goes over data-plane. Then some uncorrelated error happens and data-plane fails. This particular app should then fail because it would just slow down to insufferable slow across GACP and would overload software forwarding in GACP. In another application connection, fallback to GACP subflow for data if dat-plane subflow fails is fine, but you would only prefer data-plane for performance. You could consider the GACP potential software only forwarding like a very high cost of using it while data-plane is free. If i would just use 2 * TCP instead of MPTCP i would have to reinvent a lot of MPTCP to get the address signaling etc. Right ? Cheers Toerless > > Mirja > > > > > Am 17.01.2018 um 03:36 schrieb Toerless Eckert : > > > > Mirja, Yoshifumi > > > > I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt > > > > I have reworked the MPTCP text based on your threads feedback with > > the intention to fix errors and have it answer the questions/concerns raised, > > but without otherwise changing the scope of it: > > > > - What are they key features making MPTCP interesting > > - How could it be used to solve the stable-connectivity issue > > - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK > > beyond the scope of this document > > - Describe the areas of specification work required > > - API/policy, control by apps > > - dealing with dual VRF addresses > > > > Please check diff in this URL (not complete diff of -08, just fix for your discuss/comment): > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt > > > > I hope this resolves your DISCUSS/comments. > > > > Note that the term ACP was changed in the doc to GACP based on resolving Alvaros discus. See: > > > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt > > > > Thank you > > Toerless > > > > On Thu, Jan 11, 2018 at 03:42:53PM +0100, Mirja K?hlewind wrote: > >> Hi Toerless, > >> > >> the point I'm wondering about is your point (b) below. Yes, you can > >> set the ACP subflow to backup but that would still mean that if the > >> other link fails, it would automatically switch over to the ACP > >> subflow (without exposing this to the upper layer). Is that what you > >> want? Because my understanding was rather that there are cases where > >> you'd probably would like to know over which link the OAM packets > >> where actually sent...? > >> > >> Mirja > >> > >> On 08.01.2018 22:06, Toerless Eckert wrote: > >>> Thanks, Mirja > >>> > >>> (a) If the systems socket API does not transparently make TCP sockets > >>> to use MPTCP, then you would want a shim library. According to > >>> draft-hesmans-mptcp-socket, this is be the case on Apple (iOS). > >>> > >>> (b) Making the ACP subflow not carry traffic after establishing the > >>> data plane subflow should easily be possible possible by setting its MP_PRIO > >>> to backup. > >>> > >>> (c) How exactly to specify or implement the desired policy of only > >>> establishing a subflow between the ACP addresses and the data plane addresses > >>> (but not full-mesh) seem to be a subject for further spec work. It could > >>> be defined as a specific in-MPTCP policy, or it could be done via a shim > >>> library (orthogonal to (a)). draft-hesmans-mptcp-socket might be sufficient. > >>> > >>> But in general: i would like for this (informational!) draft to just motivate > >>> the concept and not specify the solution: MPTCP would be a simple way to > >>> make "TCP" applications automatically "upgrade" from ACP to a data-plane path > >>> and switch back when data-plane fails... because MP-TCP can signal the > >>> additional data-plane addresses, establish transparently another subflow and switch > >>> traffic between the subflows - all by using the right shim-library+API or > >>> in-MP-TCP address/subflow policies - and the ability to establish subflows > >>> across two VRFs. > >>> > >>> Cheers > >>> Toerless > >>> > >>> On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind (IETF) wrote: > >>>>>>> Suggested replacement text last two paragraphs of 2.1.5: > >>>>> A (shim) library for aplications maps TCP connections to MPTCP without the applications having to be aware of it. > >>>> It???s not the (shim) library/policy framework that opens/maps the TCP connection. MPTCP itself opens eventually multiple connections but exposes only one connection to the layer above. That means everything above MPTCP does not have any real control about which data is send over which connection. > >>>> > >>>> A policy shim layer could only implement rules about which new subflows should be established when and what the priority is over which subflow data should be sent but it generally does not control which data is send of which flow. You can???t say I want this data to be sent over subflow one and this data to be sent over sub flow two. > >>>> > >>>> I think what you want is actually a view on the different TCP connections and you try to use MPTCP only for announcing the other IP address but that is not what MPTCP meant to be. > >>>> > >>>> Mirja > >>>> > >>>> > >>>>> Names in DNS use only the ACP IPv6 addresses of network devices. Thererefore, the initial MPTCP subflow will use the ACP. After it is operating, the shim libraries on both ends add their data-plane address (MPTCP ADD_ADDR) and attempt to build a new subflow between those addresses. If that (data plane) subflow is successfully built, the shim libraries could shift all traffic over this subflow which should be forwarded hardware accelerated by the network - and use the ACP subflow across the ACP solely for signaling - beause it is most resilient against failure. > >>>>> > >>>>> This MPTCP approach is only an outline and would need to be fully speficied for interoperable implementations. It may also require extensions to MP-TCP. This mechanism must not be used without providing for encryption of subflows not running across the ACP. > >>>>> > >>>>>>> Brian: ... can not use capital MUST NOT in an information draft (i think) > >>>>>>> > >>>>> Cheers > >>>>> Toerless > >>>>> > >>>>> On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind (IETF) wrote: > >>>>>> Hi Micheal, > >>>>>> > >>>>>> to clarify one part below: > >>>>>> > >>>>>>> Am 05.01.2018 um 23:30 schrieb Michael Richardson : > >>>>>>> > >>>>>>> > >>>>>>> Mirja Kühlewind wrote: > >>>>>>>> "DNS naming is set up to provide the ACP IPv6 address of network > >>>>>>>> devices. Unbeknownst to the application, MPTCP is used. MPTCP > >>>>>>>> mutually discovers between the NOC and network device the data-plane > >>>>>>>> address and caries all traffic across it when that MPTCP subflow > >>>>>>>> across the data-plane can be built." > >>>>>>> Section 2.1.5 is discussion, it discusses ways in which the > >>>>>>> anticipated low performance (compared to what the box might do with its > >>>>>>> hardware accelerated forwarding). > >>>>>>> > >>>>>>> If we have an application that needs the bandwidth of the native hardware, > >>>>>>> the connection can be initated over the ACP (that's what would be in DNS). > >>>>>>> One presumes that an MPTCP layer could then enumerate the available IPs at > >>>>>>> each end and then start off additional flows on the other destinations. > >>>>>> MPTCP adda an additional TCP flow but for the application that still looks like one flow. As I said I???m not sure if that is what you want. > >>>>>> > >>>>>> Mirja > >>>>>> > >>>>>> > >>>>>>> The application would have to include application security, since it would > >>>>>>> not be protected by the ACP. > >>>>>>> > >>>>>>> Perhaps MPTCP doesn't work this way. > >>>>>>> > >>>>>>>> However, I'm actually uncertain how this is supposed to work and what > >>>>>>>> "Unbeknownst to the application" should mean. If another address should be > >>>>>>>> signaled to the other host, this needs to be indicated by the application or at > >>>>>>>> least some kind of policy framework above MPTCP. Also MPTCP will by default use > >>>>>>>> both paths simultaneously while still looking like one connection to the > >>>>>>>> application, meaning the application has no control which path is used for > >>>>>>>> which traffic. I guess you can open a second subflow and then configure the > >>>>>>>> first subflow as backup path but I'm not sure if that's what you want (given > >>>>>>>> the application/policy framework will still not know which path is used)..? > >>>>>>>> Please provide more information about what the expected usage scenario is here. > >>>>>>> > >>>>>>> -- > >>>>>>> Michael Richardson , Sandelman Software Works > >>>>>>> -= IPv6 IoT consulting =- > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Anima mailing list > >>>>>> Anima@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>> -- > >>>>> --- > >>>>> tte@cs.fau.de > > > > -- > > --- > > tte@cs.fau.de From nobody Mon Jan 22 10:44:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FBB127599; Mon, 22 Jan 2018 10:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcFdQNqtvQiy; Mon, 22 Jan 2018 10:44:27 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365451289B0; Mon, 22 Jan 2018 10:44:00 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B5DF958C4D4; Mon, 22 Jan 2018 19:43:55 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A2E1BB0D815; Mon, 22 Jan 2018 19:43:55 +0100 (CET) Date: Mon, 22 Jan 2018 19:43:55 +0100 From: Toerless Eckert To: "Mirja Kuehlewind (IETF)" Cc: Yoshifumi Nishida , tsv-art@ietf.org, dreft-ietf-anima-stable-connectivity@ietf.org, anima@ietf.org Message-ID: <20180122184355.GB350@faui40p.informatik.uni-erlangen.de> References: <20180117023729.GA26735@faui40p.informatik.uni-erlangen.de> <6EEEE1A4-D653-4567-AC35-706EAA445BB6@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6EEEE1A4-D653-4567-AC35-706EAA445BB6@kuehlewind.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] [Tsv-art] TSV-ART telechat review of draft-ietf-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jan 2018 18:44:29 -0000 Ack. Fill fix after second comment from Mirja is resolved. On Mon, Jan 22, 2018 at 01:25:57PM +0100, Mirja Kuehlewind (IETF) wrote: > Hi Toerless, > > I agree with Yoshi here. I guess a quick fix is the following: > > s/The MPTCP stack/The endpoint/ > > I have one more comment that I will send in reply to your other mail. > > Mirja > > > > > Am 22.01.2018 um 09:34 schrieb Yoshifumi Nishida : > > > > Hi Toerless, > > > > Thanks for the updates. It looks better to me. > > Just one very minor comment.. > > "GACP and data-plane addresses exist in different VRFs. The MPTCP > > stack needs to be able to access multiple VRFs and know which local > > address is existing in which VRF. There also needs to be a logic to > > determine which peer address is expected to be reachable via which > > local VRF/address. Because the GACP is an isolated network, data- > > plane addresses are not reachable via the GACP therefore devices can > > determine if a peer address is a data-plane address." > > > > > > I personally think the logic to determine which peer is expected to be reachable > > doesn't need to be in MPTCP stack. Or, if a MPTCP stack tries all possible combinations > > of address pairs to establish subflows, we might not need to have such a logic. It may be > > redundant, though. > > > > Thanks, > > -- > > Yoshi > > > > > > On Tue, Jan 16, 2018 at 6:37 PM, Toerless Eckert wrote: > > Mirja, Yoshifumi > > > > I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt > > > > I have reworked the MPTCP text based on your threads feedback with > > the intention to fix errors and have it answer the questions/concerns raised, > > but without otherwise changing the scope of it: > > > > - What are they key features making MPTCP interesting > > - How could it be used to solve the stable-connectivity issue > > - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK > > beyond the scope of this document > > - Describe the areas of specification work required > > - API/policy, control by apps > > - dealing with dual VRF addresses > > > > Please check diff in this URL (not complete diff of -08, just fix for your discuss/comment): > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt > > > > I hope this resolves your DISCUSS/comments. > > > > Note that the term ACP was changed in the doc to GACP based on resolving Alvaros discus. See: > > > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt > > > > Thank you > > Toerless > > > > On Tue, Jan 09, 2018 at 05:37:16PM -0800, Yoshifumi Nishida wrote: > > > I've reviewed this document as part of TSV-ART's ongoing effort to review > > > key IETF documents. These comments were written primarily for the transport > > > area directors, but are copied to the document's authors for their > > > information and to allow them to address any issues raised.When done at the > > > time of IETF Last Call, the authors should consider this review together > > > with any other last-call comments they receive. Please always CC tsv-art > > > @ietf.org if you reply to or forward this review. > > > > > > Summary: This document is almost ready for publication, but several points > > > need to be clarified or updated. > > > > > > 1: In Section 2.1.5 > > > " > > > MPTCP (Multipath TCP -see [RFC6824]) is a very attractive candidate > > > to automate the use of both data-plane and ACP and minimize or fully > > > avoid the need for the above mentioned logical names to pre-set the > > > desired connectivity (data-plane-only, ACP only, both). For example, > > > a set-up for non MPTCP aware applications would be as follows: > > > > > > DNS naming is set up to provide the ACP IPv6 address of network > > > devices. Unbeknownst to the application, MPTCP is used. MPTCP > > > mutually discovers between the NOC and network device the data-plane > > > address and caries all traffic across it when that MPTCP subflow > > > across the data-plane can be built. > > > " > > > > > > It's not very clear to me how to archive this feature. > > > I think more explanation will be required. > > > As MPTCP resides in transport layer, I think it will be very tricky to know > > > which endpoint is used for ACP or for data-plane. Also, although MPTCP > > > can transmit application data to multiple destinations, it cannot > > > identify which part of data is for ACP or for data-plane as it doesn't > > > parse app data. > > > > > > 2: in Section 2.1.8 > > > > > > " > > > Leverage and as necessary enhance MPTCP with automatic dual- > > > connectivity: If an MPTCP unaware application is using ACP > > > connectivity, the policies used should add subflow(s) via the > > > data-plane and prefer them. > > > " > > > > > > I think functions like controlling policies should be designed outside of > > > MPTCP such as middleware > > > between applications and transport layer, but the text is unclear about how > > > to enhance MPTCP. > > > > > > Thanks, > > > -- > > > Yoshi > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > > Tsv-art mailing list > > Tsv-art@ietf.org > > https://www.ietf.org/mailman/listinfo/tsv-art > > > > _______________________________________________ > > Tsv-art mailing list > > Tsv-art@ietf.org > > https://www.ietf.org/mailman/listinfo/tsv-art -- --- tte@cs.fau.de From nobody Wed Jan 24 04:34:25 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1A512025C for ; Wed, 24 Jan 2018 04:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8KXCNIbOk6U for ; Wed, 24 Jan 2018 04:34:21 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CA1120227 for ; Wed, 24 Jan 2018 04:34:21 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1eeKFs-00035e-QF; Wed, 24 Jan 2018 13:34:16 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id BCBC64202E5; Wed, 24 Jan 2018 13:34:16 +0100 (CET) To: Michael Richardson , anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B928180BE62@NKGEML515-MBX.china.huawei.com> <8b80a2b3-0ab3-659d-158a-1caeab879ab1@sandelman.ca> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <47f66b22-407e-d109-ae6d-c2f79419d8e5@kit.edu> Date: Wed, 24 Jan 2018 13:34:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <8b80a2b3-0ab3-659d-158a-1caeab879ab1@sandelman.ca> Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1516797256.866946992 Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jan 2018 12:34:24 -0000 Hi, Am 18.01.2018 um 19:46 schrieb Michael Richardson: > I have read the -05 document. An -06 is needed which just tightens the > text up slightly. > I know that Toerless has put a lot of editing cycles on this document, I > think that it needs a pass from another of the authors to tweak some things. +1 I started to read it and my impression was the same. I'll send more detailed comments later this week. Regards, Roland From nobody Wed Jan 24 09:24:01 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE991270AB; Wed, 24 Jan 2018 09:23:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151681463557.22545.6916673976540679729@ietfa.amsl.com> Date: Wed, 24 Jan 2018 09:23:55 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-voucher-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 17:23:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Voucher Profile for Bootstrapping Protocols Authors : Kent Watsen Michael C. Richardson Max Pritikin Toerless Eckert Filename : draft-ietf-anima-voucher-07.txt Pages : 22 Date : 2018-01-24 Abstract: This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a CMS structure. Other YANG- derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e. the Manufacturer Authorized Signing Authority). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-voucher-07 https://datatracker.ietf.org/doc/html/draft-ietf-anima-voucher-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 24 09:29:56 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E021270AB for ; Wed, 24 Jan 2018 09:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 tp2MzrA_4MOz for ; Wed, 24 Jan 2018 09:29:48 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7F412DA6F for ; Wed, 24 Jan 2018 09:29:48 -0800 (PST) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0OHTjgh012306 for ; Wed, 24 Jan 2018 09:29:46 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=hHz0HnZWkSLYg/0StKClGGb4Ppw+X0edtmNIU9/BMZ0=; b=Bd5mEYh+M60Q6JJiGegN1lBiBNMVy9TNWgUpJICIAlvQF/qFKNmkco4p0lcMiyAb8Bjh 9FgyLewrgVH5QgzOyk/1+X3OCRSpletc+iGIMiDY1ra8wOr1OWxsiRWR1gHDXl8BdF1Y i4CB9LACQ+0kDSMPZKbq/DXZ2c1th/K+SofRdbvkjjQNCzcCc/vqx05YIE1EqrBxHQjG NNsme5ufFarm/b4lODtyzu5tPtAUyyqpHhaN6Bkoxiap4J8dGQbRofsXMyMG46NgDH4M psy6Jwjxvo10X4l5dhXKELgDabFSpBrhw+uSWeNi7OADZ2oHax4c+cp5iyYhbJtvmrrN /Q== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0020.outbound.protection.outlook.com [207.46.163.20]) by mx0b-00273201.pphosted.com with ESMTP id 2fprjyrrs7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 24 Jan 2018 09:29:45 -0800 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3643.namprd05.prod.outlook.com (10.174.243.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Wed, 24 Jan 2018 17:29:44 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0444.013; Wed, 24 Jan 2018 17:29:44 +0000 From: Kent Watsen To: "anima@ietf.org" Thread-Topic: [Anima] I-D Action: draft-ietf-anima-voucher-07.txt Thread-Index: AQHTlTgkJxp43OcK3kS+B+DteJGuC6OC85WA Date: Wed, 24 Jan 2018 17:29:44 +0000 Message-ID: References: <151681463557.22545.6916673976540679729@ietfa.amsl.com> In-Reply-To: <151681463557.22545.6916673976540679729@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3643; 7:8UUo/Wesb5AbjvFrxqBz4AC9Xnx4W0F0iKZL9+pUNRk9YE3ikgosO4qqHWZYvuyUM/ljXbQ+SLLyUY2nK2j2fZbDJ0JGc7WTE8/dL52XGfu6Ut0NqMybBU1BCGxZaI7V2DyLLlU1P6Q1phxRwlRaptlGZ2GFuvKLF1N4yiQ5lUREFeV0sankItO5I+PjYSx07gRkeoXa0leL3KwIxo4fkLjRDDumYLMCLSRaodw2KEXuOtrPhskd4bHEzGWhcD4X x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f89cf601-2117-4185-290a-08d563500f0e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3643; x-ms-traffictypediagnostic: DM5PR05MB3643: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231023)(2400081)(944501161)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041288)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB3643; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3643; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39380400002)(366004)(39860400002)(189003)(199004)(377424004)(3280700002)(58126008)(68736007)(36756003)(2501003)(3660700001)(6512007)(77096007)(66066001)(6306002)(26005)(6246003)(5660300001)(966005)(83716003)(478600001)(99286004)(2950100002)(6916009)(86362001)(575784001)(14454004)(105586002)(2900100001)(8676002)(1730700003)(81166006)(8936002)(81156014)(3846002)(6116002)(5640700003)(83506002)(6486002)(53936002)(2906002)(97736004)(229853002)(6436002)(305945005)(2351001)(7736002)(106356001)(316002)(76176011)(59450400001)(6506007)(102836004)(25786009)(82746002)(33656002)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3643; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 7P+ZZnIo1efQ4HV0dK14VA8m/ZYRP+/N3X7iqM/nHXPjyS6nyx8pkYa0ymlXAqzsZ4mDoqzUIsohwu01hNCU6Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: f89cf601-2117-4185-290a-08d563500f0e X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 17:29:44.3287 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3643 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240231 Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-voucher-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jan 2018 17:29:51 -0000 VGhpcyB1cGRhdGUgdG8gdGhlIGRyYWZ0IGFkZHJlc3NlcyBhbGwgb2YgdGhlIExhc3QgQ2FsbCBj b21tZW50cywNCmFuZCB0aGVyZWZvcmUgaXMgcmVhZHkgZm9yIGFkdmFuY2VtZW50Lg0KDQpUaGFu a3MsDQpLZW50DQoNCj09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT0NCg0KQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp cmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQXV0b25vbWljIE5l dHdvcmtpbmcgSW50ZWdyYXRlZCBNb2RlbCBhbmQgQXBwcm9hY2ggV0cgb2YgdGhlIElFVEYuDQoN CiAgICAgICAgVGl0bGUgICAgICAgICAgIDogVm91Y2hlciBQcm9maWxlIGZvciBCb290c3RyYXBw aW5nIFByb3RvY29scw0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBLZW50IFdhdHNlbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICBNaWNoYWVsIEMuIFJpY2hhcmRzb24NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgTWF4IFByaXRpa2luDQogICAgICAgICAgICAgICAgICAgICAgICAgIFRv ZXJsZXNzIEVja2VydA0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYW5pbWEtdm91Y2hl ci0wNy50eHQNCglQYWdlcyAgICAgICAgICAgOiAyMg0KCURhdGUgICAgICAgICAgICA6IDIwMTgt MDEtMjQNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBzdHJhdGVneSB0 byBzZWN1cmVseSBhc3NpZ24gYSBwbGVkZ2UgdG8gYW4NCiAgIG93bmVyLCB1c2luZyBhbiBhcnRp ZmFjdCBzaWduZWQsIGRpcmVjdGx5IG9yIGluZGlyZWN0bHksIGJ5IHRoZQ0KICAgcGxlZGdlJ3Mg bWFudWZhY3R1cmVyLiAgVGhpcyBhcnRpZmFjdCBpcyBrbm93biBhcyBhICJ2b3VjaGVyIi4NCg0K ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGFydGlmYWN0IGZvcm1hdCBhcyBhIFlBTkctZGVm aW5lZCBKU09ODQogICBkb2N1bWVudCB0aGF0IGhhcyBiZWVuIHNpZ25lZCB1c2luZyBhIENNUyBz dHJ1Y3R1cmUuICBPdGhlciBZQU5HLQ0KICAgZGVyaXZlZCBmb3JtYXRzIGFyZSBwb3NzaWJsZS4g IFRoZSB2b3VjaGVyIGFydGlmYWN0IGlzIG5vcm1hbGx5DQogICBnZW5lcmF0ZWQgYnkgdGhlIHBs ZWRnZSdzIG1hbnVmYWN0dXJlciAoaS5lLiB0aGUgTWFudWZhY3R1cmVyDQogICBBdXRob3JpemVk IFNpZ25pbmcgQXV0aG9yaXR5KS4NCg0KICAgVGhpcyBkb2N1bWVudCBvbmx5IGRlZmluZXMgdGhl IHZvdWNoZXIgYXJ0aWZhY3QsIGxlYXZpbmcgaXQgdG8gb3RoZXINCiAgIGRvY3VtZW50cyB0byBk ZXNjcmliZSBzcGVjaWFsaXplZCBwcm90b2NvbHMgZm9yIGFjY2Vzc2luZyBpdC4NCg0KDQpUaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIu aWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGFuaW1hLTJEdm91Y2hlcl8mZD1Ed0lDQWcmYz1I QWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpH SjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWZWanN0VDhpNDc5alFYWEpyUkFIT19m azFRbUJWcGVOMzNVRlZOX2ItSTQmcz01WnA5ak5QVHJkd0J1WGtlNWIxRW5QR081ZHVrTU5ZUXB3 RndDOHdfQTVzJmU9DQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs ZSBhdDoNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRhbmltYS0yRHZvdWNoZXItMkQw NyZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0km cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09ZlZqc3RUOGk0 NzlqUVhYSnJSQUhPX2ZrMVFtQlZwZU4zM1VGVk5fYi1JNCZzPTVzSC1uZjBHMTN0QzI1WFJfR2dG ZUdTZUk1ZVRtNjhmODBtcmNZMFZpYmcmZT0NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2h0bWxfZHJh ZnQtMkRpZXRmLTJEYW5pbWEtMkR2b3VjaGVyLTJEMDcmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhy NlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFu MmdzQllhR1R2aklTbGFKZGNabyZtPWZWanN0VDhpNDc5alFYWEpyUkFIT19mazFRbUJWcGVOMzNV RlZOX2ItSTQmcz0zZjBFTEVua2d2TEVpX20yckNjOFZ4Qm9RenhSUGIxMkVGOUhaTUxUczhBJmU9 DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX3JmY2RpZmYtM0Z1cmwyLTNEZHJhZnQtMkRpZXRmLTJEYW5pbWEtMkR2b3VjaGVyLTJE MDcmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJ JnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWZWanN0VDhp NDc5alFYWEpyUkFIT19mazFRbUJWcGVOMzNVRlZOX2ItSTQmcz1wd29yZWxmNFdtdmwtMmg5aVA2 dTgwcUI1enB0ZE0tYkxJZjFXcWtxNzNVJmU9DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWZ0 cC0zQV9fZnRwLmlldGYub3JnX2ludGVybmV0LTJEZHJhZnRzXyZkPUR3SUNBZyZjPUhBa1l1aDYz cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09ZlZqc3RUOGk0NzlqUVhYSnJSQUhPX2ZrMVFtQlZw ZU4zM1VGVk5fYi1JNCZzPUVzYmZPbTY0ZGlGX0RBRGlocDRnNGI3MXVwZ01jODM1UnBuNjJOYnFQ ZzQmZT0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkFuaW1hIG1haWxpbmcgbGlzdA0KQW5pbWFAaWV0Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9fYW5pbWEmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3Zv RFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZt PWZWanN0VDhpNDc5alFYWEpyUkFIT19mazFRbUJWcGVOMzNVRlZOX2ItSTQmcz1qMEF6SjBYeGU3 WGQtb0hSOHkyb2xROUZMM2VVQjZtRW1OZl9DMnhmODFjJmU9DQoNCg0K From nobody Fri Jan 26 02:49:58 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38A812E055 for ; Fri, 26 Jan 2018 02:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 bU58L6LXdOHl for ; Fri, 26 Jan 2018 02:49:54 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3739812DA13 for ; Fri, 26 Jan 2018 02:49:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=j8240msAZNmh8AKXa632I9wlOQzCqVJK/BiL0h60ZXFrAS+kXRPn+eOgNxff7rNFbUHOwg14LI14GxgwbsYRmUcyuVd7lAr5NejOKic2k8CxTbNA6Dy94yOhgykCNYYKLqCBLHQxXutKAFQmKLWQhzh/VrgTpk4/8qEYqHmn3ZQ=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 7490 invoked from network); 26 Jan 2018 11:43:10 +0100 Received: from mue-88-130-61-209.dsl.tropolys.de (HELO ?192.168.178.33?) (88.130.61.209) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 26 Jan 2018 11:43:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> Date: Fri, 26 Jan 2018 11:43:08 +0100 Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180126104310.7480.27146@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jan 2018 10:49:57 -0000 Hi Toerless, sorry for my late reply but I spend only limited time on AD stuff on the = telechat agenda was crowded this week. See below. > Am 22.01.2018 um 19:42 schrieb Toerless Eckert : >=20 >=20 > Thanks, Mirja. Inline. >=20 > On Mon, Jan 22, 2018 at 01:37:58PM +0100, Mirja Kuehlewind (IETF) = wrote: >> Hi Toerless, >>=20 >> thanks a lot for the updated text. I still have one little point I = would like to discuss a bit further on this text: >>=20 >> "The above described behavior/policy for MPTCP must be controllable = by=09 >> applications or libraries acting on behalf of applications. APIs=09 >> and/or data models for this control need to be defined. As outlined=09= >> above, applications for example may choose to only perform transfers=09= >> if the data-plane is actually available because of performance=09 >> limitations of the GACP, so the application needs to be made aware if=09= >> the setup of the data-plane subflow fails. Or transfers may want to=09= >> only use the GACP because the connection performs configuration=09 >> changes that are likely known to bring down the data-plane. It=09 >> should be sufficient to make these policies work on a per connection=09= >> basis, and not change during the lifetime of a connection for=09 >> different data items.??? >>=20 >>=20 >> When you say that there is a need for an application to send data = only on one path, today that???s not possible with MPTCP as you may = fallback to the other path silently during the transmission. Yes, of = course this could be changed and an extended interface could indicate = this.=20 >=20 >>=20 >> So my question is still what the ???only??? really means in this = text. If you???d like to just indicate a preference that might be okay. = If you really want to rule out the possibility to fallback to the other = path, then I don???t think you need MPTCP and two separate TCP = connections would be the better option. >>=20 >> Does that make sense to you? >=20 > Not really, the goal is always to leverage existing MPTCP signaling of > addresses, indicating backup for flows, etc. I think two TCP flows = would > never be better: Okay that is fine. I mainly wanted to double-check as that was still not = fully clear from the provided text. Can you maybe propose a slight = rewording that explicitly say that there is this backup while using the = word =E2=80=9Aonly=E2=80=98 above in the cited text seems to indicated = differently. Thanks! >=20 > The GACP address is the primary identifier of a device known in DNS. > Data-Plane addresses can change over time subject to operator = configuration > and could also pose more of a security issue to be in DNS (GACP is = isolated > network). >=20 > GACP performance may be quite low because some network device may = route/forward > it in software. data-plane routing/forwarding is expected to be = fast/HW-accelerated. >=20 > With MPTCP as suggested this gives for example: > Initial subflow must use GACP because thats the only "known/stable = address" in DNS > Then MPTCP signaling is used to indicate mutually the data-plane = addresses > and make GACP subflow backup. > Then you transfer lets say a few Gigabyte of data (e.g.: firmware = update) which > goes over data-plane. > Then some uncorrelated error happens and data-plane fails. This = particular app > should then fail because it would just slow down to insufferable slow = across > GACP and would overload software forwarding in GACP. >=20 > In another application connection, fallback to GACP subflow for data = if dat-plane > subflow fails is fine, but you would only prefer data-plane for = performance. >=20 > You could consider the GACP potential software only forwarding like a = very high > cost of using it while data-plane is free. >=20 > If i would just use 2 * TCP instead of MPTCP i would have to reinvent = a lot of > MPTCP to get the address signaling etc. Right ? >=20 > Cheers > Toerless >>=20 >> Mirja >>=20 >>=20 >>=20 >>> Am 17.01.2018 um 03:36 schrieb Toerless Eckert : >>>=20 >>> Mirja, Yoshifumi >>>=20 >>> I just posted -08: = https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt >>>=20 >>> I have reworked the MPTCP text based on your threads feedback with >>> the intention to fix errors and have it answer the = questions/concerns raised, >>> but without otherwise changing the scope of it: >>>=20 >>> - What are they key features making MPTCP interesting=20 >>> - How could it be used to solve the stable-connectivity issue >>> - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK >>> beyond the scope of this document >>> - Describe the areas of specification work required >>> - API/policy, control by apps >>> - dealing with dual VRF addresses >>>=20 >>> Please check diff in this URL (not complete diff of -08, just fix = for your discuss/comment): >>>=20 >>> = http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.github= usercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74a= d152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stab= le-connectivity-08.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/a= utonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf= -anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt >>>=20 >>> I hope this resolves your DISCUSS/comments.=20 >>>=20 >>> Note that the term ACP was changed in the doc to GACP based on = resolving Alvaros discus. See: >>>=20 >>> = https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/= draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt >>>=20 >>> Thank you >>> Toerless >>>=20 >>> On Thu, Jan 11, 2018 at 03:42:53PM +0100, Mirja K?hlewind wrote: >>>> Hi Toerless, >>>>=20 >>>> the point I'm wondering about is your point (b) below. Yes, you can >>>> set the ACP subflow to backup but that would still mean that if the >>>> other link fails, it would automatically switch over to the ACP >>>> subflow (without exposing this to the upper layer). Is that what = you >>>> want? Because my understanding was rather that there are cases = where >>>> you'd probably would like to know over which link the OAM packets >>>> where actually sent...? >>>>=20 >>>> Mirja >>>>=20 >>>> On 08.01.2018 22:06, Toerless Eckert wrote: >>>>> Thanks, Mirja >>>>>=20 >>>>> (a) If the systems socket API does not transparently make TCP = sockets >>>>> to use MPTCP, then you would want a shim library. According to >>>>> draft-hesmans-mptcp-socket, this is be the case on Apple (iOS). >>>>>=20 >>>>> (b) Making the ACP subflow not carry traffic after establishing = the >>>>> data plane subflow should easily be possible possible by setting = its MP_PRIO >>>>> to backup. >>>>>=20 >>>>> (c) How exactly to specify or implement the desired policy of only >>>>> establishing a subflow between the ACP addresses and the data = plane addresses >>>>> (but not full-mesh) seem to be a subject for further spec work. It = could >>>>> be defined as a specific in-MPTCP policy, or it could be done via = a shim >>>>> library (orthogonal to (a)). draft-hesmans-mptcp-socket might be = sufficient. >>>>>=20 >>>>> But in general: i would like for this (informational!) draft to = just motivate >>>>> the concept and not specify the solution: MPTCP would be a simple = way to >>>>> make "TCP" applications automatically "upgrade" from ACP to a = data-plane path >>>>> and switch back when data-plane fails... because MP-TCP can signal = the >>>>> additional data-plane addresses, establish transparently another = subflow and switch >>>>> traffic between the subflows - all by using the right = shim-library+API or >>>>> in-MP-TCP address/subflow policies - and the ability to establish = subflows >>>>> across two VRFs. >>>>>=20 >>>>> Cheers >>>>> Toerless >>>>>=20 >>>>> On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind (IETF) = wrote: >>>>>>>>> Suggested replacement text last two paragraphs of 2.1.5: >>>>>>> A (shim) library for aplications maps TCP connections to MPTCP = without the applications having to be aware of it. >>>>>> It???s not the (shim) library/policy framework that opens/maps = the TCP connection. MPTCP itself opens eventually multiple connections = but exposes only one connection to the layer above. That means = everything above MPTCP does not have any real control about which data = is send over which connection. >>>>>>=20 >>>>>> A policy shim layer could only implement rules about which new = subflows should be established when and what the priority is over which = subflow data should be sent but it generally does not control which data = is send of which flow. You can???t say I want this data to be sent over = subflow one and this data to be sent over sub flow two. >>>>>>=20 >>>>>> I think what you want is actually a view on the different TCP = connections and you try to use MPTCP only for announcing the other IP = address but that is not what MPTCP meant to be. >>>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>> Names in DNS use only the ACP IPv6 addresses of network devices. = Thererefore, the initial MPTCP subflow will use the ACP. After it is = operating, the shim libraries on both ends add their data-plane address = (MPTCP ADD_ADDR) and attempt to build a new subflow between those = addresses. If that (data plane) subflow is successfully built, the shim = libraries could shift all traffic over this subflow which should be = forwarded hardware accelerated by the network - and use the ACP subflow = across the ACP solely for signaling - beause it is most resilient = against failure. >>>>>>>=20 >>>>>>> This MPTCP approach is only an outline and would need to be = fully speficied for interoperable implementations. It may also require = extensions to MP-TCP. This mechanism must not be used without providing = for encryption of subflows not running across the ACP. >>>>>>>=20 >>>>>>>>> Brian: ... can not use capital MUST NOT in an information = draft (i think) >>>>>>>>>=20 >>>>>>> Cheers >>>>>>> Toerless >>>>>>>=20 >>>>>>> On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind = (IETF) wrote: >>>>>>>> Hi Micheal, >>>>>>>>=20 >>>>>>>> to clarify one part below: >>>>>>>>=20 >>>>>>>>> Am 05.01.2018 um 23:30 schrieb Michael Richardson = : >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Mirja K=C3=83=C2=BChlewind wrote: >>>>>>>>>> "DNS naming is set up to provide the ACP IPv6 address of = network >>>>>>>>>> devices. Unbeknownst to the application, MPTCP is used. = MPTCP >>>>>>>>>> mutually discovers between the NOC and network device the = data-plane >>>>>>>>>> address and caries all traffic across it when that MPTCP = subflow >>>>>>>>>> across the data-plane can be built." >>>>>>>>> Section 2.1.5 is discussion, it discusses ways in which the >>>>>>>>> anticipated low performance (compared to what the box might do = with its >>>>>>>>> hardware accelerated forwarding). >>>>>>>>>=20 >>>>>>>>> If we have an application that needs the bandwidth of the = native hardware, >>>>>>>>> the connection can be initated over the ACP (that's what would = be in DNS). >>>>>>>>> One presumes that an MPTCP layer could then enumerate the = available IPs at >>>>>>>>> each end and then start off additional flows on the other = destinations. >>>>>>>> MPTCP adda an additional TCP flow but for the application that = still looks like one flow. As I said I???m not sure if that is what you = want. >>>>>>>>=20 >>>>>>>> Mirja >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> The application would have to include application security, = since it would >>>>>>>>> not be protected by the ACP. >>>>>>>>>=20 >>>>>>>>> Perhaps MPTCP doesn't work this way. >>>>>>>>>=20 >>>>>>>>>> However, I'm actually uncertain how this is supposed to work = and what >>>>>>>>>> "Unbeknownst to the application" should mean. If another = address should be >>>>>>>>>> signaled to the other host, this needs to be indicated by the = application or at >>>>>>>>>> least some kind of policy framework above MPTCP. Also MPTCP = will by default use >>>>>>>>>> both paths simultaneously while still looking like one = connection to the >>>>>>>>>> application, meaning the application has no control which = path is used for >>>>>>>>>> which traffic. I guess you can open a second subflow and then = configure the >>>>>>>>>> first subflow as backup path but I'm not sure if that's what = you want (given >>>>>>>>>> the application/policy framework will still not know which = path is used)..? >>>>>>>>>> Please provide more information about what the expected usage = scenario is here. >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Michael Richardson , Sandelman Software = Works >>>>>>>>> -=3D IPv6 IoT consulting =3D- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Anima mailing list >>>>>>>> Anima@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>>> --=20 >>>>>>> --- >>>>>>> tte@cs.fau.de >>>=20 >>> --=20 >>> --- >>> tte@cs.fau.de From nobody Fri Jan 26 15:05:30 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E08212AF83; Fri, 26 Jan 2018 15:05:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151700792861.23624.8701650562541848987@ietfa.amsl.com> Date: Fri, 26 Jan 2018 15:05:28 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-stable-connectivity-09.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 23:05:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Using Autonomic Control Plane for Stable Connectivity of Network OAM Authors : Toerless Eckert Michael H. Behringer Filename : draft-ietf-anima-stable-connectivity-09.txt Pages : 25 Date : 2018-01-26 Abstract: OAM (Operations, Administration and Maintenance - as per BCP161, (RFC6291) processes for data networks are often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on, changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to aforementioned circular dependencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-stable-connectivity-09 https://datatracker.ietf.org/doc/html/draft-ietf-anima-stable-connectivity-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-stable-connectivity-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 26 15:07:06 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399F7127201; Fri, 26 Jan 2018 15:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZvgmkzMq0XJ; Fri, 26 Jan 2018 15:06:57 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7EB4129C6F; Fri, 26 Jan 2018 15:06:56 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2217A58C4BA; Sat, 27 Jan 2018 00:06:52 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 06A69B0D894; Sat, 27 Jan 2018 00:06:51 +0100 (CET) Date: Sat, 27 Jan 2018 00:06:51 +0100 From: Toerless Eckert To: "Mirja Kuehlewind (IETF)" Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-stable-connectivity@ietf.org, jiangsheng@huawei.com Message-ID: <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jan 2018 23:07:01 -0000 On Fri, Jan 26, 2018 at 11:43:08AM +0100, Mirja Kuehlewind (IETF) wrote: > Hi Toerless, > > sorry for my late reply but I spend only limited time on AD stuff on the telechat agenda was crowded this week. Thanks for all the hard work! > Okay that is fine. I mainly wanted to double-check as that was still not fully clear from the provided text. Can you maybe propose a slight rewording that explicitly say that there is this backup while using the word ???only??? above in the cited text seems to indicated differently. I wanted to take the full extend of your feedback into account, so rewrote the paragraph in question maybe a bit more than slightly (couldn't figure out a sane "slightly" ;-): - Moved up the last sentence about per-connection policy up front, so the examples are more logical scoped. - Made the examples into three separate bullet points and expanded them to hopefully eliminate the misunderstanding wrt to backup. - Not only mentioning the fall back (backup), but also added desirable behavior under recovery of preferred subflow path. (important for both 1) and 2). - explaining in bullet point 3) how this one is actually a simple TCP connection (As you pointed out). (whereas 1) and 2) rely on the MPTCP benefit of two subflows and address signaling). -09 uploaded with this fix as well as fix for Yohi's comment. Diff: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-09.txt Here is the changed paragraph: The above described behavior/policy for MPTCP must be controllable by applications or libraries acting on behalf of applications. APIs and/or data models for this control need to be defined. It should be sufficient to make these policies work on a per connection basis, and not change during the lifetime of a connection for different data items: 1) The policy for likely most connections would be to use the data-plane subflow and fall back using the ACP subflow when the data-plane fails. This could be the default. It reduces load on the ACP but would continue to run connection traffic at likely reduced throughput when the data-plane fails. Ideally such connections would also revert back to using a data-plane subflow once its connectivity recovers. 2) Connections for non-urgent bulk transers (for example most routine firmware updates or cached log collection) may use a policy where the connection is made to fail when the data-plane fails or have transfers suspend until another data-plane subflow can successfully be built. This avoids over-taxing the ACP when the data plane fails. 3) Connections for critical network configuration change operations known to impact the data-plane might want to only use the ACP and could therefore map to a (non-MP)TCP connection. Cheers Toerless m 22.01.2018 um 19:42 schrieb Toerless Eckert : > > > > > > Thanks, Mirja. Inline. > > > > On Mon, Jan 22, 2018 at 01:37:58PM +0100, Mirja Kuehlewind (IETF) wrote: > >> Hi Toerless, > >> > >> thanks a lot for the updated text. I still have one little point I would like to discuss a bit further on this text: > >> > >> "The above described behavior/policy for MPTCP must be controllable by > >> applications or libraries acting on behalf of applications. APIs > >> and/or data models for this control need to be defined. As outlined > >> above, applications for example may choose to only perform transfers > >> if the data-plane is actually available because of performance > >> limitations of the GACP, so the application needs to be made aware if > >> the setup of the data-plane subflow fails. Or transfers may want to > >> only use the GACP because the connection performs configuration > >> changes that are likely known to bring down the data-plane. It > >> should be sufficient to make these policies work on a per connection > >> basis, and not change during the lifetime of a connection for > >> different data items.??? > >> > >> > >> When you say that there is a need for an application to send data only on one path, today that???s not possible with MPTCP as you may fallback to the other path silently during the transmission. Yes, of course this could be changed and an extended interface could indicate this. > > > >> > >> So my question is still what the ???only??? really means in this text. If you???d like to just indicate a preference that might be okay. If you really want to rule out the possibility to fallback to the other path, then I don???t think you need MPTCP and two separate TCP connections would be the better option. > >> > >> Does that make sense to you? > > > > Not really, the goal is always to leverage existing MPTCP signaling of > > addresses, indicating backup for flows, etc. I think two TCP flows would > > never be better: > > Okay that is fine. I mainly wanted to double-check as that was still not fully clear from the provided text. Can you maybe propose a slight rewording that explicitly say that there is this backup while using the word ???only??? above in the cited text seems to indicated differently. > > Thanks! > > > > > The GACP address is the primary identifier of a device known in DNS. > > Data-Plane addresses can change over time subject to operator configuration > > and could also pose more of a security issue to be in DNS (GACP is isolated > > network). > > > > GACP performance may be quite low because some network device may route/forward > > it in software. data-plane routing/forwarding is expected to be fast/HW-accelerated. > > > > With MPTCP as suggested this gives for example: > > Initial subflow must use GACP because thats the only "known/stable address" in DNS > > Then MPTCP signaling is used to indicate mutually the data-plane addresses > > and make GACP subflow backup. > > Then you transfer lets say a few Gigabyte of data (e.g.: firmware update) which > > goes over data-plane. > > Then some uncorrelated error happens and data-plane fails. This particular app > > should then fail because it would just slow down to insufferable slow across > > GACP and would overload software forwarding in GACP. > > > > In another application connection, fallback to GACP subflow for data if dat-plane > > subflow fails is fine, but you would only prefer data-plane for performance. > > > > You could consider the GACP potential software only forwarding like a very high > > cost of using it while data-plane is free. > > > > If i would just use 2 * TCP instead of MPTCP i would have to reinvent a lot of > > MPTCP to get the address signaling etc. Right ? > > > > Cheers > > Toerless > >> > >> Mirja > >> > >> > >> > >>> Am 17.01.2018 um 03:36 schrieb Toerless Eckert : > >>> > >>> Mirja, Yoshifumi > >>> > >>> I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt > >>> > >>> I have reworked the MPTCP text based on your threads feedback with > >>> the intention to fix errors and have it answer the questions/concerns raised, > >>> but without otherwise changing the scope of it: > >>> > >>> - What are they key features making MPTCP interesting > >>> - How could it be used to solve the stable-connectivity issue > >>> - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK > >>> beyond the scope of this document > >>> - Describe the areas of specification work required > >>> - API/policy, control by apps > >>> - dealing with dual VRF addresses > >>> > >>> Please check diff in this URL (not complete diff of -08, just fix for your discuss/comment): > >>> > >>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt > >>> > >>> I hope this resolves your DISCUSS/comments. > >>> > >>> Note that the term ACP was changed in the doc to GACP based on resolving Alvaros discus. See: > >>> > >>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt > >>> > >>> Thank you > >>> Toerless > >>> > >>> On Thu, Jan 11, 2018 at 03:42:53PM +0100, Mirja K?hlewind wrote: > >>>> Hi Toerless, > >>>> > >>>> the point I'm wondering about is your point (b) below. Yes, you can > >>>> set the ACP subflow to backup but that would still mean that if the > >>>> other link fails, it would automatically switch over to the ACP > >>>> subflow (without exposing this to the upper layer). Is that what you > >>>> want? Because my understanding was rather that there are cases where > >>>> you'd probably would like to know over which link the OAM packets > >>>> where actually sent...? > >>>> > >>>> Mirja > >>>> > >>>> On 08.01.2018 22:06, Toerless Eckert wrote: > >>>>> Thanks, Mirja > >>>>> > >>>>> (a) If the systems socket API does not transparently make TCP sockets > >>>>> to use MPTCP, then you would want a shim library. According to > >>>>> draft-hesmans-mptcp-socket, this is be the case on Apple (iOS). > >>>>> > >>>>> (b) Making the ACP subflow not carry traffic after establishing the > >>>>> data plane subflow should easily be possible possible by setting its MP_PRIO > >>>>> to backup. > >>>>> > >>>>> (c) How exactly to specify or implement the desired policy of only > >>>>> establishing a subflow between the ACP addresses and the data plane addresses > >>>>> (but not full-mesh) seem to be a subject for further spec work. It could > >>>>> be defined as a specific in-MPTCP policy, or it could be done via a shim > >>>>> library (orthogonal to (a)). draft-hesmans-mptcp-socket might be sufficient. > >>>>> > >>>>> But in general: i would like for this (informational!) draft to just motivate > >>>>> the concept and not specify the solution: MPTCP would be a simple way to > >>>>> make "TCP" applications automatically "upgrade" from ACP to a data-plane path > >>>>> and switch back when data-plane fails... because MP-TCP can signal the > >>>>> additional data-plane addresses, establish transparently another subflow and switch > >>>>> traffic between the subflows - all by using the right shim-library+API or > >>>>> in-MP-TCP address/subflow policies - and the ability to establish subflows > >>>>> across two VRFs. > >>>>> > >>>>> Cheers > >>>>> Toerless > >>>>> > >>>>> On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind (IETF) wrote: > >>>>>>>>> Suggested replacement text last two paragraphs of 2.1.5: > >>>>>>> A (shim) library for aplications maps TCP connections to MPTCP without the applications having to be aware of it. > >>>>>> It???s not the (shim) library/policy framework that opens/maps the TCP connection. MPTCP itself opens eventually multiple connections but exposes only one connection to the layer above. That means everything above MPTCP does not have any real control about which data is send over which connection. > >>>>>> > >>>>>> A policy shim layer could only implement rules about which new subflows should be established when and what the priority is over which subflow data should be sent but it generally does not control which data is send of which flow. You can???t say I want this data to be sent over subflow one and this data to be sent over sub flow two. > >>>>>> > >>>>>> I think what you want is actually a view on the different TCP connections and you try to use MPTCP only for announcing the other IP address but that is not what MPTCP meant to be. > >>>>>> > >>>>>> Mirja > >>>>>> > >>>>>> > >>>>>>> Names in DNS use only the ACP IPv6 addresses of network devices. Thererefore, the initial MPTCP subflow will use the ACP. After it is operating, the shim libraries on both ends add their data-plane address (MPTCP ADD_ADDR) and attempt to build a new subflow between those addresses. If that (data plane) subflow is successfully built, the shim libraries could shift all traffic over this subflow which should be forwarded hardware accelerated by the network - and use the ACP subflow across the ACP solely for signaling - beause it is most resilient against failure. > >>>>>>> > >>>>>>> This MPTCP approach is only an outline and would need to be fully speficied for interoperable implementations. It may also require extensions to MP-TCP. This mechanism must not be used without providing for encryption of subflows not running across the ACP. > >>>>>>> > >>>>>>>>> Brian: ... can not use capital MUST NOT in an information draft (i think) > >>>>>>>>> > >>>>>>> Cheers > >>>>>>> Toerless > >>>>>>> > >>>>>>> On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind (IETF) wrote: > >>>>>>>> Hi Micheal, > >>>>>>>> > >>>>>>>> to clarify one part below: > >>>>>>>> > >>>>>>>>> Am 05.01.2018 um 23:30 schrieb Michael Richardson : > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Mirja Kühlewind wrote: > >>>>>>>>>> "DNS naming is set up to provide the ACP IPv6 address of network > >>>>>>>>>> devices. Unbeknownst to the application, MPTCP is used. MPTCP > >>>>>>>>>> mutually discovers between the NOC and network device the data-plane > >>>>>>>>>> address and caries all traffic across it when that MPTCP subflow > >>>>>>>>>> across the data-plane can be built." > >>>>>>>>> Section 2.1.5 is discussion, it discusses ways in which the > >>>>>>>>> anticipated low performance (compared to what the box might do with its > >>>>>>>>> hardware accelerated forwarding). > >>>>>>>>> > >>>>>>>>> If we have an application that needs the bandwidth of the native hardware, > >>>>>>>>> the connection can be initated over the ACP (that's what would be in DNS). > >>>>>>>>> One presumes that an MPTCP layer could then enumerate the available IPs at > >>>>>>>>> each end and then start off additional flows on the other destinations. > >>>>>>>> MPTCP adda an additional TCP flow but for the application that still looks like one flow. As I said I???m not sure if that is what you want. > >>>>>>>> > >>>>>>>> Mirja > >>>>>>>> > >>>>>>>> > >>>>>>>>> The application would have to include application security, since it would > >>>>>>>>> not be protected by the ACP. > >>>>>>>>> > >>>>>>>>> Perhaps MPTCP doesn't work this way. > >>>>>>>>> > >>>>>>>>>> However, I'm actually uncertain how this is supposed to work and what > >>>>>>>>>> "Unbeknownst to the application" should mean. If another address should be > >>>>>>>>>> signaled to the other host, this needs to be indicated by the application or at > >>>>>>>>>> least some kind of policy framework above MPTCP. Also MPTCP will by default use > >>>>>>>>>> both paths simultaneously while still looking like one connection to the > >>>>>>>>>> application, meaning the application has no control which path is used for > >>>>>>>>>> which traffic. I guess you can open a second subflow and then configure the > >>>>>>>>>> first subflow as backup path but I'm not sure if that's what you want (given > >>>>>>>>>> the application/policy framework will still not know which path is used)..? > >>>>>>>>>> Please provide more information about what the expected usage scenario is here. > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Michael Richardson , Sandelman Software Works > >>>>>>>>> -= IPv6 IoT consulting =- > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Anima mailing list > >>>>>>>> Anima@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>>>> -- > >>>>>>> --- > >>>>>>> tte@cs.fau.de > >>> > >>> -- > >>> --- > >>> tte@cs.fau.de -- --- tte@cs.fau.de From nobody Fri Jan 26 19:48:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACEA12D881 for ; Fri, 26 Jan 2018 19:48:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjQrxl-UQzdp for ; Fri, 26 Jan 2018 19:48:12 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441C712D7EF for ; Fri, 26 Jan 2018 19:48:12 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id z17so1390857pgc.4 for ; Fri, 26 Jan 2018 19:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:organization:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=mlc561FsZtG1OC+NM59/KXJxizMY5ClCTVq5/VoJyfQ=; b=cr3MFnjYT8pEmOHJQzCxl/fC7hWrCmE860GqtLio3ZMbQqDV1CBoJxtXD0dixmiCr2 3WN8VgzHN0zUyyrWhh4ojuVFlfVYV8B23IFhvJFpwLEyjpld7ayIYWftUrWn6qxhTokg ur+U9JBhilxGdUJRulF+dlKIbDMg3IAbM9aFWLPVGZ0dvKZv2waNTZrawjIbBsfqoiuT bsHLh/sjrsDJCWmvss+Jy7fCcI+5/aMTrNlFh0fOrRGAIiEbCPlFa3bGPKtQ4laHZR75 txzVZGNLLN1uLlhzjtbZhWAcB+JTNR6GsU4S2awakdwoJGxLuWDQ1XzZ877ilelaCdwy IZDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:organization:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=mlc561FsZtG1OC+NM59/KXJxizMY5ClCTVq5/VoJyfQ=; b=Kog/PiVVp6Tcu8gZrTEIRYfSpODBuNzXw0cguo/hXyQ+KSEwagfVFLTWQnS4fcop54 uvDbAeP8ruLdwof1Z1698ZMbAbxCmtcAf98Pvue5BwlAIi2ZBCJ3TFimX7Ag+ZCvIK3p G7Jpq64xOK3++Dt13LwWCR4wx3NTwz5Idekcu9/rHN3x8ybqwoflaNzMkPa2zgTWrSWa 4kfjhmWcLbR5IZz4hzFFlMD1k0DB3HLLf7yWSy0IHNw901bFoPsIdgtKXrEzsG7TwzeO irGfpa31Zdmg2mUaH9WvbwsFyKMJSG03oPc3hwk3JqDAdXgOjIEBCa6rAa+j2z7pj3E+ Vr0A== X-Gm-Message-State: AKwxytc0mTSnMDhcx4g+SzVIXP4KtmuKaBvaf620etFFrNf/UKQSF+rn hMVcXrX75nmXjHM+Uty9IZZCJg== X-Google-Smtp-Source: AH8x227YimElbnHINyCDnbHF9b8yxwWGCNGtr8WPAaaHO363fuQOlw6aCT+EbfHo/Bz885QadO4RZQ== X-Received: by 10.99.96.23 with SMTP id u23mr16209636pgb.199.1517024891574; Fri, 26 Jan 2018 19:48:11 -0800 (PST) Received: from ?IPv6:2406:e001:57b1:1:28cc:dc4c:9703:6781? ([2406:e001:57b1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q27sm28554509pfd.14.2018.01.26.19.48.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2018 19:48:10 -0800 (PST) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <968b5ef8-63e2-64cf-3cbf-bdf81e227c14@gmail.com> Date: Sat, 27 Jan 2018 16:48:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Looking for event loop expertise for ANIMA drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jan 2018 03:48:14 -0000 Hi, I'm looking for somebody interested in ANIMA who has experience coding with an event-loop system (e.g. GTK+ or libevent). For a couple of documents** we need to check concepts and develop examples using an event loop model, in parallel with the multi-threaded model described so far. Somebody willing to write text would be great. Writing code as well would be awesome :-). ** draft-ietf-anima-grasp-api, draft-carpenter-anima-asa-guidelines Regards Brian From nobody Mon Jan 29 01:05:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9845212D863 for ; Mon, 29 Jan 2018 01:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUaB8mejR6-i for ; Mon, 29 Jan 2018 01:05:03 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5AFF12D877 for ; Mon, 29 Jan 2018 01:03:10 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id 16so6251196wry.12 for ; Mon, 29 Jan 2018 01:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Hr7r6cEmbOe8TyFbh4YScHG+74psu2bObz2TaT5+n50=; b=euCvlajLJ8I71dZDhNjYfXhoYGT8gLuqoFxZRM+pf6WTz0xy6UBCW42qgHS/pJL0FC 8TByfq/V9Z4wqcOyxvddOghlZyb/97PCfzLMpmFR1HSqGGMqoANRa5hFmoEM8shonkjt Q0E2hARVHN5QfgAf7K5bL3qqdN7WBB761ioSAoe18NOKt23v+YSCHmUalCihGpcfoMCe zaOP3NTcWvK4gKm/Q8Oqc/EsZSDb8opND/3ectrDChIyRfi30bW+3grrdxzO3XmsgZvW JxsldOkI85qwmL96wW2zxYjgVtieqq2rGIvPDitMfWxhbvgfMF7zAagcT69B9ZW0/PYV ldNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Hr7r6cEmbOe8TyFbh4YScHG+74psu2bObz2TaT5+n50=; b=UYxxR99WvRwP9hfbo4bJ27VEU3cvFJI+Q5GFC9CR4pgkBJtwgaoB2PgtVGw79SqhQr v4Kury0Gofydb2QBFFexcK7Tg1EluHnToK38tUQoxsDPRxyUK3sTj7di1q5rJ5g+MNal KU49VnCOVo6mbdbFeKYbNxsz7g8uYlyXGQgiJrCOay7nfSCtqWPB4xOBGFYJHeoWYCvJ vrs3mUNDNpVEWhXYJ+PmjkWKX4ta+c3lrLU7owCB7kiciP7BWb+7wV7F/dqX+1fKYfOl PRa0h0Oam9/S3z9WwnqVtay+H/aZo8lGKuQ9vJqILLtlR4XLGZu+v28kLYtng5nRop5b SxgA== X-Gm-Message-State: AKwxytcyU+x3BfWLmHSlkSFD6LPoKUaZpZN51Owccwlk6WeUa/X/EKkl AJTYmj5crJvRxHvSQ5HcmPDjRHw/ X-Google-Smtp-Source: AH8x225yMoHLDJGm6CQu4NioyBc+XihMKmIwm+pXj29kXXM1XGU6SQMIXgaO5yXFbaCMLiVkZdYI6w== X-Received: by 10.223.182.65 with SMTP id i1mr19019462wre.92.1517216588799; Mon, 29 Jan 2018 01:03:08 -0800 (PST) Received: from [192.168.1.25] (ANice-652-1-122-10.w83-201.abo.wanadoo.fr. [83.201.145.10]) by smtp.gmail.com with ESMTPSA id s13sm6377129wrf.11.2018.01.29.01.03.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 01:03:08 -0800 (PST) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> <12959.1516300465@obiwan.sandelman.ca> Message-ID: <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> Date: Mon, 29 Jan 2018 10:03:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <12959.1516300465@obiwan.sandelman.ca> Content-Type: text/html; charset=utf-8 Content-Language: fr-classic Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jan 2018 09:05:06 -0000
OK, the time for the last call is over. I'll produce a -06 version, working through the following issues:

- Sheng's review from 18 Jan (Thanks Sheng)
- Michael's response to Sheng's mail.
- the author issue. I think I'll follow Brian's suggestion, listing me as editor and all other co-authors under contributors. At least I see no better way...

I think those are all the open comments I saw. Did I miss anything?

Michael


On 18/01/18 19:34, Michael Richardson wrote:
Sheng Jiang <jiangsheng@huawei.com> wrote:
    > Hi, authors of anima-reference-model,

{contributor speaking}

    > General issues:

    > 1. In section 3.1, it says "The Autonomic Control Plane (ACP) is the
    > summary of all interactions of the Autonomic Networking Infrastructure
    > with other nodes and services.

    > In my understanding, the ACP itself is mostly a "channel", although
    > some ANI functions (signaling, aggregated reporting etc.) are running
    > within the channel, they should be parallel with ACP function in the
    > architecture view.

I concur with you, I'm also confused by the word "summary"
While we think of the ACP as the channel on which control functions occur, I
can also see that more generically (at the Dilbert's boss' level), the ACP is
the channel + all the interactions.  Perhaps we need a new term.

    > 1) Do you see ACP as an individual function as I understood (mostly a
    > channel), or a summary of a suite of functions running inside the ACP?

I also think it's worth thinking of the ACP as being a very special ASA that
creates the secure channel.  Maybe that's too recursive for some people, but
I think that doing so will encourage us to design the right management
functions for the ACP itself.

    > 2) What functions are sub-functions of ACP, and what are in parallel
    > with ACP?

That's a good question.
(/me looks distantly and tries to change the subject :-)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-






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

From nobody Mon Jan 29 02:54:47 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7912DB71; Mon, 29 Jan 2018 02:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0xZw5vV8y4d; Mon, 29 Jan 2018 02:54:42 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9019512D84F; Mon, 29 Jan 2018 02:54:42 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 428DD91862B2; Mon, 29 Jan 2018 10:54:38 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 29 Jan 2018 10:54:39 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Mon, 29 Jan 2018 18:54:25 +0800 From: Sheng Jiang To: Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Result//WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 Thread-Index: AdOY7z+p0xFgNg2zQTKgu88cnEH8gg== Date: Mon, 29 Jan 2018 10:54:24 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B928181D0F5@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B928181D0F5NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Result//WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jan 2018 10:54:45 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B928181D0F5NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, We received no negative response to the WGLC on draft-ietf-anima-reference-= model-05 during the two-week WGLC and two weeks extension and we did receiv= e good reviews through the WG document stage, through the shepherd review p= rocess and WGLC period. Considering the past history of this work, I, with = my ANIMA chair cap on, feel it has passed the WGLC and should advance. This= conclusion is made with the condition that the authors would solve the com= ments received during the WGLC and these modifications were not substantial= changes from -05 version. If there are big changes, a shorter second WGLC = may be needed. Up to now, there is no IPR disclosure to this document. Once the update is published and it meets the above condition, for which th= e second WGLC is not needed, as the document shepherd, I will finalize the = shepherd document and send the document on. Best regards, Sheng (co-chair, Toerless who as a co-author stayed neutral on the content = side) From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Tuesday, January 09, 2018 2:26 PM To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by J= anuary 22nd, 2018 Hi all, This message starts the two-week ANIMA Working Group Last Call to advance d= raft-ietf-anima-reference-model-05, A Reference Model for Autonomic Network= ing. This document's intended status is Informational. At present, there is= no IPR file against this document. Please send your comments by January 22nd, 2018. If you do not feel this do= cument should advance, please state your reasons why. Sheng JIANG is the assigned document shepherd. Regards, Sheng (co-chair, Toerless who as a co-author stayed neutral on the content = side) --_000_5D36713D8A4E7348A7E10DF7437A4B928181D0F5NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all, 

We received no negative response to the WGLC on dra= ft-ietf-anima-reference-model-05 during the two-week WGLC and two weeks ext= ension and we did receive good reviews through the WG document stage, through the shepherd review process and WGLC period= . Considering the past history of this work, I, with my ANIMA chair cap on,= feel it has passed the WGLC and should advance. This conclusion is made wi= th the condition that the authors would solve the comments received during the WGLC and these modifications = were not substantial changes from -05 version. If there are big changes, a = shorter second WGLC may be needed. 

Up to now, there is no IPR disclosure to this docum= ent.=

Once the update is published and it meets the above= condition, for which the second WGLC is not needed, as the document shephe= rd, I will finalize the shepherd document and send the document on.

Best regards,

Sheng (co-chair, Toerless who as a co-author stayed= neutral on the content side)

&n= bsp;

From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang
Sent: Tuesday, January 09, 2018 2:26 PM
To: anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respo= nd by January 22nd, 2018

 

Hi all,=

 <= o:p>

This message starts the two-week ANIMA Working Group Last Call to a= dvance draft-ietf-anima-reference-model-05, A Reference Model for Autonomic= Networking. This document's intended status is Informational. At present, there is no IPR file against this doc= ument.

 <= o:p>

Please send your comments by January 22nd, 2018. If you do not feel= this document should advance, please state your reasons why.

 <= o:p>

Sheng JIANG is the assigned document shepherd.

 <= o:p>

Regards,

 

Sheng (co-chair, Toerless who as a co-author stayed neutral on the = content side)

 

--_000_5D36713D8A4E7348A7E10DF7437A4B928181D0F5NKGEML515MBXchi_-- From nobody Mon Jan 29 10:58:37 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB8E12FAB3 for ; Mon, 29 Jan 2018 10:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fftRFcemUga3 for ; Mon, 29 Jan 2018 10:58:33 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9121243FE for ; Mon, 29 Jan 2018 10:58:33 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id c6so6185610pfi.8 for ; Mon, 29 Jan 2018 10:58:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Jk8hOZVQoRqD4csERNT3NHTREAp3xSUAq/j8qXeFAUI=; b=b888PIWL5qzcw7SMUhD0f6DFHlREhXgshx9lphW8Y4EZICJcX6fdsb+WRyzpGg925Z jOKKWgtR/BzZWVFZg/lIcqaX0SAArCLrPrsCYcQ1kCv/IFmx1FQ9TGwgD3sy66oLwnVS hj6vSFTGO3gONjbP9eeNXxNiA0j3LZsCpJqt6ZlGNZrttfuOGevt1UTeyu2x81en0eOV sp670DeTkkunnNBCqIIxU7oO2o3Z192bE8c/ykCwNbznyKy2KVdWdSwd7/zLm7HfAFzC MXn2acYPDB6VXZFrn3v4i/GzW6F/HLLDbM3XsRQXryvJt8/x53Aoo5PwL8t8ir649ATJ E9sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Jk8hOZVQoRqD4csERNT3NHTREAp3xSUAq/j8qXeFAUI=; b=rvxSZgHfwKqdrAf5nTwJck7XZULEFBqM27MZWrOJUOMhZ6PuW/M9Ye68xFxAr6v1Dt cVNKXr8cCSdKWdrHD+x3eVxu9ljCmfd9NpTTKNGLjkAm/QaGxKRlnvNxdXwASzNDtsqd uKbNJmlsp5dmE2x7wVJuQPUhuxzMoscwPbB483Mcw+04guYH3OtOZrEzvZzvXsEJopEX 8jgmHZ+VX/3iRJrCMsXrhItid2x0OD6gHW+ld0Ueo8zLAuzATE+ld/zHYpkMKn/giHSj cHg2HQk7Yd87E898x1vMyF2A0hyVi0TNVXTONNo/eJ3kY3JMUTOrJ2deZHBLDw9iozOv ZudA== X-Gm-Message-State: AKwxyteZnDYwsxHT39YIMUrIU9xAHVfYnID6gOJSJcMwEpdbPDB4Z5Hb L0Ul58Cgz9wxOiorSV73lDHCmA== X-Google-Smtp-Source: AH8x225MbHTltcwmQ3EibP94Hrqq7rv1NS7uqVi8BXojsT7u/bjOw2ij7sVAgplXMOtmHlc0Cv+Fmw== X-Received: by 10.98.233.10 with SMTP id j10mr27305808pfh.123.1517252312250; Mon, 29 Jan 2018 10:58:32 -0800 (PST) Received: from ?IPv6:2406:e001:3ff5:1:28cc:dc4c:9703:6781? ([2406:e001:3ff5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h11sm18229337pgq.91.2018.01.29.10.58.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 10:58:30 -0800 (PST) To: "Michael H. Behringer" , anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> <12959.1516300465@obiwan.sandelman.ca> <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6611b5f4-0690-e6bb-cb54-6faf3f9d0ac2@gmail.com> Date: Tue, 30 Jan 2018 07:58:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jan 2018 18:58:35 -0000 Michael, Sounds good to me. One minor point is whether to mention the distinction between *the* ACP and the abstract Generic ACP that Toerless introduced: https://mailarchive.ietf.org/arch/msg/anima/2hxcRbAWu-dkGCQQu9UFvcmF6LM In section we have this sentence: "The Autonomic Control Plane (ACP) is the summary of all interactions of the Autonomic Networking Infrastructure with other nodes and services." That's actually a rather strange sentence. How about this instead: "The Autonomic Control Plane (ACP) is a secure substrate used for all interactions of the Autonomic Networking Infrastructure with other autonomic nodes and services. It is a generic concept but a specific implementation is described in [I-D.ietf-anima-autonomic-control-plane]." Regards Brian On 29/01/2018 22:03, Michael H. Behringer wrote: > OK, the time for the last call is over. I'll produce a -06 version, working > through the following issues: > > - Sheng's review from 18 Jan (Thanks Sheng) > - Michael's response to Sheng's mail. > - the author issue. I think I'll follow Brian's suggestion, listing me as editor > and all other co-authors under contributors. At least I see no better way... > > I think those are all the open comments I saw. Did I miss anything? > > Michael > > > On 18/01/18 19:34, Michael Richardson wrote: >> Sheng Jiang wrote: >> > Hi, authors of anima-reference-model, >> >> {contributor speaking} >> >> > General issues: >> >> > 1. In section 3.1, it says "The Autonomic Control Plane (ACP) is the >> > summary of all interactions of the Autonomic Networking Infrastructure >> > with other nodes and services. >> >> > In my understanding, the ACP itself is mostly a "channel", although >> > some ANI functions (signaling, aggregated reporting etc.) are running >> > within the channel, they should be parallel with ACP function in the >> > architecture view. >> >> I concur with you, I'm also confused by the word "summary" >> While we think of the ACP as the channel on which control functions occur, I >> can also see that more generically (at the Dilbert's boss' level), the ACP is >> the channel + all the interactions. Perhaps we need a new term. >> >> > 1) Do you see ACP as an individual function as I understood (mostly a >> > channel), or a summary of a suite of functions running inside the ACP? >> >> I also think it's worth thinking of the ACP as being a very special ASA that >> creates the secure channel. Maybe that's too recursive for some people, but >> I think that doing so will encourage us to design the right management >> functions for the ACP itself. >> >> > 2) What functions are sub-functions of ACP, and what are in parallel >> > with ACP? >> >> That's a good question. >> (/me looks distantly and tries to change the subject :-) >> >> -- >> Michael Richardson, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jan 29 12:01:27 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DD113195A for ; Mon, 29 Jan 2018 12:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED2SvKeQlGBn for ; Mon, 29 Jan 2018 12:01:23 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FAB1319E7 for ; Mon, 29 Jan 2018 12:00:33 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5368058C500; Mon, 29 Jan 2018 21:00:28 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3BEEFB0D8D1; Mon, 29 Jan 2018 21:00:28 +0100 (CET) Date: Mon, 29 Jan 2018 21:00:28 +0100 From: Toerless Eckert To: "Michael H. Behringer" Cc: anima@ietf.org Message-ID: <20180129200028.GB13751@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> <12959.1516300465@obiwan.sandelman.ca> <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jan 2018 20:01:26 -0000 If its ok. with the other contributors, i would appreciate if i could be listed as well as an editor. Thank you Toerless On Mon, Jan 29, 2018 at 10:03:07AM +0100, Michael H. Behringer wrote: > > > > > >
OK, the time for the last call is over. > I'll produce a -06 version, working through the following issues: >
>
> - Sheng's review from 18 Jan (Thanks Sheng)
> - Michael's response to Sheng's mail.
> - the author issue. I think I'll follow Brian's suggestion, > listing me as editor and all other co-authors under contributors. > At least I see no better way...
>
> I think those are all the open comments I saw. Did I miss > anything?
>
> Michael
>
>
> On 18/01/18 19:34, Michael Richardson wrote:
>
>
cite="mid:12959.1516300465@obiwan.sandelman.ca"> > 
> Sheng Jiang <jiangsheng@huawei.com> wrote:
>     > Hi, authors of anima-reference-model,
> 
> {contributor speaking}
> 
>     > General issues:
> 
>     > 1. In section 3.1, it says "The Autonomic Control Plane (ACP) is the
>     > summary of all interactions of the Autonomic Networking Infrastructure
>     > with other nodes and services.
> 
>     > In my understanding, the ACP itself is mostly a "channel", although
>     > some ANI functions (signaling, aggregated reporting etc.) are running
>     > within the channel, they should be parallel with ACP function in the
>     > architecture view.
> 
> I concur with you, I'm also confused by the word "summary"
> While we think of the ACP as the channel on which control functions occur, I
> can also see that more generically (at the Dilbert's boss' level), the ACP is
> the channel + all the interactions.  Perhaps we need a new term.
> 
>     > 1) Do you see ACP as an individual function as I understood (mostly a
>     > channel), or a summary of a suite of functions running inside the ACP?
> 
> I also think it's worth thinking of the ACP as being a very special ASA that
> creates the secure channel.  Maybe that's too recursive for some people, but
> I think that doing so will encourage us to design the right management
> functions for the ACP itself.
> 
>     > 2) What functions are sub-functions of ACP, and what are in parallel
>     > with ACP?
> 
> That's a good question.
> (/me looks distantly and tries to change the subject :-)
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
>
>
>
>
> 
_______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
>
>
> > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Jan 29 13:25:01 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78B3130A93 for ; Mon, 29 Jan 2018 13:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCbNzzNm_n5p for ; Mon, 29 Jan 2018 13:24:57 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C2D12FB63 for ; Mon, 29 Jan 2018 13:24:57 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id e76so6579457pfk.1 for ; Mon, 29 Jan 2018 13:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YAOsqsU58K/MY7hCjXHKHhKX8meEJLxLEOJciPz0iEw=; b=GOATGLnREsEcKFZvPWnoNghb6tdj8Kju0XN5AkefAesiGIYxjdCTeNfEuAvKzL1q49 YJmstMqQoiWGsuGQjhXs9nQH2QqtqW/Z4LjhqzGHWlORr+jqxplssxh12iX3tNc1BphD RYiEyTHZWJZIKJ10876+Q6vhio7f+2IXPZFCXaqy7xug8M6RUhUXhPGKG4i/82iiyyY9 ZLnlkWM7OuJVHVIrrZvBlR5h7AxS666j2pbaBBQeXQbcSNhO9aDzdG9cDOidi2pq5BM7 dBe/XGPJG+UD0agQzT9zEMjioHnLfdMzNu8lAhq658hLlbCu/GoKpYojo5VsWmdUw2Xp clOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YAOsqsU58K/MY7hCjXHKHhKX8meEJLxLEOJciPz0iEw=; b=KbocEIzrs5cYaPJl+Zpqza/FkPWSqYI8bP9Y/44Su6g5jobshpTqatwlsiMJhrQxfW abmPWYyT8xBQiqC0C+TMQgFmxYghlK0wTC3WmT6o2lGA1UK1fo5AlyWmH8qiPGULrHbE W0VHsg9r2PS2Kixwt4GobaiGK9lP1vwv23HS0n1EbKrXiRwjNS+hVHerARR7FBcpxgqv dKBhM8sMgfPcGBt69m0I/wJDzyOG/gPkeiiFVY79z2bjkMHBULV2/UfARgTAEr2Qq3Le SrRDC6T+Ziuoo0xOm27RvDA+FuW1if7FLDb8oiLyG+r0pY+CLcBNKe1Ai4UUYL7TxfZB wZeA== X-Gm-Message-State: AKwxyte36K3n2Y3uRAct6dCafbRIZX3web+LybN90LRL9h6X4/1t6cEa 0Jh39FiQ+UNk9f11lPeH1LYIEA== X-Google-Smtp-Source: AH8x227o5I5Ch9XPjYLTvnLk3LeBxs0+DSh+CPx+w3hkNVBIOXLpuMlAG04JaIrxHgH0lYTu1Ds+4w== X-Received: by 10.101.85.138 with SMTP id j10mr5516708pgs.144.1517261097107; Mon, 29 Jan 2018 13:24:57 -0800 (PST) Received: from [130.216.38.84] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.84]) by smtp.gmail.com with ESMTPSA id c184sm33996829pfg.57.2018.01.29.13.24.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 13:24:56 -0800 (PST) To: Toerless Eckert , "Michael H. Behringer" Cc: anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> <12959.1516300465@obiwan.sandelman.ca> <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> <20180129200028.GB13751@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3316958c-aff7-8b03-8869-f6d62514fc2c@gmail.com> Date: Tue, 30 Jan 2018 10:24:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180129200028.GB13751@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jan 2018 21:25:00 -0000 On 30/01/2018 09:00, Toerless Eckert wrote: > If its ok. with the other contributors, > i would appreciate if i could be listed as well as an editor. It's always a judgment call. Who's done most of the editing? Certainly Michael Behringer. (See https://github.com/mbehring/ANIMA-Reference-Model/commits/master) My view of this tricky topic: https://tools.ietf.org/html/draft-carpenter-whats-an-author Brian From nobody Mon Jan 29 17:59:28 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC1E130134; Mon, 29 Jan 2018 17:59:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sheng Jiang To: X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Cc: anima-chairs@ietf.org, iesg-secretary@ietf.org, Sheng Jiang , anima@ietf.org, jiangsheng@huawei.com Message-ID: <151727756643.27308.5687636419202240227.idtracker@ietfa.amsl.com> Date: Mon, 29 Jan 2018 17:59:26 -0800 Archived-At: Subject: [Anima] Publication has been requested for draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 01:59:26 -0000 Sheng Jiang has requested publication of draft-ietf-anima-autonomic-control-plane-13 as Proposed Standard on behalf of the ANIMA working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ From nobody Tue Jan 30 11:15:57 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912E21242EA; Tue, 30 Jan 2018 11:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBaBpTlwbLqf; Tue, 30 Jan 2018 11:15:53 -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 76FA3129966; Tue, 30 Jan 2018 11:15:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BC29C20092; Tue, 30 Jan 2018 14:21:36 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7100380243; Tue, 30 Jan 2018 14:15:30 -0500 (EST) From: Michael Richardson To: anima@ietf.org cc: hackathon In-Reply-To: <5b88246f-6625-8e66-d638-9c815950f220@gmail.com> References: <9599d40a-230a-e07e-6835-6d25599e0daf@gmail.com> <500.1503098557@obiwan.sandelman.ca> <69aab3db-1857-b115-6d23-ac47aeee6fb1@gmail.com> <23147.1504661338@obiwan.sandelman.ca> <5b88246f-6625-8e66-d638-9c815950f220@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] hackathon for ANIMA at IETF101 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jan 2018 19:15:55 -0000 --=-=-= Content-Type: text/plain I have added ANIMA to the Hackathon page at: https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon I believe that we will have Bill Atwood and Brian Carpenter "remote" as well, although I don't know they will be sufficiently caffeinated :-) I am hoping that we will have some libest people remote as well. I wrote: ANIMA voucher and ACP Champion(s) Michael Richardson Project(s) use of the ANIMA BRSKI for enrollment of devices into a PKI use of IPsec and RPL to construct the ANIMA ACP overlay between devices ACP construction can include people who are remote! I hope that we will have an opportunity to exchange some vouchers and validate if the examples are correct. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpwxFIACgkQgItw+93Q 3WVXDAf+IPXT+Z1qZjhBIrhJy2xt/02R02fbvtCraz4U9GptJZyPDY+qP/dSlC1h MjtgZbAtsIkc9YsdBKZ4GICt3Cd/Qq0Q+Eai8kBKwdjIUpCaAdZuhgdoGy8Y3AcH JiXdw6ESj9Om1HfauyV1m74EvagIJMX4E+zZiC9WWYsWFzJ5hVj+HczIDqavWrr2 x3jclxftIUDqGw6ipXahviIM42CV2C0YLiXxF1Uj0DkjDYRXydF9SybUEh+7p7yv Qj90Jni/+xifHtUiLANeEaYZxkqOIaU0qjKvHuK+KyUqOrB4PVJacEUJWoGkRFwu KW0zi3cibFHQworP627Q0VusBOx+bQ== =r40h -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 30 16:29:37 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6796712DFDB for ; Tue, 30 Jan 2018 16:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S-Tx3xGxxDH for ; Tue, 30 Jan 2018 16:29:32 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3181200E5 for ; Tue, 30 Jan 2018 16:29:32 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9869F58C564; Wed, 31 Jan 2018 01:29:27 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7D7BEB0D8FB; Wed, 31 Jan 2018 01:29:27 +0100 (CET) Date: Wed, 31 Jan 2018 01:29:27 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: "Michael H. Behringer" , anima@ietf.org Message-ID: <20180131002927.GA2019@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> <12959.1516300465@obiwan.sandelman.ca> <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> <20180129200028.GB13751@faui40p.informatik.uni-erlangen.de> <3316958c-aff7-8b03-8869-f6d62514fc2c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3316958c-aff7-8b03-8869-f6d62514fc2c@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jan 2018 00:29:35 -0000 Brian: The commits do not show all contributions to text. I often provided text in email to michael to merge in the past when i didn't want to bother about github. But i am not insisting on editor status, but as indicated only author status, and for that the question of direct editing on github is irrelevant. I suggest we move everyone who explicitly wants to be listed as contributor into that section, otherwise we keep the list of authors (including Michael as only editor) as it is right now and we will see what happens during IESG review. There are also new RFCs coming out with 8 authors, eg: rfc8321. Cheers Toerless On Tue, Jan 30, 2018 at 10:24:54AM +1300, Brian E Carpenter wrote: > On 30/01/2018 09:00, Toerless Eckert wrote: > > If its ok. with the other contributors, > > i would appreciate if i could be listed as well as an editor. > > It's always a judgment call. Who's done most of the editing? > Certainly Michael Behringer. > (See https://github.com/mbehring/ANIMA-Reference-Model/commits/master) > > My view of this tricky topic: > https://tools.ietf.org/html/draft-carpenter-whats-an-author > > Brian From nobody Tue Jan 30 18:09:25 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCEF131911 for ; Tue, 30 Jan 2018 18:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y27vEkvLLvQA for ; Tue, 30 Jan 2018 18:09:22 -0800 (PST) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB061318FC for ; Tue, 30 Jan 2018 18:09:11 -0800 (PST) Received: by mail-lf0-f50.google.com with SMTP id g72so18304961lfg.5 for ; Tue, 30 Jan 2018 18:09:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b74FgZuCj+1E7RYI6aQ1eFEVt+nVJcnPGVyN6K3fP1w=; b=Gki2Wyv2ttMgXECjYtySHkSkkKWZNYvKoPPeM+86ZD5Fj/Rs4aykjVz1ZyaoiUOEDh DckNPTgHpbYgE29IY76glZiLhPMLSypN4uAoSOd7AYgIg6UU3itYVFt5UR7YshUFgafy 2ITel9HuXBJfLi895LfpPaTY77F60S1EEgsPxAjQJEecIDHGGvl7oispyF/Y9ILMtc55 5DTqwMucaKa7YKVAkWehYGFvHeI/CPL4C+Qg6+144C4g/cXlActbwoD5CyAU4D3i/cv8 CQajUNUFvbKME2LtdR16bzuXnG190SS6s2tLGSsLu8Pjimn6xQAoBeFNg0MCsKXKTELt lRZQ== X-Gm-Message-State: AKwxytcfAIWE6I7MDBkAF0f46/xVF7ubjUc0PhPLKs0ygPdGyDAA3YoI qDFC8eRXwEOX3i3TBzsoDVp7NmeOu0WoYKgCVw== X-Google-Smtp-Source: AH8x226qLaGt5SnIbYp6Ov7tcYCu82Pk+tCbRyZ8gSqH4n0W08cg7RepZxCshC0kbjKfcx73S/ILzByJ0PCQqTQtaqg= X-Received: by 10.46.1.132 with SMTP id f4mr17966716lji.116.1517364549085; Tue, 30 Jan 2018 18:09:09 -0800 (PST) MIME-Version: 1.0 References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> <12959.1516300465@obiwan.sandelman.ca> <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> <20180129200028.GB13751@faui40p.informatik.uni-erlangen.de> <3316958c-aff7-8b03-8869-f6d62514fc2c@gmail.com> <20180131002927.GA2019@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180131002927.GA2019@faui40p.informatik.uni-erlangen.de> From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Wed, 31 Jan 2018 02:08:58 +0000 Message-ID: To: Toerless Eckert Cc: Brian E Carpenter , anima@ietf.org, "Michael H. Behringer" Content-Type: multipart/alternative; boundary="001a1142b5d6f16ff5056408f601" Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jan 2018 02:09:24 -0000 --001a1142b5d6f16ff5056408f601 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All. It seems that we have the same "author information" as RFC 8321. I had understood reading a previous email that this was not possible. Thus, I suggest to maintain our current configuration (Michael as Editor and everybody else as authors) and wait for the IESG review. Best. J=C3=A9ferson Em ter, 30 de jan de 2018 =C3=A0s 22:29, Toerless Eckert escreveu: > Brian: > > The commits do not show all contributions to text. > I often provided text in email to michael to merge in the past > when i didn't want to bother about github. But i am not insisting > on editor status, but as indicated only author status, and > for that the question of direct editing on github is irrelevant. > > I suggest we move everyone who explicitly wants to be > listed as contributor into that section, otherwise we keep > the list of authors (including Michael as only > editor) as it is right now and we will see what happens during > IESG review. > > There are also new RFCs coming out with 8 authors, eg: rfc8321. > > Cheers > Toerless > > On Tue, Jan 30, 2018 at 10:24:54AM +1300, Brian E Carpenter wrote: > > On 30/01/2018 09:00, Toerless Eckert wrote: > > > If its ok. with the other contributors, > > > i would appreciate if i could be listed as well as an editor. > > > > It's always a judgment call. Who's done most of the editing? > > Certainly Michael Behringer. > > (See https://github.com/mbehring/ANIMA-Reference-Model/commits/master) > > > > My view of this tricky topic: > > https://tools.ietf.org/html/draft-carpenter-whats-an-author > > > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --001a1142b5d6f16ff5056408f601 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All.
It seems that we have the same "author = information" as RFC 8321. I had understood reading a previous email th= at this was not possible.
Thus, I suggest to maintain our current= configuration (Michael as Editor and everybody else as authors) and wait f= or the IESG review.
Best.
J=C3=A9ferson

Em ter, 30 de jan de 2018 =C3=A0s 22:29= , Toerless Eckert <tte@cs.fau.de>= ; escreveu:
Brian:

The commits do not show all contributions to text.
I often provided text in email to michael to merge in the past
when i didn't want to bother about github.=C2=A0 But i am not insisting=
on editor status, but as indicated only author status, and
for that the question of direct editing on github is irrelevant.

I suggest we move everyone who explicitly wants to be
listed as contributor into that section, otherwise we keep
the list of authors (including Michael as only
editor) as it is right now and we will see what happens during
IESG review.

There are also new RFCs coming out with 8 authors, eg: rfc8321.

Cheers
=C2=A0 =C2=A0 Toerless

On Tue, Jan 30, 2018 at 10:24:54AM +1300, Brian E Carpenter wrote:
> On 30/01/2018 09:00, Toerless Eckert wrote:
> > If its ok. with the other contributors,
> > i would appreciate if i could be listed as well as an editor.
>
> It's always a judgment call. Who's done most of the editing? > Certainly Michael Behringer.
> (See https://github.com/mbehrin= g/ANIMA-Reference-Model/commits/master)
>
> My view of this tricky topic:
> https://tools.ietf.org/html/draft-ca= rpenter-whats-an-author
>
>=C2=A0 =C2=A0 Brian

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--001a1142b5d6f16ff5056408f601-- From nobody Tue Jan 30 19:13:35 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5784131921 for ; Tue, 30 Jan 2018 19:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFBInMuyrdYh for ; Tue, 30 Jan 2018 19:13:32 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A87E131912 for ; Tue, 30 Jan 2018 19:13:32 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id a88so11180374pfe.12 for ; Tue, 30 Jan 2018 19:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ddtS4bdwz+vGCDWksrM9P7YKOvv1E6QIgQzUvTUbwJk=; b=AdLuKVNSC2S+y6FXiEeDyv6taMqdZERkwp/1of+frv7pPip6Y0VaWrEVzFM9WbEY+1 NKa8NxRWcbQOrWDMTkm8J0hFDjtjcGLyojX7muVjRSmtA0iK15gOPy9aRd4Ftdtvfcu1 w/ziLiXWsozm8ScIG5yOFe3jfWE8SSWa1DCJ29H1dY7RHcZSVZrDn3geMobyUuVz5YQ8 Nl22YJbhQYxgETz5K3eEmBEz0agbwqx29BxvIGIstt7/qKenzsF50QdZs7z2ErX/DqzN l1MO6+Y0Xj9Bp654yJt37B9bXDwKGhoaunyb4wrm2/8lp4daePtCiPK+lOLgJfW24xW2 Zudg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ddtS4bdwz+vGCDWksrM9P7YKOvv1E6QIgQzUvTUbwJk=; b=IQQ+wnJGHRjnITU8ghC6ohyo/aHvYmhwCZ8raa2WTYtJ6c5aXX81Cj3quqGOvgnce7 GM/Jnnw6s8BezhWH9PSbJzBaer67gX+IQPWUPv8hb3hOSx0YkeYaYPwqYvdwHeIbGstY h7Rz0pc9eQNwnl6gzLf6QO1WF3VGx0GFd+f4+2qyMwdUmb9399/an3U5a/Z50CypuObA UL16FLPznA0zJ6GqeiBY/HRCbx7SbQ5r4pGKphnNalU+QEse9sZpDpFqajHtvlraU6zW WFYxHmR43OD+xWUt+BMyu9KfxCBSMikPVqXWmNKMGNamRPsr2GbiypOrTi0tWT6tpPPM Zrcg== X-Gm-Message-State: AKwxytdjjgSAry3qtc39rpDXBK2e3Pj6AFGYr6kXoeLXap3nmyIrtsfF r6dc3NqMDcPet0fyEn32kk0= X-Google-Smtp-Source: AH8x226gSlnbxoXtTZruxCBhL9yg6l2TsCbjF469gr9ysp67XvCL3+IPpFH9ipJIlaSA1aG8e5OEBA== X-Received: by 2002:a17:902:2843:: with SMTP id e61-v6mr25233922plb.260.1517368411742; Tue, 30 Jan 2018 19:13:31 -0800 (PST) Received: from ?IPv6:2406:e001:3ff5:1:28cc:dc4c:9703:6781? ([2406:e001:3ff5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s3sm21267523pgq.0.2018.01.30.19.13.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 19:13:30 -0800 (PST) To: =?UTF-8?Q?J=c3=a9ferson_Campos_Nobre?= , Toerless Eckert Cc: anima@ietf.org, "Michael H. Behringer" References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> <12959.1516300465@obiwan.sandelman.ca> <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> <20180129200028.GB13751@faui40p.informatik.uni-erlangen.de> <3316958c-aff7-8b03-8869-f6d62514fc2c@gmail.com> <20180131002927.GA2019@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <45313dc9-b8da-7d33-a8ee-c388fdde0f4e@gmail.com> Date: Wed, 31 Jan 2018 16:13:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jan 2018 03:13:35 -0000 I don't know the background to RFC8321. I do know that we'll spend a lot of time on this issue if it goes forward with more than 5 authors. Been there, done that, don't want to do it again... Regards Brian On 31/01/2018 15:08, J=C3=A9ferson Campos Nobre wrote: > Dear All. > It seems that we have the same "author information" as RFC 8321. I had > understood reading a previous email that this was not possible. > Thus, I suggest to maintain our current configuration (Michael as Edito= r > and everybody else as authors) and wait for the IESG review. > Best. > J=C3=A9ferson >=20 > Em ter, 30 de jan de 2018 =C3=A0s 22:29, Toerless Eckert > escreveu: >=20 >> Brian: >> >> The commits do not show all contributions to text. >> I often provided text in email to michael to merge in the past >> when i didn't want to bother about github. But i am not insisting >> on editor status, but as indicated only author status, and >> for that the question of direct editing on github is irrelevant. >> >> I suggest we move everyone who explicitly wants to be >> listed as contributor into that section, otherwise we keep >> the list of authors (including Michael as only >> editor) as it is right now and we will see what happens during >> IESG review. >> >> There are also new RFCs coming out with 8 authors, eg: rfc8321. >> >> Cheers >> Toerless >> >> On Tue, Jan 30, 2018 at 10:24:54AM +1300, Brian E Carpenter wrote: >>> On 30/01/2018 09:00, Toerless Eckert wrote: >>>> If its ok. with the other contributors, >>>> i would appreciate if i could be listed as well as an editor. >>> >>> It's always a judgment call. Who's done most of the editing? >>> Certainly Michael Behringer. >>> (See https://github.com/mbehring/ANIMA-Reference-Model/commits/master= ) >>> >>> My view of this tricky topic: >>> https://tools.ietf.org/html/draft-carpenter-whats-an-author >>> >>> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >=20 From nobody Wed Jan 31 09:22:32 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C3C12DA4A; Wed, 31 Jan 2018 09:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umYN8KYHXZsJ; Wed, 31 Jan 2018 09:22:29 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5C212D869; Wed, 31 Jan 2018 09:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1878; q=dns/txt; s=iport; t=1517419349; x=1518628949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hQtMbXgg8gz9Ci8ZrClAO/QRQ0+hxvCuH6Y2Uwzbc74=; b=h6suiTE17UI0GZwsTB4yVElYXj1PwP/ac9tlYa4ELfNi+YkSJQSfJj+1 N48+5B3DYXCn85VcoLUhR2L2cYt4HdmJ290F3eLYY/kzhn0INz/Uy+ZVD aG5+yA8VNZ+8JrS30G2t33/l9B2oteJcYPdsdbc9W6VcRL+Txy4WimyLA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAACw+nFa/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMRMWZ1KAqDVookjiqBWyeXRoIXCiOBXoM6AhqCNVQYAQEBAQE?= =?us-ascii?q?BAQECayiFIwEBAQQjEUUMBAIBCBEDAQIDAiYCAgIwFQgIAgQBDQWKNRCnMIIni?= =?us-ascii?q?mIBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPg0yCFYNoDIJDNoFJgWYCAoFvgxc?= =?us-ascii?q?xgjQFpB4CiBaNVJQtjWeJVQIRGQGBOwEfOYFQcBVnAYF/gmGCFniJXSyBBoEXA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.46,440,1511827200"; d="scan'208";a="64412109" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 17:22:28 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w0VHMS2R024386 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Jan 2018 17:22:28 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 31 Jan 2018 11:22:27 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1320.000; Wed, 31 Jan 2018 11:22:27 -0600 From: "Charles Eckel (eckelcu)" To: Michael Richardson , "anima@ietf.org" CC: hackathon Thread-Topic: [hackathon] hackathon for ANIMA at IETF101 Thread-Index: AQHTmf7JfE7R5K9yaEi4ELst7B0emqOOrwoA Date: Wed, 31 Jan 2018 17:22:27 +0000 Message-ID: <6B03726C-F955-4D8D-8589-01437753F486@cisco.com> References: <9599d40a-230a-e07e-6835-6d25599e0daf@gmail.com> <500.1503098557@obiwan.sandelman.ca> <69aab3db-1857-b115-6d23-ac47aeee6fb1@gmail.com> <23147.1504661338@obiwan.sandelman.ca> <5b88246f-6625-8e66-d638-9c815950f220@gmail.com> <11898.1517339730@obiwan.sandelman.ca> In-Reply-To: <11898.1517339730@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.35.75] Content-Type: text/plain; charset="utf-8" Content-ID: <9664A12161FE4C41AB741322CB9562D9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] [hackathon] hackathon for ANIMA at IETF101 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jan 2018 17:22:31 -0000 U291bmRzIGdyZWF0IE1pY2hhZWwuIFRoYW5rcyBmb3IgY2hhbXBpb25pbmcgdGhpcyBwcm9qZWN0 Lg0KDQpDaGVlcnMsDQpDaGFybGVzDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBoYWNrYXRob24gPGhhY2thdGhvbi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yg TWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+DQpEYXRlOiBUdWVzZGF5 LCBKYW51YXJ5IDMwLCAyMDE4IGF0IDg6MTYgUE0NClRvOiAiYW5pbWFAaWV0Zi5vcmciIDxhbmlt YUBpZXRmLm9yZz4NCkNjOiAiaGFja2F0aG9uQGlldGYub3JnIiA8aGFja2F0aG9uQGlldGYub3Jn Pg0KU3ViamVjdDogW2hhY2thdGhvbl0gaGFja2F0aG9uIGZvciBBTklNQSBhdCBJRVRGMTAxDQoN CiAgICANCiAgICBJIGhhdmUgYWRkZWQgQU5JTUEgdG8gdGhlIEhhY2thdGhvbiBwYWdlIGF0Og0K ICAgICAgaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWV0Zi9tZWV0aW5nL3dpa2kvMTAxaGFj a2F0aG9uDQogICAgDQogICAgSSBiZWxpZXZlIHRoYXQgd2Ugd2lsbCBoYXZlIEJpbGwgQXR3b29k IGFuZCBCcmlhbiBDYXJwZW50ZXIgInJlbW90ZSIgYXMgd2VsbCwNCiAgICBhbHRob3VnaCBJIGRv bid0IGtub3cgdGhleSB3aWxsIGJlIHN1ZmZpY2llbnRseSBjYWZmZWluYXRlZCA6LSkNCiAgICBJ IGFtIGhvcGluZyB0aGF0IHdlIHdpbGwgaGF2ZSBzb21lIGxpYmVzdCBwZW9wbGUgcmVtb3RlIGFz IHdlbGwuDQogICAgDQogICAgSSB3cm90ZToNCiAgICANCiAgICBBTklNQSB2b3VjaGVyIGFuZCBB Q1ANCiAgICANCiAgICBDaGFtcGlvbihzKQ0KICAgICAgICAgICAgTWljaGFlbCBSaWNoYXJkc29u DQogICAgUHJvamVjdChzKQ0KICAgICAgICAgICAgdXNlIG9mIHRoZSBBTklNQSBCUlNLSSBmb3Ig ZW5yb2xsbWVudCBvZiBkZXZpY2VzIGludG8gYSBQS0kNCiAgICAgICAgICAgIHVzZSBvZiBJUHNl YyBhbmQgUlBMIHRvIGNvbnN0cnVjdCB0aGUgQU5JTUEgQUNQIG92ZXJsYXkgYmV0d2VlbiBkZXZp Y2VzDQogICAgICAgICAgICAgICAgQUNQIGNvbnN0cnVjdGlvbiBjYW4gaW5jbHVkZSBwZW9wbGUg d2hvIGFyZSByZW1vdGUhDQogICAgDQogICAgSSBob3BlIHRoYXQgd2Ugd2lsbCBoYXZlIGFuIG9w cG9ydHVuaXR5IHRvIGV4Y2hhbmdlIHNvbWUgdm91Y2hlcnMgYW5kDQogICAgdmFsaWRhdGUgaWYg dGhlIGV4YW1wbGVzIGFyZSBjb3JyZWN0Lg0KICAgIA0KICAgIC0tDQogICAgTWljaGFlbCBSaWNo YXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MN CiAgICAgLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KICAgIA0KICAgIA0KICAgIA0KICAgIA0K DQo= From nobody Wed Jan 31 11:16:13 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322D512ECBE for ; Wed, 31 Jan 2018 11:16:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhV1aCF675Ii for ; Wed, 31 Jan 2018 11:16:10 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF7A1243F3 for ; Wed, 31 Jan 2018 11:16:10 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id w69so166477pfd.13 for ; Wed, 31 Jan 2018 11:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZSFwYbmWeVyzx/qx54tyn3Oaq+05D3d+90sTYL87Ri4=; b=K6pGB1QyJe6Jis00LAlh+3C3WpONw3kbOGJ8kMkYjE2Fu3EgdakGU7nyLhPDieajEN dE2Ozhd8K1XWoTB66zWlT9NapkZAQkR8PIxNRLLodwDwSJtHBq6nYo2WrLn5w/35FGJ5 OUYV+GtJdsuOEKvm+THyN9SjUcz7I2C3OyDlCx9JxH5go3BWvRaL6R6onW4F0Q16sqb6 7s4yRAFOCuUHZTVEMbegQ5BMI8RMLE3IrTCoaPB2BotfMWphiZIRuoDprlvce9WzQElF zacZrgJisE/1+Zdj+e7j23eACr3gw+F0F9oYyajd4bb398kk02210A2utiDl9zPth1s6 P2Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ZSFwYbmWeVyzx/qx54tyn3Oaq+05D3d+90sTYL87Ri4=; b=ktJGYGwNueM7lq0S/jpgBQFBqm0hY6a4Vm8+FH108SR3HtyM8EE4L7tUCiiDtu5U6Q Jg4ThiNzkQ4wrQBTWSECfvD9jFts6EHcoICVcmqJ+ydHt9NJPnK27tQh0VLWexy5g/xA lriCAHtNfizyQhoUBA+BNwzh5XpgF206Au7LCdTurF+ontm2IopRVTWQU4sNXZFgv7wI uyF4N7AIu8hgPQ0FLP+plhPcRtSWhJ+DRne1zEEf7T+uJrFd3WaO/IKdcvV+DjSj14q4 AhBRxla42eIfsp+JvW6Xg+S5V5a5L7cEurZIyO5p+fZkCfMf6LS3HWEFcYuuod9g6AQo /eSA== X-Gm-Message-State: AKwxytdsgWtbR4vBaPPlNVB0PqlK0B0NOfkoD85GPnhs2saPEJ4TDxwZ 2LTIqyQPuuPls7kzSikuyBSJdQ== X-Google-Smtp-Source: AH8x224lMCmYdcVmzppZ637RNinMVonzvhYVkAnJ6ZuFhcKkn6t5TXxVChFPa3JjQSLtT0cr1bgfcg== X-Received: by 10.99.4.213 with SMTP id 204mr383759pge.93.1517426169692; Wed, 31 Jan 2018 11:16:09 -0800 (PST) Received: from ?IPv6:2406:e001:3ff5:1:28cc:dc4c:9703:6781? ([2406:e001:3ff5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f12sm26955367pga.67.2018.01.31.11.16.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 11:16:08 -0800 (PST) To: "Michael H. Behringer" , anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> <12959.1516300465@obiwan.sandelman.ca> <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> <6611b5f4-0690-e6bb-cb54-6faf3f9d0ac2@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 1 Feb 2018 08:16:12 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <6611b5f4-0690-e6bb-cb54-6faf3f9d0ac2@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jan 2018 19:16:12 -0000 On 30/01/2018 07:58, Brian E Carpenter wrote: ... > On 29/01/2018 22:03, Michael H. Behringer wrote: >> OK, the time for the last call is over. I'll produce a -06 version, working >> through the following issues: >> >> - Sheng's review from 18 Jan (Thanks Sheng) >> - Michael's response to Sheng's mail. >> - the author issue. I think I'll follow Brian's suggestion, listing me as editor >> and all other co-authors under contributors. At least I see no better way... On looking at that again, please consider that what I actually wrote was: >> To answer to Brian comments on co-authors: if we have one or more Editors, should all other "authors" be listed as contributors? > > That is the option suggested by the RFC Editor site, and Michael has been the editor all along. > Personally I would be quite happy to be listed as a contributor. I think it's perfectly fine to list one or two editors, then three or four authors of substantial text, to a maximum of 5, and then list the rest as contributors. If you really can't cut the list at 5, we'd need to justify it to the AD. Brian