[OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement for configuration by SNMP

"David B Harrington" <dbharrington@comcast.net> Mon, 06 November 2006 18:10 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8vM-0008M9-Rh; Mon, 06 Nov 2006 13:10:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggms2-0006sH-OE; Sun, 05 Nov 2006 13:37:26 -0500
Received: from relay1.san2.attens.net ([192.215.81.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggms1-0001Cs-AF; Sun, 05 Nov 2006 13:37:26 -0500
Received: from Harrington73653 (0127bhost64.starwoodbroadband.com [12.105.247.64]) by relay1.san2.attens.net (8.13.6/8.13.6) with ESMTP id kA5Ib7ik011759; Sun, 5 Nov 2006 18:37:12 GMT
From: David B Harrington <dbharrington@comcast.net>
To: "'Romascanu, Dan (Dan)'" <dromasca@avaya.com>, 'MIB Doctors' <mib-doctors@ietf.org>, ops-nm@ietf.org
Date: Sun, 05 Nov 2006 10:34:39 -0800
Message-ID: <036301c70109$0e9a5fc0$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-reply-to: <AAB4B3D3CF0F454F98272CBE187FDE2F0BAC603D@is0004avexu1.global.avaya.com>
Thread-Index: AccBAO6rhewlWuHXQY6mVZ1QdqAbuAAAXO4A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
X-Mailman-Approved-At: Mon, 06 Nov 2006 13:10:19 -0500
Cc: 'Mark Townsley' <townsley@cisco.com>
Subject: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement for configuration by SNMP
X-BeenThere: ops-nm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OPS Area NM e-mail list <ops-nm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ops-nm>, <mailto:ops-nm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ops-nm>
List-Post: <mailto:ops-nm@ietf.org>
List-Help: <mailto:ops-nm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ops-nm>, <mailto:ops-nm-request@ietf.org?subject=subscribe>
Errors-To: ops-nm-bounces@ietf.org

Hi,

At this point in the evolution of IETF management, we have only one
management protocol that is widely deployed and offers vendor-neutral
interoperability. No other IETF-related protocol offers the
widley-deployed standardized generic management capabilities of SNMP.
I believe therefore, we should recommend only SNMP as a viable generic
purpose management protocol at this time.

Since possible alternatives are on the horizon, and the IETF
management framework has always permitted the support for alternative
protocols for carrying MIB module data, I suggest that any long-lived
requirements section RECOMMEND, but not REQUIRE, SNMP so that
alternative protocols could be used in the future to meet these
management functionality requirements.

However, I believe that MIB modules and support for SNMP should
continue to be required as a condition of IETF standards-track
advancement until suitable alternative solutions are completed and
available.

I have not read the complete ANCP document, just the management
requirements section, so some of my comments may be incorrect when
considered in light of the complete document.

Here is the list of management requirements:

6.  Management related requirements

   o  The configuration of the IP layer (e.g.  IP address assignment)
      for the Control Channel MUST be possible via SNMP on both the AN
      and the NAS.

Dbh:/MUST/SHOULD/

   o  When the operational status of the Control Channel is changed
      (up>down, down>up) a linkdown/linkup trap SHOULD be sent towards
      the EMS.  This requirement applies to both the AN and the NAS.

Dbh: agree

   o  The Access Node MUST provide the possibility using SNMP to
      associate individual DSL lines with specific Access Node Control
      Sessions.

Dbh: /MUST/SHOULD/

   o  The Access Node MUST notify the EMS of Access Node Control
      configuration changes in a timely manner.

Dbh: I think this is a requirement that is poorly specified. What is
timely? Is it a protocol **requirement** (ala RFC2119) that such
notification be received by the EMS to ensure the network continues to
operate properly, or is this MUST an attempt to strengthen a
nice-to-have feature rather than a real requirement of the protocol
interoperation? Is there a clear specification of what the EMS MUST do
after receiving such a required notification?

   o  The Access Node MUST provide a mechanism that allows the
      concurrent access on the same resource from several managers
(EMS
      via SNMP, NAS via ANCP).  Only one manager may perform a change
at
      a certain time.

Dbh: this is another requirement that seems poorly specified. How long
is a certain time? What is "one manager"? Does this mean SNMP and the
CLI cannot perform a change at the same time on the access node? What
if the change is to different aspects of the access node
functionality? Does ANCP provide a method for locking the management
processing to prevent concurrent access at a certain time, as Netconf
and COPS-PR have done?

The SNMP protocol allows concurrent access to functionality, including
SET functionality. The order in which SNMP messages are processed,
including for example the processing of concurrent messages on a
multi-threaded system, is an implementation-dependent decision. This
ANCP management requirement would require a change to the processing
model of SNMP.  

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net

 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] 
> Sent: Sunday, November 05, 2006 9:37 AM
> To: MIB Doctors; ops-nm@ietf.org
> Cc: Mark Townsley
> Subject: [MIB-DOCTORS] Mandatory Requirement for 
> configuration by SNMP 
> 
> 
> 
> I would like to hear the opinion of the MIB Doctors and OPS-NM folks
> concerning the following. The Access Node Control Protocol (ANCP)
> framework document
> http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-
> 00.txt has
> a management-related requirements section (Section 6) which is quite
> nice. The issue is that the section includes MUST requirements for
> configuration by SNMP. 
> 
> Is this what we want at this stage of evolution of the IETF
management
> protocols, or should we advice them to do something different? 
> 
> Dan
> 
> 
>  
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www1.ietf.org/mailman/listinfo/mib-doctors
> 



_______________________________________________
OPS-NM mailing list
OPS-NM@ietf.org
https://www1.ietf.org/mailman/listinfo/ops-nm