Subject: Separate policy tables for docsDevFilterIpTable

From: "Michael W. Patrick" <[email-masked]>
Date: Fri, 19 Feb 1999 13:20:28 -0500

I have a concern that people consider the cable device mib all but
ready to go. The IETF drafts directly has only rev -06, dated in October.
The -07 draft was posted only on 12/29.  I replied privately to the
author with major concerns on 1/25, which I am sharing with the group
with this email.

The community has been heavily involved with Docsis Certification Wave 7,
which specified only that rev -04 of the CD mib be used.  I'm sure
that some vendors have -05, -06, or -07 ready to deploy, but these
MIBs certainly have NOT undergone interoperability testing at least at
Cablelabs.  They have NOT undergone signficant discussion or agreement
on the mailing list.  Is it really an IETF policy that "silence
implies consent" even when silence implies "that's not important
enough to respond to yet" :-)

I have several major concerns with the docsDevIpFilter table in the
-05 through -07 drafts of the Cable Device MIB. I'm writing this to see if anyone
else shares these concerns. I'm also proposing a recommended solution
to the concerns.

1)  Isn't the combination of "filtering" and "policy" in the
    docsDevFilterIpTable is extremely awkward.
    Doesn't "Filtering" means deciding which packets to add or drop,
    or is it a general term to mean the classification of packets?

    Aren't "Policies" the rules you apply (to IP packets in this case).
    Isn't "filtering" just *one* of the possible policies?
    
    Isn't the definiton of "docsDevFilterIpControl" with its choices
    of  discard(1), accept(2), and policy(3) just an attempt to re-use
    the (large) number of objects in the table for both filtering and
    TOS overwrite (and future) policies?

    If so, shouldn't we just remove docsDevFilterIpControl and have a separate
    "Filtering Policy Table" with just two policy indexes:  discard(1) or
    accept(2)?

2)  Isn't the purpose of docsDevFilterIpContinue simply to indicate
    that separate policies may be applied to a packet matching a
    classification rule?  

    If so, isn't is problematic whether 'IpContinue is set or not?
    This means that when new rules are added, you may have to go back
    and change all those "don't continue" rules that could possible
    match a rule back to 'continue'. 

    For example, I have thousands of configuration files deployed that
    have IpContinue set to zero on the rules referencing my Tos
    Overwrite policy. Now I want to add an IpSec policy. Every single
    'IpFilter MIb setting ever made will have to change to set
    'IpContinue to 1 because I've added a new policy.

    Wouldn't it be *much* easier to administer if each policy had its
    own group of rules?  That way, the "Filter" policy rules would
    affect the "Tos Overwrite" policy rules.  And future policies like
    IpSec or  Docsis 1.1 Service Flow Classification would have no 
    interaction with existing policies (read "MIB setting scripts or
    config files"). 

3)  If and when other policies are added in the future, isn't it
    wasteful to specify that ALL RULES are searched, i.e. with this 
    "IpContinue" bit?  

    For example, consider a policy to control  Multicast forwarding,
    e.g. whether to permit joins, whether to send a trap, etc. 
    This policy is obviously NOT applicable to unicast packets, and
    yet if we were to add a reference to it in the docsDevFilterTable,
    we would have to get the "Continue" bit right again. 
    
    Why should a policy that affects only multicasts have to
    co-ordinate the "IpContinue" bit with policies that affect only
    unicasts?

4)  Isn't it difficult to co-ordinate the single number space of
    docsDevFilterIpIndex among all policies?

    Suppose I don't leave any gaps. When I want to add a new policy,
    don't I have to RENUMBER all of the docsDevFilterIpIndex values
    of exising policy matching rules?

    OK, so you leave holes in IpIndex? How big? 10? 100?  How many
    policies might we add in the future?

    If we had separate logical tables, each policy would have its
    own number space of "docsDevFilterIpIndex"; the rules would apply
    only when the policy itself was applied.

