[Casm] Comments on CASM documents

Ignas Bagdonas <ibagdona.ietf@gmail.com> Thu, 02 March 2017 12:48 UTC

Return-Path: <ibagdona.ietf@gmail.com>
X-Original-To: casm@ietfa.amsl.com
Delivered-To: casm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91172126FDC for <casm@ietfa.amsl.com>; Thu, 2 Mar 2017 04:48:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQEjtfxvowpT for <casm@ietfa.amsl.com>; Thu, 2 Mar 2017 04:48:40 -0800 (PST)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C65120727 for <casm@ietf.org>; Thu, 2 Mar 2017 04:48:39 -0800 (PST)
Received: by mail-lf0-x22f.google.com with SMTP id k202so33099547lfe.1 for <casm@ietf.org>; Thu, 02 Mar 2017 04:48:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=OZzblTLjuM8ZGMFItPQchkrvcSjy3uLVQf4F7zi++/c=; b=GRuJN73DUuU4BSIk1plkbgBa/Am4uoxB4St5aT0jyTRBeFvJBcuTeynK8Spx/JZIvu Gvq1aB66jnxS2nozrFZVOdQVWfiBNdabkHLcz8AWAvn8CKTeR4XQ0IZXUEwccimD8fV4 91NqGPMSdpFCC3uHss1hKc9U28l3qH/lazOsBsiVmhIeo3Bvt8AsDePZwKN7Jtu7b+Sk UyKoFrOKbUQmZEbtLMq1gBecZb130Vlb0nVWf1dA8lEmxq2kT4ktUh1f9Wksy7WA9KxV 0l0krF9t7F16sTcOtf1nkO96bWP76S0TEri28Mmclc2q1wSrLg3lJH+f6UW4LH1fmnCc VXEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=OZzblTLjuM8ZGMFItPQchkrvcSjy3uLVQf4F7zi++/c=; b=mjzFWIDSURZoKOSZvNei+kk6/Z60aS+oCLOBQ7wLPM95kFqy/ztb+di4nY4yckhywH 47f4BcmY+kCEkOec1BkwbDcn97WNq7nr7jiuHs+/hqQEeXqELzh9MwPC+7DQqk60XHQJ YI277v8kSnwm/hZ1QmVqTzwl0jg6P9RgIGh3ydrHEaF1kSJgw7kfqs44Y1NTU1wBQHnh 17ncL041ZcR0zmwtGlURZxPmmeYWvMc6/ocP+eIwgY96WSJZZUw26sBVWQnS5TRjW9Q8 B5GXPG907yUIfF/aJYxdZ8gQIdP9dT2KefL//liWeU+NOt4fNfmBMpCijZP8chMentCJ FrCA==
X-Gm-Message-State: AMke39kC87mNup8UgF4GOxevNVoYXrf5KZAqevuYOXwXhQ/YfoTYeFuM67+Q0lBlTdQbew==
X-Received: by 10.46.20.27 with SMTP id u27mr4896490ljd.103.1488458917280; Thu, 02 Mar 2017 04:48:37 -0800 (PST)
Received: from [192.168.32.185] ([84.15.180.153]) by smtp.gmail.com with ESMTPSA id c76sm1714700ljd.44.2017.03.02.04.48.36 for <casm@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Mar 2017 04:48:36 -0800 (PST)
To: casm@ietf.org
From: Ignas Bagdonas <ibagdona.ietf@gmail.com>
Message-ID: <52c72233-805d-5af7-7046-6a3353381c23@gmail.com>
Date: Thu, 2 Mar 2017 12:48:35 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------EE3BDDE52A276A9FB5C7AD0C"
Archived-At: <https://mailarchive.ietf.org/arch/msg/casm/ruLoqCKQr5rDaEhECPSSIol37aY>
Subject: [Casm] Comments on CASM documents
X-BeenThere: casm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Centralized Address Space Management <casm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/casm>, <mailto:casm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/casm/>
List-Post: <mailto:casm@ietf.org>
List-Help: <mailto:casm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/casm>, <mailto:casm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 12:48:41 -0000

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