Subject: [Anima] [draft-ietf-anima-prefix-management-03] review

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Jun 2017 02:11:04 +0200

[darn, second mail header typo on my side. sorry.]

Dear authors

Some feedback for the PD draft:

1. Relationship to DHCPv6 PD:

The note in 4.3 makes it sound as if there is a concern by the authors that this proposal
could potentially be seen as being in conflict with DHCPv6.

I am not sure about a practical case where this case would ever be a concern. If the authors
can think of such a case, then it would be good to add sentences explaining that case. Otherwise
maybe revisit this concern. IMHO ANIMA-PD could nicely integrate/expand DHCP-PD:

RFC3633 (DHCPv6 PD) abstract says: "..delegating a long- lived prefix from a delegating
router to a requesting router, across an administrative boundary.."
                                         ^^^^^^^^^^^^^^^^^^^^^^^
To validate the ANI, IMHO we just need to show how to use GRASP within a domain, eg: not across
an administrative boundary. == no overlap with the declared intended use of DHCPv6 PD. Instead
i could rather see ANI/GRASP used inside the domain and then DHCP/DHCPv6-PD be used on the edge
of the domain to client (non-ANI devices).

2. Prefix Management Parameters

I do not understand from the text what prefix length is described in 6.1. Maybe i am misunderstanding
how the proposed PD mechanism should work, but in my understanding, a device has at least
TWO type of prefixes:

       GRASP/(+DHCP-PD)   +---------+
         requested        | router  |  ------    Interfaces with assigned prefixes
      <-----------------> |  with   |  ...       "Assigned prefix-length 'APL'"
         prefix-length    | PM-ASA  |  ------    or
           'RPL'          +---------+            GRASP/DHCP-PD requests via downstream PM-ASA

If RPL == APL, then there is no prefix aggregation. This may be acceptable (==scale well enough)
at GRASP/DHCP-PD signaling level. If thats what the authors have in mind then that should
be written explicitly.

Note that if RPL == APL, then this will result in more prefixes at the routing level because
all APLs can be from different prefixes and may not be aggregateable. IMHO, achieving aggregation
and managing that via PM-ASA would be a big benefit of PM-ASA.

Aka: If the document intends to support RPL < APL, then that should be better described. For
example, section 6.1 could for each role have simply those two parameters (requested_prefix_length,
assigned_prefix_length):

[
      [["role", "RSG"],["requested_prefix_length", 34], ["assigned_prefix_length", 56] ],
      [["role", "ASG"],["requested_prefix_length", 44], ["assigned_prefix_length", 64] ],
      [["role", "CSG"],["requested_prefix_length", 56], ["assigned_prefix_length", 64] ]
]

Thre assigned_prefix_length is of course most important if the downstream is an interface
where the router with PM-ASA needs to configure the prefix and the addresses are assigned
by SLAAC or DHCP from the router itself. If the downstream is not a local interface but
requests from PM-ASA, then the prefix can be determined by the  downstream PM-ASA. 

3. Mobile network roles

section 6.1: Please expand (in parenthesis) the abbreviations you use on first use, eg:
IPRAN, RNC in section 6.1. Please check any other unexplained TLAs in the document.

A good picture with RSG, ASG, CSG would be great and help. Especially if you want to take
the prior suggestion into account of what prefix length would be required in which role device.

4. If you read the point 5 below, i think there are a lot of options how PDs with ASAs can be done.
All of these options would require further details such as more GRASP objective parameters,
more description of the ASA state machinery, the individual GRASP negotiation steps etc.
I do not think we want to go through all that detail work because that is IMHO easier done by
first building prototypes, and instead having the document rather be a "framework" or
"architecture document instead of an ASA functional specification. To that end, it would IMHO be
 prudent to say so, for example before the last two paragraphs of the introduction:

proposed text, as 3rd last paragraph of introduction:

  This document is not a functional specification of the proposed autonomic function
  "prefix management" or all detail all the aspects of GRASP objective parameters and ASA procedures
  necessary to achieve all the different options of building a complete system. Instead it
  describes the architectural framework utilizing the components of the ANI and outlines the
  different deployment options and aspects and defines simple type of objectives in GRASP to 
  start building the system as well as some basic parameter examples.

