Subject: [ipcdn] Re: rf mib draft v6 to draft v7 suggestions

From: [email-masked]
Date: Tue, 17 Jun 2003 13:57:56 -0600

Minnie,
        I do have a slight concern with this.
        Right now, a CMTS does not need to track whether or not a modem 
has NACO enabled or disabled.  From the 1.1 RFI spec, section C.1.1.3: 
"The value of this field does not affect CMTS service flow operation and 
does not affect CMTS data forwarding operation. ... With respect to DOCSIS 
v1.1 provisioning, a CMTS should ignore the NACO value and allocate any 
service flows that have been authorized by the provisioning server."
        If the MIB were changed so that the CMTS has to indicate if NACO 
is disabled, then that's one additional thing a CMTS is going to have to 
track that it doesn't now.  It may well be a minor change, but then again 
it might not be, and that makes me hesitate.
        Additionally, NACO is enforced at the modem, not at the CMTS. 
Therefore, it might actually be more logical to check that state at the 
modem than at the CMTS.
        Just a couple of thoughts.

Matt

Minnie Lu <[email-masked]>
06/17/03 11:49 AM

        To:     Joe Godas <[email-masked]>
        cc:     "Raftus, David" <[email-masked]>, "Rich Woundy (Work) (E-mail)" 
<[email-masked]>, [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], "Docsis 20 Reflector (E-mail)" 
<[email-masked]>, "Docsis Oss Reflector (E-mail)" 
<[email-masked]>, "Ipcdn List (E-mail)" <[email-masked]>, 
"Raftus, David" <[email-masked]>
        Subject:        Re: rf mib draft v6 to draft v7 suggestions

Hi, Joe,

Good suggestion.  Maybe in more general, no matter the BPI is enabled or 
not, a new state for the case that CM is registrationComplete but network 
access has being disabled by operator/system administrator.

Thanks!
Minnie

At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:
>"urn:schemas-microsoft-com:office:office" xmlns:w = 
>"urn:schemas-microsoft-com:office:word">
>Hi,
><I hope I'm not missing something obvious ;>
>
>Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI 
>state....I am concerned that we haven't captured the case where a modem 
>has successfully negotiated BPI but it's network access has been 
disabled.
>
>Implementation example: on a Cisco CMTS a BPI enabled voice product would 

>look like this:
>ubr110.cmts.hcvlny#scm | inc pt
><snip>
>MAC Address    IP Address      I/F       MAC         Prim 
>RxPwr  Timing  Num BPI
>                                          State       Sid  (db)   Offset 
> CPE Enb
>0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899 
>0.75   1946    0   Y
>
>This modem is showing as online (with BPI) whether or not it's network 
>access has been disabled due to customer not paying their bill.
>
>Is there a response code in the Mib that reflects this BPI negotiated 
>(with data disabled) state or do we have to rely on querying the 
>forwarding state of the actual CM?
>
>Thanks,
>Joe Godas
>Cablevision
>
>
>----- Original Message -----
>From: <mailto:[email-masked]>Raftus, David
>To: <mailto:[email-masked]>Rich Woundy (Work) (E-mail) ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]' ; 
><mailto:[email-masked]'>[email-masked]'
>Cc: <mailto:[email-masked]>Docsis 20 Reflector (E-mail) ; 
><mailto:[email-masked]>Docsis Oss Reflector (E-mail) ; 
><mailto:[email-masked]>Ipcdn List (E-mail) ; 
><mailto:[email-masked]>Raftus, David
>Sent: Tuesday, June 17, 2003 11:36 AM
>Subject: rf mib draft v6 to draft v7 suggestions
>
>Hi everyone,
>
>Since RF mib v2 draft 6 was released in March, I have received publicly 
or 
>privately 17 requests for updates/changes to appear in draft v7. The 
>people on the To: list have participated in either initiating or 
>commenting on the suggestions.
>
>Could I ask these people to please verify their suggestions as they are 
>listed below? This mib update from v6 to v7 is extensive - want to ensure 

