Re: [Diffserv] Dscp and DscpOrAny TCs

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

Andrew,

That is a valid point (we have the same issue for the IPv6 Flow Label).

However, in answer to Bert's question, John Schnizlein is correct.

It's a violation of the diffserv architecture to mask bits in a DSCP.
There are no encoded bit fields in a DSCP; it's an opaque 6 bit
quantity.

docsSubMgtPktFilterDscpMask needs to be deleted.

   Brian

Andrew Smith wrote:
> 
> I've not been following the DOCSIS MIB work closely and don't know the
> context in which this MIB was developed. That said, shouldn't IETF be
> promoting the use of generic, already-standards-track solutions, instead
> of trying to police each new reincarnation of the same thing? It would
> have been nice if, given that this MIB is a work item of an IETF WG, the
> IESG had put in some provision in the WG charter about re-use of
> existing IETF work where appropriate, rather than reinventing the wheel
> (which this looks like - see my first sentence above though). Granted,
> there is a choice of almost-equivalent wheels for packet
> matching/filtering in the IETF standards-track repertoire but that's not
> an argument for creating yet another one.
> 
> This is one aspect of the general IETF process issue of how to ensure
> that appropriate "subject matter experts" are available to a WG that
> needs them, even when that subject matter's own WG is no longer
> existent: the more generic the solutions that IESG steers us to, the
> less this maintenance problem will be.
> 
> Reuse of already-defined MIB ojects/tables is also one of the issues
> that an SMIng should try to make easier (and people have been looking at
> doing this, I believe).
> 
> Andrew Smith
> 
> -----Original Message-----
> From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] On Behalf
> Of John Schnizlein
> Sent: Wednesday, March 05, 2003 9:29 AM
> To: Wijnen, Bert (Bert)
> Cc: diffserv@ietf.org
> Subject: Re: [Diffserv] Dscp and DscpOrAny TCs
> 
> Good catch, Bert.
> The idea of a mask for the DSCP was killed some time ago in Policy
> Framework based on its incompatibility with the following explicit
> prohibition in the definition of the Differentiated Services Field:
> 
> RFC 2474 Section 3, page 7
>    Implementors should note that the DSCP field is six bits wide.  DS-
>    compliant nodes MUST select PHBs by matching against the entire 6-bit
>    DSCP field, e.g., by treating the value of the field as a table index
>    which is used to select a particular packet handling mechanism which
>    has been implemented in that device.  The value of the CU field MUST
>    be ignored by PHB selection.  The DSCP field is defined as an
>    unstructured field to facilitate the definition of future per-hop
>    behaviors.
> 
> John
> 
> At 11:36 AM 3/5/2003, Wijnen, Bert (Bert) wrote:
> >Do Diffservers think that the following is wise and makes sense?
> >
> >   docsSubMgtPktFilterDscpValue OBJECT-TYPE
> >       SYNTAX      Dscp
> >       MAX-ACCESS  read-create
> >       STATUS      current
> >       DESCRIPTION
> >           "The Differentiated Services Code Point (DSCP) value to
> match
> >            in the IP packet."
> >       DEFVAL { 0 }
> >       ::= { docsSubMgtPktFilterEntry 9 }
> >
> >   docsSubMgtPktFilterDscpMask OBJECT-TYPE
> >       SYNTAX      Dscp
> >       MAX-ACCESS  read-create
> >       STATUS      current
> >       DESCRIPTION
> >           "The mask to apply against the DSCP value to be matched in
> >       the IP packet.  The default for both these objects taken
> together
> >       matches all DSCP values. A packet matches this filter if the
> >       following is true:
> >           AND (FilterDscpValue, FilterDscpMask) ==
> >           AND (Packet DSCP Value, FilterDscpMask)."
> >       DEFVAL { 0 }
> >       ::= { docsSubMgtPktFilterEntry 10 }
> >
> >It is defined in draft-ietf-ipcdn-subscriber-mib-10.txt and I'd like
> >to hear comments from Diffserv experts.
> >
> >Thanks,
> >Bert
>
_______________________________________________
diffserv mailing list
diffserv@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html