Subject: RE: RFC 2669 - CableDevice MIB Object ID { mib-2 69 } vs { experi ment al 83 }

From: Yost William <[email-masked]>
Date: Tue, 7 Sep 1999 17:41:55 -0500

That is what the requirement seems to imply to me.

----------- William H. Yost, Thomson Consumer Electronics ------------ 
..     Home of RCA, GE, and Proscan (317) 587-4816 [email-masked]   .

-----Original Message-----
From: Beifuss, Tom (SD-EX) [mailto:[email-masked]]
Sent: Tuesday, September 07, 1999 5:05 PM
To: [email-masked]'; [email-masked]'
Subject: RFC 2669 - CableDevice MIB Object ID { mib-2 69 } vs {
experiment al 83 }

Does the DOCSIS requirement for the RFC 2669 version of the Cable Device MIB
cause some
DOCSIS 1.0 CM's to use the old { experimental 83 } OID while other DOCSIS
1.0 CM's use
the new { mib-2 69 } OID?

If so, won't it be a big pain in the neck to view event log, set up filters
and the NMAccess table,
reset the modem, and all the other wonderful things the CD MIB controls?

Tom Beifuss

---

From: Jason Schnitzer <[email-masked]>
Date: Tue, 07 Sep 1999 17:04:27 -0600

Yost and Tom,

It's true -- the new CD MIB branch point will cause co-existence problems
for a short period. The key here is for:

1. Vendors to implement the new MIB ASAP and release it in their next rev.
(a cert. requirement anyway).
2. MSOs to schedule field upgrades that synchronize these new SW versions in
multi-vendor networks -- forcing management consistency across all CMs in a
system. Any modem that requests a config file containing varbinds based on
the new branch point will have already upgraded its software via the config.
file mismatch anyway.

From an MSO perspective, I don't think this'll be to big of a deal --
another revision control challenge in a sea of many :^)

Cheers,
Jason  

-----Original Message-----
From: Yost William [mailto:[email-masked]]
Sent: Tuesday, September 07, 1999 4:42 PM
To: 'Beifuss, Tom (SD-EX)'; [email-masked]';
[email-masked]'
Subject: RE: RFC 2669 - CableDevice MIB Object ID { mib-2 69 } vs {
experi ment al 83 }

-----Original Message-----
From: Beifuss, Tom (SD-EX) [mailto:[email-masked]]
Sent: Tuesday, September 07, 1999 5:05 PM
To: [email-masked]'; [email-masked]'
Subject: RFC 2669 - CableDevice MIB Object ID { mib-2 69 } vs {
experiment al 83 }

Tom Beifuss

---

From: Yost William <[email-masked]>
Date: Tue, 7 Sep 1999 19:06:28 -0500

There is a problem in that the config file needs to be generated one way for
modems with old software and a different way for modems with new software.
And you can't tell what software is loaded into the modem before you send
the config file.

But I believe the MSO's can handle this problem this way:  The config file
can be changed so it directs the modem to download the new image that
expects the MIB's in the new locations.  Then modems with the old software
will re-load and then reboot and be able to read the config file with the
new MIB elements correctly.

-----Original Message-----
From: Mike St. Johns [mailto:[email-masked]]
Sent: Tuesday, September 07, 1999 6:04 PM
To: Beifuss, Tom (SD-EX); [email-masked]';
[email-masked]'
Subject: Re: RFC 2669 - CableDevice MIB Object ID { mib-2 69 } vs {
experiment al 83 }

>reset the modem, and all the other wonderful things the CD MIB controls?

Yes - but we understand that this will be a pain from our side.  We can't 
use the experimental oids for this any longer due to IETF rules.  We're 
already used to having to play games with the OIDS based on the type of the 
modem.

Mike

---

From: "Mike St. Johns" <[email-masked]>
Date: Tue, 07 Sep 1999 17:12:28 -0700

Use a different sysIdentifier OID for old (-04 CMs) and new (RFC 
mibs).  Then its up to the MSO's (actually, @Home and Road Runner) to deal 
with the provisioning problems.

Mike

---

From: Yost William <[email-masked]>
Date: Tue, 7 Sep 1999 20:07:25 -0500

Actually, our sysObjectID will be different because it includes the software
revision loaded in the modem.  How will that help you though, since you
can't read the sysObjectID before sending the config file to the modem?

-----Original Message-----
From: Mike St. Johns [mailto:[email-masked]]
Sent: Tuesday, September 07, 1999 7:12 PM
To: Yost William; 'Mike St. Johns'; Beifuss, Tom (SD-EX);
[email-masked]'; [email-masked]'
Cc: Gervais John
Subject: RE: RFC 2669 - CableDevice MIB Object ID { mib-2 69 } vs {
experi ment al 83 }

Mike

---

From: Yost William <[email-masked]>
Date: Mon, 13 Sep 1999 10:22:09 -0500

I do not interpret the following as meaning that if any one MIB set fails,
all must fail:

