Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11

From: [email-masked]
Date: Mon, 9 Jun 2003 14:17:08 -0400

Kirk - thanks for your comments. My mailer doesn't do a good job of
inlining responses, so I'll refer to your numbering:

1. Agreed on the redundancy on packet matching, although the two mechanisms
and their matching criteria differ. How does this affect the decision to
use RFC3289, though?

2. Yes, we have Docsis classifiers, and now we have
RFC3289-filter-classifiers-as-used-for-subscriber-management. But the 3289
classifiers are doing what the old submgt Filter table was doing. So is the
confusion just in the word "classifier", or am I missing something else?

3. The ifIndex should be the Docsis MAC interface, which is a bidirectional
interface. Does this need to be clarified in the i-d?

4. I don't think there's any mandate that we move any functionality
unrelated to subscriber management under the 3289 umbrella. So yes, we have
token buckets (for the QoS MIB), but they do not appear in the context of
RFC3289.

5. Thee is no need to support diffServQEntry at all. zeroDotZero, Count
Actions, and Drop Actions are all that is needed. (see below for your
broader comment about the QoS MIB).

6. In recent versions of the subscriber management MIB, two classifiers
would have been needed to match the same port numbers in TCP and UDP, so no
savings there. Here's the relevant text from the -10 draft:

   docsSubMgtPktFilterUlp OBJECT-TYPE
       SYNTAX      Integer32 (0..256)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Upper level protocol to match.  If this value is 256,
       matches ALL ULP values.  Otherwise, this matches the specific
       protocol value.  Note that if the packet ULP is either 6 (tcp) or
       17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be
       consulted (if its entry exists) to see if this entry matches.
       If this value is neither tcp(6) nor udp(17), then that
       table is not consulted."

7. There are no values for the CM - this is a CMTS-only MIB. We *do* need a
section of the OSSI spec which calls out the minimal requirements for
implementation of RFC3289 on CMTSs. Do we need anything beyond that? I
don't think it lines up quite as cleanly as, for example, ifTable, because
the expressive power of RFC3289 lies in the flexibility of its structure.

(re your unnumbered summary):

On the most literal level, there is no reason why this change should cause
any confusion with the QoS MIB. Subscriber Management has always been
independent of the QoS MIB, and the choice to adopt RFC3289 representation
for packet-filtering  criteria doesn't change that. The QoS MIB will
continue to use its own criteria and will continue to be applied
independently of the representation of subscriber management filtering.

On a broader broader MIB-representational level,  I'd agree that there may
be work ahead to coordinate with the QoS MIB.  The QoS MIB is also
evolving, and may one day also choose to adopt conventions from RFC3289.
If so, the 3289 framework will need to convey the relationship between the
two processes. I believe that it has the expressive power to do so.  But,
for now, I'd be very reluctant to push for that level of unity with
something as necessarily complex as the QoS MIB. I'd rather make progress
independently for now.

As for implementation, keep in mind that even if QoS does go this way,
there is no requirement that the full arbitrary expressiveness of 3289 be
implemented - classifying the same packet through 3 meters, two merge
ramps, a toll booth and two truck stops. We can use 3289 as a tool to
express the problems we have - not to impose arbitrarily difficult queuing
regimes.

Regards,
Wilson Sawyer

                      "Kirk Friedman"                                                                     
                      <kfriedman@correl        To:       <[email-masked]>, <[email-masked]>     
                      ant.com>                 cc:       <[email-masked]>                             
                                               Subject:  RE: [ipcdn] draft submitted: subscriber          
                      06/09/03 12:50 PM         management MIB -11                                        

Hi Wilson,

     Sorry this took so long to put together.  I have real reservations
about this change.  While it does indeed remove some MIB redundancy and
allow for some future capabilities, it also complicates matters quite a bit
during implementation and for understanding how the QoS and Subscriber
Management MIBs work together on CMTS and CMs.

1) There is already redundancy between the DOCSIS 1.1 QoS MIB (currently
draft-ietf-ipcdn-qos-mib-08.txt) and the subscriber MIB in the packet
matching criteria.  In some sense that simplifies both implementation and
understanding how the two MIBs operate together.

2) It is confusing that classifiers for a DOCSIS system are no longer
uniquely defined.  There are DOCSIS packet classifiers for service flows
and
now classifiers associated with RFC3289 and the Subscriber Mgmt MIB.

