Subject: [ipcdn] RE: draft-ietf-ipcdn-docs-rfmibv6

From: "Raftus, David" <[email-masked]>
Date: Tue, 11 Mar 2003 05:42:14 -0800

Hi Joel,
 
Please see replies inline.
 
Thanks,
Dave
 
************************************
David Raftus
Terayon Canada Ltd
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
 
[email-masked]           
613.592.1052  ext 222
************************************               

-----Original Message-----
From: Joël Demarty [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 5:58 AM
To: Raftus, David
Cc: Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 Reflector
(E-mail)
Subject: Re: draft-ietf-ipcdn-docs-rfmibv6
 
Hi David,

I have two questions regarding the new DOCS-IF-MIB (any version, not only
v5):
*	In docsIfCmtsModulationTable, the docsIfCmtsModPreambleType object
has 2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only
object in this table without a meaningfull default value when this parameter
does not make sense. For instance, for a TDMA modulation profile using
QAM16, the actual preamble type is indeed not QPSK0 but something else. Does
it make sense to have a value of 0 in this case, like
docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles?
<dave>
Note that the description for this object states, "Preamble type for Docsis
2.0 bursts". It would be logical to deduce from this that this preamble type
is not applicable to Docsis 1.x bursts. Your statement is understood though
- a casual user not familiar with preamble usage may misunderstand this.
<end dave>
 
*	In docsIfUpstreamChannelTable, can you help me understand the
benefit of docsIfUpChannelCloneFrom and docsIfUpChannelUpdate objects.
Contrary to the usmUserCloneFrom object in usmUserTable, these objects
cannot be used to duplicate the configuration of an existing and active
channel because parameters like the frequency cannot be duplicated. Another
use of these objects would be to let the user configure each object of a row
independently until the parameter are compatible with each other (valid
upstream configuration) and commit the new configuration in a single
operation by setting docsIfUpChannelUpdate to true. But this seems overkill
as the SNMP protocol already allows to commit a partial or complete row
change in a single operation and all SNMP tools like UCD-snmp or SNMPc give
the user the capacity to modify parameters independently and commit the
change in a single operation. If you take the example of SNMPc, you can
adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to
commit these new parameters in a single operation. If the commit fails, the
adjusted parameters are still available for further adjustments. 
On the other hand, this mechanism has a potential drawback because the user
decides the ifIndex of the template upstream channel entry but this ifIndex
may conflict with existing or reserved ifIndex (e.g for multiple logical
upstream channels).
Given these points, I propose to have the objects docsIfUpChannelCloneFrom
and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. 
<dave>
This methodology was arrived at after much consultation with CMTS vendor
representatives. They are indeed intended to permit the operational
parameter update of a currently active channel. A clone of a currently
active channel is created 'offline'. The desired parameters are adjusted
using the offline channel clone. This methodology allows the underlying
software to verify the new parameters' compatibility with each other before
the snmp commit begins. This would not be possible during processing of an
snmp packet containing many SET commands.
<end dave>
 
Thanks,

-- Joël

Raftus, David wrote:

Hi,
Please find attached an update of draft-ietf-ipcdn-docs-rfmib from v5 to v6.
The draft has been updated to incorporate editorial suggestions from the Feb
13 IPCDN WG meeting, and is intended for last call submission.
Thanks,
Dave
************************************
David Raftus
Terayon Canada Ltd
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
[email-masked] <mailto:[email-masked]>            
613.592.1052  ext 222
************************************

---

From: Joël Demarty <[email-masked]>
Date: Wed, 12 Mar 2003 15:07:52 +0100

Thanks David for your detailed answers. See my comments/questions below.
-- Joël

>       benefit of docsIfUpChannelCloneFrom and docsIfUpChannelUpdate
>       objects. Contrary to the usmUserCloneFrom object in
>       usmUserTable, these objects cannot be used to duplicate the
>       configuration of an existing and active channel because
>       parameters like the frequency cannot be duplicated. Another use
>       of these objects would be to let the user configure each object
>       of a row independently until the parameter are compatible with
>       each other (valid upstream configuration) and commit the new
>       configuration in a single operation by setting
>       docsIfUpChannelUpdate to true. But this seems overkill as the
>       SNMP protocol already allows to commit a partial or complete row
>       change in a single operation and all SNMP tools like UCD-snmp or
>       SNMPc give the user the capacity to modify parameters
>       independently and commit the change in a single operation. If
>       you take the example of SNMPc, you can adjust the SCDMA
>       parameters off-line and when satisfied, asks SNMPc to commit
>       these new parameters in a single operation. If the commit fails,
>       the adjusted parameters are still available for further
>       adjustments.
>       On the other hand, this mechanism has a potential drawback
>       because the user decides the ifIndex of the template upstream
>       channel entry but this ifIndex may conflict with existing or
>       reserved ifIndex (e.g for multiple logical upstream channels).
>       Given these points, I propose to have the objects
>       docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for
>       DOCSIS 2.0 CMTS. 
>
> <dave>
>
> This methodology was arrived at after much consultation with CMTS 
> vendor representatives. They are indeed intended to permit the 
> operational parameter update of a currently active channel. A clone of 
> a currently active channel is created 'offline'. The desired 
> parameters are adjusted using the offline channel clone. This 
> methodology allows the underlying software to verify the new 
> parameters' compatibility with each other before the snmp commit 
> begins. This would not be possible during processing of an snmp packet 
> containing many SET commands.
>
> <end dave>
>
>  
>
According to your explanations, these 2 objects are defined only as a 
convenience for the CMTS vendors because no technical issue prevents to 
implement a CMTS that would be capable of "verifying the new parameters' 
compatibility with each other before the SNMP commit begins".

Moreover, if you read the DESCRIPTION clause of these 2 objects, it is 
written that "[these objects] may also be used at the vendor's 
discretion for non-SCDMA parameter adjustment". Thus, on non-SCDMA 
channels, these objects are either optional or useless because the MIB 
only requires the transfer of SCDMA parameters.

This means that this clone mechanism is not usable as is from an NMS 
viewpoint because it cannot be used consistently on every type of 
upstream channels. So we should either make these objects mandatory for 
all non-SCDMA parameters and channel types or simply make these objects 
optional and supported at the CMTS vendor's discretion.

As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my 
proposition to have theses objects docsIfUpChannelCloneFrom and 
docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.

Thanks,

-- Joël