Subject: [Anima] Discuss: Adressing schemes

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 20 Jul 2015 11:43:45 +0200

Hi everyone,

(first, the session was good, and remote experience was decent).

Michael R. started a discussion on the meetecho chat about the 
addressing schemes (or approaches).

Just wanted to continue it here.

One proposition is to allocate the address pool to the AFs instead of 
the ANs.
Some reasons for that:
     -AFs are not necessarily bind to a single AN.
     -AFs can dynamically assign the addresses to the ASAs on a per need 
basis (Michael R. rightly mentioned that some ASAs may not even start 
before the intent is actually distributed).
     -AFs / ASAs, especially if running in a virtualized mode, could 
relocate dynamically and thus the "AF topology" will change. Binding the 
addresses to the AFs might prevent to renumber/re-aggregate on such 
network changes.

Obviously, the constraints on the addressing may be different depending 
on what perspective we consider (security, bootstrap...)

Please share your thoughts.
Thanks, best regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Jul 2015 02:48:33 +1200

On 20/07/2015 21:43, Laurent Ciavaglia wrote:
> Michael R. started a discussion on the meetecho chat about the addressing schemes (or approaches).
> 
> One proposition is to allocate the address pool to the AFs instead of the ANs.
> Some reasons for that:
>     -AFs can dynamically assign the addresses to the ASAs on a per need basis (Michael R. rightly mentioned that some ASAs may
> not even start before the intent is actually distributed).

You're assuming that ASAs will have their own addresses instead of using
the address of the AN that hosts them. I'm not at all sure that is
necessary. (Actually I think it creates additional complexity for the
signaling protocol, which will have its own state machine. If the
various ASAs on a given node have different addresses, the protocol
engine will have to deal with it. If the ASAs all share the node's
ACP address, things will be a little simpler.)

However, if the decision is to give each ASA its own address in the ACP,
rather than sharing the address of the node that hosts it, that doesn't
require the AF to hand out addresses; it's just a function of the
ACP itself. Anyway, surely the AF is just the set of ASAs managing a
given resource? It isn't a separate thing in itself, so how can it
hand out addresses? The ASAs that form a given AF will discover each
other dynamically. In fact that is the main purpose of GRASP Discovery
- find the other ASAs that handle the same objectives as you.

>     -AFs / ASAs, especially if running in a virtualized mode, could relocate dynamically and thus the "AF topology" will change.

Migration of active ASAs is a bit scary. If we have multiple equipotent ASAs,
can't we just allow an ASA to die and create a new one somewhere else? That
will happen anyway when there is a sudden failure, so we must be able to
recover. Also, I would be very nervous to think of the ACP running over a
layer of VMs that itself is subject to VM migration by some underlying layer.
We need the ACP to be very robust when any kind of failure occurs.

> Binding the addresses to the AFs might prevent to renumber/re-aggregate on such network changes.

But you can never completely eliminate this in some error conditions. So our
solution must survive such events anyway. In a sense, a large autonomic network
will be in a state of continuous bootstrap - somewhere, there will always some
nodes failing, joining, or leaving.

   Brian

> 
> Obviously, the constraints on the addressing may be different depending on what perspective we consider (security, bootstrap...)
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 20 Jul 2015 08:50:03 -0700

Let me try to approach this from a different perspective:

I assume that in many ANs, we may have a good number of ASAs on every AN.
As Michael mentioned, a separate IPv6 address per ASA would make different
models of virtualization of ASAs on ANs easier. Assigning a prefix to an AN
to achieve route aggregation would help. 10,000 router network, 20 ASA
be AN == 200,000 routes unless we have aggregation.

Trying to keep the same network layer address for a mobile entity is an
artefact of transport layers that can not easily adopt to changing network
addresses. I don't think we would have this problem for ASAs whose main
communication mechanism should be GRASP. In the end, an ASA will communicate
with another ASA based on an objective, and when either ASA moves and
changes IPv6 address, i am sure we could come up with easy ways of resolving
that address change at the GRASP level.

Cheers
    Toerless

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Jul 2015 04:11:10 +1200

> be AN == 200,000 routes unless we have aggregation.

Yes, that makes sense. I have a preference for ASAs themselves not needing
to worry about this, i.e. keep the address-to-ASA mapping down in the protocol
engine.

> that address change at the GRASP level.

Yes. Since you commented verbally yesterday about the GRASP discovery cache
question, I've been thinking that if a cached address fails without warning,
because a remote ASA has failed or migrated, the local ASA will be forced
to repeat discovery. If necessary, we can add an instance ID to each ASA,
which would survive migration and could be used in the re-discovery process
following migration.

   Brian

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 20 Jul 2015 18:59:02 +0200

Dear all,

