RE: RFI v2 MIB Draft 08
"Pollak, Lucy" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
Eduardo and Jason. Sorry for so late answer. I guess, the text your mentioned should not be removed, but modified. Let me return to Jason's example. I guess, the problem here is the mistake, which always is done for Admin and Oper status. Admin status is a command, which should be reflected in Oper status of lower layers, but should not change the Admin status of lower layers (in this point I agree with Jason). (1) Initial state: interface ifAdminStatus ifOperStatus docsCableUpstream US 1 up up docsCableUpstreamChannel 1 up up docsCableUpstreamChannel 2 up down (not in use) docsCableUpstreamChannel 2 up down (not in use) docsCableUpstreamChannel 2 up down (not in use) (2)Setting ifAdminStatus of US 1 to down results in this: interface ifAdminStatus ifOperStatus docsCableUpstream US 1 down down docsCableUpstreamChannel 1 up down docsCableUpstreamChannel 2 up down docsCableUpstreamChannel 2 up down docsCableUpstreamChannel 2 up down (3)Setting ifAdminStatus of US 1 to up results in exactly (1). This is my understanding of MIB text: "The administrative status of this interface. This reflect the total status of all the channels under this interface. So if at least one channel has a physical connection this interface has connection. Any SNMP SET on this interface will cause a SET to all the channels under this interface." So, from my POV "This reflect the total status of all the channels under this interface. So if at least one channel has a physical connection this interface has connection." is applicable for ifOperStatus, not ifAdminStatus. The "Any SNMP SET on this interface will cause a SET to all the channels under this interface." should be rephrased: "Any SNMP SET on this interface will influence the ifOperStatus of all the channels under this interface." The implicit SNMP SET will cause very complex implementation of different lower-higher layer state superposition. But, I guess, that wording about status of lower layer influenced by ifAdminStatus of higher layer should be kept. Regards. Lucy -----Original Message----- From: Eduardo Cardona [mailto:[email protected]] Sent: Tuesday, November 04, 2003 5:58 PM To: Ipcdn (E-mail) Cc: Richard Woundy; Jean-Francois Mule; DOCSIS OSS Majordomo List Subject: RFI v2 MIB Draft 08 Hi dear IPCD folks and OSSI reflector Few updates of the last posted Draft -08 I am planning to do a quick update to the MIB draft after the IETF meeting to correct the below minor issues, Just a quick note, I will wait until the resolutions of the IETF IPCDN meeting to take actions on that. Jason Tessier, identified a description in the idAdminStatus in the draft that is not needed and does not reflect the needs for interface Stack based on RFC 2863 to propagate ifAdminStatus top to bottom of the stack for and up/down transition. Only ifOperStatus is propagated because of ifAdminStatus changes or inherent interface changes. Also for docsIfUpChannelUpdate related to the clone mechanism, all the related objects were updated to not being SCMA specific. One objects left out of the updates docsIfUpChannelUpdate. The proposed change will align that object description. See at the end of the email the Jasson arguments for the ifAdminStatus change Below are the proposed changes, let us know any changes. Thanks Eduardo update to RFI Mib v2 with two changes: 1- ifAdminStatus requirements for UpChannels should read. 3.2.5.2. ifEntry for Upstream interfaces ifAdminStatus The administrative status of this interface. 2- Re-define the requirement for docsIfUpChannelUpdate as below - All the associated objects for the Clone Mechanism are no longer referencing exclusively to SCDMA. The intention now is normalize this requirements for all type of profiles. - change GEN-ERROR for genError and COMMIT_FAILED_ERROR for commitFailed docsIfUpChannelUpdate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Used to perform the transfer of adjusted SCDMA parameters from the temporary upstream row to the active upstream row indicated by the docsIfUpChannelCloneFrom object. The transfer is initiated through an SNMP SET of TRUE to this object. The SNMP SET will fail with a GEN_ERROR (snmpv1) or COMMIT_FAILED_ERROR (snmpv2c/v3) if the adjusted SCDMA parameter values are not compatible with each other. Although this object was created to facilitate SCDMA parameter adjustment, it may also be used at the vendor's discretion for non-SCDMA parameter adjustment. An SNMP GET of this object always returns FALSE." ::= { docsIfUpstreamChannelEntry 17 } to: docsIfUpChannelUpdate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Used to perform the transfer of adjusted parameters from the temporary upstream row to the physical upstream row indicated by the docsIfUpChannelCloneFrom object. The transfer is initiated through an SNMP SET to 'true' of this object. The SNMP SET failure returns an error genError (snmpv1) or commitFailed (snmpv2c/v3) if the adjusted parameter values are not compatible with each other. Reading this object always return 'false'." ::= { docsIfUpstreamChannelEntry 17 } -------------------------------- IfAdminStatus Jasson email -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Wednesday, October 22, 2003 10:20 AM To: DOCSIS OSS Majordomo List Subject: ifAdminStatus sets to docsCableUpstream (129) Hello, In the DOCS-IF-MIB there's a requirement that ifAdminStatus sets to a docsCableUpstream interface also be applied to the docsCableUpstreamChannel interfaces under it. 3.2.5.2.1. ifEntry for Upstream interfaces in Cable Modem Termination Systems ifTable Comments ============== =========================================== <SNIP> ifType The IANA value of docsCableUpstream (129). <SNIP> ifAdminStatus The administrative status of this interface. This reflect the total status of all the channels under this interface. So if at least one channel has a physical connection this interface has connection. Any SNMP SET on this interface will cause a SET to all the channels under this interface. So in the case where there are multiple logical channels under one upstream interface, if you want to enable/disable the docsCableUpstream interface all of the logical channels associated with it are also set to up/down. I think that this makes it difficult for the operator to set the ifAdminStatus of the docsCableUpstream interface without affecting several logical channels, some of which may not even have been enabled in the first place. If an operator sets the ifAdminStatus of the docsCableUpstream to down, the set will already be reflected in the ifOperStatus of the docsCableUpstreamChannels under it. The OperStatus of the docsCableUpstreamChannels will reflect their own state, taking into account the upper layer and modulation profiles, etc. I don't see a need for this requirement. An example: interface ifAdminStatus docsCableUpstream US 1 down docsCableUpstreamChannel 1 up docsCableUpstreamChannel 2 down (not in use) docsCableUpstreamChannel 2 down (not in use) docsCableUpstreamChannel 2 down (not in use) Setting ifAdminStatus of US 1 to up results in this: interface ifAdminStatus docsCableUpstream US 1 up docsCableUpstreamChannel 1 up docsCableUpstreamChannel 2 up docsCableUpstreamChannel 3 up docsCableUpstreamChannel 4 up The effect is that with one set 4 ifAdminStatus are affected, and 3 channels are put into use that may not be desired. I'm thinking of proposing an ECR to remove this requirement from the MIB. Thanks, Jason Tessier QA Engineer ARRIS Communications Ireland Ltd. [email protected] +353-21-7305826