Subject: [Anima] Addressing: Do we need link addressing?

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 23 Apr 2015 16:45:21 +0000

ANIMA WG, 

I'd like to raise a question to the list for discussion: Do we need to create autonomic link addressing? 

Here is my view: We need to distinguish about addressing done in the Autonomic Networking Infrastructure, and addressing configured and managed by an operator. For the Autonomic Networking Infrastructure, which serves autonomic service agents, I do not think we need routable addresses on links, and suggest to use only link-local addressing. So the only addressing we should make routable are loopback addresses on devices. 

Thoughts?
Michael

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 23 Apr 2015 11:10:36 -0700

[individual]

+1

Would recommend folks to to read up on RFC7404 to understand the
pro/cons for the general case. IMHO none of the mentioned caveats applies to ANI,
so it is the ideal case to leverage 7404. Wrt to 7404 text: I don't think using
loopback from NMS operations is a caveat, IMHO its a benefit, especially when you
have as in ANI a zero-touch routing protocol announcing it.

On Thu, Apr 23, 2015 at 04:45:21PM +0000, Michael Behringer (mbehring) wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Apr 2015 09:02:43 +1200

> Here is my view: We need to distinguish about addressing done in the Autonomic Networking Infrastructure, and addressing configured and managed by an operator. For the Autonomic Networking Infrastr…

Firstly, yes, we should clearly separate the addressing realm used by ASAs to
communicate between themselves from the addressing realm(s) used by the user network.
(I made that "realm(s)" because in the case of highly virtualized data centres
etc., there might be many tenant addressing realms. And of course those addressing
realms might well be administered by certain ASAs.) So here, we are talking about
the addressing realm used by the ASAs to talk to each other.

But now we come to a branching point. Michael wants everybody to have a distinct
ACP. I think that's a fine idea but I want to keep the option where there is no
ACP, but the ASAs simply communicate using IP among themselves. In that mode
there's nothing special about addressing; for example all ASAs could be numbered
out of a specific ULA prefix, which would be the AN addressing realm, but they
don't need to be routers. So in that mode, no, there is no restriction to link-local
addressing.

Back to Michael's model. I have a question. If ASA Alpha on a given link wants to
communicate with ASA Beta on another link, what addresses are used?

   Brian

> .

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 24 Apr 2015 09:23:16 +0000

> > Here is my view: We need to distinguish about addressing done in the
> Autonomic Networking Infrastructure, and addressing configured and
> managed by an operator. For the Autonomic Networking Infrastructure,
> which serves autonomic service agents, I do not think we need routable
> addresses on links, and suggest to use only link-local addressing. So the only
> addressing we should make routable are loopback addresses on devices.
> 
> Firstly, yes, we should clearly separate the addressing realm used by ASAs
> to communicate between themselves from the addressing realm(s) used by
> the user network.
> etc., there might be many tenant addressing realms. And of course those
> addressing realms might well be administered by certain ASAs.) So here, we
> are talking about the addressing realm used by the ASAs to talk to each
> other.

So far - we're in sync! :-)   Absolutely agree on the realm(s) (Plural). Single realm does not make sense these days. 
 
> But now we come to a branching point. Michael wants everybody to have a
> distinct ACP. I think that's a fine idea but I want to keep the option where
> there is no ACP, but the ASAs simply communicate using IP among
> themselves. In that mode there's nothing special about addressing; for
> example all ASAs could be numbered out of a specific ULA prefix, which
> would be the AN addressing realm, but they don't need to be routers. So in
> that mode, no, there is no restriction to link-local addressing.

We don't disagree actually ;-)   While I see a number of real advantages of the ACP, there may well be environments where the ACP isn't feasible for one reason or another. Constrained devices could be one such case. 

So, assume that ASAs run in the data plane of the network, and NOT in a separate ACP. I claim the fundamentals of the discussion apply here as well. In particular: 

- we want a specific realm for the autonomic service agents, independent of what an admin configures.  So: ASA uses autonomically set up addressing; "normal" configured processes use the configured addressing. With IPv6 this shouldn't be an issue. This autonomic realm shouldn't be configurable; it should just happen (just like in the ACP). So the admin cannot mess up the addressing of the ASAs. He CAN mess up routing if there's no separate ACP, but that's a choice we'll have to make. 

- It would be nice (although not mandatory) if the same addressing we use inside the ACP would apply here too. 