5)  Don't we have conflicts between internal and external genration
    of TOS overwrite policy?

    Isn't it likely in the future that there may be local diffserv
    entitites that use protocols other than SNMP  (e.g. COPS?) to 
    decide how to color the TOS bits?  Isn't in problematic how the
    local Diffserv entity and an external SNMP manager co-ordinate
    their assignment of the docsDevFilterIpIndex (not to mention
    the  'IpContinue and 'IpPolicyId objects).

    In general, I beliver we have a major internal/external number assignment problem 
    over the following object values:

         - docsDevFilterIpIndex
         - docsDevFilterIpPolicyID

6)  The PolicyID is a single number that is supposed to encode
    every used COMBINATION of policies. This means that for each
    possible combination of every policy we come up with, a 
    unique PolicyID must be generated.

    This is MUCH more complicated that the concept of having
    logically separate policies, each with its own PolicyId
    applied to a packet, if need be.

All of these issues, I believe, are addressed by defining the 
docsDevFilterIpTable as logically separate IP packet matching tables,
one for each policy.

The decision to Accept/Drop should be a separate "policy"
along with Tos Overwrite, and we shouldn't add "policies" as a bag on
the side of an Accept/Drop Filtering table

My specific proposals are

A. Instead of the single { docsDevIpFilterIpIndex } 
as the index to docsDevIpFiltertable, we should have a two-part index

   { docsDevFilterPolicyTableIndex  docsDevFilterIpRuleIndex }

Where docsDevFilterPolicyTableIndex is a read-write small integer indexing
a table of OIDs pointing to the separate policy tables themselves. 

That essentially makes the 'IpFilterTable have separate subtables for each
policy. Each policy therefore gets its own space of docsDevFilterIpRuleIndex to
order its own rules.

B.  Replace the numeric index of the docsDevFilterPolicyTable by the tuple:

    { DocsDevFilterPolicyTableIndex  DocsDevFilterPolicyId }

    That is, the combination of a table and PolicyId (which you found
    in the DocsDevFilterTable) give you a docsDefFilterPolicyPtr
    which tells you what to do for this policy.

    This allows the docsDevFilterPolicyId to be defined only within
    its particular policy; you don't have to have a global agreement
    on the number.

C. Remove docsDevFilterIpContinue, because its problematic and not needed
   The appropriate policies are applied at the appropriate time.

   The DropPolicyTable, for instance, is applied only to forwarded
   packets between interfaces.  The TosOverwritePolicyTable, however,
   would also be applied to internally generated packets. 

   The generic "forwarding" model in the CM and CMTS that appears in
   the RFI spec can and should be supplemented to show the four
   Ifindex values specified by the RF MIB. It can also be updated to
   show which policy is applied by which module.

   I think we have introduced FAR too much complexity and coupling by
   dictating semantics that call for a single pass through a filter table.

   All bridge/routers tha I know of have separate configuration tables/records/commands for 
   separate functions. While I applaud the desire to have a common
   syntax for specifying packet matching, I think its going too far to
   say that a single table is scanned to identify ALL policies that
   might apply to a generated, received, or forwarded IP packet.
   I think what was intended was to recognize that the concept of
   matching an IP packet header to a "template" is common to a number
   of different policies. My proposal to have logically separate
   policy tables does that in a much cleaner and easily-administered manner.

Regards,
mike

---

From: Guenter Roeck <[email-masked]>
Date: Fri, 19 Feb 1999 10:44:40 -0800 (PST)

> implies consent" even when silence implies "that's not important

IMHO, yes. Mike StJohns stated _several_ times that silence would 
imply consent. It is not as if this would be unknown and a total surprise.
As such, I personally strongly disagree with your statement about
lack of agreement on the mailing list.

Also, interoperability testing is NOT a requirement for going to proposed
standard. This is a requirement for draft/full standard. To require
interoperability results _before_ going to Proposed Standard is
a back-door change of IETF policies. To publish a MIB as Proposed
Standard is supposed to get vendors to implement it. The term
"Proposed" should already indicate this.

Related comment:

In the current state, both RF Interface MIB and Cable Device MIB would
normally _never_ be shipped by cisco, since they are both not even 
published as RFC and proposed standard. That we are shipping those 
anyway is a BIG exception, not to be repeated. We will NOT ship 
(i.e., put into released code) any of the other MIBs. 

Reason for this is that by now we have at least three different versions
of the RF Interface MIB in released code. CD MIB is even worse. This
is a pain to support in released code, and we are not going to repeat
this experience.

If the MSO community is interested in released code supporting the
Telco Return MIB, the BPI MIB, or any other DOSCIS related MIB,
I would strongly suggest to get it published as Proposed Standard,
and to reject further attempts to delay standardization.
Otherwise, we will have to assume that there is no real interest
in having those MIBs supported.
That does not mean that MIBs will not be available for evaluation,
but they will not be released until published as Proposed Standard.

I believe that any attempt to prevent publication of any DOCSIS MIB
as Proposed Standard at this time is purely an attempt to delay
standardization and nothing else.
This is my personal opinion only and does in no way reflect the opinion
of my employer.

Guenter

---

From: "Michael W. Patrick" <[email-masked]>
Date: Fri, 19 Feb 1999 18:00:23 -0500

>>>>> "Guenter" == Guenter Roeck <[email-masked]> writes:

>> ready to go. The IETF drafts directly has only rev -06, dated in
>> October.  The -07 draft was posted only on 12/29.  I replied
>> privately to the author with major concerns on 1/25, which I am
>> sharing with the group with this email.
>> 
>> The community has been heavily involved with Docsis Certification
>> Wave 7, which specified only that rev -04 of the CD mib be used.
>> I'm sure that some vendors have -05, -06, or -07 ready to deploy,
>> but these MIBs certainly have NOT undergone interoperability
>> testing at least at Cablelabs.  They have NOT undergone signficant
>> discussion or agreement on the mailing list.  Is it really an IETF
>> policy that "silence implies consent" even when silence implies
>> "that's not important

> imply consent. It is not as if this would be unknown and a total
> surprise.  As such, I personally strongly disagree with your
> statement about lack of agreement on the mailing list.

> Also, interoperability testing is NOT a requirement for going to
> proposed standard. This is a requirement for draft/full standard. To
> require interoperability results _before_ going to Proposed Standard
> is a back-door change of IETF policies. To publish a MIB as Proposed

> In the current state, both RF Interface MIB and Cable Device MIB
> would normally _never_ be shipped by cisco, since they are both not
> even published as RFC and proposed standard. That we are shipping
> those anyway is a BIG exception, not to be repeated. We will NOT
> ship (i.e., put into released code) any of the other MIBs.

> Reason for this is that by now we have at least three different
> versions of the RF Interface MIB in released code. CD MIB is even
> worse. This is a pain to support in released code, and we are not
> going to repeat this experience.

> Telco Return MIB, the BPI MIB, or any other DOSCIS related MIB, I
> would strongly suggest to get it published as Proposed Standard, and
> to reject further attempts to delay standardization.  Otherwise, we
> will have to assume that there is no real interest in having those
> MIBs supported.  That does not mean that MIBs will not be available
> for evaluation, but they will not be released until published as
> Proposed Standard.

> standardization and nothing else.  This is my personal opinion only
> and does in no way reflect the opinion of my employer.

>> enough to respond to yet" :-)

I suggest, then, that we publish CD MIB -04 (and RF MIB -04) as
*informational* RFCs, i.e. documenting the MIBs of Docsis
certification wave 7.  We probably should do that anyway for 
historical purposes. 

I share your frustration with the number of different RF and CD MIBs
around.  I still contend that we should get the IP Filter MIB "right"
so that it can be easily administered for future policies.
That way, we can *add* future policy MIBs, rather than having to 
*change* the CD MIB yet again.

-mike