There is an assumption in your aproache(s) that the ASA are executing 
over the resources they control/operate on (e.g. the routers).
Other models are possible, especially if we consider AFs/ASAs to be 
"applications/programs" (this has been repeatedly said in the ANIMA 
sessions).
The AF/ASA can run on a server, and control (remote) resources (such as 
routers, base stations...)... then what do you define as the Autonomic 
Node(s): the servers or the routers/base stations? Where are the 
addresses defined/aggregated?

(Further comment might come on other points when time allows, thanks) ;)

Laurent.

-- 

*Laurent Ciavaglia*

Secure Cloud Networking

phone: +33 160 402 636

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Jul 2015 07:10:07 +1200

On 21/07/2015 04:59, Laurent Ciavaglia wrote:
> Dear all,
> 
> There is an assumption in your aproache(s) that the ASA are executing over the resources they control/operate on (e.g. the
> routers).
> Other models are possible, especially if we consider AFs/ASAs to be "applications/programs" (this has been repeatedly said in
> the ANIMA sessions).
> The AF/ASA can run on a server, and control (remote) resources (such as routers, base stations...)... 

Yes, certainly: an ASA could use a traditional north/south control protocol
to manage its collection of resources.

> then what do you define as
> the Autonomic Node(s): the servers or the routers/base stations? 

Definitely only the servers containing ASAs, IMHO.

> Where are the addresses defined/aggregated?

In the ACP model, each autonomic node will generate its own ULA addresses. But
I don't believe we are discussing the addresses used between the ASA and the
devices that it controls in the traditional style. Wouldn't those be
data-plane addresses as far as the autonomic network is concerned? (The
terminology is a bit strange because they are used for in-band control.)

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 22 Jul 2015 13:20:55 +0000

My view: 

- Autonomic *nodes* get addresses. 
- an autonomic node can host several ASAs. Those do NOT have their own addresses, but use the addresses of the node. (In fact, if we get the API right, the ASAs should not need to know about addresses.). 
- If an ASA interfaces with something non-autonomic, the autonomic node picks another, non-autonomic address. (This may be necessary anyway if the connection goes outside the domain). 

What would not work in this model? 
Michael

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 20 July 2015 21:10
> To: Laurent Ciavaglia; Toerless Eckert (eckert)
> Cc: anima
> Subject: Re: [Anima] Discuss: Adressing schemes
> 
> routers, base stations...)...
> 
> Yes, certainly: an ASA could use a traditional north/south control protocol to
> manage its collection of resources.
> 
> In the ACP model, each autonomic node will generate its own ULA
> addresses. But I don't believe we are discussing the addresses used
> between the ASA and the devices that it controls in the traditional style.
> Wouldn't those be data-plane addresses as far as the autonomic network is
> concerned? (The terminology is a bit strange because they are used for in-
> band control.)
> 
>    Brian
> 
> >
> >> As Michael mentioned, a separate IPv6 address per ASA would make
> >> different models of virtualization of ASAs on ANs easier. Assigning a
> >> prefix to an AN to achieve route aggregation would help. 10,000
> >> router network, 20 ASA be AN == 200,000 routes unless we have
> aggregation.
> >>
> >> Trying to keep the same network layer address for a mobile entity is
> >> an artefact of transport layers that can not easily adopt to changing
> >> network addresses. I don't think we would have this problem for ASAs
> >> whose main communication mechanism should be GRASP. In the end, an
> >> ASA will communicate with another ASA based on an objective, and
> when
> >> either ASA moves and changes IPv6 address, i am sure we could come up
> >> with easy ways of resolving that address change at the GRASP level.
> >>
> >> Cheers
> >>      Toerless
> >>
> >>>      -AFs can dynamically assign the addresses to the ASAs on a per
> >>> need basis (Michael R. rightly mentioned that some ASAs may not even
> >>> start before the intent is actually distributed).
> >>> relocate dynamically and thus the "AF topology" will change. Binding
> >>> the addresses to the AFs might prevent to renumber/re-aggregate on
> >>> such network changes.
> >>>
> >>> Obviously, the constraints on the addressing may be different
> >>> depending on what perspective we consider (security, bootstrap...)
> >>>
> >>> linkedin: laurentciavaglia
> >>> <http://fr.linkedin.com/in/laurentciavaglia/>
> >>>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2015 02:31:40 +1200

On 23/07/2015 01:20, Michael Behringer (mbehring) wrote:
> - an autonomic node can host several ASAs. Those do NOT have their own addresses, but use the addresses of the node. (In fact, if we get the API right, the ASAs should not need to know about addresses.)

That was my assumption too. In the GRASP model, each ASA handles a certain set
of Objectives and those are used to distinguish multiple ASAs on one
GRASP instance. (We might need an ASA ID too, that is not 100% clear yet.)
In any case, only one address is needed. Also, when an ASA requests
discovery of other ASAs handling the same Objective, it doesn't need to
know their addresses either; the discovery cache can be held in the
GRASP engine. It's better that way, so that all the complexities of
caching (TTL, LRU, etc.) can be solved once only.

