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

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 16 Jul 2003 10:19:20 -0600

Wilson,

I like the work on the RFC3289 integration, nice job.

Going through the changes you proposed in draft11 w.r.t. mandating part
of RFC 3289, find below a suggestion to address the concerns that what's
required from 3289 is kind of loosely defined in the draft. I agree that
this can be done via the DOCSIS RFI; below is a complementary proposal.
First, the requirements on 3289 in section 2.3 are written in terms of
objects, not object groups. Consequently, it is not possible to enforce
any level of requirement is on these objects (object groups could allow
you to be more precise with SYNTAX and WRITE-SYNTAX clauses for e.g.). 
Secondly, going through the RFC3289 object groups one by one, you are
not that far from actually mandating some object groups:

   o    diffServDataPathTable
        => this is diffServMIBDataPathGroup object group
   o    diffServClfrTable
        => based on section 3.2.1 of RFC3289, I think you may also need
to mandate the support of diffServClfrNextFree. diffServClfrNextFree is
populated by the agent when creating ids in the table. If you agree to
add this one object, requiring diffServClfrNextFree + diffServClfrTable
objects => diffServMIBClfrGroup.
This comment applies to the next tables as well.
   o    diffServClfrElementTable
        => how about diffServClfrElementNextFree?
         If you include diffServClfrElementNextFree +
diffServClfrElementTable => diffServMIBClfrElementGroup
   o    diffServMultiFieldClfrTable
        how about diffServMultiFieldClfrNextFree?
        If you include diffServMultiFieldClfrNextFree +
diffServMultiFieldClfrTable => diffServMIBMultiFieldClfrGroup
   o    diffServActionTable
        how about diffServActionNextFree?
        If you include diffServActionNextFree +  diffServActionTable =>
diffServMIBActionGroup.
   o    diffServAlgDropTable (diffServAlgDropType=alwaysDrop)
        how about diffServAlgDropNextFree ?
        If you include diffServAlgDropNextFree + diffServAlgDropTable =>
diffServMIBAlgDropGroup
   o    diffServCountActTable
	  how about diffServCountActNextFree?
        If you include diffServCountActNextFree + diffServCountActTable
+ the following objects from diffServAlgDropTable
(diffServAlgDropOctets, diffServAlgDropPkts,
diffServAlgRandomDropOctets, diffServAlgRandomDropPkts)
             => diffServMIBCounterGroup
==> In short, if you agree that supporting the diff*NextFree objects is
not a bad idea (especially since it's probably going to be implemented
by the agent with the various tables), you can easily transform the
section 2.3 and write it in terms object groups.

To that extent, I am wondering if the docsSubMgtBasicCompliance module
compliance statement could be enhanced to actually include the object
groups from RFC3289 cited above. Based on your section 2.3, this
enhancement could then look something like this:

 docsSubMgtBasicCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for CMTS devices that implement
       CMTS centric subscriber management."

  MODULE DIFFSERV-MIB -- RFC3289
  MANDATORY-GROUPS {
           diffServMIBDataPathGroup,
           diffServMIBClfrGroup, 
           diffServMIBClfrElementGroup,
           diffServMIBMultiFieldClfrGroup,
           diffServMIBActionGroup, 
           diffServMIBAlgDropGroup,
           diffServMIBCounterGroup
           }
   ...
   ... 
   -- and now you may formerly specify that 
   -- diffServAlgDropType=alwaysDrop in diffServAlgDropTable, etc. 

   MODULE -- This module i.e. DOCS-IETF-SUBMGT-MIB
   MANDATORY-GROUPS {
           docsSubMgtGroup
           }
   ...

Thoughts? Sorry for not sending this proposal earlier,
Jean-Francois.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, June 11, 2003 10:44 AM
> To: Kirk Friedman
> Cc: [email-masked]; [email-masked]
> Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11
> 
> 
> 
> Kirk - Agreed that the Docsis OSSI Spec needs new language to 
> spec out CMTS compliance w.r.t.  RFC3289. For the most part, 
> I think that language more properly belongs in the OSSI spec 
> than in the internet draft.  But I'm open to suggestions.
> 
> Keep in mind that there's a necessary lag in the publication 
> of the OSSI
> Spec: It can't mandate compliance with the subscriber 
> management internet-draft until the MIB is assigned a root - 
> and that won't happen until publication as an RFC.
> 
> Regards,
> Wilson
> 
> 
> 
>                                                               
>                                                               
>                  
>                       "Kirk Friedman"                         
>                                                               
>                  
>                       <kfriedman@correl        To:       
> <[email-masked]>                                    
>                       
>                       ant.com>                 cc:       
> <[email-masked]>, <[email-masked]>                        
>                       
>                                                Subject:  RE: 
> [ipcdn] draft submitted: subscriber management MIB -11        
>                   
>                       06/11/03 11:59 AM                       
>                                                               
>                  
>                                                               
>                                                               
>                  
>                                                               
>                                                               
>                  
> 
> 
> 
> 
> 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
> 
> 
> 
> 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
> 

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

---

From: [email-masked]
Date: Mon, 28 Jul 2003 12:07:06 -0400

(Apologies for the delay in responding)

Jean-Francois's suggestions make sense to me - I'll proceed with a draft
-12 to incorporate them. Any other comments on J-F's suggestion? Any other
comments on the subscriber management MIB i-d that I should fix in this
draft?

- Wilson

                      "Jean-Francois                                                                                  
                      Mule"                    To:       <[email-masked]>                                   
                      <jf.mule@cablelab        cc:       <[email-masked]>, "Kirk Friedman"                        
                      s.com>                    <[email-masked]>, <[email-masked]>                           
                      Sent by:                 Subject:  RE: [ipcdn] draft submitted: subscriber management MIB -11   
                      ipcdn-admin@ietf.                                                                               
                      org                                                                                             

                      07/16/03 12:19 PM                                                                               

Wilson,

   o    diffServDataPathTable