5. Abstract deployment pictures / solution overview:

I think it would help in understanding the document if it would include a logical deployment
model pictures with explanations of the target deployment models. Ideally comparing to how this
is done with DHCP.

For example: In the introduction, there are some high level, very suggestive statements about limitations
of DHCP (non-autonomicity). Its really hard to detail why/how the PD solution improves over
this without a more explicit comparison of some DHCP deployment model example and a PD
deployment model example.

So, i have appended two proposed texts: 5.1 for what i understand to be the two most common
DHCP deployment models, and 5.2 for what i understand to be the proposed PD deployment model.

I would strongly suggest to consider using 5.2 in the document - or something equivalent.
Otherwise its IMHO hard to follow / understand how PD is meant to work.

Brian Carpenter already proved the feedback that a section like 5.1 might be contentuous and
also incomplete because centralized address management has a wide range of options not only
limited to DHCP but also involving Radius and other protocols - and there is even a whole working group
in the making (CASM - coordinated address space management).

So maybe my proposed 5.1 would better go into an appended with sufficient preface stating
exactly that these are just examples, and that there are many more deployment models, and
that there are no current IETF recommendations or documents laying out such complete deployment
pictures. (which IMHO is exactly one of the may problems). If folks feel that any more
explicit description of even exemplary DHCP deployment models is inappropriate because
it would get too contentuous, then its almost impossible to make statements about
the limitations about DHCP in the introduction. But without trying to give an example
and getting backpressure from reviewers, its IMHO a dead end:wq

5.1. Address & Prefix management with DHCP

                                                              edge
                    dynamic, "netconf/YANG"                 interfaces
                     <----------------->   +-------------+
   +-------------+      <- telemetry       | edge router/|+   ------  +--------+
   |config server|    ..... Domain ....    | DHCP server ||   ...     | CPE    |-+   LANs
   +-------------+                         +-------------+|   ------  +--------+ | (----| )
                                            +-------------+   DHCP/    +---------+
                                                            DHCPv6 / PD

Edge DHCP server deployment requires every edge router connecting to CPE to be a DHCP server
assigning IPv4/IPv6 addresses to CPE - and optionally IPv6 prefixes via DHCPv6-PD (RF3633)
for IPv6 capable CPE that are router and have LANs behind them.

This requires various coordination functions via some backend system depicted
as "config server": The address prefixes on the edge interfaces should be slightly larger
than required for the number of CPE connected so that the overall address space is best used.
The config server needs to provision edge interface address prefixes and DHCP parameters
for every edge router.  If too fine grained prefixes are used, this will result in large routing
tables across the "Domain". If too coase grained prefixes are used, address space is wasted.

There is no standard describing algorithms for how config servers would best perform this
ongoing dynamic provisioning to optimize routing table size and address space utilization.
There are currently no complete YANG models that a config server could use to perform
these actions (including telemetry of assigned adddresses from such distributed DHCP servers).
For example, a YANG model for controlling DHCP server operations is still in draft
(draft-liu-dhc-dhcp-yang-model-06).

Due to these and other problems of the above model, the more common DHCP deployment model is as
follows:

                                                              edge
   +-------------+     initial, "CLI"                       interfaces
   |config server|   ----------------->    +-------------+
   +-------------+                         | edge router/|-+   ------  +--------+
         |            ..... Domain ....    | DHCP relay  | |   ...     | CPE    |-+    LANs
   +-------------+                         +-------------+ |   ------  +--------+ | (----|  )
   |DHCP server  |                          +--------------+   DHCP/    +---------+
   +-------------+                                            DHCPv6 / PD