- the link local discussion DOES apply also in the data plane, in my opinion, and I would make the same claim that I made for the ACP: I think the autonomic infrastructure shouldn't assign any routable link addressing for the autonomic processes. (What the user does is independent of this). 

- Note: There may well be an ASA that assigns *user space* addressing, to be used for the normal data plane, and Sheng's use case draft is an example of one. This is perfectly legitimate. To re-state: We don't want autonomically set up routable link addressing *for autonomic traffic*. 

> Back to Michael's model. I have a question. If ASA Alpha on a given link
> wants to communicate with ASA Beta on another link, what addresses are
> used?

In my mind: The routable ULA addresses that we describe in draft-behringer-anima-autonomic-addressing. ASAs communicate with the loopback addresses of the nodes. 

Michael

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 24 Apr 2015 11:07:56 +0000

Hi Michael, Brian, and all,

Please allow me to fork this thread into another specific topic: do we need separated addressing realm for ASAs communication?
I see we've already had some good discussion, so let's confirm whether we could reach consensus on this specific topic in this WG. 

Let me briefly summarize current discussion here (please correct me if I make something wrong):
- Requirement: we need separate addressing realm for communication between Autonomic Service Agents.
  a) when there is ACP, since ACP uses separate addressing realm, the ASAs are also naturally in a separated addressing realm.
  b) when there is NO ACP:
    b-1: use the draft-behringer-anima-autonomic-addressing to number the autonomic nodes ULAs on loopback interfaces.
    b-2: use the same prefix ( the normal data plane prefix) for autonomic nodes. The ASAs communication is just in the normal data plane.

>From the separate addressing realm perspective, the b-2 should NOT be the choice. However, the b-2 could also be autonomic if [I.D.jiang-anima-prefix-management] applies.

So please allow me confirm two questions:
1. Do we reach consensus on separate addressing realm for ASAs?
2. Do we also count b-2 option in or not?

Best regards,
Bing

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Michael
> Behringer (mbehring)
> Sent: Friday, April 24, 2015 5:23 PM
> To: Brian E Carpenter; Anima WG
> Subject: Re: [Anima] Addressing: Do we need link addressing?
> 
> > > I'd like to raise a question to the list for discussion: Do we need
> > > to create
> > autonomic link addressing?
> > >
> > addresses on links, and suggest to use only link-local addressing. So
> > the only addressing we should make routable are loopback addresses on
> devices.
> >
> > Firstly, yes, we should clearly separate the addressing realm used by
> > ASAs to communicate between themselves from the addressing realm(s)
> > used by the user network.
> > (I made that "realm(s)" because in the case of highly virtualized data
> > centres etc., there might be many tenant addressing realms. And of
> > course those addressing realms might well be administered by certain
> > ASAs.) So here, we are talking about the addressing realm used by the
> > ASAs to talk to each other.
> 
> > But now we come to a branching point. Michael wants everybody to have
> > a distinct ACP. I think that's a fine idea but I want to keep the
> > option where there is no ACP, but the ASAs simply communicate using IP
> > among themselves. In that mode there's nothing special about
> > addressing; for example all ASAs could be numbered out of a specific
> > ULA prefix, which would be the AN addressing realm, but they don't
> > need to be routers. So in that mode, no, there is no restriction to link-local
> addressing.
> 
> We don't disagree actually ;-)   While I see a number of real advantages of
> the ACP, there may well be environments where the ACP isn't feasible for
> one reason or another. Constrained devices could be one such case.
> 
> So, assume that ASAs run in the data plane of the network, and NOT in a
> separate ACP. I claim the fundamentals of the discussion apply here as well.
> In particular:
> 
> - we want a specific realm for the autonomic service agents, independent of
> what an admin configures.  So: ASA uses autonomically set up addressing;
> "normal" configured processes use the configured addressing. With IPv6 this
> shouldn't be an issue. This autonomic realm shouldn't be configurable; it
> should just happen (just like in the ACP). So the admin cannot mess up the
> addressing of the ASAs. He CAN mess up routing if there's no separate ACP,
> but that's a choice we'll have to make.
> 
> - the link local discussion DOES apply also in the data plane, in my opinion,
> and I would make the same claim that I made for the ACP: I think the
> autonomic infrastructure shouldn't assign any routable link addressing for
> the autonomic processes. (What the user does is independent of this).
> 
> - Note: There may well be an ASA that assigns *user space* addressing, to be
> used for the normal data plane, and Sheng's use case draft is an example of
> one. This is perfectly legitimate. To re-state: We don't want autonomically
> set up routable link addressing *for autonomic traffic*.
> 
> > Back to Michael's model. I have a question. If ASA Alpha on a given
> > link wants to communicate with ASA Beta on another link, what
> > addresses are used?
> 
> In my mind: The routable ULA addresses that we describe in
> draft-behringer-anima-autonomic-addressing. ASAs communicate with the
> loopback addresses of the nodes.
> 
> Michael
> 
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 24 Apr 2015 12:06:45 +0000

> From: Liubing (Leo) [mailto:[email-masked]]
> Sent: 24 April 2015 13:08
> To: Michael Behringer (mbehring); Brian E Carpenter; Anima WG
> Subject: Addressing: Consensus on Separate Addressing Realms?-//RE:
> [Anima] Addressing: Do we need link addressing?
> 
> Please allow me to fork this thread into another specific topic: do we need
> separated addressing realm for ASAs communication?
> I see we've already had some good discussion, so let's confirm whether we
> could reach consensus on this specific topic in this WG.
> 
>   a) when there is ACP, since ACP uses separate addressing realm, the ASAs
> are also naturally in a separated addressing realm.
>   b) when there is NO ACP:
>     b-1: use the draft-behringer-anima-autonomic-addressing to number the
> autonomic nodes ULAs on loopback interfaces.
>     b-2: use the same prefix ( the normal data plane prefix) for autonomic
> nodes. The ASAs communication is just in the normal data plane.
> 
> From the separate addressing realm perspective, the b-2 should NOT be the
> choice. However, the b-2 could also be autonomic if [I.D.jiang-anima-prefix-
> management] applies.
> 

The discussion is just starting so I doubt we can call consensus at this point. 

I strongly favour a separate addressing scheme for ASAs, even in the case where there is no separation. 

Arguments in favour: 
- consistent way of addressing autonomic nodes. As an ASA developer you know what you'll get. 
- I would make this addressing scheme not configurable or modifyable. It's an autonomic process. --> stability
- Therefore: Address (mis-) configuration has little chance to interfere with the autonomic addressing. (Of course for true separation you still benefit from the ACP). 
- and: It's cheap - I see no reason to *not* do it. 

Michael
 
> > > > I'd like to raise a question to the list for discussion: Do we
> > > > need to create
> > > which serves autonomic service agents, I do not think we need
> > > routable addresses on links, and suggest to use only link-local
> > > addressing. So the only addressing we should make routable are
> > > loopback addresses on
> > devices.
> > >
> > > Firstly, yes, we should clearly separate the addressing realm used
> > > by ASAs to communicate between themselves from the addressing
> > > realm(s) used by the user network.
> > > (I made that "realm(s)" because in the case of highly virtualized
> > > data centres etc., there might be many tenant addressing realms. And
> > > of course those addressing realms might well be administered by
> > > certain
> > > ASAs.) So here, we are talking about the addressing realm used by
> > > the ASAs to talk to each other.
> >
> > > But now we come to a branching point. Michael wants everybody to
> > > have a distinct ACP. I think that's a fine idea but I want to keep
> > > the option where there is no ACP, but the ASAs simply communicate
> > > using IP among themselves. In that mode there's nothing special
> > > about addressing; for example all ASAs could be numbered out of a
> > > specific ULA prefix, which would be the AN addressing realm, but
> > > they don't need to be routers. So in that mode, no, there is no
> > > restriction to link-local
> > addressing.
> >
> > the ACP, there may well be environments where the ACP isn't feasible
> > for one reason or another. Constrained devices could be one such case.
> >
> > So, assume that ASAs run in the data plane of the network, and NOT in
> > a separate ACP. I claim the fundamentals of the discussion apply here as
> well.
> > In particular:
> >
> > - we want a specific realm for the autonomic service agents,
> > independent of what an admin configures.  So: ASA uses autonomically
> > set up addressing; "normal" configured processes use the configured
> > addressing. With IPv6 this shouldn't be an issue. This autonomic realm
> > shouldn't be configurable; it should just happen (just like in the
> > ACP). So the admin cannot mess up the addressing of the ASAs. He CAN
> > mess up routing if there's no separate ACP, but that's a choice we'll have
> to make.
> >
> > - the link local discussion DOES apply also in the data plane, in my
> > opinion, and I would make the same claim that I made for the ACP: I
> > think the autonomic infrastructure shouldn't assign any routable link
> > addressing for the autonomic processes. (What the user does is
> independent of this).
> >
> > - Note: There may well be an ASA that assigns *user space* addressing,
> > to be used for the normal data plane, and Sheng's use case draft is an
> > example of one. This is perfectly legitimate. To re-state: We don't
> > want autonomically set up routable link addressing *for autonomic
> traffic*.
> >

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Apr 2015 11:10:05 -0400

