Re: [OPSAWG] draft-richard-opsawg-cna-mib-00.txt

["David Harrington" <[e-mail]>]

Hi,

I reviewed this document quickly.
I have some concerns.

1) I think the title "Centralized Network Architecture" is misleading.
This is not about an architecture for Centralized Networking. It is an
architecture for centralized network management.

2) I think the term Centralized is misleading. This architecture is
about distibuted management, handled through distributed configuration
servers, that configure and monitor a set of "dumb devices", such as
wireless access points. The server is central only to the set of local
devices, not centralized in the network.

3) That said, I believe the CAPWAP model for locally-centralized
configuration management could, and should, be extended to also work
in wired networks. With the emergence of "dumb" devices like netbooks,
which might connect via a wireless or wired interface, this method of
locally-centralized configuration could be very useful.

4) I found the beginning of section 5 difficult to understand. It
discusses the "SNMP based management model of centralized network
architecures", and I am not sure I agree with such a characterization.
An SNMP system can have multiple management applications interacting
with multiple managed devices. They have an m:n relationship, not a
1:n relationship. I think the problem here is again the use of
"centralized network architecture" terminology. 

5) The description in section 5 is really about using SNMP to
distribute configurations to distributed configuration servers, and
then to use a CAPWAP-like protocol to actually pass the configuration
from the distributed server to the CAPWAP-managed device. 

6) SNMP has a long history, but has not been wildly successful as a
configuration protocol, or a configuration distribution protocol. The
IETF is moving away from the SNMP-and-MIB Management Framework, and
moving toward an approach that permits multiple co-existing management
protocols to be used for different purposes, including SNMP-and-MIB.
Designing an SNMP-only approach to distribute configurations to
support this CAPWAP-like distributed configuration approach might not
be the best approach. 

- I recommend that this document clearly separate the AC-TP
relationship from the configuration distribution mechanism. 
- I recommend the protocol distribution mechanism (and design
objectives, etc.) be described in an information model. See RFC3444
for discussion of information models versus data models.
- I recommend the document (or a supplementary document) could then
show how SNMP and the MIB data model defined here could be used. In
that way, this proposal could be supplemented, using other
configuration protocols, such as Netconf, to provide configuration
distribution to the AC.

7) This MIB module deliberately reuses existing MIB modules, and I
applaud this. Hopefully when data models are developed for other
configuration protocols, such as Netconf, care will be taken to reuse
existing information models, such as those underlying the Interfaces
MIB and associated MIB modules.

8) It is unclear whether this MIB module depends on an unchanging
ifIndex, which has proven problematic in real world devices with
hot-swap capabilities. IfAlias was developed to help address the lack
of persistence of ifIndexes across reboots. The TP Profile and TP
Virtual Interfaces solution should be looked at closely to ensure
assumptions about interfaces have not become outdated assumptions.

9) COPS-PR and Netconf have both been designed explicitly to address
configuration needs. Both found the need to have a configuration lock
capability to prevent conflicts from multiple NM interfaces (and for
this proposal, an SNMP lock would probably be needed to prevent two
different SNMP managers from trying to change the configuration
distributed to the AC at the same time.)

10) In section 7.3, it says "By combining the MIB modules,"; I think
this should be "By querying both the CMA-MIB and ENTITY-MIB modules,"

11) In section 8, part 2, I think there is an assumption that ifIndex
values will be assigned in a range from 1..number of interfaces. I am
not sure that assumption is valid. If I recall correctly, especially
in response to hotswap capabilities, some vendors have used structured
numbering, especially in chassis environments. For example, a vendor
might use ifIndex 41 to indicate slot 4, interface 1. If slot 4 was
hotswapped and the new blade had a different number of interfaces,
only the ifIndexes of slot 4 would be impacted.

12) This document uses stations and termination points. I know this is
normal terminology for 802.11 and CAPWAP, but I think it deserves more
explanation in the terminology section. Since MIB modules are often
distributed without the surrounding text, I think the description
clauses also need to be clear about what the terminology means,
especially in the TEXTUAL-CONVENTIONs. 

cnaTpSessions and cnaStationSessions have a rnage of 0..65535; why
were these numbers chosen? Are these carry-overs from 802.11 limits?
Can a wired AC support more TPs or stations?

in cnaTpProfiletable, "An operator could change a TP's configuration
by changing
         the values of parameters in the corresponding TP profile." I
think this needs to be more explicit about how this happens. Just
changing the value of an object does not seem sufficient to me. 

cnaTpProfileTpId says the tunnel protocol **should** contain the MAC
address. If the tunnel does not contain the mac address, then this
system doesn't work right? So shouldn't this be a MUST?

cnaTpProfileRowStatus says the system should ask the operator to
confirm the decision to delete the profile. SNMP has no support for
such a confirmation step. I recommend you put this into an
implementer's guidelines section of the document, not in the MIB
itself. Why is it not a MUST to remove the related network access MIB
objects? When is it acceptable to not delete such objects? 

