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

From: "Raftus, David" <[email-masked]>
Date: Wed, 12 Mar 2003 06:26:31 -0800

Hi Joel,
 
The methodology can be used for non-scdma parameters. Its necessity was
inspired by the number of scdma parameters, but it can certainly be used by
other channel types.
 
Please note that these objects are not new - they were introduced by draft
v2 of the rf mib, and were made mandatory for 2.0 CMTSs by oss2-n-02016 on
Feb 27/02 - significantly predates the first 2.0 qualification. They remain
optional for 1.1 CMTSs.
 
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: Wednesday, March 12, 2003 9:08 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
 
Thanks David for your detailed answers. See my comments/questions below.
-- Joël

*         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>
 
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

---

From: Joël Demarty <[email-masked]>
Date: Wed, 12 Mar 2003 18:20:22 +0100

Thanks David,

I cannot but accept your points, but, still, you are not answering the 
questions and arguments of my previous email.

Anyway, I'm definitely not convinced that the spec should stay as it is. 
For instance, the spec is vague about the minimum set of parameters that 
the CMTS must transfer during a clone operation to be DOCSIS 2.0 
compliant. Only those starting with docsIfUpChannelScdma or all 
parameters defining an SCDMA channel, like the channel width? Then what 
about the frequency?
Definitely, this clone mechanism is sophisticated enough that it would 
deserve a more detailed specification (and testing) and, as a 
consequence, an ECR.

-- Joël

Raftus, David wrote:

> Hi Joel,
>
>  
>
> The methodology can be used for non-scdma parameters. Its necessity 
> was inspired by the number of scdma parameters, but it can certainly 
> be used by other channel types.
>
>  
>
> Please note that these objects are not new - they were introduced by 
> draft v2 of the rf mib, and were made mandatory for 2.0 CMTSs by 
> oss2-n-02016 on Feb 27/02 - significantly predates the first 2.0 
> qualification. They remain optional for 1.1 CMTSs.
>
>  
>
> Thanks,
>
> Dave
>
>  
>
> /David Raftus/
> /Terayon Canada Ltd/
> /340 Terry Fox Drive, Suite 202/
>
> /Ottawa Canada  K2K 3A2/
>
> / /
>
> /[email-masked]           /
>
> /613.592.1052  ext 222/
>
> /************************************  /             
>
>  
>
>  
>
> *From:* Joël Demarty [mailto:[email-masked]]
> *Sent:* Wednesday, March 12, 2003 9:08 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
>
>  
>
> ·         In docsIfUpstreamChannelTable, can you help me understand 
> the benefit of docsIfUpChannelCloneFrom anddocsIfUpChannelUpdate 
> 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 totrue. 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>
>
>  
>
> 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".
>
> 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.
>
> 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.
>