RE: [Diffserv] Dscp and DscpOrAny TCs

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Fri, 07 March 2003 11:22 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19358 for <diffserv-archive@odin.ietf.org>; Fri, 7 Mar 2003 06:22:13 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27BXgT13298 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 06:33:42 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27BOeO12345; Fri, 7 Mar 2003 06:24:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27B8gO11612 for <diffserv@optimus.ietf.org>; Fri, 7 Mar 2003 06:08:42 -0500
Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18630 for <diffserv@ietf.org>; Fri, 7 Mar 2003 05:56:43 -0500 (EST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27Awk227525 for <diffserv@ietf.org>; Fri, 7 Mar 2003 05:58:47 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <DVZ3CQ0L>; Fri, 7 Mar 2003 11:58:35 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501156B3A@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Andrew Smith <ah_smith@acm.org>, Bert Wijnen <bwijnen@lucent.com>
Cc: diffserv@ietf.org, Richard_Woundy@cable.comcast.com, jf.mule@cablelabs.com, narten@us.ibm.com, erik.nordmark@sun.com
Subject: RE: [Diffserv] Dscp and DscpOrAny TCs
Date: Fri, 7 Mar 2003 11:57:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-BeenThere: diffserv@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=unsubscribe>
List-Id: Diffserv Discussion List <diffserv.ietf.org>
List-Post: <mailto:diffserv@ietf.org>
List-Help: <mailto:diffserv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=subscribe>

Andrew,

Sure.... and what I am doing here is not the ideal solution,
but clearly I am trying to get various solutions aligned
as much as possible (you have seen my issues raised
for common definitions for Dscp, DscpOrAny, FlowLabel,
FlowLabelOrAny, VlanId, VlanIdOrAny ... etc etc.

In the case of DOCSIS, the original stuff got developed
outside IETF. They now try to bring their stuff under the
IETF umbrella. We could tell them to drop/ditch all their own
stuff and start from scratch... which I suspect will not work,
or we can try to get them aligned as much as possible without
making them start from scratch.

I think I am on the latter path...
Are you suggesting we (IETF) should be on the former path?

Just trying to understand what you are urging us to do.

Thanks,
Bert 

> -----Original Message-----
> From: Andrew Smith [mailto:ah_smith@acm.org]
> Sent: woensdag 5 maart 2003 21:42
> To: Bert Wijnen
> Cc: diffserv@ietf.org; Richard_Woundy@cable.comcast.com;
> jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com
> Subject: RE: [Diffserv] Dscp and DscpOrAny TCs
> 
> 
> 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/curre
nt/maillis
t.html

_______________________________________________
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