Subject: Re: [Anima] prefix assignment

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Mar 2017 11:04:08 -0400

This discussion started in a private thread, so I'll try to bring people
up-to-date by repeating and moving around text.

The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is
to do distributed prefix allocation.  This is very much in the space of
*coordinated* address management.

(My take, BTW, is that CASM should be considered the first spin-off WG
From ANIMA...)

Mark and Brian discussed how HNCP does prefix distribution within Homenet.

Brian then suggests:

  brian> But if the CE includes a little autonomic service agent (ASA) which
  brian> is in the ISP's security domain (not the SOHO domain), it can act for
  brian> HNCP to solicit address space from the ISP. That's the southern side
  brian> of the CASM model and the northern side of HNCP.

I asked a simple question: don't we have DHCPv6 for this?

I also then asked:

    > a) the CPE device is now part of the ISP's ACP.
    > That's okay if the CPE device is owned by the ISP and/or the CPE device
    > includes some kind of trusted computation environment.
    > {But a CPE owned by the ISP, might not be trusted by the home owner,
    > so another router in between would be needed,

Brian answered:
    > Really? Why not?

I don't think that the ISP can trust to have code controlled by end users
running in their ACP domain.

I also think that many end-users will be quite reasonably upset that their
ISPs can snoop on their internal traffic.  This may in fact violate many
work-at-home agreements; which is often the case of why you see multiple
routers/firewalls in documents like
         https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router.

(Fred had more interesting diagrams in presentations, which I could dig up)

    >> b) DHCPv6 PD is already the protocol that solves prefix allocation across
    >> trust boundaries.

    > Indeed. That's why we have "PD supported"  as a Boolean property of the
    > PrefixManager objective. There's no intention to undermine PD.

Why do I need to run a protocol in order to find if I can run a protocol,
when DHCP has the same mechanism already.  And use of DHCPv6 itself is well
defined in cable and DSL connections already.

    >> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deals with
    >> prefixes.  It would speak DHCPv6-PD to the south, and GRASP/ASA to the north.

    > Yes, the DSLAM is definitely a good place to put one.

    >> North of the ISP's device would be the ISP's (distributed) IPAM.
    >> GRASP/ASA-Prefix would be the protocol between.

    > Anyway, my point is that these approaches (ANIMA, HNCP and PD) are
    > complementary not competitors.

I don't see you saying that.

I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP
in the home) such that they interact directly, rather than using PD.  You
say this right here:

  brian> But if the CE includes a little autonomic service agent (ASA) which

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Mar 2017 05:13:43 +1300

OK, I'll front-post.

Where you want to plug in an ASA (autonomic service agent) is anywhere
you want plug in some intelligence to govern an automatic process.
Intelligence, for example, to figure out what to do if the user side
asks for a /48 and the ISP offers a /60. So the ASA might negotiate
a compromise at /56 and then PD does its thing. But we didn't want
to exclude a scenario where PD isn't available, hence a flag is
included.

> running in their ACP domain.

Right. But in ISP-provided CEs this could presumably be fixed, because
that code would be locked down. In a store-bought CE, isn't this exactly
where BRSKI will help us? There is certainly an issue for home-made CE
images, but they will be a tiny minority of users.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Mar 2017 16:16:28 -0400

> to exclude a scenario where PD isn't available, hence a flag is

To put this is pseudo-(monty)pythonesq:

Customer: Hi, I'd like to buy a parrot.
Store: Would you like a Blue Parrot or a Red Parrot?
Customer: I'd like a Blue Parrot.
Store: I'm sorry, but we don't sell Parrots.

I just don't see the point of the ASA here.

If DHCPv6-PD isn't available, then it's not a compliant ISP connection
(RFC7204) and it's outside of the scope of homenet to begin with.

    > images, but they will be a tiny minority of users.

No, BRSKI doesn't help the ISP feel safe that the code I am running
on my store-bought CE won't attempt to mess with their network.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Mar 2017 09:46:54 +1300

> Store: I'm sorry, but we don't sell Parrots.

No, it's not really Pythonesque but negotiation is allowed to fail.
 
> I just don't see the point of the ASA here.

There's already a thing called an HNCP agent. Why couldn't
it be enhanced to negotiate with an upstream ASA for resources?

> (RFC7204) and it's outside of the scope of homenet to begin with.

No disagreement; the idea was simply to ensure that the GRASP objective
can communicate that PD is or isn't available. If PD is required in
a particular scenario then that parameter will always be set True.
 
> on my store-bought CE won't attempt to mess with their network.

Yes, I see that. (Unless of course we get into much more complex validation
and authorization stuff, which seems unlikely to fly.)

  Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 29 Mar 2017 15:56:22 -0500

HNCP just doesn't care.  HNCP has a notion of "External Connection", and
an External Connection may provide one or more External Prefixes.  HNCP
will assign to each link in the HNCP one /64 from each External Prefix.

HNCP doesn't care where these External Connection TLVs come from, but it
is my understanding that there is WG consensus that DHCPv6-PD is the
default mechanism.  I don't think there's anything in any of our RFCs that
would prevent an implementation from obtaining External Prefixes using
a different protocol, e.g. manual configuration, a proprietary
provisioning protocol or even algorithmically derived from an IPv4 address
(as with 6rd).

Both implementations of HNCP are easy to extend with a different mechanism
for obtaining External Prefixes, should you wish to experiment.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 29 Mar 2017 16:04:50 -0500

> it be enhanced to negotiate with an upstream ASA for resources?

Could you please clarify what you mean by "negotiate"?  Current HNCP
implementations are provided with a bunch of External Prefixes, which they
then carve into /64, one per prefix.  Are you envisioning a scenario where
the HNCP implementation actually performs active negotiation on its
external interfaces?

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Mar 2017 17:38:55 -0400

> it be enhanced to negotiate with an upstream ASA for resources?

Because it's already done. It's called DHCPv6.
It already has extensive running code :-)
It's not even that complex.

I would love to request address space via ASA from the DHCPv6 server.
That would all happen within the ISP's ACP though.

Right now (on DSL lines), the address space mostly comes via radius.
Which is to say that the problem has been centralized by MBS builders into
being someone else's problem. Advertising the address space is often done by
OSPFv3, but there are additional things that would be easier for the DHCPv6
server to do, such as the DNS delegations that homenet is working on
finishing.

I think that CASM could very nicely define/extend the prefix ASA to deal with
DNS reverse names, and as the RIRs (George) said, better link the delegated
prefix to clear ownership records.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Mar 2017 17:41:45 -0400

> the HNCP implementation actually performs active negotiation on its

Yes, that's what Brian is suggesting.
The HNCP daemon would speak GRASP ASA on the "northbound" interface.
It wouldn't necessarily speak HNCP.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 29 Mar 2017 16:59:22 -0500

> The HNCP daemon would speak GRASP ASA on the "northbound" interface.

Sorry if I wasn't clear.  Would it merely request address space and handle
it out using HNCP, or would it actively renegotiate address space in
response to HNCP events?

If the latter -- why?

---

From: "Mark Townsley (townsley)" <[email-masked]>
Date: Wed, 29 Mar 2017 22:14:37 +0000

> On Mar 29, 2017, at 10:04 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

I was really pointing out that RFC 7695 could be used independent of HNCP. 

HNCP is just one protocol that uses the RFC 7695 distributed prefix assignment algorithm (which actually began as extensions to OSPF before HNCP even existed). 

- Mark

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Mar 2017 12:01:26 +1300

> the HNCP implementation actually performs active negotiation on its

Yes. But if it's a useless use case, that's fine. I was motivated to
point out that there *really* is no conflict between the homenet work
and Anima, and that they could be complementary if we want.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Mar 2017 12:04:54 +1300

> HNCP is just one protocol that uses the RFC 7695 distributed prefix assignment algorithm (which actually began as extensions to OSPF before HNCP even existed).

True. And I don't see any reason why a CASM system including autonomic service
agents shouldn't be used to supply prefixes for use by an RFC7695 implementation.
So the various tools can fit together.

    Brian
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Mar 2017 12:12:41 +1300

> It's not even that complex.

All true. But it isn't designed for negotiation as far as I know,
just a request/response.
 
> That would all happen within the ISP's ACP though.

Agreed, that is a little higher up the food chain. Maybe that is as close
to the user as an ASA will get. I don't really care; I just wanted to
explore the way we might fit our various tools together.

> server to do, such as the DNS delegations that homenet is working on

Yes, indeed, and then we could discuss how the radius server gets new
address space when it runs out.
 
> prefix to clear ownership records.

Yes, by defining a full set of relevant objectives.

    Brian

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 29 Mar 2017 18:16:43 -0500

> Le 29 mars 2017 à 18:04, Brian E Carpenter <[email-masked]> a écrit :
> 

Absolutely. RFC7695 Applicability Statement (Section 3.) explains that the algorithm can be used as
long as participating nodes gets configured with an eventually consistent set of non-overlaping prefixes,
which are then used to carve-out sub-prefixes that are assigned to link/nodes/objects/toasters.

- If ANIMA provides a protocol capable of configuring nodes with such a set of delegated prefixes, RFC7695 can be used. 
- CASM can also be used, as discussed earlier, in order to provision HNCP (by the mean of a border router), and hence be used as a provisioning mechanism to Homenet border routers.
- If CASM intends to adopt a distributed architecture, and assuming the existence of a reliable flooding protocol (AFAIK, grasp would be capable of such a thing), RFC7695 could be used in order to reliably carve and assign prefixes out of available addressing space.
 
- Pierre

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Mar 2017 10:45:59 -0400

> If the latter -- why?

It would hand out space via HNCP, and if it ran out of space, get more.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Mar 2017 09:50:36 -0500

> It would hand out space via HNCP, and if it ran out of space, get more.

This can also be done with DHCP.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Mar 2017 10:51:51 -0400

Pierre Pfister <[email-masked]> wrote:
    > long as participating nodes gets configured with an eventually
    > consistent set of non-overlaping prefixes,

I think that I can envision a situation where a largish distributed
enterprise could use auto-configuring Homenet technology in a "Small Office"
configuration, and would use a CASM/ANIMA mechanism at the edge to ask for
more address space from HQ.  (That could well be occuring via a VPN, or some
dark fiber, doesn't matter)

In that case, the HNCP and ANIMA parts would be in a common trust environment.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 04:26:57 +1300

> This can also be done with DHCP.

Indeed. I'm not trying to force the Anima approach, just pointing out that
it will be available in contexts where more than a simple PD operation might
be appropriate.

    Brian