Brian E Carpenter <[email-masked]> wrote:
    > distinct ACP.

I think you must mean Michael Behringer? :-)

    > I think that's a fine idea but I want to keep the option
    > where there is no ACP, but the ASAs simply communicate using IP among
    > themselves.

So I think that the "simply communicate using IP" is not the opposite of
"everybody to have a distinct ACP".
I'd think that the opposite of:
    "everybody to have a distinct ACP".
is:
    "the ACP is shared between different Autonomous Systems ("enterprises")"

but, clearly that's not what you meant.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Apr 2015 08:01:58 +1200

> I think you must mean Michael Behringer? :-)

Yes, sorry about the ambiguous address.

> but, clearly that's not what you meant.

No, because we need security and trust boundaries between enterprises. There
is an interesting systems-level question there though - can a service level
agreement between two operators allow certain autonomic operations across
the border between the two operators? As a test case, consider autonomic
configuration of inter-provider QoS (compare draft-ietf-tsvwg-diffserv-intercon).

In the GDNP draft we touch very briefly on this:
      On the other hand, a limited negotiation model might be deployed
      based on a limited trust relationship.  For example, between two
      administrative domains, devices might also exchange limited
      information and negotiate some particular configurations based on
      a limited conventional or contractual trust relationship.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Apr 2015 08:06:26 +1200

> - and: It's cheap - I see no reason to *not* do it. 

I tend to agree with Michael B on this. There is the minor point that I
just raised in response to Michael R: what if we have a specific use case
that crosses the normal (enterprise-based) trust boundary? For that particular
case, we might have to run an autonomic process in public address space.
Of course, it would still need to be secured (e.g. with TLS).

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 25 Apr 2015 20:25:32 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> So I think that the "simply communicate using IP" is not the opposite
    >> of "everybody to have a distinct ACP".  I'd think that the opposite
    >> of: "everybody to have a distinct ACP".  is: "the ACP is shared
    >> between different Autonomous Systems ("enterprises")"
    >>

    > No, because we need security and trust boundaries between
    > enterprises. There is an interesting systems-level question there
    > though - can a service level agreement between two operators allow
    > certain autonomic operations across the border between the two
    > operators? As a test case, consider autonomic configuration of
    > inter-provider QoS (compare draft-ietf-tsvwg-diffserv-intercon).

We could consider running an/the Autonomic resource allocation/discovery
protocol between providers, but I would suggest that it would never run
through the ACP, rather it would between GUAs of the routers, I think.

Perhaps we will figure out how to configure this autonomically later, but for
the moment, I would claim it would require a higher-level trust relationship
in order setup/enable, and is therefore out of scope.  (Maybe someone can
later on figure out how to merge SIDR address/ASN delegations with an autonomic
enabled BGP to enable an intent on both sides to enable a cross-realm
diffserv signaling protocol).

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Apr 2015 14:04:09 +1200

Michael, I fully agree, we can defer this question for now, as long as the
protocol design is agnostic on address scope.

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 27 Apr 2015 08:29:31 +0000

Hi, Bing & Brian,

Firstly, I have to point out that ASAs are functions. They do NOT have addresses. What we are discussing is the communication channels and their correspondent addresses that ASAs use to exchange controlling messages.

Then, I agree the controlling message exchanging should go through the ACP which has separate addressing realm. In the case that ACP is not available or not chosen, the controlling message exchanging should be done with necessary security mechanism. Whether it uses ULAs or other data plane addresses, I don't see much different. Unless the network uses different mechanism to build up routing for ULA, then, ULA may be used as backup communication way when data plane crashed. However, without the analysis on the specific mechanism that used to build up routing for ULA, I don't think using ULA itself is any more reliable than other communication in the normal data plane.

Best regards,

Sheng