>data is accurate before undertaking. The wider communities are also 
>welcome to comment.
>
>Thanks for your time,
>Dave
>
>
>1) Return name to pre draft v6 DOCS-IF-MIB from draft v6 
DOCS-IETF-RFI-MIB.
>
>Contributors - Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve 
Malenfant 
>Com21
>
>
>
>2) docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw 
bytes 
>- stuffed bytes) / raw bytes))
>since it assumes that MPEG payload consists only DOC MAC payload. As we
>know, MPEG could consist video payload and NULL packets. Suggest to 
remove
>this line since the first 2 lines in the formula are good enough.
>
>Contributor - Minnie Lu    Cisco
>
>
>
>3) Add discontinuity descriptions to all counters related to an 
interface.
>
>Contributor - Minnie Lu    Cisco
>
>
>
>4) docsIfCmtsInsertInterval - For the docsIfCmtsInsertInterval object, 
>there is no such thing as a
>"broadcast station maintenance" interval for new modems joining the 
>network.   Station should be
>changed to initial to make the text read - "The amount of time to elapse 
>between each broadcast
>initial maintenance grant.  Broadcast initial maintenance grants are used 

>to allow new cable modems
>to join the network.  Zero indicates that a vendor-specific algorithm is 
>used instead of a fixed time.
>Maximum amount of time permitted by the specification is 2 seconds."
>
>Contributor - Margo Dolas Broadcom
>
>
>
>5) docsIfCmtsModPreambleType - (Joel) 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
>meaningful 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?
>
>(Eduardo) for the benefit of clarifications wouldn't be good to have a 
>enumeration unknown(0) for this
>object when not a 2.0 burst ?
>Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is 
>tdma(1) a value unknown(0) is used for this object"
>I would say unknown(0) rather than unknown(3) since it looks like the 
>possible current implementation may be reporting
>'0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType
>
>Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs
>
>
>
>6) docsIfUpstreamChannelTable clone mechanism - improve descriptive 
>wording. 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.
>
>Contributor - Joel Demarty Juniper
>
>
>
>7) docsIfUpChannelPreEqEnable - add DEFVAL clause.
>
>Contributor - John Gillis ADC
>
>
>
>8) docsIfCmtsUpChnlCtrUcastGrantedMslots - In Cisco CMTS, we use IUC14 
>(reserved) and SID (HEX): 1FFF (max. of
>unicast sid number) for quite some time.
>Q: Should it be counted in docsIfCmtsUpChnlCtrUcastGrantedMslots ?
>My personal think that this objects seems to mean the
>meaningful  UNICAST SID, so user could get a good idea about the how many
>minislots really assigned to some meaningful CM.  So, the reserved IUCs
>should be excluded from this object though minislots for reserved IUCs 
are
>still be counted into docsIfCmtsUpChnlCtrTotalMslots.
>Minnie,
>I agree, I think IUC14 grants to SID 1FFF (assuming the CMTS reserves
>that SID to mean no CM) should not be counted in UcastGrantedMslots.
>I also think (and maybe this case is more obvious) than grants to SID 0
>should not be counted in UcastGrantedMslots.
>This brings up a question that I've had for some time.  Why does the
>Cisco CMTS use IUC14 and SID 1FFF????  The use of IUC14 is prohibited by
>the spec, since it is labeled as "Reserved", and SID 0 is already
>defined to mean "no CM".
>-Greg
>
>Contributors - Minnie Lu Cisco, Greg White Cablelabs
>
>
>
>9) docsIfCmStatusTable - possibly add new objects for successful/failed 
>ucc transactions.
>Hi, Alex,
>I do not think that this is good idea. What will you count into
>docsQosDCCAcks? The relationships between DCC Req/Rsp/Ack is important 
and
>should not be lost because of UCC additions. I guess, the better place 
for
>this counters is RFI MIB docsIfCmStatusTable. It may be extended in 
future
>versions.
>Regards.
>Lucy
>Hello all,
>A question about counting successful and failed UCC transactions.
>It seems like there is no counters dedicated for UCC failed or
>succeeded operation as it is for DCC transactions.
>The question is, since UCC is a subset of DCC operation for 1.1 modem,
>should the modem count UCC transactions in DCC counters (docsQosDCCs,
>docsQosDCCFails) ?
>Thank you in advance.
>
>Contributors - Lucy Pollak TI, Alex Betis Coresma
>
>
>
>10) docsIfUpChannelPreEqEnable, docsIfCmStatusEqualizationData - clarify 
>descriptions.
>Lucy,
>Sorry for the delay in responding.  I don't have an objection to your 
>proposal, as long as the
>format of the object is clear.
>To summarize, the object docsIfCmStatusEqualizationData will only include 

