Subject: [ipcdn] RFI v2 MIB Draft 08

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 4 Nov 2003 08:58:01 -0700

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-masked] [mailto:[email-masked]] 
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-masked]
+353-21-7305826

---

From: "Eduardo Cardona" <[email-masked]>
Date: Sun, 23 Nov 2003 15:49:28 -0700

Thanks Lucy for the comments, 

Hence you agree with Jason, wouldn't be the case of that text you
proposed well explained in overal inf RFC 2863 which is normative for
RFI MIB module? 
particularly  

3.1.2.  Guidance on Defining Sub-layers
3.1.13.  IfAdminStatus and IfOperStatus
3.1.14.  IfOperStatus in an Interface Stack

The text was in particular for upstream channel but would that be
applicable also for the CATV MAC interface, 

Since a CMTS contains other interfaces not associated with DOCSIS
interface, I would prefer leave all the requirements in RFC 2863

Let me know if I am missing something,

Thanks

Eduardo

-----Original Message-----
From: Pollak, Lucy [mailto:[email-masked]] 
Sent: Sunday, November 23, 2003 10:26 AM
To: Eduardo Cardona; Ipcdn (E-mail)
Cc: Richard Woundy @ Comcast; Jean-Francois Mule; DOCSIS OSS Majordomo
List
Subject: RE: RFI v2 MIB Draft 08 

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

 

 

Thanks
 
Eduardo

to:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2003 10:20 AM
To: DOCSIS OSS Majordomo List
Subject: ifAdminStatus sets to docsCableUpstream (129)

Hello, 

     
       ifTable           Comments 

<SNIP>

<SNIP>     

An example: 

interface                        ifAdminStatus 

interface                        ifAdminStatus 

Thanks, 

Jason Tessier
QA Engineer

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Pollak, Lucy" <[email-masked]>
Date: Sun, 23 Nov 2003 19:25:38 +0200

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) 

 

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

 
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.

 
Thanks
 
Eduardo

 

 

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 } 

 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
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. 

       ifTable           Comments 

<SNIP>

<SNIP>     

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 

interface                        ifAdminStatus 

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