[OPSAWG] IPPROV BoF was declined

Benoit Claise <bclaise@cisco.com> Tue, 11 October 2016 16:27 UTC

From: Benoit Claise <bclaise@cisco.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
Message-ID: <6516fa03-8075-1401-933f-dda07c507db1@cisco.com>
Date: Tue, 11 Oct 2016 18:27:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------709E24ED4FD48B19F4652F44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/g74fPa3UuMPo4mKvj15-ZJpfLU4>
Cc: Sebastien Marchal <smarchal@cisco.com>, draft-xie-ps-centralized-address-management@ietf.org, draft-sun-i2apm-address-pool-management-arch@ietf.org, draft-sun-i2apm-address-pool-management-yang@ietf.org
Subject: [OPSAWG] IPPROV BoF was declined
Precedence: list

Dear all,

Let me inform you that the IPPROV 
<https://trac.tools.ietf.org/bof/trac/#OperationsandManagement>BoF was 
declined by the IESG/IAB.

Even if the IETF discussion started three IETF meetings ago 
(draft-sun-i2apm-address-pool-management-arch 
<http://tools.ietf.org/html/draft-sun-i2apm-address-pool-management-arch> 
and draft-sun-i2apm-address-pool-management-yang 
<http://tools.ietf.org/html/draft-sun-i2apm-address-pool-management-yang> 
were presented at IETF 94 in OPSAWG), this BoF request came as a 
surprise, on the last day just before the BoF submission deadline. As 
such, it didn't generate much (visible) discussion among the community.

draft-sun-i2apm-address-pool-management-yang 
<http://tools.ietf.org/html/draft-sun-i2apm-address-pool-management-yang> 
is about a YANG model for IPv4 management. Coming from an operator, it 
was specifically welcome, and OPSAWG seems like the perfect WG.

        This document describes an mechanism for a standard, programmatic
    interface for address pool management.   With the remaining IPv4
        address becoming more and more scattered, it is complicated to
        manually configure the address pools on lots of Broadband Network
        Gateways(BNGs) for operators.  By introducing SDN/NFV in BNG, the
        address pools can be allocatedin a centralized way.  It will not
        only simplify the address management for operators, but also improve
        the utilization efficiency of the address pool.

One issue is that IPAM use cases involve many different NMS/OSS 
different systems: IPAM, DHCP, DNS, Orchestrator, CMTS, Router, 
Firewall. All these different key players need to agree on these 
protocol exchanges/APIs/data models. Btw, I consider YANG models as 
APIs, as the APIs can be deduced from the models.
While we understand that any operators have this issue today and would 
like to have a simplified solution for address pool management, do we 
have all the key players from the NMS/OSS ecosystems involved, and a 
willingness to implement what would become a standard?

On top of that, some integration happens today, as those independent 
different systems have some embedded automation and event mechanisms. 
Today, the controller/orchestrator will take whatever is APIs are 
available. Granted, the integration is certainly clean and standardized, 
but aren't we risking to be late if a standard is approved in 1.5 years? 
Or maybe this effort should be supported in opensource, with de facto 
solutions?

Looking at the scope, it seems that it extended along the time: From 
IPv4 address management to IPv6 (well, obviously, we have the same 
issues with IPv6) to bandwidth and services management, along with some 
"possible protocol work", as mentioned in the BoF description.
A well defined scope is a plus for a BoF request.

This BoF would be have benefited from some more preparation and 
preliminary discussions with the community and the ADs.
The connection with ANIMA, as discovered on the mailing list, is 
certainly a prove of that.

Finally, not having a BoF is certainly not a reason for the community to 
stop organizing itself.

Regards, Benoit

[OPSAWG] IPPROV BoF was declined Benoit Claise