[Casm] Comments on CASM documents

[Ignas Bagdonas <[e-mail]>]

Hi there.

An assorted list of comments on all 5 of CASM-related documents.

The focus of the documents seems to be on BNG-type of SP access 
solutions. That is an important use case but not the only one that 
relies on (semi)dynamic allocation of address blocks.

Prefix and address notations – an address is a form of prefix, it does 
not seem to be practical to single out a /32, /48, or /128 and treat 
them fundamentally differently.

DHCP is not the only form of pool based address block allocation.

What is meant by term ‘Interface’ here? There are intermixed 
interpretations of the term, in some places it tends to describe a 
programmatic interface and a protocol, in other places it is a 
conceptual control flow, in yet other places it seems to be a data model 
type of interface. What would be the deliverable of CASM solution?

The value of address management systems is in ability to assign an 
arbitrary attributes to blocks of addresses which are not interpreted in 
any way by the address management system itself, instead they are kept 
and propagated as opaque metadata on which the consumers of such 
metadata can react.

The concept of centralized IPAM – it is not practical to expect a truly 
centralized system of such impact and importance to be usable and 
resilient, there are many factors in network design (not all of them 
being only technical) that would mandate a distributed system instead. 
Something along the lines of RIR/LIR split.

Standardized interfaces to IPAM – how much is it feasible and how much 
is it needed? The text can be interpreted as an attempt to define a 
standard interface based on a specific product implementation.

IPAM access to network elements – there seems to be an assumption that 
IPAM element/system itself can interact with network elements. While it 
certainly can be the case, for practical deployments it would cause 
substantial manageability complexity increase by requiring coordination 
between IPAM and other entities that provide configuration and state 
information for network elements. Typically IPAM is seen as a backend 
database that does not directly have direct interface to network elements.

Address block utilization feedback from network elements into IPAM 
system could be an area worth exploring.

The overlay use case seems to assume that underlay infrastructure 
addressing is also coordinated by IPAM. That is not likely due to 
unnecessary manageability complexity increases.

Not everything relies on DHCP, and there are different use patterns of 
DHCP in SP access compared to SP services compared to DHCP use in 
enterprise environment. The more generalized approach with flexible 
attributes would be preferred to a specialized use case scenarios 
targeted for a specific place in network.

There are identifiers and address families other than IPv4 and IPv6 in 
use, and not excluding Ethernet tags, NVO3 VNIs, MPLS labels, 
identifiers related to VPN address families likely would be of value.

There seems to be a distinction of interpretation between physical and 
virtual network elements – that does not seem to be practical.

The examples of manageability constraints in use case examples can and 
in fact are solvable by automation even with existing systems without 
any new protocol work. IPAM as a function has close ties with operator’s 
internal systems and toolkits already.

Use cases could try to cover traffic accounting integration into address 
management too.

The fundamental question to me still remains on what is the scope of 
CASM – does it try to define CASM as an more abstract address management 
framework, or does it try to define CASM as a more concrete address 
management system?

Ignas