Dynamic provisioning changes to edge routers are avoided by using a central DHCP server
and reducing the edge router from DHCP server to DHCP relay. The "configuration" on the
edge routers is static, the DHCP relay function inserts "edge interface" and/or subscriber
identifying options into DHCP requests from CPE (eg: rfc3046, rfc6221), the DHCP server
has complete policies for address assignments and prefixes useable on every 
edge-router/interface/subscriber-group. When the DHCP relay sees the DHCP reply, it inserts
static routes for the assigned address/address-prefix into the routing table of the edge router
which are then to be distributed by the IGP (or BGP) inside the domain to make the CPE
and LANs reachable across the Domain (the same.

There is no comprehensive standardization of these solutions. RFC3633 section 14. for example
simply refers to "a [non-defined] protocol or other out-of-band communication to add routing
information for delegated prefixes into the provider edge router".

5.2 Prefix management with ANI/GRASP

With the proposed use of ANI and Prefix-management ASAs using GRASP, the deployment model 
is intended to look as follows: 

  |<................... ANI Domain / ACP...................>| (...) ............->

                                              Roles
                                                |
                                                v   "Edge routers"
     GRASP parameter                      +----------------+
     Network wide parameters/policy       | PM-ASA         |  downstream interfaces
         |                                |(DHCP-functions)|  ------
         v  "central device"              +----------------+
   +-------+                                    ^                      +--------+
   |PM-ASA |      <................... GRASP ....             ....     | CPE    |-+  ( LANs )
   +-------+              .                     v                      |(PM-ASA)| |    ----|  
        .               +........+        +----------------+           +--------+ | 
   +...........+        . PM-ASA .        |     PM-ASA     |  ------    +---------+
   .DHCP server.        +........+        |(DHCP-functions)|  SLAAC /
   +...........+     "intermediate router"+----------------+  DHCP / DHCP-pd

The network runs an ANI domain with ACP between some central device (eg: router or ANI
enabled management device) and the edge routers. ANI/ACP provides a secure, zero-touch
communication channel between the devices and enables the use of GRASP not only for p2p
communication, but also for distribution/flooding.

The central devices and edge-routers run software to support this documents autonomic
IPv6 edge prefix management (PM). In the autonomic networking terminology, such software are called
"Autonomic Service Agents" (ASA). The ASA for Prefix Management are called PM-ASA in this document
and form together the Autonomic Prefix Management Function.

Edge-routers can have different roles based on the type and number of CPE attaching to them.
Consider edge routers could be RSG, ASG CSG in mobile aggregation networks (see Section 6.1).
Mechanisms outside the scope of this document make routers aware of their role.

1. In a minimum Prefix Managmeent solution, the central device uses the "PrefixManager.Params"
GRASP Objective introduced in this document to disseminate network wide, per-role parameters
to edge routers. The PM-ASA use the parameters applying to its role to locallly "configuring"
pre-existing addressing functions. Because PM-ASA do not manage the dynamic assignment of actual
IPv6 address prefixes in this case, the following options can be considered:

1.a The edge router connects via downstream interfaces to (host) CPE that each require an address.
The PM-ASA sets up for each such interface a DHCP requesting router (according to RFC3633) to
request an IPv6 prefix for the interface. The routers address on the downstream interface can
be another parameter from the GRASP Objective. The CPEs assign addresses in the prefix via
RAs from the router or the PM-ASA manages a local DHCPv6 server to assign addresses to the
CPEs. A central DHCP server acting as the DHCP delegating router (according to RFC3633) is
required. Its address can be another parameter from the GRASP Objective.

1.b The edge router also connects via downstream interfaces to (customer managed) CPEs that are
routers and act as DHCPv6 requesting routers. The need to support this could be derived from
role and/or GRASP parameters and the PM-ASA sets up a DHCP relay function to pass on requests
to the central DHCP server as in 1.a.

2. In a solution without a central DHCP server, the PM-ASA on the edge routers do not only
learn parameters from "PrefixManager.Params" but also utilize GRASP to request/negotiate
actual IPv6 prefix delegation via the GRASP "PrefixManager" objective described in more detail below.
In the most simple case, these prefixes are delegated via this GRASP objective from the PM-ASA
in the central device.  These addresses are then used by the PM-ASA on the edge routers
to edge routers to configure prefixes on their downstream interfaces to assign addresses
via RA/SLAAC to host CPEs. The PM-ASA may also start local DHCP servers (as in 1.a) to assign
addresses via DHCP to CPE from the prefixes it received. This includes both host CPEs requesting
IPv6 addresses as well as router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the
address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and the
local DHCP servers it starts. It need to monitor the address utilization and accordingly request
more address prefixes if its existing prefixes are exhausted, or return address prefixes when they
are unneeded.

This solution is quite similar to the initial described IPv6 DHCP deployment model without
central DHCP server, and ANI/ACP/GRASP and the PM-ASA do provides the automation to make this
approach work more easily than it is possible today.

3. The address pool(s) from which prefixes are allocated do not need to be taken all from
one central location. Edge router PM-ASA that received a big (short) prefix from a central
PM-ASA could offer smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could be used
in such a way that the PM-ASA would find and select the objective from the closest neighboring
PM-ASA, therefore allowing to maximize aggregation: A PM-ASA would only request further
(smaller/shorter) prefixes when it exhausts its own poll (from the central location) and can
not get further large prefixes from that central location anymore. Because
the overflow prefixes taken from a topological nearby PM-ASA, the number of longer prefixes
that have to be injected into the routing tables is limited and the topological proximity
increases the chances that aggregation of prefixes in the IGP can most likely limit
the geography in which the longer prefixes need to be routed. 

4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASA can be built
(indicated in he picture via a dotted intermediate router). This would require additional parameters
to the "PrefixManager" objective to allow creating a hierarchy of PM-ASA across which the
prefixes can be delegated. This is not detailed further below.

5.  In cases where CPEs are also part of the ANI Domain (eg: "Managed CPE"), then GRASP will extend
into the actual customer sites and can equally run a PM-ASA. All the options described in points
1..4 above would then apply to the CPE as the edge router with the mayor changes being that
a) a CPE router will most likley not need to run DHCPv6 PD itself, but only DHCP address assignment,
b) The edge routers to which the CPE connect would most likely become ideal places to run a
hierarchical instance of PD-ASAs on as outlined in point 1.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 13:01:34 +1200

> could potentially be seen as being in conflict with DHCPv6.

Yes, and I think that is a mistake. It would be an equal mistake to
see this as in conflict with Radius. Rather than discussing DHCPv6/PD
or Radius, I think they are really out of scope. As in a previous
message to the WG, my idea is to drop the "PD" flag in the proposed
objective.

An ASA that uses this GRASP objective to obtain a pool of prefixes
can then use DHCPv6/PD, Radius, or any other method it wants
to hand prefixes out to client routers. It should be completely
independent.

(But including some 'serving suggestions' may well be useful,
as in your items 5.1 and 5.2.)

Skipping ahead:

...

>       [["role", "CSG"],["requested_prefix_length", 56], ["assigned_prefix_length", 64] ]

The intention is "assigned_prefix_length", i.e. what the gateway
concerned will assign to connected routers. I'm not sure that
we need to specify the requested length; that could be decided
by a heuristic in the gateway when its pool is getting low.
I don't have a strong opinion about that, but I did code a
heuristic in https://www.cs.auckland.ac.nz/~brian/graspy/pfxm2.py
so it can be done.
 
> requests from PM-ASA, then the prefix can be determined by the  downstream PM-ASA.

The prefix that the client would like, yes, but the prefix length
that the network allows surely has to be defined by the NOC.
So maybe it should be "minimum_allowed_prefix_length"

The text about these parameters is intentionally not definitive.
I think only experience will tell us the correct answer(s).

>  prudent to say so, for example before the last two paragraphs of the introduction:

Yes. And as far as I can see, we might need to express anything
that the CASM people can express, for the same reasons:
draft-sun-casm-address-pool-management-yang
 
>   start building the system as well as some basic parameter examples.

Yes, it's Informational for a reason.

Thanks
    Brian

