Subject: RE: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS

From: Mike MacFaden <[email-masked]>
Date: Fri, 9 Feb 2001 09:16:38 -0800

The idea seems fine to me.

I would be concerned that a system that relied on
"traps" to keep CM to IP bindings would not be
reliable. "informs" could be used if one is using SNMPv2c
or SNMPv3 to get the reliability at the cost of memory to 
hold on to the trap till it can be sent/ack'd. 

The general term that encompases both terms is "notification"
as defined in the SMIv2 RFCs.

When using traps, there should related objects
one can poll in case the trap do not arrive
at its intended destination.

Off the top of my head, the only existing IETF standards track 
MIB modules I can think of that provide IPv4 addresses are
ipNetToMedia (RFC 2011) and and nlHostTable (RFC 2021)
from RMON2-MIB.

Regards,
Mike MacFaden
www.riverstonenet.com

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

---

From: Kirk Friedman <[email-masked]>
Date: Wed, 28 Feb 2001 11:46:21 -0800

Good morning,

I don't agree that a CMTS should send these traps on behalf of a CM.  This 
was discussed as a possibility in the DOCSIS Account Management/OSS meeting 
last year ( August 25 ) and rejected.  The only way I am aware of for a 
CMTS to really keep up with the CMs IP address is to keep track of the DHCP 
Acknowledgement from the DHCP server to the CM.   The DHCP acknowledgments 
have to be used because there could be multiple DHCP servers sending DHCP 
offers to a CM.  A bridging CMTS is not directly involved with layer 3 
traffic and requiring it to snoop and keep track of this in order to send 
traps to the CMTS was deemed too burdensome.

The second reason that you would not want the CMTS, or even the CM, to send 
the trap was because the trap could be lost.  A discussion of using INFORM 
Trap type ( requires confirmation ) could eliminate the lost trap issue but 
that also lead to another discussion of what to do if the INFORM is not 
acknowledged and it also requires the CMTS (or CM) to keep a state machine 
going for the INFORM until its acknowledged.

At that time, the emphasis ( agreed to by the MSO members present at the 
meeting ) was for the DHCP server to communicate with the rest of the NMS 
to keep track of IP addresses vs CM mac addresses and assignments.
Sending a trap when a CM comes online and offline is relatively easy as all 
CMTS' have to know that anyway.   One concern raised by MSOs and others was 
getting standard DHCP server providers to add this extra hook.  I believe 
the response was that there are many DHCP vendors out there who would be 
willing to add these hooks in order to get a share of the MSO market.

Kirk Friedman
Correlant Communications (formerly TurboNet Communications)
15110 Avenue Of Science
San Diego, CA., 92128-3405
Ph:   858-451-1061 x105
Fax: 858-451-1061 x1775
[email-masked]

-----Original Message-----
From:	Azlina Ahmad [SMTP:[email-masked]]
Sent:	Wednesday, February 28, 2001 10:15 AM
To:	Pirozzi, Timothy (Max Power)
Cc:	[email-masked]'
Subject:	Re: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS

I agree that the CMTS should be able to send these 2 traps on behalf of
the CM.  In fact, Cisco CMTS is already sending a "trap" when a modem
comes online and goes offline  :)

Azlina

"Pirozzi, Timothy (Max Power)" wrote:

>  Hi All,After receiving responses to my orginal email, I have realized
> that the idea of having CMs send traps to update a Management
> Stationmay have been more of a burden than serve a useful
> function.But, I still believe this ability will solve a major problem.
> Might I suggest a new means to this end. Would it be possible toallow
> the CMTS to send these traps on behalf of a CM? Any feedback on this
> idea would be greatly appreciated.Thanks TimPS.Here is my original
> email.
>
>      -----Original Message-----
>      From: Pirozzi, Timothy (Max Power)
>      [mailto:[email-masked]]
>      Sent: Wednesday, February 07, 2001 3:47 PM
>      To: [email-masked]'
>      Subject: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS
>
>      Hi All,
>
>      I was looking at the DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS
>      and I was looking for a fuctionality not mentioned by any of
>
>      the traps currently listed.
>      Here is the background:
>
>      Currently, in a customer's cable modem deployment keeping
>      track
>      of a CM's IP is a nightmare. Every morning a list has to be
>      retrieved from DHCP server and that is used to reorganised
>      to
>      what was in the snmp management system usually some type of
>      model.
>      This is a big concern to many ISPs
>
>      I was wondering if there could be two more Traps added to
>      the
>      list of cm traps currently available.
>
>      The first trap would say I (the CM) have just connected
>      up and the DHCP gave me this IP.
>
>      The second trap would say I (the CM) have just leasted a new
>      IP
>      from the DHCP server here is the OLD IP and here is the NEW
>      IP.
>
>      What does everyone think?
>
>      Thanks
>
>      Tim
>