Re: FW: Returned mail: see transcript for details

[Brian E Carpenter <brian@hursley.ibm.com>]

True, but we explicitly killed diffserv due a horrible daily spam 
load.

Use diffserv-interest@ietf.org instead. I will forward your note
there.

   Brian

"Wijnen, Bert (Bert)" wrote:
> 
> 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
> 
>   --------------------------------------------------------------------------------------------------------------------------------
> 
>    ATT3145135.TXTName: ATT3145135.TXT
>                  Type: Plain Text (text/plain)
> 
>   --------------------------------------------------------------------------------------------------------------------------------
> 
> Subject: Re-usability of DIFFSERV MIB
> Date: Fri, 4 Apr 2003 15:12:15 +0200
> From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> To: diffserv@ietf.org
> 
> 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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland