Subject: [Anima-signaling] Prefix management use case and GDNP

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jun 2015 11:53:49 +1200

Hi,

This is a rough analysis of how the use case described in
draft-jiang-anima-prefix-management could be mapped into GDNP.
It is not debugged; it is only a proof of concept.

The model is that an ASA uses Anima signaling to obtain a
pool of IPv6 prefixes for subsequent delegation, from any peer
that has enough free space. When the network is created, there
needs to be at least one ASA "pre-loaded" with the network's
supply of IPv6 prefixes. As time goes on, this pool would be
shared out autonomically among all the interested ASAs,
according to supply and demand.

Note, this is quite orthogonal to actually delegating the
prefixes (probably done with DHCPv6-PD) or injecting them into
the routing protocol.

Assumptions:

1) The ASA has already become trusted (by the general trust
bootstrap mechanism).

2) The ASA has already joined the ACP (or can create TLS sessions
with peers). The ACP is best, because it uses self-created ULA
prefixes, so we don't have a bootstrap problem due to lack of
prefixes.

3) Either from intent or from its built-in role, the ASA knows
the following properties:
 - the default prefix length to assign to a requesting device
 - that it has the right to request additional space from peers
 - the criterion for requesting new prefix space from elsewhere
   (e.g. "current space 90% depleted")

Now assume that a certain ASA wants new address space, either
because it is just starting up and has no address space, or because
it has delegated most of its pool. It will therefore act as a GDNP
initiator. The basic process is
1) discover peers that also support address space assignment
2) negotiate with one of them to get the needed prefix.
Therefore, we need an "IPv6 Prefix" objective in GDNP.

We'll use a JSON model here. A binary TLV model would be equivalent,
but more complicated to define.

>From here on, you don't want the text to wrap, use a nice wide window ;-).

Here is the objective, expressed in JSON. This is a maximum version,
with all possible fields included, with sample values.

{"ipv6_prefix": [null,                                      // Standardized objective (no domain name)
                {"disc_OK": true}, {"neg_OK": true},        // Valid for discovery and negotiation
                {"ct": 5},                                  // Negotation loop count
                {"v6a": "20010000dead00000000000000000000"},// A prefix in simplified text format
                {"length": 48}                              // Prefix length of 48 bits
                ]}

An ASA that needs to obtain address space will do the following:

1. Discover peer ASAs that support the "ipv6_prefix" objective:

{"disc": [121212, {"ipv6_prefix": null}]}                        // Discovery
{"resp": [121212, {"v6a": "fd00beefdeadbeefc0daac175f6d8e76"},
                  {"v6a": "fd00deadbeefdeadc0daac175f6d8e77"}]}  // Response with addresses of 2 peers

2. Try the first peer, initiate negotiation for a certain amount of IPv6 space:

{"req": [54321, {"ipv6_prefix": [null, {"ct": 5}, {"length": 50}]}]}  // Requests 50 bit prefix

{"neg": [54321, {"ipv6_prefix": [null, {"ct": 4},
        {"v6a": "20010000dead00000000000000000000"},{"length": 48}    // Peer offers 48 bit prefix
        ]}]}

{"neg": [54321, {"ipv6_prefix": [null, {"ct": 3}, {"length": 49}]}]}  // Not enough, requests 49 bits

{"neg": [54321, {"ipv6_prefix": [null, {"ct": 2},
        {"v6a": "20010000dead00000000000000000000"},{"length": 48}    // Peer offers 48 bits again
        ]}]}

{"end": [54321, false]}                                               // Not enough, refuses offer.

3. Try again with the 2nd peer

{"req": [72134, {"ipv6_prefix": [null, {"ct": 5}, {"length": 50}]}]}  // Requests 50 bit prefix

{"wait": [72134, 120000]}                                             // Peer sets 2 minute timeout.

{"neg": [72134, {"ipv6_prefix": [null, {"ct": 4},
        {"v6a": "20010000beef00000000000000000000"},{"length": 49}    // Peer offers 49 bit prefix
        ]}]}

{"end": [72134, true]}                                                // Initiator accepts offer.

// At this point, the initiator adds the /49 prefix to its pool,
// and the peer removes it from its own pool.

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 9 Jun 2015 20:53:27 -0700

Brian,

I think this is a nice conceptual direction. I just feel this level of
signaling details jumps to conclusions without us having defined the
higher level use case flows well enough.

Eg:

- In the first place, we need to start IMHO with adress allocation
  on a per- l3-subnet basis. Les assume most simply all routers on
  a subnet have an ASA. We should describe how GDNP negotiates between
  them to get a prefix for the subnet. I think ultimately that needs
  to be some form of election "which router on this subnet should
  assign a prefix". That router then could take the prefic from its
  pool. 
  There are a bunch of things to negotiate to come to this decision:

  what should be prefix-length ?
  p2p could be /31 or /30. /30 would need to be negotiated if either
  router on the p2p has features with issues when using /30.
  transit-LANs (just routers, eg: ring) should get address prefix
  based on how many routers are on the ring.

  all transit link addresses are only used for silly purposes like
  SNMP or ping from an NMS to interfaces to see if they're up.

  So the assigned addresses also need to be stable once they're
  assigned once. So when redoing GDNP there needs to be elements
  that ensure stability as long as no mayor topology changes
  happened.

  Access-LANs, the prefix-length depends on the maximum number of
  hosts to support. Not sure if this could reasonably be more
  automatic than intent based. 

  address assignment of the routers own addresses on transit and
  access-LANs is often subject to policies:
  - one router wants to be primary on all access lans, the other
    secondary, so the primary should get the highest address in the
    repfix range the other the second highest. So this type
    of negotiation would not be per l3-subnet but most likely
    once between each pair of redundant access routers.
  
  handing out individual addresses to hosts is yet another ballpark,
  becuase that gets into either helping to simplify DHCP or replace DHCP
  ballparks. So not sure which one we'd care about most. I'd like
  the "replace DHCP" one, but i think "simplify DHCP" would be
  better business...

Cheers
    Toerless

On Wed, Jun 10, 2015 at 11:53:49AM +1200, Brian E Carpenter wrote:
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jun 2015 16:35:28 +1200

> higher level use case flows well enough.

Oh, sure, I completely agree with that; this was aimed only at
the problem of getting a resource from a distributed pool.
There are plenty of other aspects, which might generate their
own objectives. What we're looking for at the moment is specific
cases where the answer is "No, we can't do that with GDNP." When
we find one of them, we will have some thinking to do.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jun 2015 10:14:44 -0400

> according to supply and demand.

I agree completely.
I imagine this initial ASA running on a management system that also
probably deals with the original domain bootstrap domain.
It could also arrive on the scene on a laptop, etc.

    > (e.g. "current space 90% depleted")

How do we express the intents?

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jun 2015 08:31:49 +1200

below...
> How do we express the intents?

I'm going to duck for now, except to say that I could easily hack out
JSON objects to express them (and I could probably do it in WSDL
or SMIv2 if I had to). I'm not far from thinking that intent is just
another objective I could discover and synchronize with GDNP.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jun 2015 18:22:00 -0400

> another objective I could discover and synchronize with GDNP.

I think we need to take this back to the main list, and we have to figure
this out.  I am not convinced that "synchronize" is the correct thing
to do with intents.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jun 2015 12:59:44 +1200

> this out.  I am not convinced that "synchronize" is the correct thing

It may not be, but that's part of a wider discussion, indeed. I have reason
to believe there might be a draft about this soon, so we can wait until
that comes out, perhaps.

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 11 Jun 2015 15:58:05 +0000

> -----Original Message-----
> From: Anima-signaling [mailto:[email-masked]] On
> Behalf Of Brian E Carpenter
> Sent: 11 June 2015 03:00
> To: Michael Richardson
> Cc: Anima signaling DT
> Subject: Re: [Anima-signaling] Prefix management use case and GDNP
> 
> > I think we need to take this back to the main list, and we have to
> > figure this out.  I am not convinced that "synchronize" is the correct
> > thing to do with intents.
> 
> It may not be, but that's part of a wider discussion, indeed. I have reason to
> believe there might be a draft about this soon, so we can wait until that
> comes out, perhaps.

I agree that intent isn't synchronized, it's flooded. (We might just use different vocabulary, but mean the same thing). 

But I also agree with Brian: If the signalling protocol is flexible enough, intent distribution might be a function of the signalling protocol. This is why sections 4.4 and 4.5 are next to each other, and why I suggested Brian to have a stab at both ;-) 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Jun 2015 08:18:57 +1200

> I agree that intent isn't synchronized, it's flooded. (We might just use different vocabulary, but mean the same thing). 

Yes. DNCP for example is a synch protocol that works by flooding
(using the Trickle algorithm). The current posted version of GDNP
supports 1:1 synch between two peers, but we took out a 1:many
synch. However, Toerless suggested that we need it and I think
he's right, with intent being an obvious application. It isn't
quite trivial, however.

> But I also agree with Brian: If the signalling protocol is flexible enough, intent distribution might be a function of the signalling protocol. This is why sections 4.4 and 4.5 are next to each oth…

In due course...

    Brian