>the "value" from figure 8-23.
>In other words, the first byte reported in the MIB object will be the 
main 
>tap location.  A clarification
>should also be made to the description of docsIfUpChannelPreEqEnable to 
>indicate your interpretation (b).
>Regarding the question about reverse taps, figure 8-23 is a 
simplification 
>of figure 6-23 from the 1.1 RFI
>spec (which includes a format to encode reverse taps).  It seems to make 
>sense to me to use the format
>shown in that figure.  Perhaps this MIB object could be clarified to 
>reference both figures.
>-Greg
>
>Greg,
>to summarize our objections:
>1. MIB requires equalization data, then type/length is irrelevant.
>2. There are 2 possible types 4 (Transmit Equalization Adjust) or 9 
>(Transmit Equalization Set), which is
>irrelevant after convolution.
>3. To be consistent with DS equa data, some TLV should be added also into 

>it. What?
>We propose to use only value from referenced figure without type/length 
to 
>avoid questions in the future. If not,
>(2) and (3) should be clarified. I guess, that it will be also very 
>helpful if clarification (b) will be entered into MIB.
>Best Regards.
>Lucy
>
>Contributors - Lucy Pollak TI, Greg White Cablelabs
>
>
>
>11) docsIfSignalQualityEntry - clarify wording for back compatibility.
>In draft -03 the description of  docsIfSignalQualityEntry was changed
>from :
>docsIfSignalQualityEntry OBJECT-TYPE
>            SYNTAX      DocsIfSignalQualityEntry
>            MAX-ACCESS  not-accessible
>            STATUS      current
>            DESCRIPTION
>                "At the CM, describes the PHY characteristics of a
>                 downstream channel. At the CMTS, describes the PHY
>signal
>                 quality of an upstream channel.
>                 An entry in this table exists for each ifEntry with an
>                 ifType of docsCableUpstream(129) for Cable Modem
>Termination
>                 Systems and docsCableDownstream(128) for Cable Modems."
>            INDEX { ifIndex }
>            ::= { docsIfSignalQualityTable 1 }
>to :
>docsIfSignalQualityEntry OBJECT-TYPE
>         SYNTAX      DocsIfSignalQualityEntry
>         MAX-ACCESS  not-accessible
>         STATUS      current
>         DESCRIPTION
>             "At the CM, describes the PHY characteristics of a
>              downstream channel. At the CMTS, describes the PHY signal
>              quality of an upstream channel.
>              An entry in this table exists for each ifEntry with an
>              ifType of docsCableUpstreamChannel(205) for Cable Modem
>Termination
>              Systems and docsCableDownstream(128) for Cable Modems."
>         INDEX { ifIndex }
>         ::= { docsIfSignalQualityTable 1 }
>But now RFI mib also apply to 1.1 CMTSes with no concept of ifType 205
>but 129
>
>Contributor - Eduardo Cardona Cablelabs
>
>
>
>12) docsIfCmtsCmStatusValue - add new defined value 
>registeredBPIInitializing(9),
>deprecate former value operational(8).
>
>Contributors - Eduardo Cardona Cablelabs, Lucy Pollak TI, Minnie Lu 
Cisco, 
>David White Arris,
>Matt Schmitt Arris, Kirk Friedman Correlant, Fred Oko Stargus, Joe Godas 
>Kar-el, Steve Malenfant Com21
>
>
>
>13) Adjust compliance statements for objects designated optional. Add 
>separate augmentation table for
>optional objects in docsIfCmtsUpChannelCounterTable.
>
>Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike 
>StJohns Mindspring, Eduardo Cardona Cablelabs
>
>
>
>14) Add section explaining counter interaction between Docsis 
1.0/1.1/2.0.
>The QOS MIB tried to handle
>DOCSIS 1.1 changes to RFC2670. Now that rfc2670 is being obsoleted, the 
>rf-mib v2 and the DOCSIS OSS Specs is the place
>that should clearly state how these counters and other tables interact in 

>DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.
>I would even hope to see a section in the rf-mib v2, "Interoperation with 

>the version of DOCSIS" like or to replace
>what the DOCSIS QOS MIB has. This is the place to describe what table are 