---

From: Duzongpeng <[email-masked]>
Date: Wed, 7 Jun 2017 06:33:58 +0000

Hi, Toerless

	Thanks for the review and suggestions.

	Some personal opinions to share. Please correct me if any misunderstanding.

	1. The description about the relationship between DHCP PD and ANIMA prefix-management mechanism is ambiguous. 
	
	I agree with Brian's suggestion about deleting the PD issue from this document. 
	It is a realization problem and deleting it will not cause too much misunderstanding. 
	IMO, to talk too much about the details is not the document's purpose, i.e., validation of the designation of autonomic networking infrastructure.

	2. A node model containing "requested_prefix_length" and "assigned_prefix_length" is propsoed, while in current document we only have a prefix_length for the node.

	I think the problem is shortage of description of the whole structure, or a clear example. It causes the reader hard to image the mechanism.
	We need make it clear about the main mechanism, for example, adding some topology pictures and TLA descriptions as suggested. 
	
	3. It is suggested to add more abbreviation explanations and a picture about 6.1 (the IPRAN example section)

	Agree.

	4. It is suggested that we should not go through all that detail work because that is easier done by first building prototypes. Also, you have proposed a paragraph of introduction:

  describes the ***architectural framework*** utilizing the components of the ANI and outlines the

	Agree. But as suggested by Brian, ***architectural framework*** perhaps is not very proper here. 
	I suggest some other word here, such as "initial realization" or "prototype system". Is it OK?

	5. You suggest that add some texts about the abstract deployment pictures / solution overview
	Including:

	I agree that we need to add some mechanism descriptions to make the reader more easily catch the main point about the mechanism.
	However, although it may be helpful, I do not suggest describing too much about the DHCP mechanism in this document.

	I suggest focusing on the main mechanism about ANIMA prefix-management and adding more details about it.
	If it can solve the problem of ambiguity, we do not need to add too much contents about other detailed descriptions in this document.

	On the other side, I agree with the proposed solution architecture, and I think it should be able to work. 
	If it is agreed that to add all the texts is necessary, i.e., it is worthwhile to explain the multiple solutions in the document, I am ok with it.

Best Regards
Zongpeng Du

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Wednesday, June 07, 2017 8:11 AM
To: [email-masked]; [email-masked]
Subject: [draft-ietf-anima-prefix-management-03] review

Dear authors

The note in 4.3 makes it sound as if there is a concern by the authors that this proposal could potentially be seen as being in conflict with DHCPv6.

I am not sure about a practical case where this case would ever be a concern. If the authors can think of such a case, then it would be good to add sentences explaining that case. Otherwise maybe revisit this concern. IMHO ANIMA-PD could nicely integrate/expand DHCP-PD:

RFC3633 (DHCPv6 PD) abstract says: "..delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary.."
                                         ^^^^^^^^^^^^^^^^^^^^^^^ To validate the ANI, IMHO we just need to show how to use GRASP within a domain, eg: not across an administrative boundary. == no overlap with the declared intended use of DHCPv6 PD. Instead i could rather see ANI/GRASP used inside the domain and then DHCP/DHCPv6-PD be used on the edge of the domain to client (non-ANI devices).

I do not understand from the text what prefix length is described in 6.1. Maybe i am misunderstanding how the proposed PD mechanism should work, but in my understanding, a device has at least TWO type of prefixes:

If RPL == APL, then there is no prefix aggregation. This may be acceptable (==scale well enough) at GRASP/DHCP-PD signaling level. If thats what the authors have in mind then that should be written explicitly.

Note that if RPL == APL, then this will result in more prefixes at the routing level because all APLs can be from different prefixes and may not be aggregateable. IMHO, achieving aggregation and managing that via PM-ASA would be a big benefit of PM-ASA.

Aka: If the document intends to support RPL < APL, then that should be better described. For example, section 6.1 could for each role have simply those two parameters (requested_prefix_length,
assigned_prefix_length):