>From: Anima [mailto:[email-masked]] On Behalf Of Brian E
>Carpenter
>Sent: Saturday, April 25, 2015 4:06 AM
>To: Michael Behringer (mbehring); Liubing (Leo); Anima WG
>Subject: Re: [Anima] Addressing: Consensus on Separate Addressing
>Realms?-//RE: Addressing: Do we need link addressing?
>
>> - Therefore: Address (mis-) configuration has little chance to interfere with
>the autonomic addressing. (Of course for true separation you still benefit
>from the ACP).
>>>> So far - we're in sync! :-)   Absolutely agree on the realm(s) (Plural).
>Single
>>>> realm does not make sense these days.
>>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Apr 2015 07:53:29 +1200

> Then, I agree the controlling message exchanging should go through the ACP which has separate addressing realm. In the case that ACP is not available or not chosen, the controlling message exchangi…

There is one difference - if the network gets disconnected from the Internet,
and is reconnected later with a different prefix, the ULA communication will not
be affected. That could affect small networks but not large enterprises. From
every other aspect, I agree there is no difference.

Regards
  Brian

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 28 Apr 2015 00:51:34 +0000

>> Firstly, I have to point out that ASAs are functions. They do NOT have
>addresses. What we are discussing is the communication channels and their
>correspondent addresses that ASAs use to exchange controlling messages.
>>
>> Then, I agree the controlling message exchanging should go through the
>ACP which has separate addressing realm. In the case that ACP is not available
>or not chosen, the controlling message exchanging should be done with
>necessary security mechanism. Whether it uses ULAs or other data plane
>addresses, I don't see much different. Unless the network uses different
>mechanism to build up routing for ULA, then, ULA may be used as backup
>communication way when data plane crashed. However, without the analysis
>on the specific mechanism that used to build up routing for ULA, I don't think
>using ULA itself is any more reliable than other communication in the normal
>data plane.
>

So, are you talking about using ULA address as the device identifier? If so, may be yes, I am not sure. We are not explore the device identifier yet. So far, from the reachability perspective, ULA does not make much different as it also goes through the normal data plane.

Regards,

Sheng

>>>>>     b-1: use the draft-behringer-anima-autonomic-addressing to
>number
>>> the
>>>> - consistent way of addressing autonomic nodes. As an ASA developer
>you
>>> know what you'll get.
>>>> - I would make this addressing scheme not configurable or modifyable.
>It's
>>> an autonomic process. --> stability
>>>>>> We don't disagree actually ;-)   While I see a number of real
>advantages
>>> of

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Apr 2015 13:56:04 +1200

> So, are you talking about using ULA address as the device identifier? If so, may be yes, I am not sure. We are not explore the device identifier yet. So far, from the reachability perspective, ULA…

No, I'm not referring to authenticated identity, only to addressing for the control
plane. Although I'm not convinced by the behringer-anima-autonomic-addressing model,
I do see the value of  control plane addressing that is independent of the Internet
and never needs renumbering.

In my mind it is a secure session (ACP or just TLS) that authenticates identity.

Regards
   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 28 Apr 2015 02:08:21 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2015 3:53 AM
> To: Sheng Jiang; Michael Behringer (mbehring); Liubing (Leo); Anima WG
> ACP which has separate addressing realm. In the case that ACP is not
> available or not chosen, the controlling message exchanging should be done
> with necessary security mechanism. Whether it uses ULAs or other data
> plane addresses, I don't see much different. Unless the network uses
> different mechanism to build up routing for ULA, then, ULA may be used as
> backup communication way when data plane crashed. However, without the
> analysis on the specific mechanism that used to build up routing for ULA, I
> don't think using ULA itself is any more reliable than other communication in
> the normal data plane.
> 
> and is reconnected later with a different prefix, the ULA communication will
> not be affected. 
[Bing] This is actually one of the suggestions for ease of renumbering described in RFC6879:
"For enterprise networks, using ULA simultaneously with
   PA addresses can provide a local routing plane logically separated
   from the global routing plane.  The benefit is to ensure stable and
   specific local communication regardless of any ISP uplink failure.
   This benefit is especially meaningful for renumbering."

However, it seems like it's not solid enough to assign ULAs for ASAs communication when there is no ACP only in terms of renumbering consideration.
One thing I thought was that ULAs assignment could be guaranteed fully-autonomic at any time; it is independent of SLAAC which relies on pre-configurations on the routers.
Are there any other reasons that support separating the ASAs addressing scheme from the data plane addressing?

Best regards,
Bing