>populated under the docsIfMib when the
>the modems are registering.
>This way this issue can be re-discussed and whatever conculsion is 
>reached, can be document in the description of those
>objects.
>
>Contributor - Will Murwin Motorola, Minnie Lu Cisco
>
>
>
>15) Change docsIfCmtsServiceTable to count packets for both upstream and 
>downstream flows.
>One of the things that has long been an issue with the RF MIB is that the 

>docsIfCmtsServiceTable only counts
>InOctets and InPackets (i.e. upstream packets only). If the reason for 
>keeping this table is to support DOCSIS
>1.0 modems would it also make sense to add downstream packet counts to 
>this table, too? Many CMTS'es already
>count this information and store it in a proprietary MIB. It would be 
nice 
>to standardize this as a requirement
>so that NMS such as usage monitoring systems could (a) count on it 
>existing and (b) find it in a standard location.
>
>Contributor - Andrew Sundelin Stargus
>
>
>
>16) Add 4 objects to docsIfCmtsCmStatusTable
>While writing DOCS-IETF-QOS-MIB version 9, I find myself still thinking 
>about Minnie suggestion of having
>docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets count for DOCSIS 

>1.1 and 2.0. Even though the QOS
>MIB has pawned off this discussion, I have had some thoughts on the 
subject.
>(1) If these counters where used to count the DOCSIS 1.1 and 2.0, than 
>this would the best place in all
>of the mibs to
>     get a quick summary of the upstream data received by a particular 
> modem, no matter the version.
>(2) At the same time, The rest of the docsIfCmtsCmServiceTable might not 
>make sense for DOCSIS 1.1 or 2.0
>However the more I looked around at the different counters that existed 
in 
>all of MIB required by DOCSIS,
>the more I kept looking for an overall counter on the CMTS to count data 
>packet received and transmitted
>for a particular CM.
>I would like to start a discussion on about adding 4 new object to the 
>docsIfCmtsCmStatusTable:
>docsIfCmtsCmStatusInPackets
>docsIfCmtsCmStatusInOctets
>docsIfCmtsCmStatusOutPackets
>docsIfCmtsCmStatusOutoctets
>While I understand that these counts can be gathered by via numerous 
>objects on both the CMTS and CM
>and then just appling simple math. However I want to query only one agent 

>and just get a quick summary
>without have to determine which version of DOCSIS the modem is, which 
will 
>determine which mibs I look etc.
>and objects I query.
>
>For example if I want query only one agent(i.e. the CMTS) and get the 
>number of transmitted and received
>data for each CM, then
>        (1) GET-NEXT the docsIfCmtsCmStatusRegMode to see what version of 

> DOCSIS this modem is operting
>
>        if 'docsis10(1)' then
>                      (2) WALK the entire docsIfCmtsServiceTable for 
> ifIndex and SID that
>                        have docsIfCmtsServiceNewCmStatusIndex that 
> matches the index for step (1).
>
>                      (3) Add the all the instances of 
> docsIfCmtsServiceInPacket for the
>                        ifIndex and SIDs that match from step(2) to get 
> the total Received packets from a CM.
>
>                      NOTE: Not sure it is possible to get from a CMTS 
> agent from the Standard MIBs the number of
>                          of packets transmitted to a single docsis 1.0 
> cable modem.
>
>        else if 'docsis11(2)' or 'docsis20()' then
>                      (2) WALK the docsQosCmtsMacToSrvFlowTable all for 
> the instances of that contain the
>                        same mac address.
>                      (3) Then GET the docQosServiceFlowPkts using the 
> ifIndex and
>                       service flow id from step(2). Add this to the 
total 
> of received or transmitted for this CM.
>                          To determine the direction of the flow use the 
> same index and query the docsQosServiceFlowDirection.
>This seems very complicated for something so simple. This is just a 
>suggestion of simple way the RF MIB v2 can correct the
>mistakes of the past.
>
>Contributors - Will Murwin Motorola, Minnie Lu Cisco
>
>
>
>17) docsIfCmtsCmStatusTimingOffset - possibly change decription of 
>existing object or
>add new object to reconcile unit differences between 1.1/2.0. Still under 

>discussion.
>
>Contributors - Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk 
>Friedman Correlant.
>
>
>
>
>
>
>
>
>
>************************************
>David Raftus
>Terayon Canada Ltd
>340 Terry Fox Drive, Suite 202
>Ottawa Canada  K2K 3A2
>
>[email-masked]
>613.592.1052  ext 222
>************************************
>
>

