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

[Toerless Eckert <[e-mail]>]

On Mon, Jul 27, 2015 at 08:13:17AM +0000, Duzongpeng wrote:
> Hi, Toerless
> 
> 	I agree that IPv6 will be the future trend, and an IPv6 only ACP is simpler and kind of "sufficient".

Contributor head on...

> 	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.

I have not met a customer that did not expect that he would need to
support IPv6 in the near future. The fact of IPv6 only ACP was always
seen as a simplicity benefit. The customers want to ask their
app-vendros to support IPv6, but they MAY need some TEMPORARY life-insurance
policy in case some app isn't fast enough in delivering. 

> 	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? 
Putting one NAT in front of bad apps that are too late to support IPv6
is the much easier lifeline for customers than bothering about duplication
of all networking for a sunset technology (IPv4). NAT looks a lot better
if you consider that it's still an application that just looks like
it supports IPv6. Aka: Its not the case of NAT somwhere in the network,
but just "integrated" with an old App to make it survive to the next
upgrade. 

Btw: Some recent events like Apple mandating IPv6 support starting with
IOS9 (or else you can't put the app onto the story) is going to speed
up IPv6 support in applications quite a bit.

> 	As talked before in the maillist, there are some this kind of operators (not the big ones).
> 	I still do not see any harm to provide this IPv4 ACP option.

I wouldn't want to see an IPv4 option standardized. I want to
keep the standards track option as lightweight, strategic future proof
and scaleable as possible.

Wrt to implementation, i can't see a reasonable way to assign "static"
IPv4 addresses to the ACP, and it is even likely you'd still need NAT:

If you assign addresses out of some /16 or /8 block dynamically, you
still run into very likely collision problems. You can try to have
hosts persistently remember their past address, but when you have
partitioning and new device deployment together, you get collisions
afterwards with the need for reassignments of ACP addresses. That makes
NOC devices very unhappy. I know this is not a good argument, we should
never use addresses, but only DNS entries, but it will take a while longer
before all NOC equipment will support DNS instead of addresses as
identifiers (*sigh*, one bridge at a time).

Also, if you use rfc1918 for ACP, thats when you likely need NAT because
many networks already use too much rfc1918.  So the only choice would
be to ask IANA to carve out some additional new space similar to rfc6598.

If i now put on my working group chair head:

If customer(s) would want to stand up in ANIMA and ask for IPv4,
then we would have a better basis to continue this discussion. 
I think its unlikely.

I fear IPv4 work for ACP would steal cycles from other ANIMA work,
especially considering above addressing issues.

Cheers
    Toerless

> Best Regards
> Zongpeng Du
> 
> -----Original Message-----
> From: Anima [mailto:[e-mail]] 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) < 
> > [e-mail]> 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:[e-mail]] 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 <[e-mail]> 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/anima
> > >
> > > _______________________________________________
> > > Anima mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/anima
> > >
> > 
> > 
> > 
> > --
> > regards,
> > John
> 
> > _______________________________________________
> > Anima mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/anima
> 
> 
> --
> ---
> Toerless Eckert, [e-mail]
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
Toerless Eckert, [e-mail]