> - If an ASA interfaces with something non-autonomic, the autonomic node picks another, non-autonomic address. (This may be necessary anyway if the connection goes outside the domain). 

Exactly, or even if it simply needs to talk to a non-autonomic device via
the data plane.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 24 Jul 2015 13:19:27 +0000

Need to think more about that, thanks for this interesting discussion.
My knee-jerk reaction: We need IP addressing up even if no AF is active. For example to distribute Intent. So I would argue that an AN node itself needs an address.
This does of course not preclude that AFs could *also* have addresses. But that would have serious consequences on routing. Assume every node runs 5 AFs, then you have instead of one 5 addresses sourced there? Of course we could do this AF addressing scheme differently, more aggregatable. But all of that would have to be worked out in detail.
Michael

From: Anima [mailto:[email-masked]] On Behalf Of Laurent Ciavaglia
Sent: 20 July 2015 11:44
To: anima
Subject: [Anima] Discuss: Adressing schemes

Hi everyone,

One proposition is to allocate the address pool to the AFs instead of the ANs.
Some reasons for that:
    -AFs are not necessarily bind to a single AN.
    -AFs can dynamically assign the addresses to the ASAs on a per need basis (Michael R. rightly mentioned that some ASAs may not even start before the intent is actually distributed).
    -AFs / ASAs, especially if running in a virtualized mode, could relocate dynamically and thus the "AF topology" will change. Binding the addresses to the AFs might prevent to renumber/re-aggregate on such network changes.

--

Laurent Ciavaglia
Secure Cloud Networking

phone: +33 160 402 636
email: [email-masked]<mailto:[email-masked]>
linkedin: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>
address: Route de Villejust | 91620 Nozay | France

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 28 Jul 2015 03:02:46 +0000

With my chair hat on, I am not sure address for AF is in our current charter. However, there is not problem for you guys to work on that topic, submit an individual draft, and present it in the future meeting. Overall, it is in scope of autonomic network.
On another side, as discussed on site with Michael B, Bing and Brian, also in another conversation with Terry (our responsible AD), the addressing scheme for ACP and even an address pool for AF, which would only be used within ACP, are worth a dedicated draft. It would be well in the current charter. We could even create new milestone for it. But, be careful, assign mechanism from the pool to each AF is not in the current charter, or we have to get further approval from our responsible AD.
Best regards,
Sheng
From: Anima [mailto:[email-masked]] On Behalf Of Michael Behringer (mbehring)
Sent: Friday, July 24, 2015 9:19 PM
To: Laurent Ciavaglia; anima
Subject: Re: [Anima] Discuss: Adressing schemes

Hi everyone,

Laurent Ciavaglia
Secure Cloud Networking

phone: +33 160 402 636

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 28 Jul 2015 07:31:15 +0000

Thanks Sheng for that clarification.
Let me re-play in my own words to see whether I understand:
In the simplest case, for the bootstrap process, we need a mechanism where, with some simple commands on a central nodes (for example, setting up a trust anchor, defining the domain name) network elements can bootstrap. This requires them to have an IP address, to communicate with the registrar. The IP address used, in the ACP, for the autonomic bootstrap, is in scope of the charter and a current mile stone.
So we need a mechanism such that every autonomic node gets an IP address during bootstrap, inside the ACP.
The current thinking is in section 4.2 in draft-behringer-anima-reference-model. I’ll leave the requirements and high level concepts in the reference draft, but put the suggested addressing scheme and approach back into draft-behringer-anima-autonomic-addressing now.
Right?
Michael

From: Sheng Jiang [mailto:[email-masked]]
Sent: 28 July 2015 04:03
To: Michael Behringer (mbehring); Laurent Ciavaglia; anima
Cc: Liubing (Leo); Brian E Carpenter
Subject: RE: [Anima] Discuss: Adressing schemes

Hi everyone,

Laurent Ciavaglia
Secure Cloud Networking

phone: +33 160 402 636

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 29 Jul 2015 01:40:25 +0000

Hi, Michael B,
Your recatching looks good for me. Only, the better place for requirements may be the separated address draft. Also, if you could rename the draft to be something like ACP-addressing, it would be more precise and explicit for the WG.
Regards,
Sheng
From: Michael Behringer (mbehring) [mailto:[email-masked]]
Sent: Tuesday, July 28, 2015 3:31 PM
To: Sheng Jiang; Laurent Ciavaglia; anima
Cc: Liubing (Leo); Brian E Carpenter
Subject: RE: [Anima] Discuss: Adressing schemes

Hi everyone,

Laurent Ciavaglia
Secure Cloud Networking

phone: +33 160 402 636