---

From: Joe Godas <[email-masked]>
Date: Tue, 17 Jun 2003 17:56:40 -0400

Interesting subtleties Matt, thanks.
It might be best solved in vendor implementation than spec....

In terms of using the Cmts as one stop shopping for CM device status, this has the potential for some thorny migration issues wrt backend customer service tools (at least the ones we have here! ;).  A combination of service class and CmtsCmStatusValue will likely have to be queried on the CMTS if the MSO decides to only trust the CMTS Mib to derive a given CM's provisioned state and status....

-Joe
  ----- Original Message ----- 
  From: [email-masked] 
  To: Minnie Lu 
  Cc: [email-masked] ; [email-masked] ; Raftus, David ; [email-masked] ; Docsis 20 Reflector (E-mail) ; Docsis Oss Reflector (E-mail) ; [email-masked] ; [email-masked] ; [email-masked] ; Ipcdn List (E-mail) ; [email-masked] ; Joe Godas ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; Rich Woundy (Work) (E-mail) ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Tuesday, June 17, 2003 3:57 PM
  Subject: Re: rf mib draft v6 to draft v7 suggestions

  Minnie, 
          I do have a slight concern with this. 
          Right now, a CMTS does not need to track whether or not a modem has NACO enabled or disabled.  From the 1.1 RFI spec, section C.1.1.3: "The value of this field does not affect CMTS service flow operation and does not affect CMTS data forwarding operation. ... With respect to DOCSIS v1.1 provisioning, a CMTS should ignore the NACO value and allocate any service flows that have been authorized by the provisioning server." 
          If the MIB were changed so that the CMTS has to indicate if NACO is disabled, then that's one additional thing a CMTS is going to have to track that it doesn't now.  It may well be a minor change, but then again it might not be, and that makes me hesitate. 
          Additionally, NACO is enforced at the modem, not at the CMTS.  Therefore, it might actually be more logical to check that state at the modem than at the CMTS. 
          Just a couple of thoughts. 

  Matt 

                To:        Joe Godas <[email-masked]> 
                cc:        "Raftus, David" <[email-masked]>, "Rich Woundy (Work) (E-mail)" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "Docsis 20 Reflector (E-mail)" <[email-masked]>, "Docsis Oss Reflector (E-mail)" <[email-masked]>, "Ipcdn List (E-mail)" <[email-masked]>, "Raftus, David" <[email-masked]> 
                Subject:        Re: rf mib draft v6 to draft v7 suggestions 

  Hi, Joe,

  Thanks!
  Minnie

  At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:
  >has successfully negotiated BPI but it's network access has been disabled.
  >
  >Since RF mib v2 draft 6 was released in March, I have received publicly or 
  >1) Return name to pre draft v6 DOCS-IF-MIB from draft v6 DOCS-IETF-RFI-MIB.
  >
  >Contributors - Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve Malenfant 
  >Com21
  >
  >
  >
  >2) docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw bytes 
  >know, MPEG could consist video payload and NULL packets. Suggest to remove
  >3) Add discontinuity descriptions to all counters related to an interface.
  >
  >should be excluded from this object though minislots for reserved IUCs are
  >docsQosDCCAcks? The relationships between DCC Req/Rsp/Ack is important and
  >should not be lost because of UCC additions. I guess, the better place for
  >this counters is RFI MIB docsIfCmStatusTable. It may be extended in future
  >versions.
  >Regards.
  >Lucy
  >Hello all,
  >In other words, the first byte reported in the MIB object will be the main 
  >Regarding the question about reverse taps, figure 8-23 is a simplification 
  >We propose to use only value from referenced figure without type/length to 
  >Contributors - Eduardo Cardona Cablelabs, Lucy Pollak TI, Minnie Lu Cisco, 
  >David White Arris,
  >14) Add section explaining counter interaction between Docsis 1.0/1.1/2.0.
  >count this information and store it in a proprietary MIB. It would be nice 
  >MIB has pawned off this discussion, I have had some thoughts on the subject.
  >However the more I looked around at the different counters that existed in 
  >without have to determine which version of DOCSIS the modem is, which will 
  >                       service flow id from step(2). Add this to the total