Subject: [ipcdn] Some joint DOCSIS/IPCDN issues

From: Rich Woundy <[email-masked]>
Date: Fri, 17 Nov 2000 14:27:26 -0500

Folks,

Pak Siripunkaw and I had a phone call on joint DOCSIS/IPCDN issues on 
October 19th. This conversation generated new IPCDN work activities, which 
I wanted to communicate with the working groups.

Note that *all* IPCDN decisions occur in public, as a group, on the ipcdn 
mailing list. No IPCDN working group decisions occurred on this phone call.

Below are my notes on our conversation. We discussed three major subjects: 
DOCSIS applicability of RFC 2933 (formerly known as 
draft-ietf-ipcdn-igmp-mib-00.txt), new DOCSIS traps, and the "IP Spoofing 
Filters" in RFC 2669 (docsDevCpe group).

* DOCSIS Applicability of RFC 2933

The DOCSIS OSS group has developed an Engineering Change Request to their 
OSS specification, ECR OSS-R-00106, that describes how the IGMP MIB defined 
in RFC 2933 applies to DOCSIS 1.1 cable modem environments. With respect to 
IGMP capability, a DOCSIS 1.1 CM or CMTS can act in "passive mode" (where 
it merely passes through subscriber IGMP messages) or in "active mode" 
(where it terminates subscriber IGMP messages and originates its own IGMP 
messages, such as in the role of an IGMP proxy or a multicast router).

Similar functionality was originally proposed in IPCDN as 
draft-ietf-ipcdn-igmp-mib-00.txt, which was allowed to expire.

Since our phone call, Howard Abramson (original author of 
draft-ietf-ipcdn-igmp-mib-00.txt) has agreed to reintroduce the text in 
OSS-R-00106 into an updated IPCDN internet-draft.

Another related proposal was to extend the Cable Device MIB (RFC2669) to 
add one (or two) MIB objects that would manage the IGMP passive/active mode 
state of a DOCSIS 1.1 CM. In the two object version of the proposal, one 
object would report the current mode, and the other object would allow a 
manager to change the mode (if possible -- note that some modems are 
passive-only).

* New DOCSIS Traps

The DOCSIS OSS group has developed another Engineering Change Request to 
their OSS specification, ECR OSS-R-00108, that defines a set of trap OIDs 
for DOCSIS 1.1 cable modem environments (which might also be used for 
DOCSIS 1.0 as well). It also extends the RFC 2670 MIB with one new MIB 
object that indicates the DOCSIS operating mode (i.e. 1.0 versus 1.1).

RFC 2669 section 3.2.2 defined requirements for trap definitions but 
explicitly did not define any standard trap OIDs.

Since our phone call, Junming Gao (author of OSS-R-00108) and Pak 
Siripunkaw have agreed to create a new IPCDN internet-draft for the DOCSIS 
traps.

*  IP Spoofing Filters in RFC 2669 (docsDevCpe)

Pak stated that several MSOs and DOCSIS vendors were encountering 
development and deployment difficulties with the IP Spoofing Filters in RFC 
2669, i.e. the docsDevCpe group. The DOCSIS CM learns up to docsDevCpeIpMax 
IP addresses from subscriber equipment before packets are dropped. The 
default value for docsDevCpeIpMax is 1, which requires a DOCSIS 
configuration file override for many MSOs. The docsDevCpe group also 
appears to interfere with IP subnet renumbering, since the CM does not 
track DHCP conversations of subscriber equipment.

Pak and I agreed that these issues needed to be discussed on both the 
docsis-oss and IPCDN mailing lists. The most attractive solution appears to 
be to make the docsDevCpe group functionality optional, though we are still 
debating a little bit on the right approach. One approach (Pak's) is to 
declare the docsDevCpe group MIB objects to be optional. The other approach 
(Rich's) is to declare the default value of docsDevCpeIpMax to be -1, since 
that value effectively makes the docsDevCpe group non-functional.

Since our phone call, Pak has sent email on this subject to docsis-oss, 
which generated agreement from several vendors and no opposition.

-- Rich

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

---

From: Andre Lejeune <[email-masked]>
Date: Fri, 17 Nov 2000 19:48:30 -0500

Pak, Rich,

About IP anti-spoofing, one solution does not prevent the other:
declare the docsDevCpe group MIB objects to be optional AND
declare the default value of docsDevCpeIpMax to be -1. This
way, the solution (default of -1) that was put in place in
oss-n-99090 would still be valid. I would not like it if it
was now required to change 1.0 code that was providing the same
results.

André