Subject: [Diffserv] Dscp and DscpOrAny TCs

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 5 Mar 2003 17:36:59 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 7 Mar 2003 19:31:47 +0100

Inline

> -----Original Message-----
> From: Andrew Smith [mailto:[email-masked]]
> Sent: vrijdag 7 maart 2003 17:45
> To: 'Wijnen, Bert (Bert)'
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Diffserv] Dscp and DscpOrAny TCs
> 
> Bert,
> 
> When you say "bring their stuff under the IETF umbrella", are you saying
> that the original MIB in question was developed outside of IETF and is
> being brought in, or are you talking about the link technology itself? 
> 
As far as I understand it, several (if not all) of the MIB modules 
(quite a few) have been developed in cablelabs context, and in fact
have been implemented at a large scale.

> If the latter, then I think the older IEEE802/IETF cooperation model on
> MIBs works OK - there you had an IETF WG (bridge, maumib, ifmib etc.)
> defining SMI MIBs under IETF root OID and having WG contributors make
> sure that adequate coordination happened; a newer model where IEEE802
> has defined some of its own SMI MIBs has also been working OK (e.g. Link
> Aggregation MIB from IEEE802, defined under IEEE802's own root OID). 
> 
> For the former case, what I don't think works is to have a MIB defined
> outside of IETF and then brought to the IETF for some reason. What would
> be the reason to do that? for IETF endorsement, for having IETF fixing
> things that are broken, just to use the IETF root OID? I don't know the
> specific reasons in this case for how this work got here. But it's
> obvious to me that, if you bring existing work to IETF for
> standardisation, be it the work of another standards' group, an industry
> group or individual contributions, *you give up change control* and you
> do not get any guarantees of backwards-compatibility: naturally you
> don't expect gratuitous non-compatibility with earlier work - the WG
> needs a valid reason to change something and one such reason would be
> alignment with other IETF MIBs.
> 
I think that is all understood. 
But I will leave it to Rich and JeanFrancois to answer the exact motives
for coming to IETF. 
From my point of view, we will not just accept everything and rubber stamp.
But I also understand that we have to be practical and that we do not just
want to make them start from scratch just for the fun of it.

By the way, quite a bit of the discussion about the Dscp, DscpOrAny,
VlanID and VlanIDOrAny is also an issue for MIB modules from the past
from IETF WGs.

> [Note that, for this particular example of filter/pattern-matching on IP
> packets with DSCPs, I'd originally proposed a separate generic MIB
> module (included a "sixTupleClassifier" table) for the reason of making
> it clear that this was general purpose and should be used by other MIBs,
> including the Diffserv MIB. However, in the end, it was decided to merge
> it into the main Diffserv MIB module (it became the
> "diffServMultiFieldClfrTable" in RFC3289 - maybe it is less visible
> there but maybe ADs can do something to raise awareness of its presence
> amongst other WGs].
> 
That is why I DID ask the question to IPCDN WG, did you guys look at the
other filter tables that we already have in the IETF.

Bert
> 
> Andrew Smith
> 
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Friday, March 07, 2003 2:57 AM
> To: Andrew Smith; Bert Wijnen
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Diffserv] Dscp and DscpOrAny TCs
> 
> 
> 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:[email-masked]]
> > Sent: woensdag 5 maart 2003 21:42
> > To: Bert Wijnen
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > 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: [email-masked] 
> > [mailto:[email-masked]] On Behalf
> > Of John Schnizlein
> > Sent: Wednesday, March 05, 2003 9:29 AM
> > To: Wijnen, Bert (Bert)
> > Cc: [email-masked]
> > 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:
> > Archive:
> > http://www.ietf.org/mail-archive/working-groups/diffserv/curre
> nt/maillis
> t.html
> 
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 7 Mar 2003 16:15:16 -0700

Folks,

The motive for most cable folks coming to the IETF is to collaborate on
standards documents between IETF and cable industry experts, that adhere to
the IETF architecture and meet the engineering requirements of the cable
industry. Sometimes that means that folks extend the IETF architecture model
due to considerations that are found first in (and are possibly unique to)
the cable industry. Sometimes that means the cable industry adopts output
from other IETF groups in place of ad-hoc cable industry solutions.
Sometimes we agree not to collaborate -- after all, DOCSIS is supposed to be
a layer two protocol. ;^)

The IPCDN WG as a whole, and this chair in particular, understands that the
IETF owns change control for its drafts and RFCs. That doesn't mean that
folks in IPCDN will never object to changes -- but is that really unique to
this WG?

>want to make them start from scratch just for the fun of it.

-- Richard Woundy, IPCDN Co-Chair

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Friday, March 07, 2003 1:32 PM
To: Andrew Smith; 'Wijnen, Bert (Bert)'
Cc: [email-masked]; Woundy, Richard; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Diffserv] Dscp and DscpOrAny TCs

Inline

Bert

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 7 Mar 2003 16:23:34 -0700

> The IPCDN WG as a whole, and this chair in particular, 
> understands that the IETF owns change control for its drafts 
> and RFCs. That doesn't mean that folks in IPCDN will never 
> object to changes -- but is that really unique to this WG?
> 
> >From my point of view, we will not just accept everything and rubber 
> >stamp. But I also understand that we have to be practical 
> and that we 
> >do not just want to make them start from scratch just for the fun of 
> >it.
> 
I second Rich's point above.
The cable industry and CableLabs have made tremendous efforts to adopt a
higher net citizen profile in working *with* IETF (of which some of us
"cable" engineers feel a part of and have been a part of in previous
lifes).
 
Jean-Francois Mule, the other IPCDN Co-Chair
_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 12 Mar 2003 15:59:30 -0700

Brian (and many diffserv folks),

Thanks for your input and of the diffserv WG. I will assume that our IPCDN
MIBs need to use explicit DSCP values and not use DSCP masks.

Please forgive this question for my DiffServ education. I have heard several
times that "network operators are free to ignore the recommended code
points", and that this is a major reason why we should not use DSCP masks.

What benefits does a network operator achieve with an unstructured set of
DSCPs?

In fact, I *am* a network operator -- I work for Comcast Cable, which has
lots of regional networks and millions of residential cable modem
subscribers. I see the pain associated with network management of my
boundary nodes with unstructured DSCP assignments. Where's the benefit to
me?

I don't mind if folks take this question off-list, or if folks refer me to
specific diffserv mail archives (e.g. a specific "thread" name) where this
was already discussed. Just as long as I am not mistaken as a spammer. ;^)

-- Rich

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Saturday, March 08, 2003 6:59 AM
To: John Schnizlein
Cc: Woundy, Richard; [email-masked]'
Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs

What John writes is definitive. Masking DSCPs is
simply wrong. The fact that the recommended AF code
points happen to be numerically consecutive is just an
accident of the code point assignment process; the bit
positions are not significant, and network operators are
free to ignore the recommended code points if they want to.

   Brian

John Schnizlein wrote:
> 
> Comments embedded in context below:
> 
> At 09:40 AM 3/7/2003, Woundy, Richard wrote:
> 
> >I'm looking for further reaction to my email below about DOCSIS/Dscp
> >interaction.
> >...
> >I think there are two issues here: are Dscp mask objects legal,
> 
> No.
> 
> >and are they worthwhile?
> 
> No.
> 
> >... enable the DOCSIS equipment to act precisely as "re-marking boundary
> >nodes", which are also described in RFC 2474 Section 3, pages 8-9:
> >
> >   The structure of the DS field shown above is incompatible with the
> >   existing definition of the IPv4 TOS octet in [RFC791].  The
> >   presumption is that DS domains protect themselves by deploying re-
> >   marking boundary nodes, as should networks using the RFC 791
> >   Precedence designations.  Correct operational procedure SHOULD follow
> >   [RFC791], which states: "If the actual use of these precedence
> >   designations is of concern to a particular network, it is the
> >   responsibility of that network to control the access to, and use of,
> >   those precedence designations."  Validating the value of the DS field
> >   at DS boundaries is sensible in any case since an upstream node can
> >   easily set it to any arbitrary value.  DS domains that are not
> >   isolated by suitably configured boundary nodes may deliver
> >   unpredictable service.
> >
> >   Nodes MAY rewrite the DS field as needed to provide a desired local
> >   or end-to-end service.  Specifications of DS field translations at DS
> >   boundaries are the subject of service level agreements between
> >   providers and users, and are outside the scope of this document.
> >   Standardized PHBs allow providers to build their services from a
> >   well-known set of packet forwarding treatments that can be expected
> >   to be present in the equipment of many vendors.
> >
> >On the other hand, I see the definite lack of structure in the DiffServ
> >codepoints, and I am debating with myself whether a "Dscp mask" is worth
the
> >trouble or not.
> >
> >In particular, I am looking at the current codepoint assignments in
> ><http://www.iana.org/assignments/dscp-registry>,...
> 
> You may be running into a subtlety that was worried about early in
> defining the DiffServ field. The code points in the registry are
> just recommended values, not required values. While there are
> requirements regarding which behaviors must be supported to claim
> DiffServ compliance, there is no requirement that the recommended
> values be used to indicate these behaviors.
> 
> The point is that there is no reliable structure for "the network
> operator to take advantage of". The presence of masks in data objects
> would encourage creating the sort of structure the RFC prohibits.
> 
> Note the distinction between the SHOULD regarding values, and the MUST
regarding treating the value as a unit (copied farther below):
> 
> RFC 2474 section 2, page 5
>    Codepoint: a specific value of the DSCP portion of the DS field.
>    Recommended codepoints SHOULD map to specific, standardized PHBs.
> 
> >From: [email-masked] [mailto:[email-masked]]
> >
> >Keep in mind we're talking about a *filter* here, not a PHB selector.
> 
> I don't appreciate the distinction. What was intended by PHB selector
> was that traffic could be selected from the aggregate by the DSCP.
> How is this different from filtering traffic based on DSCP matches?
> 
> >And we'e not inferring bit-structure in the implementation, merely
> >allowing the network operator to take advantage of any structure
> >that exists. Do we really want to require the operator to install
> >three separate filters to catch one AF class?
> >
> >I don't find anything in the cited paragraph that contraindicates this
sort
> >of usage. The fact that today's PHB selector set is likely to change is
all
> >the more reason to give a filter-installer some options for concise
> >representation.
> >...
> >   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