> That could affect small networks but not large enterprises.
> From every other aspect, I agree there is no difference.
> 
> Regards
>   Brian
> 
> >
> > Best regards,
> >
> > Sheng
> >
> >>>> Please allow me to fork this thread into another specific topic: do
> >>>> we need separated addressing realm for ASAs communication?
> >>>> I see we've already had some good discussion, so let's confirm
> >>>> whether we could reach consensus on this specific topic in this WG.
> >>>>
> >>>>   a) when there is ACP, since ACP uses separate addressing realm,
> >>>> the
> >> ASAs
> >>>> From the separate addressing realm perspective, the b-2 should NOT
> >>>> be
> >> the
> >>> I strongly favour a separate addressing scheme for ASAs, even in the
> >>> case
> >> where there is no separation.
> >>>
> >>> Arguments in favour:
> >>> - I would make this addressing scheme not configurable or
> >>> modifyable. It's
> >> the autonomic addressing. (Of course for true separation you still
> >>benefit from the ACP).
> >> I tend to agree with Michael B on this. There is the minor point that
> >> I just raised in response to Michael R: what if we have a specific
> >> use case that crosses the normal (enterprise-based) trust boundary?
> >> For that particular case, we might have to run an autonomic process in
> public address space.
> >>>>>> Autonomic Networking Infrastructure, and addressing configured
> >>>>>> and managed by an operator. For the Autonomic Networking
> >>>>>> Infrastructure, which serves autonomic service agents, I do not
> >>>>>> think we need routable addresses on links, and suggest to use
> >>>>>> only link-local addressing. So the only addressing we should make
> >>>>>> routable are loopback addresses on
> >>>>> devices.
> >>>>>>
> >>>>>> Firstly, yes, we should clearly separate the addressing realm
> >>>>>> used by ASAs to communicate between themselves from the
> >>>>>> addressing
> >>>>>> data centres etc., there might be many tenant addressing realms.
> >>>>>> And of course those addressing realms might well be administered
> >>>>>> by certain
> >>>>>> have a distinct ACP. I think that's a fine idea but I want to
> >>>>>> keep the option where there is no ACP, but the ASAs simply
> >>>>>> communicate using IP among themselves. In that mode there's
> >>>>>> nothing special about addressing; for example all ASAs could be
> >>>>>> numbered out of a specific ULA prefix, which would be the AN
> >>>>>> addressing realm, but they don't need to be routers. So in that
> >>>>>> mode, no, there is no restriction to link-local
> >>>>> addressing.
> >>>>>
> >>>>> the ACP, there may well be environments where the ACP isn't
> >>>>> feasible for one reason or another. Constrained devices could be one
> such case.
> >>>>>
> >>>>> So, assume that ASAs run in the data plane of the network, and NOT
> >>>>> in a separate ACP. I claim the fundamentals of the discussion
> >>>>> apply here as
> >>>> well.
> >>>>> In particular:
> >>>>>
> >>>>> independent of what an admin configures.  So: ASA uses
> >>>>> autonomically set up addressing; "normal" configured processes use
> >>>>> the configured addressing. With IPv6 this shouldn't be an issue.
> >>>>> This autonomic realm shouldn't be configurable; it should just
> >>>>> happen (just like in the ACP). So the admin cannot mess up the
> >>>>> addressing of the ASAs. He CAN mess up routing if there's no
> >>>>> separate ACP, but that's a choice we'll have
> >>>> to make.
> >>>>>
> >>>>> - It would be nice (although not mandatory) if the same addressing
> >>>>> we use inside the ACP would apply here too.
> >>>>>
> >>>>> - the link local discussion DOES apply also in the data plane, in
> >>>>> my opinion, and I would make the same claim that I made for the
> >>>>> ACP: I think the autonomic infrastructure shouldn't assign any
> >>>>> routable link addressing for the autonomic processes. (What the
> >>>>> user does is
> >>>> independent of this).
> >>>>>
> >>>>> - Note: There may well be an ASA that assigns *user space*
> >>>>> addressing, to be used for the normal data plane, and Sheng's use
> >>>>> case draft is an example of one. This is perfectly legitimate. To
> >>>>> re-state: We don't want autonomically set up routable link
> >>>>> addressing *for autonomic
> >>>> traffic*.
> >>>>>
> >>>>>> Back to Michael's model. I have a question. If ASA Alpha on a
> >>>>>> given link wants to communicate with ASA Beta on another link,
> >>>>>> what addresses are used?
> >>>>>
> >>>>> draft-behringer-anima-autonomic-addressing. ASAs communicate
> with
> >>>> the