[
      [["role", "RSG"],["requested_prefix_length", 34], ["assigned_prefix_length", 56] ],
      [["role", "ASG"],["requested_prefix_length", 44], ["assigned_prefix_length", 64] ],
      [["role", "CSG"],["requested_prefix_length", 56], ["assigned_prefix_length", 64] ] ]

Thre assigned_prefix_length is of course most important if the downstream is an interface where the router with PM-ASA needs to configure the prefix and the addresses are assigned by SLAAC or DHCP from the router itself. If the downstream is not a local interface but requests from PM-ASA, then the prefix can be determined by the  downstream PM-ASA. 

3. Mobile network roles

A good picture with RSG, ASG, CSG would be great and help. Especially if you want to take the prior suggestion into account of what prefix length would be required in which role device.

4. If you read the point 5 below, i think there are a lot of options how PDs with ASAs can be done.
All of these options would require further details such as more GRASP objective parameters, more description of the ASA state machinery, the individual GRASP negotiation steps etc.
I do not think we want to go through all that detail work because that is IMHO easier done by first building prototypes, and instead having the document rather be a "framework" or "architecture document instead of an ASA functional specification. To that end, it would IMHO be  prudent to say so, for example before the last two paragraphs of the introduction:

I think it would help in understanding the document if it would include a logical deployment model pictures with explanations of the target deployment models. Ideally comparing to how this is done with DHCP.

For example: In the introduction, there are some high level, very suggestive statements about limitations of DHCP (non-autonomicity). Its really hard to detail why/how the PD solution improves over this without a more explicit comparison of some DHCP deployment model example and a PD deployment model example.

So, i have appended two proposed texts: 5.1 for what i understand to be the two most common DHCP deployment models, and 5.2 for what i understand to be the proposed PD deployment model.

Brian Carpenter already proved the feedback that a section like 5.1 might be contentuous and also incomplete because centralized address management has a wide range of options not only limited to DHCP but also involving Radius and other protocols - and there is even a whole working group in the making (CASM - coordinated address space management).

So maybe my proposed 5.1 would better go into an appended with sufficient preface stating exactly that these are just examples, and that there are many more deployment models, and that there are no current IETF recommendations or documents laying out such complete deployment pictures. (which IMHO is exactly one of the may problems). If folks feel that any more explicit description of even exemplary DHCP deployment models is inappropriate because it would get too contentuous, then its almost impossible to make statements about the limitations about DHCP in the introduction. But without trying to give an example and getting backpressure from reviewers, its IMHO a dead end:wq

                                                              edge

Edge DHCP server deployment requires every edge router connecting to CPE to be a DHCP server assigning IPv4/IPv6 addresses to CPE - and optionally IPv6 prefixes via DHCPv6-PD (RF3633) for IPv6 capable CPE that are router and have LANs behind them.

This requires various coordination functions via some backend system depicted as "config server": The address prefixes on the edge interfaces should be slightly larger than required for the number of CPE connected so that the overall address space is best used.
The config server needs to provision edge interface address prefixes and DHCP parameters for every edge router.  If too fine grained prefixes are used, this will result in large routing tables across the "Domain". If too coase grained prefixes are used, address space is wasted.

There is no standard describing algorithms for how config servers would best perform this ongoing dynamic provisioning to optimize routing table size and address space utilization.
There are currently no complete YANG models that a config server could use to perform these actions (including telemetry of assigned adddresses from such distributed DHCP servers).
For example, a YANG model for controlling DHCP server operations is still in draft (draft-liu-dhc-dhcp-yang-model-06).

                                                              edge