3) The diffServDataPathEntry is indexed by ifIndex (which is fine) and
ifDirection.  It is somewhat based on the premise that an interface is
bi-directional.  The RFI interfaces are uni-directional.  So there needs to
be a description that indicates which direction applies for which interface
type for which device (CMTS/CM).  See last item.

4) In order to follow the compliancies of RFC3289, groups that are not
called out in the subscriber MIB are now mandatory.  The
diffServMIBTBParamGroup must be implemented because "This group is
mandatory
for devices that implement token-bucket metering functions."  The
diffServMIBMeterGroup is "... is mandatory for devices that implement
metering functions."  Both the CMTS and CM do this.

5) The requirements to include row pointers to diffServQEntry is also
confusing, even if zeroDotZero is applied in most cases.  Again, there is
alot of overlap with QoS MIB.

6) Two classifiers must be used if it is desired to match only TCP/UDP
packets.  This was one of the shortcuts in the previous version of the
Subscriber Mgmt MIB since this is the majority of the traffic on the
Internet.

7) One way out of this confusion would be to specify all the various values
for the objects of this MIB for CM and CMTS.  This would be like the
relationship between the ifTable and RFC2670 called Appendix B of the
DOCSIS
OSSI specification.  However, my understanding is that for DOCSIS 1.1 this
specification is going to be wrapped up soon.

     RFC3289 is used to provide a solution for both filtering and QoS.  But
requiring part of its implementation seems to me to open up a whole new can
of worms about implementation and precedence with the DOCSIS 1.1 QoS MIB.

Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Thursday, May 29, 2003 5:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: [ipcdn] draft submitted: subscriber management MIB -11

I have submitted a greatly-revised version of the subscriber management mib
(draft-ietf-ipcdn-subscriber-mib-11.txt), making use of the Diffserv MIB
(RFC3289) as outlined in my April 28 email. The good news is that the
document is now shorter, since much of filtering is now deferred to
existing facilities in RFC3289. This will be a significant implementation
change for CMTS vendors and operators.

The reason for the change is that the overlap with RFC3289 was so great
that I did not believe that the document would pass the broader review
needed for RFC approval. We gain by re-using the work that has already gone
into 3289. It also gives us the ability, although not mandated, to
integrate with other facilities within 3289.

I urge CMTS vendors and operators, in particular, to review this carefully
and make suggestions. As always, this document is the product of the
working group and only proceeds with working group consensus.

Respectfully submitted,
Wilson Sawyer
ARRIS

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

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

---

From: "Kirk Friedman" <[email-masked]>
Date: Wed, 11 Jun 2003 08:59:55 -0700

Hi Wilson,

Thanks for the prompt reply.  Walking through your responses

1. I agree its not a major issue.  More of a implementation simplification.

2. RFC3289 does not refer to
filter-classifiers-used-for-subscriber-managemment.  Considering 3289 by
itself is using classifiers for filters and for QoS management.  There is
definitely cause for confusion between this and the QoS MIB without
careful explanation.

3. The ifIndex makes sense if only applied to the Docsis MAC interface.
This should be clarified.

4. The question is how RFC3289 is interpreted for use in a CMTS and what
constitutes compliance.  If this MIB is going to be used in DOCSIS 1.1
systems then an ECR should immediately be drafted the OSSI Spec "Detailed
MIB Requirements" so there is no confusion about what is and is not required
to be implemented.  Otherwise the confusion will snowball.

5. Agree, see 4.

6. Agreed.

7. Agreed since the ifIndex is only applicable to the MAC interface.

To re-iterate comment 4.  If I take a look at RFC3289 without any other
documentation, then there are MIB entries other than the classifiers that
could be said to apply to the CMTS.  Section 3 "Management Information Bases
(MIBS)" should also be ECRd to change the requirements for the subscriber
mgmt mib and add a section for RFC 3289.  If not, there will be a large
disconnect between 1.1 systems and 2.0 systems that will make MSO management
that much more difficult.

Thanks again,

Kirk Friedman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 09, 2003 11:17 AM
To: Kirk Friedman
Cc: [email-masked]; [email-masked]
Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11

Regards,
Wilson Sawyer

                      "Kirk Friedman"
                      <kfriedman@correl        To:
<[email-masked]>, <[email-masked]>
                      ant.com>                 cc:
<[email-masked]>
                                               Subject:  RE: [ipcdn] draft
submitted: subscriber
                      06/09/03 12:50 PM         management MIB -11

Hi Wilson,

Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128

-----Original Message-----

Respectfully submitted,
Wilson Sawyer
ARRIS