>> -05 through -07 drafts of the Cable Device MIB. I'm writing this to
>> see if anyone else shares these concerns. I'm also proposing a
>> recommended solution to the concerns.
>> 
>> docsDevFilterIpTable is extremely awkward.  Doesn't "Filtering"
>> means deciding which packets to add or drop, or is it a general
>> term to mean the classification of packets?
>> 
>> Isn't the definiton of "docsDevFilterIpControl" with its choices of
>> discard(1), accept(2), and policy(3) just an attempt to re-use the
>> (large) number of objects in the table for both filtering and TOS
>> overwrite (and future) policies?
>> 
>> If so, shouldn't we just remove docsDevFilterIpControl and have a
>> separate "Filtering Policy Table" with just two policy indexes:
>> discard(1) or accept(2)?
>> 
>> e.g. whether to permit joins, whether to send a trap, etc.  This
>> policy is obviously NOT applicable to unicast packets, and yet if
>> we were to add a reference to it in the docsDevFilterTable, we
>> would have to get the "Continue" bit right again.
>> 
>> don't I have to RENUMBER all of the docsDevFilterIpIndex values of
>> exising policy matching rules?
>> 
>> If we had separate logical tables, each policy would have its own
>> number space of "docsDevFilterIpIndex"; the rules would apply only
>> when the policy itself was applied.
>> 
>> 
>> entitites that use protocols other than SNMP (e.g. COPS?) to decide
>> how to color the TOS bits?  Isn't in problematic how the local
>> Diffserv entity and an external SNMP manager co-ordinate their
>> assignment of the docsDevFilterIpIndex (not to mention the
>> 'IpContinue and 'IpPolicyId objects).
>> 
>> In general, I beliver we have a major internal/external number
>> assignment problem over the following object values:
>> 
>> - docsDevFilterIpIndex - docsDevFilterIpPolicyID
>> 
>> 6) The PolicyID is a single number that is supposed to encode every
>> used COMBINATION of policies. This means that for each possible
>> combination of every policy we come up with, a unique PolicyID must
>> be generated.
>> 
>> This is MUCH more complicated that the concept of having logically
>> separate policies, each with its own PolicyId applied to a packet,
>> if need be.
>> 
>> 
>> docsDevFilterIpTable as logically separate IP packet matching
>> tables, one for each policy.
>> 
>> The decision to Accept/Drop should be a separate "policy" along
>> with Tos Overwrite, and we shouldn't add "policies" as a bag on the
>> side of an Accept/Drop Filtering table
>> 
>> A. Instead of the single { docsDevIpFilterIpIndex } as the index to
>> docsDevIpFiltertable, we should have a two-part index
>> 
>> Where docsDevFilterPolicyTableIndex is a read-write small integer
>> indexing a table of OIDs pointing to the separate policy tables
>> themselves.
>> 
>> That essentially makes the 'IpFilterTable have separate subtables
>> for each policy. Each policy therefore gets its own space of
>> docsDevFilterIpRuleIndex to order its own rules.
>> 
>> in the DocsDevFilterTable) give you a docsDefFilterPolicyPtr which
>> tells you what to do for this policy.
>> 
>> This allows the docsDevFilterPolicyId to be defined only within its
>> particular policy; you don't have to have a global agreement on the
>> number.
>> 
>> C. Remove docsDevFilterIpContinue, because its problematic and not
>> needed The appropriate policies are applied at the appropriate
>> time.
>> 
>> All bridge/routers tha I know of have separate configuration
>> tables/records/commands for separate functions. While I applaud the
>> desire to have a common syntax for specifying packet matching, I
>> think its going too far to say that a single table is scanned to
>> identify ALL policies that might apply to a generated, received, or
>> forwarded IP packet.  I think what was intended was to recognize
>> that the concept of matching an IP packet header to a "template" is
>> common to a number of different policies. My proposal to have
>> logically separate policy tables does that in a much cleaner and
>> easily-administered manner.
>> 
>> Regards, mike
>> 
>> 
>> 
>> 
>> 
>> 
>>

---

From: Guenter Roeck <[email-masked]>
Date: Fri, 19 Feb 1999 15:33:35 -0800 (PST)

Informational does not help for the standards process - if it is not
on the standards track, you can not expect anyone to implement it.

It might have been a good idea to do so, but that would
have been 6 months or so ago.

Guenter