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

From: Duzongpeng <[email-masked]>
Date: Thu, 23 Jul 2015 04:00:23 +0000

Dear all:

We have submitted a new draft about IPv4 ACP. Welcome for comments.

Its purpose is to describe an IPv4 ACP, which is helpful for the deployment of ACP when the IPv6 has not replace all IPv4.

IMO, the work of IPv6 ACP standardization does not need to be compatible with this one. They could be developed independently, and the IPv6 one should have a higher priority because the future of Internet should move to that direction.

In this version, the document lists some problems of developing an IPv4 ACP based on the talking in the mail list.

The content of this draft is still at the preliminary stage. Welcome to join in.

Best Regards
Zongpeng Du

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 23, 2015 11:42 AM
To: Sheng Jiang; Duzongpeng; Sheng Jiang; Duzongpeng
Subject: New Version Notification for draft-du-anima-ipv4-acp-00.txt

A new version of I-D, draft-du-anima-ipv4-acp-00.txt has been successfully submitted by Zongpeng Du and posted to the IETF repository.

Name:		draft-du-anima-ipv4-acp
Revision:	00
Title:		Autonomic Control Plane Based on IPv4
Document date:	2015-07-22
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-du-anima-ipv4-acp-00.txt
Status:         https://datatracker.ietf.org/doc/draft-du-anima-ipv4-acp/
Htmlized:       https://tools.ietf.org/html/draft-du-anima-ipv4-acp-00

Abstract:
   This document describes an Autonomic Control Plane (ACP) based on
   IPv4.  The ACP is an overlay control plane logically separate from
   the data plane.  It is established autonomically independent of the
   operator's configurations.  This document introduces the approach of
   using IPv4 addresses for the routing in an ACP.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2015 12:47:59 -0400

Duzongpeng <[email-masked]> 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.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jul 2015 05:03:42 +1200

> 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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 23 Jul 2015 17:13:39 +0000

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

> From: Anima [mailto:[email-masked]] 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
> 
> > I am very much opposed to this document, and I want to suggest that we
> > make it out of scope in our charter.
> 
> 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
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: John Strassner <[email-masked]>
Date: Thu, 23 Jul 2015 14:36:11 -0700

I agree with Michael B, Brian, and Michael R

regards.
John

On Thu, Jul 23, 2015 at 10:13 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

> and

-- 
regards,
John

---

From: Duzongpeng <[email-masked]>
Date: Fri, 24 Jul 2015 02:38:21 +0000

Hi, Brian

	I think I can understand your opinion. 
	However, the statement of "This requires no work or decision by the network operators" is just an ideal assumption, or design principle. 
	At one aspect, it can not be always achieved; at the other aspect, it does not mean the network operator can not make decision in an autonomic network.

	I think in a long time, Autonomic Network is just used to ease the work of an network operator, and not to replace all the human network operators.
	We can not assume in any time, the Autonomic network can make a better decision than human, especially in the very beginning.

	I understand that IPv4 is not as suitable as IPv6 for an ACP. I just want to make the gaps clear in this time.

Best Regards
Zongpeng Du

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Friday, July 24, 2015 1:04 AM
To: Michael Richardson; anima
Subject: Re: [Anima] Autonomic Control Plane Based on IPv4 draft - 00

> 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

---

From: Juliao Braga <[email-masked]>
Date: Fri, 24 Jul 2015 16:10:04 -0300

Hi All,

We have developed an alternative model for the implementation of 
autonomous functions (and autonomic, too). This model attempts to reduce 
complexity in the development of intelligent functions (intelligent 
elements) in the Internet Infrastructure, bringing the problem to the 
restricted area of Autonomous Systems. We call this model: Autonomous 
Network Architecture over Restricted Domains (ANARD).

There is a full paper (in Portuguese) here: 
http://www.braga.eti.br/papers/145326_1-Braga.pdf and a short paper in 
English, here: http: //www.braga.eti.br/papers/artigoTeseEn.pdf.

My question is about how to present this model to the ANIMA WG. If a 
model description is needed here on the list in TXT or if it is enough, 
for now, the short paper above. The interest is to submit the model for 
consideration by the group.

Our view is that this model is not conflicting on the proposals so far, 
here in the WG, but an additional and alternative model.

We did a case study on the IRR and the results were convincing in order 
to give more reliability to the information, since there is no human 
intervention and ensures the updating of objects in real time.

Among other issues involving the continuity of our project there is need 
to create vocabularies associated with the AS domain, with the 
relationship between ASes and with the IETF as a whole, in order to 
allow semantic interoperability, ontologies and learning of the 
intelligent elements. This is another issue on which we would like to 
get suggestions on how we should act so that we have cooperation, 
including people outside of our environment.

Thank you,

Julião

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 26 Jul 2015 23:11:48 -0700

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

-- 
---
Toerless Eckert, [email-masked]

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 27 Jul 2015 07:05:21 +0000

Yes, you are right, we should explain that in the draft, it is wrong to assume that this is obvious. Let's do that for the next revision! 

Michael

> From: Toerless Eckert (eckert)
> Sent: 27 July 2015 07:12
> To: John Strassner
> Cc: Michael Behringer (mbehring); Michael Richardson; anima
> 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
> 
> 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.
> 
> 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.
> 
> 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
> > > > > I simply don't understand; and I wonder if you understand what
> > > > > the ACP
> > > is.
> > > > >
> > > > > 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.

---