(I04 C.8.13: "All such Sets MUST be treated as if simultaneous). 

Especially since there is no way to report such a failure.  So the only way
for an operator to tell if his config file works and be sure it doesn't
create any problems is to implement the config file on a set of cable modems
that are offline.

I interpret this requirement to mean that it must be done 'atomically' which
means that to set some of the elements and then allow other activities to
occur, such as SNMP gets or sets via the ethernet or RF interface to occur,
and then to set the rest of the elements would occur.  I interpet this
requirement as meaning that the setting must be done in one SNMP packet.
This would tell the headend that he would use CreateAndGo's for example,
instead of CreateAndWait and then Active to create rows.  There are some
advantages to allowing some of the MIB elements to fail (If they are not
recognized by the modem, I think they should still fail if they contain
improper values).  One reason is when you go to SNMP V3, there will be MIB
elements to put the modem into SNMP V3 mode.  This would mean you could not
run both SNMP V2 only modems and SNMP V3 modems on the same network because
the SNMP V2 modems would not accept the config file.

I would be in favor of not specifying the requirement that if any element of
the config file is unknown, the entire config file fails because this would
prevent a vendor from providing the greatest compatibility of old modems and
new modems on the same network. 

-----Original Message-----
From: Patrick Michael-LZZ007 [mailto:[email-masked]]
Sent: Monday, September 13, 1999 9:49 AM
To: [email-masked]'; [email-masked]'
Cc: Patrick Michael-LZZ007
Subject: RE: RFC 2669 - CableDevice MIB Object ID { mib-2 69 } vs {
experi ment al 83 }

Although the upgrade problem is moot for CW 11, we still have to solve it
for CW12 and it 
will continue to be an operational issue.   I introduce two possible
solutions in this memo and
ask for your feedback.

The simple fix of duplicating docsDev table varbinds from both locations in
a config file won't work,
because the current spec appears to require that if ANY varbind fails, ALL
of them do.
(I04 C.8.13: "All such Sets MUST be treated as if simultaneous). 

And the various solutions such as "upgrade all the modems and then have them
use the new
config file" also won't work, because there will always be "old" modems in
inventory that will
be deployed.  

In the absence of DHCP information that tells which MIB location to use, the
only thing I 
can think of that -does- work is a system for having per-modem config files
tied to the
modem's MAC address.  DHCP servers certainly permit this, with varying
degrees of 
pain and suffering.  What would be easiest for the operators, of course, is
a single config 
file to work with multiple vendor's modems, regardess of modem software
level.

Approach 1:  "Two names, one object"
-------------------------------------------------------
A possible short-term approach would be to require modems to support BOTH
MIB locations. In essence,
we would have separate names (OIDs) for the same objects (e.g. the docsDev
tables). 
I haven't done an object-by-object comparison of -04 vs 2669, but I don't
believe there would
be major conflicts with this "two names, one object" approach.  There are
some objects that
are only in 2669 (e.g.the policy table stuff), and these obviously would be
supported only under
the new OIDs.  Implementing "two names, one object" is not that hard,
either, since it 
involves compiling the new MIB with pointers to the same "handler" routines.

Adopting the "two names, one object" approach means that MSOs do not need to
make
any changes to their operations when modems appear supporting both MIBs.
When they
roll out mechanisms for per-CM config files, then they can introduce the
extended capabilities
of 2669 over -04. 

The major disadvantage of "two names, one object" is that the names are not
different :-).
RFC2669 still defines the name object names as CD MIB 04.  SNMP managers and
agents (that's we modem vendors) wishing to compile BOTH MIBs would need
some
convention for changing the name of the 2669 objects, e.g. replacing "docs"
with "docsIetf"
or something.  I admit this is gross, but "two names, one object" requires
unique names.

The "two-names, one object" approach is also the ONLY way that an MSO will
be able
to manage a MIXTURE of both old and new style modems from the same SNMP
manager.
That SNMP manager will require unique names for the two different OIDs. 

Approach 2:  "Varbind List TLV"
-----------------------------------------------
As mentioned, the main problem with including BOTH OID settings in the
config file
is that Docsis and SNMP  requires that if ANY varbind fails, ALL of them do.

We could fix this problem by adding a new TLV to the config file to define a
varbind LIST, rather than a single varbind.  The TLV would contain a single
ASN.1 
sequence (BER type code 0x30) that contains multiple internal sequences of
{OID, Value}.
The semantics would be that 
each varbind LIST is considered to be a single SET message to the modem.
Any particular varbind LIST setting could fail without affecting the others.

If we had a Varbind LIST TLV, that's a rather clean way out of our 2669 vs.
04 quandary.
The MSO could define two varbind lists in the config file: one with -04 OIDs
and one
with 2669 OIDs.  The modem would then be able to ignore the one it didn't
support,
without causing ALL of the varbinds in the config file to be ignored.  This
way,
a config file that contains both type of varbind lists would support both
"old" and "new" 
modem images.

The varbind LIST TLV idea also allows config files to contain multiple
vendor "private MIB"
settings.  As long as these are in separate varbind -lists-, the ones not
supported by
the modem are rejected, but those that -are- supported are implemeted
normally. 

So, I've talked about two approaches to the -04 vs. 2669 issue:
  1)  "two names, one object", in which modems would be required to accept
BOTH -04 and 
        2669 OIDs; and
  2)  "varbind list" TLV, where the -04 and 2669 settings would be in
different varbind lists,
       any one of which could fail without affecting the others. 

Consider this to be an informal request for discussion of  separate ECNs for
each approach.

What d'yall think?

-mike

> ----------
> From: 	Mike St. Johns[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Tuesday, September 07, 1999 5:12 PM
> > >Does the DOCSIS requirement for the RFC 2669 version of the Cable
> Device
> >MIB
> > >cause some

---

From: "Mike St. Johns" <[email-masked]>
Date: Mon, 13 Sep 1999 10:20:49 -0700

Bill's right, Mike's wrong.  The SNMP varbinds in the config file are 
simultaneous, but NOT atomic.  If one fails, the rest don't fail (unless 
for example you can't create a row without a missing object).

This was the intent of the original language - if not clear, perhaps we 
need an ECR.  The original discussion covering this topic took place about 
18 months ago and was primarily at the face to face meetings.  Basically, 
we needed a way of including in a config file vendor specific varbinds 
without having to write a config file per modem type.  If you don't treat 
it this way - problems.

Mike