Dynamic provisioning changes to edge routers are avoided by using a central DHCP server and reducing the edge router from DHCP server to DHCP relay. The "configuration" on the edge routers is static, the DHCP relay function inserts "edge interface" and/or subscriber identifying options into DHCP requests from CPE (eg: rfc3046, rfc6221), the DHCP server has complete policies for address assignments and prefixes useable on every edge-router/interface/subscriber-group. When the DHCP relay sees the DHCP reply, it inserts static routes for the assigned address/address-prefix into the routing table of the edge router which are then to be distributed by the IGP (or BGP) inside the domain to make the CPE and LANs reachable across the Domain (the same.

There is no comprehensive standardization of these solutions. RFC3633 section 14. for example simply refers to "a [non-defined] protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router".

With the proposed use of ANI and Prefix-management ASAs using GRASP, the deployment model is intended to look as follows: 

                                              Roles
                                                |
                                                v   "Edge routers"

The network runs an ANI domain with ACP between some central device (eg: router or ANI enabled management device) and the edge routers. ANI/ACP provides a secure, zero-touch communication channel between the devices and enables the use of GRASP not only for p2p communication, but also for distribution/flooding.

The central devices and edge-routers run software to support this documents autonomic
IPv6 edge prefix management (PM). In the autonomic networking terminology, such software are called "Autonomic Service Agents" (ASA). The ASA for Prefix Management are called PM-ASA in this document and form together the Autonomic Prefix Management Function.

1. In a minimum Prefix Managmeent solution, the central device uses the "PrefixManager.Params"
GRASP Objective introduced in this document to disseminate network wide, per-role parameters to edge routers. The PM-ASA use the parameters applying to its role to locallly "configuring"
pre-existing addressing functions. Because PM-ASA do not manage the dynamic assignment of actual
IPv6 address prefixes in this case, the following options can be considered:

1.a The edge router connects via downstream interfaces to (host) CPE that each require an address.
The PM-ASA sets up for each such interface a DHCP requesting router (according to RFC3633) to request an IPv6 prefix for the interface. The routers address on the downstream interface can be another parameter from the GRASP Objective. The CPEs assign addresses in the prefix via RAs from the router or the PM-ASA manages a local DHCPv6 server to assign addresses to the CPEs. A central DHCP server acting as the DHCP delegating router (according to RFC3633) is required. Its address can be another parameter from the GRASP Objective.

1.b The edge router also connects via downstream interfaces to (customer managed) CPEs that are routers and act as DHCPv6 requesting routers. The need to support this could be derived from role and/or GRASP parameters and the PM-ASA sets up a DHCP relay function to pass on requests to the central DHCP server as in 1.a.

2. In a solution without a central DHCP server, the PM-ASA on the edge routers do not only learn parameters from "PrefixManager.Params" but also utilize GRASP to request/negotiate actual IPv6 prefix delegation via the GRASP "PrefixManager" objective described in more detail below.
In the most simple case, these prefixes are delegated via this GRASP objective from the PM-ASA in the central device.  These addresses are then used by the PM-ASA on the edge routers to edge routers to configure prefixes on their downstream interfaces to assign addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local DHCP servers (as in 1.a) to assign addresses via DHCP to CPE from the prefixes it received. This includes both host CPEs requesting
IPv6 addresses as well as router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and the local DHCP servers it starts. It need to monitor the address utilization and accordingly request more address prefixes if its existing prefixes are exhausted, or return address prefixes when they are unneeded.

This solution is quite similar to the initial described IPv6 DHCP deployment model without central DHCP server, and ANI/ACP/GRASP and the PM-ASA do provides the automation to make this approach work more easily than it is possible today.

3. The address pool(s) from which prefixes are allocated do not need to be taken all from one central location. Edge router PM-ASA that received a big (short) prefix from a central PM-ASA could offer smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could be used in such a way that the PM-ASA would find and select the objective from the closest neighboring PM-ASA, therefore allowing to maximize aggregation: A PM-ASA would only request further
(smaller/shorter) prefixes when it exhausts its own poll (from the central location) and can not get further large prefixes from that central location anymore. Because the overflow prefixes taken from a topological nearby PM-ASA, the number of longer prefixes that have to be injected into the routing tables is limited and the topological proximity increases the chances that aggregation of prefixes in the IGP can most likely limit the geography in which the longer prefixes need to be routed. 

4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASA can be built (indicated in he picture via a dotted intermediate router). This would require additional parameters to the "PrefixManager" objective to allow creating a hierarchy of PM-ASA across which the prefixes can be delegated. This is not detailed further below.

5.  In cases where CPEs are also part of the ANI Domain (eg: "Managed CPE"), then GRASP will extend into the actual customer sites and can equally run a PM-ASA. All the options described in points
1..4 above would then apply to the CPE as the edge router with the mayor changes being that
a) a CPE router will most likley not need to run DHCPv6 PD itself, but only DHCP address assignment,
b) The edge routers to which the CPE connect would most likely become ideal places to run a hierarchical instance of PD-ASAs on as outlined in point 1.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Jun 2017 21:24:38 +0200

