Re: [Anima] Autonomic Control Plane Based on IPv4 draft - 00

"Jason Coleman (colemaj)" <colemaj@cisco.com> Mon, 27 July 2015 13:07 UTC

Return-Path: <colemaj@cisco.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68841B2D1D for <anima@ietfa.amsl.com>; Mon, 27 Jul 2015 06:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1J8yd-HZGSZ for <anima@ietfa.amsl.com>; Mon, 27 Jul 2015 06:07:26 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79431B2D19 for <anima@ietf.org>; Mon, 27 Jul 2015 06:07:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9282; q=dns/txt; s=iport; t=1438002446; x=1439212046; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GwRlve7PxHea+DxafUIT6vUtPqYqZfb/U5whx25f0h0=; b=G+je8/3iiwOegw/AGT0mczN0lXxvVAad2ai6zPKQO8fXcPBFoh2HGOio xr91L7nMP+F3NfSat89iOSy6mS3X6Gp7k2AhySDzLetWpS7dvlKrXdAYY 6pN846la4Z7fuGNBTW9yMxNUl6jjFv53OKBGLj8mbB4vIK2np3sS1OXOf I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CLAwDKLLZV/5tdJa1bgxVUaQaDHbh0CYFtCoV5AhyBIDgUAQEBAQEBAYEKhCMBAQEDAQEBASARMwcLDAQCAQgRBAEBAQICIwMCAgIlCxQBCAgCBAENBRuICwgNuw+VXwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKJKoEChC4mGBsHBoJjL4EUAQSUaQGEd4dJgUWEHYsnhDuDYiaCDhyBU28BgQRDgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,554,1432598400"; d="scan'208";a="172596062"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 27 Jul 2015 13:07:17 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6RD7HIf019615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 13:07:17 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.225]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 08:07:16 -0500
From: "Jason Coleman (colemaj)" <colemaj@cisco.com>
To: Duzongpeng <duzongpeng@huawei.com>, "Toerless Eckert (eckert)" <eckert@cisco.com>, John Strassner <strazpdj@gmail.com>
Thread-Topic: [Anima] Autonomic Control Plane Based on IPv4 draft - 00
Thread-Index: AQHQxWdfb7lsc+DZl0i+rOlb94irf53pnBAAgAACyICAAElagIAFRw4AgAAh8YCAAHO0AA==
Date: Mon, 27 Jul 2015 13:07:15 +0000
Message-ID: <6E251C4F-5BCF-40A4-BA4E-E295A1C99587@cisco.com>
References: <BAFEC9523F57BC48A51C20226A5589575F3DB9B2@nkgeml505-mbx.china.huawei.com> <23016.1437670079@sandelman.ca> <55B11E6E.70708@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF23016921@xmb-rcd-x14.cisco.com> <CAJwYUrG5VLECLkHT7n_fgGuORCFqiYaTb02UrzqiMUWpOtbnGQ@mail.gmail.com> <20150727061148.GA32331@cisco.com> <BAFEC9523F57BC48A51C20226A5589575F3DC09E@nkgeml505-mbx.china.huawei.com>
In-Reply-To: <BAFEC9523F57BC48A51C20226A5589575F3DC09E@nkgeml505-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-originating-ip: [10.99.70.120]
Content-Type: text/plain; charset="utf-8"
Content-ID: <AA2ACF8005D5BB479AF0F3E995EDE5CE@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/3u3C8ruJ3Wdkqz83Qovm3wOf99s>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, anima <anima@ietf.org>, "Michael Behringer (mbehring)" <mbehring@cisco.com>
Subject: Re: [Anima] Autonomic Control Plane Based on IPv4 draft - 00
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2015 13:07:33 -0000

-- 
Jason Coleman






On 7/27/15, 3:13 AM, "Duzongpeng" <duzongpeng@huawei.com> wrote:

>Hi, Toerless
>
>	I agree that IPv6 will be the future trend, and an IPv6 only ACP is simpler and kind of "sufficient".
>
>	However, when connecting to an IPv4 only NOC application devices, it requires the use of IPv4 to IPv6 NAT as said in section 2.1.4 of your draft https://tools.ietf.org/id/draft-eckert-anima-stable-connectivity-01.txt.
>
>	In this situation, would it be simpler to provide an IPv4 ACP for the network operator if this operator has no plan to update to IPv6, and all are IPv4? 
>	As talked before in the maillist, there are some this kind of operators (not the big ones).

Jason - I do agree that there are operators that are not looking to move their network to IPv6 at this point.  However, I do not understand why this is an implication or a driver for a need for an IPv4 ACP.  The ACP itself sets up and runs IPv6 without input from the operator, so given the ACP design of tunnel to tunnel this will have no impact on the Data Plane of the operator.

Interaction between the operator and the ACP will need to have some type of IPv4 to IPv6 conversion at the edge.  Which as you stated is discussed in section 2.1.4.  So at this point we are talking about the operator having to make a choice to run IPv4 to IPv6 NAT on a limited scale or implement an IPv4 ACP.  