From: Duzongpeng <[email-masked]>
Date: Mon, 27 Jul 2015 08:13:17 +0000

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

	I still do not see any harm to provide this IPv4 ACP option.
	
Best Regards
Zongpeng Du

-----Original Message-----
From: Anima [mailto:[email-masked]] 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

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.

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

Cheers
    Toerless

On Thu, Jul 23, 2015 at 02:36:11PM -0700, John Strassner wrote:
> > > Network Protocol or Novell Netware - it simply doesn't matter outside the ACP.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 27 Jul 2015 09:52:55 +0000

> From: Duzongpeng [mailto:[email-masked]]
> Sent: 27 July 2015 09:13
> To: Toerless Eckert (eckert); John Strassner
> Subject: RE: [Anima] Autonomic Control Plane Based on IPv4 draft - 00
> 
> Hi, Toerless
> 
> 	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?

I agree with that, it doesn't cause "harm", but I still would like to understand why we want to support it. "not causing harm" is generally not an accepted justification in the IETF. :-)  

There are two ways to support IPv4, which do you propose?
(a) - dual stack in the ACP  <--- my guess
(b) - an IPv4 only ACP. 

Which one do you suggest, or both? (a) would be more resource consuming, and introducing more complexity. (b) would IMO not be acceptable. 

Everything can be done, for sure, I am just (very) sceptical about the need. Even in the NOC. 

Michael

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 27 Jul 2015 02:57:28 -0700

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

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.

> 	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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jul 2015 23:39:06 +1200

> expand on that, eg: check out the following text as a starting point:

To me the technical argument for a v6 ACP is mainly that it's future-proof
and that it allows a very reliable automatic addressing model (the ULA
scheme based on the domain hash). Even if ACP packets leaked by some error,
they would not collide with anything in the data plane and would in fact
be undeliverable. That seems very robust.

I agree that draft-eckert-anima-stable-connectivity needs to be more
complete on how a legacy v4 NOC will communicate with the autonomic
system. It may actually require an ALG. NAT46 is an underdeveloped art

    Brian

---

From: "Jason Coleman (colemaj)" <[email-masked]>
Date: Mon, 27 Jul 2015 13:07:15 +0000

-- 
Jason Coleman

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Jul 2015 10:23:09 -0400

> system. It may actually require an ALG. NAT46 is an underdeveloped art

My take is:
1) for services that the NOC provides to the ACP (for instance, a netconf
   server, various OCSP validations, even DNS servers), that DNS64 and
   NAT64 are just fine.  The NOC service sees a NAT'ed v4 address and isn't
   the wiser.

2) for devices that the v4NOC wants to reach out and touch in the ACP,
   it will require allocation of v4 address space (yes, probably already
   overloaded rfc1918 space), and then one uses DC-SIIT.
   see: http://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/

Both of these things can even occur in a VM running on the same hypervisor
as the NOC services if needed, which means that the chosen rfc1918 could
be made to not even leak.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 27 Jul 2015 10:30:24 -0700

>    NAT64 are just fine.  The NOC service sees a NAT'ed v4 address and isn't

Yes.

>    see: http://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/

I quickly browsed through the draft, and it seems to primarily target
the reverse case: NOC with v6 only, client v4. Now one can of course
reverse the setup, but i am not sure the draft directly lends itself
to what would make NAT a piece of cake.

Correct me if i am wrong, but effectively the NAT that would make
this direction painless would need to be able to find some eg: 16 bit
of an IPv4 address in some offset in the IPv6 ULA. Or we embed a full
IPv4 32 bit address in the ULA. Then we can also use stateless NAT64.

So this does relate to our ULA address format discussion, which is
why i changed the topic.

If we ignore the desire to IPv4/NAT access all ULAs, then the solution
is an orchestration that creates 1:1 NAT entries whenever new AN devices
enroll. I'd be ok with that approach as well.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Jul 2015 18:44:27 +1200

> to what would make NAT a piece of cake.

Correct. The NOC is the legacy in the Anima case, and SIIT-DC concerns
a data centre that is trying to be IPv6-only.
> IPv4 32 bit address in the ULA. Then we can also use stateless NAT64.

As I said earlier, it's NAT46 (IP4-only clients reaching an IPv6-only
world) not NAT64, and it is not a scenario that the BEHAVE WG fully
developed. So it's underdeveloped in the IETF. I advise against it,
having sat through years of pain in BEHAVE just to get NAT64 almost
right (the 'almost' refers to DNSSEC issues). I *really* suggest
thinking about this as an application layer gateway problem.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Jul 2015 13:52:29 -0400

> to what would make NAT a piece of cake.

You are letting the terminology confuse you.
The thing that has v6-only is the ACP.
The thing that is claimed to be IPv4 is the NOC.

When NOC (v4) devices need to reach out (TCP SYN) to the ACP (v6), you have
the same situation as DC-SIIT... the client has v4 only and the "server" has
v6-only.

    > IPv4 32 bit address in the ULA. Then we can also use stateless NAT64.

Yes.  You would publish foo-bar-router-v4 as 10.1.2.3, and the SIIT would
accept traffic to that IPv4, and then send it out as U:L:A:ffff:10.2.3.4.
The foo-bar-router would then have to configure (and announce) that address
as well as it's "normal" privacy-enhanced-stable-address.

    > enroll. I'd be ok with that approach as well.

I would also be okay with that too: a 1:1 NAT46 that would translate 10.1.2.3
to U:L:A:0001:abcd:abcd:0123:0123.  This would also be stateless (no
per-packet state required), but not configuration-less.