Thankz, Duzongpeng,

inline:

> 	It is a realization problem and deleting it will not cause too much misunderstanding. 

Instead of deletion it might be more helpful to write text that explains as i did in
my review how RFC3633 is meant for interdomain (administative boundary) operation and
that the GRASP/ANI based approach is intra-domain and therefore could even be a great
complement to DHCPv6 - and not replace it.

> 	IMO, to talk too much about the details is not the document's purpose, i.e., validation of the designation of autonomic networking infrastructure.

Not sure what specific change proposal that refers to.

> 	We need make it clear about the main mechanism, for example, adding some topology pictures and TLA descriptions as suggested. 

Thanks.

> 	I suggest some other word here, such as "initial realization" or "prototype system". Is it OK?

Well, Brian is a native english speaker so i'd happily defer to his selection of words.

To me "architectural framework is always the best lame excuse for providing an overview and 
then NOT go into details. Just enough to feel safe that it can be built and will deliver
the claimed benefits. "initiaial realization" or "prototype" sounds to me as if 
a lot more details would have to be worked out.

> 	If it is agreed that to add all the texts is necessary, i.e., it is worthwhile to explain the multiple solutions in the document, I am ok with it.

So, the DHCP text i proposed has two purposes:

a) It is meant to justify paragraph 2 of section 3 (problem statement).
b) It is meant to show how the proposed picture/solution with PD could fill in exactly
   the not well defined/working pieces of one of the DHCP pictures.

Aka: Mayve lets wait with the DHCP texts for when Brian has time (after getting through GRASP),
so that we can understand his best insight and then finalize that part of the discussion.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Jun 2017 08:25:07 +1200

On 08/06/2017 07:24, Toerless Eckert wrote:
...
> Instead of deletion it might be more helpful to write text that explains as i did 

To be clear, my idea is to delete the PD flag from the objective, since it
actually serves no purpose. Explaining how DHCPv6/PD might be used along
with the GRASP mechanism is useful. Explaining how RADIUS might be used
is useful too. Anyway, there will be a new draft to discuss.

     Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Jun 2017 23:29:20 +0200

On Wed, Jun 07, 2017 at 01:01:34PM +1200, Brian E Carpenter wrote:
> or Radius, I think they are really out of scope.

So... i'll wait for the next rev wrt. to seeing an answer of how the text
can improve on better motivating an answer to the question "how does the
current solution suite suck and how could i imagine a PM solution to look
and operate like in deployment".

> As in a previous

I'd like that very much.

Btw: While we're at naming: The whole thing is IMHO in terms of the reference
model an "autonomic function". Would help cross-doc consistency to use that
term.

> to hand prefixes out to client routers. It should be completely

Pls. do not forget the most simple case where there are no "prefixes"
handed out, but just individual addresses and the PM-ASA just runs on
an edge-router setting up the interface prefixes locally.

> heuristic in https://www.cs.auckland.ac.nz/~brian/graspy/pfxm2.py

Thats fine. But the text didn't explain that. Aka: some understandable example of how
aggregation can happen.

> I think only experience will tell us the correct answer(s).

Right. But its IMHO a mayor important design aspect so it should be mentioned.

> draft-sun-casm-address-pool-management-yang

push(enless-reading-list, draft-sun-casm-address-pool-management-yang)

> Yes, it's Informational for a reason.

Thanks,
  Toerless

-- 
---
[email-masked]