cnaTpEntry says an operator can query TP status using identifier of a
TP profile. Since you say this in the cnaTpEntry, I assume you mean
you can GET a cnaTpEntry using an identifier of TP profile. I believe
that is incorrect. SNMP knows how to GET an entry using the INDEX to
this table, which is cnaTPId not cnaTpProfileId.

cnaTpProfileTpModelNumber says it "Represents the model name of a TP."
Then you should call it cnaTpProfileTpModelName. This is an
SnmpAdminString, which is not necessarily a number. It also says the
TP modle name reflects the number of PHY interfaces. You seem tp be
greatly overloading this field and making unwarranted assumptions
about its content, and what you can surmise from its content.

cnaTpIpAddress Represents the IP address of a TP. Can a TP have a
non-IP address?

cnaTpState enumerations appear to be based on 802.11. 

"        The information such as software version of a specific TP
         could be accessed through the" cnaTpPhyIndex. I believe that
is incorrect, if you are
using SNMP, which only provides access through the INDEX. SNMP does
not have secondary or indirect indexes. Are you sayiong that
cnaTpPhyIndex matches the INDEX of another table that contains
siftware version? If so, then you need to be explicit about the other
table. 

If you are going to provide pointers to other tables this way, you
need to pay close attention to fate sharing. If the row with
cnaTpPhyIndex=79 is deleted, than does the entry in another table with
INDEX=79 need to be deleted to match? Or if the entry in another tbale
with INDEX=79 is deleted, then must this row that points to that row
need to be deleted? What happens if the row pointed to does not exist?
What happens if the row pointed is deleted and then a new row with the
same INEX is created? Now this row points to the wrong row in the
other table. is the other tabel defined in a way that prevents reuse
of a deleted index from happening?

cnaInterfaceMappingIfId makes assumptions abotu hwo the numbering is
done. Where is it required that the first interface is numbered the
same on different TPs? Is that first number a 0 or a 1? Why can a
vendor not choose to start numbering at 101 (to represent say, blade 1
interface 1)?

cnaInterfaceMappingVirtualIfIndex Represents the index value that
uniquely identifies a
         TP Virtual Interface. The interface identified by
         a particular value of this index is the same interface as
         identified by the same value of the ifIndex.
While not usually a problem, you should recognize that contexts are an
important part of instance identification in SNMP. If I query an SNMP
agent for its interfaces table using one context, and I query the same
SNMP agent for its interfaces table using a different context, I can
get different interfaces tables. 

For example, a chassis with a single SNMP agent and multiple blades
might send back different ifIndex lists depending on whether the
context is "blade 1" or "blade 2" or "". When queried for "blade 1",
the ifIndex list might be 1,2,3. When queried for "blade 2", it might
return 1,2,3,4. When queried for the "" context, you might get 101,
102, 103, 201, 202, 203, 204. You need to be more careful with your
assumptions. RFC3411 describes this in section 3.3.1.

cnaStationAssociateTime "Represents the time when the station is
associated with
         the network." Is that the same time as the station is
associated with the TP specified in cnaStationAssociateTpId? is that
the same time station is associated with the interface specified in
cnaStationAssociateMappingIfId? What's a network?

cnaTpEventsStatsRebootCount is only triggered by a crash, and not
another type of reboot? Then why not call it Crash Count?

cnaTpEventsStatsLinkFailureCount "Represents the number of times that
a tunnel protocol
         connection with an AC has failed due to link failure." From
whose prespective? the TP or the AC? If there is a filure connecting
to the AC, then that happens at the TP, right? But the TP doesn't
necessarily support MIB statistics; it is the AC that supports SNMP.
So shouldn't the count be done by the AC? i.e., the AC should count
the number of failures to connect to the TP. This problem seems to
apply to all your counters.

Are the notifications designed to be sent by the AC or the TP? I
thought the TP did not support SNMP. I think you need to make this
clearer.

I think the security consideration should discuss the different
security domains involved. The security chosen to secure the SNMP
messages between an NMS application and the AC might be of a different
strength, or even based on different users, than the CAPWAP-like
protocol used between the AC and TPs. Using SNMPv3 might secure the
sensitive information between the NMS and the AC, but the data might
be totally unsecured between AC and TP. 

The security considerations doesn't really discuss the implications of
exposing the stats table or the eventsstatstable. What about the othr
objects in the MIB? How sensitive are they?












*For those who might wonder, the authors work for H3C (aka
Huawei-3Com), I officially work for Huawei USA, and am doing work for
HuaweiSymantec. These are three different companies, and I have no
Huawei-related interactios with the authors, only IETF-related
interactions.

David Harrington
[e-mail]
[e-mail]
[e-mail]







-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Monday, June 29, 2009 10:30 AM
To: [e-mail]
Subject: I-D Action:draft-richard-opsawg-cna-mib-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : A Generic MIB for Centralized Network
Architecture
	Author(s)       : Y. Shi, J. Wang
	Filename        : draft-richard-opsawg-cna-mib-00.txt
	Pages           : 37
	Date            : 2009-06-29

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols.  In particular, it
describes the managed objects for a generic model to manage the
centralized network architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-richard-opsawg-cna-mib-00.tx
t

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.