Subject: [MIB-DOCTORS] Mandatory Requirement for configuration by SNMP

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 5 Nov 2006 19:36:31 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "David B Harrington" <[email-masked]>
Date: Sun, 5 Nov 2006 10:34:39 -0800

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
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Sunday, November 05, 2006 9:37 AM
> To: MIB Doctors; [email-masked]
> Cc: Mark Townsley
> Subject: [MIB-DOCTORS] Mandatory Requirement for 
> configuration by SNMP 
> 
> 
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Nov 2006 11:02:56 -0800

Hi -

> From: "David B Harrington" <[email-masked]>
> To: "'Romascanu, Dan (Dan)'" <[email-masked]>; "'MIB Doctors'" <[email-masked]>; <[email-masked]>
> Cc: "'Mark Townsley'" <[email-masked]>
> Sent: Sunday, November 05, 2006 10:34 AM
> Subject: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement for configurationby SNMP 
...
> advancement until suitable alternative solutions are completed and
...

I'm having trouble fitting these two paragraphs together.
The first is consistent with the changes suggested, but
the second is a strong argument against making those
changes.

Randy

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 6 Nov 2006 12:14:15 -0800

Hi Randy,

I think we need to prepare other WGs to move to a multi-protocol
Management Framework, but we do not yet have a standardized
multi-protocol solution for them to move to. Until we have a data
model for netconf (presuming netconf will be the second NM protocol
supported), we should still stress the importance of making IETF
technologies manageable with standardized NM solutions. 

That means we still need to stress the importance of providing a data
model in our only existng standard data modeling language, SMIv2,
until a new data modeling language becomes available.

Between now and then we should ask the managed-technology WGs to
develop a MIB module for management now, and request a corresponding
information model that can be used to develop a netconf data model
later.

AND between now and then, the management protocol development
community needs to figure out how to make the two protocols
compatible, so we do not have two standard protocols that cannot share
information.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Monday, November 06, 2006 11:03 AM
> To: 'MIB Doctors'; [email-masked]
> Cc: 'Mark Townsley'
> Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement 
> forconfigurationby SNMP 
> 
> Hi -
> 
> > To: "'Romascanu, Dan (Dan)'" <[email-masked]>; "'MIB 
> Doctors'" <[email-masked]>; <[email-masked]>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Nov 2006 12:52:18 -0800

Hi -

> To: "'Randy Presuhn'" <[email-masked]>; "'MIB Doctors'" <[email-masked]>; <[email-masked]>
> Sent: Monday, November 06, 2006 12:14 PM
> Subject: RE: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement forconfigurationby SNMP 
>
> Hi Randy,
> 
...

These are all strong arguments for retaining the current MUSTs.
I'm even more puzzled by the suggestion to replace them with
SHOULDs.

Randy

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 6 Nov 2006 16:15:01 -0500

Hi,

Yes, I appreciated Dave's insightful observations (esp. wrt things like
quantifying "timely" and being more precise about multi-manager
operations when stipulating requirements), but agree with Randy (per
below) wrt the MUST vs SHOULD implications of them.

Cheers,
BobN

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 3:52 PM
To: 'MIB Doctors'; [email-masked]
Cc: 'Mark Townsley'
Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] Mandatory
Requirementforconfigurationby SNMP 

Hi -

> To: "'Randy Presuhn'" <[email-masked]>; "'MIB Doctors'"
<[email-masked]>; <[email-masked]>
...

Randy

_______________________________________________
OPS-NM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-nm

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 6 Nov 2006 17:44:04 -0800

Hi,
 
I think the OPS-NM community and the whole IETF and the operator
community need to make a decision about whether the right approach is
to have a multi-protocol solution, or a single protocol solution.
 
If we accept a multi-protocol approach, then the MUST should be a
SHOULD in the management requirements. However, we need to be very
clear how to make the different interfaces "interoperable" (e.g. they
need to be able to share data, reuse security approaches, correlate
different access control policies, etc.). The balance of security
properties is a special concern, because it maks little sense to put a
multi-lock stell door on the front of the house, and only an unsecured
screen door on the back of the house.
 
If we accept one-protocol-to-do-all-FCAPS, then the MUST should be a
MUST, and the IETF NM community needs to define how the protocol and
data models and transport and secuirty can be extended to perform the
functions which the original protocol does not necessarily do well.
So if SNMP is kept as the single protocol, we need to make it possible
to add such things as task-oriented interfaces (functions/methods),
and support for XML rather than ASN.1 and BER, among other things.
 
My personal preference is to stay with a single protocol to do all
things, because it offers the best interoperability, BUT NOT because I
like SNMP. I find the peek-poke design of SNMP to be comparable to
assembly language. That was approrpriate for 1988, but it is no longer
adequate in 2006. We need to bring our one-interface up to at least a
functional programming interface style, and possibly to a design that
offers some of the benefits (and hopefully not all the problems of) an
object-oriented design. A one-protocol solution needs to be changed to
allow support of functionality that is more consistent with real
operational requirements.  
 
If we cannot update our one protoocl to an interface that is more
consistent with good software programming approaches, then we should
move to a multi-protocol approach and at least shoot for interoperable
monitoring, plus interoperable configuration, plus interoperable
accounting, and so on.
 
One approach that is a compromise is to allow multiple protocols to
utilize a consistent MIB approach, but to update the MIB information
model to use an XML interface rather than OIDs/ASN.1/BER, and to
develop mechanisms to extend the capabilities of the MIB information
modeling to match real world data structures.
 
(and Mark, I apologize if you don't want to be involved in this whole
discussion.)
 
David Harrington
[email-masked]
[email-masked]
[email-masked]

 

  _____  

From: Jon Saperia [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 4:00 PM
To: David B Harrington
Cc: 'Randy Presuhn'; 'MIB Doctors'; [email-masked]; 'Mark Townsley'
Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement
forconfigurationby SNMP 

David, 

This is certainly one way to go. Another possibility would be to:

1. Create a single standard that all believe meet all needs WRT FCAPS.

2. The IETF would then be in a position to define a core set of
objects in all areas that would support interoperability better and
with less cost than is currently the case.

In the interim, your suggestion is perhaps the best that can be done.
/jon

On Nov 6, 2006, at 3:14 PM, David B Harrington wrote:

Hi Randy,

David Harrington
[email-masked] 
[email-masked]
[email-masked]

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 11:03 AM
To: 'MIB Doctors'; [email-masked]
Cc: 'Mark Townsley'
Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement 
forconfigurationby SNMP 

Hi -

Cc: "'Mark Townsley'" <[email-masked]>
Sent: Sunday, November 05, 2006 10:34 AM
Subject: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement 

for configurationby SNMP 
...

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

...

Randy

Jon Saperia

---

From: Jon Saperia <[email-masked]>
Date: Mon, 6 Nov 2006 19:00:01 -0500

David,

Jon Saperia