Subject: Re: cable device MIB IP filter masks

From: Rich Woundy <[email-masked]>
Date: Mon, 08 Mar 1999 13:37:58 -0500

Bruce,

Speaking for myself (not Cisco), I think that you need to consider that the
train is starting to leave the station -- CableLabs has certified modems
already, and more will be certified rather soon.

But assuming your approach is taken, then you *must* account for the
important case of netmask 0.0.0.0. There are in fact *33* legal bit mask
lengths...

-- Rich

At 09:18 AM 3/8/99 -0800, Bruce Lueckenhoff wrote:
>Hello,
>
>This message concerns the filters source and destination IP mask
>objects in the cable device MIB.  (docsDevFilterIpSmask and
>docsDevFilterIpDmask) The draft says these must be "leftmost and
>contiguous." However, the MIB does not specify the proper action for an
>agent to take if someone attempts to SET a non-contiguous and/or not
>left-packed mask value.
>
>The MIB must specify how agents should handle this case, or else not
>restrict the bitmaps at all.
>
>I propose instead specifying 'Smask and 'Dmask the same way one
>specifies network prefixes.  The advantage to this is that doing so
>makes the "error case" impossible.  Here's an example of what I have in
>mind:
>
>docsDevFilterIpDmaskBits OBJECT-TYPE
>        SYNTAX      Integer32 (1..32)
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>          "A description of the bit mask that is to be applied to the
>          destination address prior to matching. The resulting mask
>          is a bit pattern that has:
>              o a contiguous string of ones at the more significant end,
>              o a contiguous string of zeros at the less significant end,
>              o no intervening bits, and
>            o number of ones bits equal to docsDevFilterIpDmaskBits.
>            For example:
>          docsDevFilterIpDmaskBits    resulting mask (in binary)
>          ------------------------    --------------------------------
>             1                          10000000000000000000000000000000
>             2                          11000000000000000000000000000000
>             3                          11100000000000000000000000000000
>            ...
>            30                          11111111111111111111111111111100
>            31                          11111111111111111111111111111110
>            32                          11111111111111111111111111111111"
>        DEFVAL { 0 }
>        ::= { docsDevFilterIpEntry 10 }
>
>(I stole the description of a network prefix from RFC1812, page 23)
>
>Does anybody else think this is the way to go, or have a problem with
>specifying the src & dst masks this way?
>
>
>Bruce
>--
>Bruce Lueckenhoff	mailto:[email-masked]
>Cadence Design Systems	DID:805-571-1246 FAX:805-571-1300
>