[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: Returned mail: see transcript for details

Mmmm... I thought that we normally keep WG mailing lists alive,
even after the WG closes. At least for some time, no?

Thanks,
Bert 

-----Original Message-----
From: Mail Delivery Subsystem
[mailto:MAILER-DAEMON@auemail1.firewall.lucent.com]
Sent: vrijdag 4 april 2003 15:13
To: bwijnen@lucent.com
Subject: Returned mail: see transcript for details


The original message was received at Fri, 4 Apr 2003 08:12:18 -0500 (EST)
from h135-85-76-62.lucent.com [135.85.76.62]

   ----- The following addresses had permanent fatal errors -----
<diffserv@ietf.org>
    (reason: 550 <diffserv@ietf.org>... User unknown)

   ----- Transcript of session follows -----
... while talking to ietf-mx.ietf.org.:
>>> RCPT To:<diffserv@ietf.org> NOTIFY=FAILURE,DELAY
<<< 550 <diffserv@ietf.org>... User unknown
550 5.1.1 <diffserv@ietf.org>... User unknown

Attachment: ATT3145135.TXT
Description: Binary data

--- Begin Message --- 
FYI and possible (re-)action.

Thanks,
Bert 

-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: donderdag 3 april 2003 0:58
To: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert)
Cc: ipcdn@ietf.org
Subject: RE: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt


Wilson and Bert,

One immediate issue I found, in trying to re-use the DiffServ MIB for the
DOCSIS Subscriber Management functionality, was in the structure of the Data
Path table, which is the initial table for packet classification.

The Data Path Table is the first lookup table in the DiffServ MIB, and it
uses ifIndex and ifDirection as the initial parameters to match. Upon a
match, the typical next table is the Classifier Table (although the entry
may point to other Tables in the MIB).

In the Subscriber Management MIB, the first lookup table is
docsSubMgtCmFilterTable, which uses the particular cable modem, upstream or
downstream direction (similar to ifDirection), and CM versus CPE (CPEs are
behind the CMs on the subscriber home network) source/target to map to a
filter-group. The filter-group points to a set of rows in the
docsSubMgtPktFilterTable for packet classification. The four subscriber
management filter-groups are configured through the DOCSIS 1.1/2.0 CM
registration processes.

The two gaps I see in DiffServ MIB functionality are:
1. The DiffServ MIB assumes that a uniform set of classifiers are applied to
all traffic flowing over a particular interface, because in the general
network case, one cannot differentiate traffic except by classification. The
Subscriber Management MIB assumes that distinct sets of classifiers are
applied to different groups of cable modems that co-exist on the same cable
RF interface, because the DOCSIS registration process aids the CMTS in
differentiating different CM/CPE traffic sources and sinks. Note that there
can be thousands of CMs from different filter-groups co-existing on the same
cable RF interface, so an operator would need to add thousands of Classifier
Table entries to match on specific CM/CPE sources and sinks.
2. The Subscriber Management MIB differentiates between CM source/sink
traffic and CPE source/sink traffic. The CMTS knows the difference between
CMs and CPEs on the same cable RF IP subnet(s) via the DOCSIS registration
process. Using the current DiffServ MIB, making distinctions between CM and
CPE traffic would require many more entries in the Classifier Tables, in
order to enumerate the CM source IP addresses.

It looks like the DiffServ folks were looking to use more generic parameters
than the ifIndex during the development of the MIB. From section 2.2 of RFC
3289:

   Another possible direction of abstraction is one using a concept of
   "roles" (often, but not always, applied to interfaces).  In this
   case, it may be possible to re-use the object definitions in this
   MIB, especially the parameterization tables.  The Data Path table
   will help in the reuse of the data path linkage tables by having the
   interface specific information centralized, allowing easier
   mechanical replacement of ifIndex by some sort of "roleIndex".  This
   work is ongoing.

I don't know how to apply this "ongoing work" to the immediate issues that
are solved by the current Subscriber Management MIB.

-- Rich
--- End Message ---