Is your concern that operators will not want to put this NAT in place at the edge between the ACP and their equipment?
In my opinion, operators that want to move to Autonomics will see this is a small change and has little impact to their overall network design and therefore not be a blocking point to implement AN.

>
>	I still do not see any harm to provide this IPv4 ACP option.
>	
>Best Regards
>Zongpeng Du
>
>-----Original Message-----
>From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless Eckert
>Sent: Monday, July 27, 2015 2:12 PM
>To: John Strassner
>Cc: Michael Richardson; anima; Michael Behringer (mbehring)
>Subject: Re: [Anima] Autonomic Control Plane Based on IPv4 draft - 00
>
>The ACP draft is currently very lightweight explaining why IP6-only for the ACP is proposed. Please let me know if you think we should expand on that, eg: check out the following text as a starting point:
>
>Cheers
>    Toerless
>
>The ACP is intended to provide ONLY IPv6 for a variety of reasons.
>
>On the overall design implementation and operations side of the ACP, relying only on one network layer improves simplicity, reliability and scalability. The ACP provides protection/security for the traffic it carries. Each network layer it would need to support would require another set of security associations which may not only be control resources, but also HW resources. Each network layer requires its own routing tables and routing process calculations.
>
>The ACP is intended to carry ASA control traffic and other OAM traffic:
>
>ASAs are new designs so it is easily possible to have them rely on only a single network layer for their ACP signaling,
>IPv6 even if they intend to serve multiple address families in the data-plane. 
>
>All widely used OAM protocols in SP, Enterprise and IoT do support
>IPv6: SNMP, TFTP, SSH/SCP, Radius, Diameter, ...  Current and future going IETF work result will not result anymore in any IPv4-only OAM protocols, but it may easily result in IPv6 only OAM solutions
>(example: Frank Brockners work - referrence).
>
>.. (better/additional text welcome)..
>
>Cheers
>    Toerless
>
>On Thu, Jul 23, 2015 at 02:36:11PM -0700, John Strassner wrote:
>> I agree with Michael B, Brian, and Michael R
>> 
>> 
>> regards.
>> John
>> 
>> On Thu, Jul 23, 2015 at 10:13 AM, Michael Behringer (mbehring) < 
>> mbehring@cisco.com> wrote:
>> 
>> > I concur with MichaelR and Brian, this doesn't make sense to me.
>> >
>> > Before going down this route, I'd like to see very clear use cases 
>> > that require it.
>> >
>> > Michael
>> >
>> > > -----Original Message-----
>> > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E 
>> > > Carpenter
>> > > Sent: 23 July 2015 19:04
>> > > To: Michael Richardson; anima
>> > > Subject: Re: [Anima] Autonomic Control Plane Based on IPv4 draft - 
>> > > 00
>> > >
>> > > On 24/07/2015 04:47, Michael Richardson wrote:
>> > > >
>> > > > Duzongpeng <duzongpeng@huawei.com> wrote:
>> > > >     > Its purpose is to describe an IPv4 ACP, which is helpful for the
>> > > >     > deployment of ACP when the IPv6 has not replace all IPv4.
>> > > >
>> > > > I simply don't understand; and I wonder if you understand what 
>> > > > the ACP
>> > is.
>> > > >
>> > > > This is all new code and new (virtual) wires.  I don't see what 
>> > > > the state of
>> > > > IPv4 matters.  Maybe this is part of the Data-Plane ACP "confusion".
>> > > >
>> > > > I am very much opposed to this document, and I want to suggest 
>> > > > that we make it out of scope in our charter.
>> > >
>> > > I would argue it a bit differently. The IPv6-based ACP will create 
>> > > itself automatically, simply because all autonomic nodes will 
>> > > contain the code that knows how to do this (IPv6 stack, SLAAC, the 
>> > > IPv6 routing protocol,
>> > and
>> > > some sort of ACP-creating engine to drive it all). This requires 
>> > > no work
>> > or
>> > > decision by the network operators. So the question of whether IPv6 
>> > > is already deployed in the network is totally irrelevant - the ACP 
>> > > simply doesn't care. Also the operators don't need to care what 
>> > > protocol the
>> > ACP is
>> > > running. Actually it could be running ISO/OSI Connectionless 
>> > > Network Protocol or Novell Netware - it simply doesn't matter outside the ACP.
>> > > But we have chosen IPv6 because it has useful properties that IPv4 lacks.
>> > >
>> > >    Brian
>> > >
>> > > _______________________________________________
>> > > Anima mailing list
>> > > Anima@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/anima
>> >
>> > _______________________________________________
>> > Anima mailing list
>> > Anima@ietf.org
>> > https://www.ietf.org/mailman/listinfo/anima
>> >
>> 
>> 
>> 
>> --
>> regards,
>> John
>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>
>
>--
>---
>Toerless Eckert, eckert@cisco.com
>
>_______________________________________________
>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