Subject: [Diffserv] Re: Question about qosActionEntry

From: Andrew Smith <[email-masked]>
Date: Thu, 27 Jul 2000 00:51:26 -0700

Michael,

I may be reading too much into your answer but I think that those are both bad
assumptions to make in general (they might be OK in specific deployments or for
specific devices - perhaps that's what you meant?). 

For (1), you need to be able to represent rules that filter and/or mark on
802.1p and/or DSCP, all 4 combinations of the above, independently.

For (2), I think it is a really bad idea to use DSCP as a canonical
representation of a PHB - go back and read all of the ancient Diffserv
discussion which lead to the whole idea of separating the two for some clues as
to why this is a bad thing to do. A DSCP is merely a 6-bit label for use *on the
wire* - it has no meaning internal to a device once it has been translated to
the PHB that it represents. What happens if you have a device that supports 65
different PHBs? What if a DSCP means one thing on one interface and a different
thing on another? You need an internal representation but you must not overload
DSCP with that function. 

BTW, on a related topic, you discounted my earlier comment that the PIB ought to
be able to reflect the capability to influence a drop algorithm using more than
just DSCP (the use of VLAN, 802.1p, uni-/multicast or IPsrc/dest information
come to mind) - that is why the Diffserv model and MIB allow for placing an
arbitrary classifier at that point: I think that the PIB should do the same -
this is a gratuitous difference from the Model for the sake of saving a few
objects in the PIB definition. If not then at least an extensibility mechanism
should be provided to achieve this.

Andrew

[CCing the Diffserv list]

Michael Fine wrote:
> 
> There are two ways to look at this.
> 
> 1.  The filter is filtering on layer 2 (or any other) information but
> the packets are still IP packets.  In this case, it still makes sense
> to re-write the DSCP in the packet header.
> 
> 2.  The DSCP is a canonical representation of the PHB.  It is used
> internal to the device to decide how to treat the packet.  For
> example, it determines which queue to enqueue the packet onto even for
> non-IP packets (do such things exist? :-).  In this case it would not
> imply any modification of the packet header itself.
> 
> That said, one can imagine a enterprise-specific PIB that, say, maps
> DSCP to 802.1p CoS and a device that writes the 802.1p field of a
> packet based on the mapped DSCP from the qosActionEntry.
> 
> Michael
> 
> Rajiv Dighe writes:
>  > From: Rajiv Dighe <[email-masked]>
>  > To: rap <[email-masked]>
>  > Subject: Question about qosActionEntry
>  > Date: Tue, 25 Jul 2000 14:31:28 -0400
>  >
>  > Hi All,
>  >
>  >     Pardon me if this seems like a stupid question. in qosActionEntry,
>  > possible values for qosActionAction are drop, mark or leave unchanged.
>  > hypothetically speaking let's say that I am talking to a PEP that is capable
>  > of layer2 as well as layer3 classification. If I install a qos802Ace entries
>  > in my decision & specify action as mark with Dscp of 0x24 is that an error?
>  > AFAIK, even if device was capable of looking deep witheen ethernet frame,
>  > this action will not make sense if payload carried in the frame is anything
>  > other than IP. If this indeed an error, does that mean specifying an action
>  > of mark for 802 traffic is not allowed? this becomes more of an issue now
>  > that latest drafts allow a target entry to point to a mix of IP & 802
>  > filters.
>  >
>  > Regards,
>  >
>  > --Rajiv
>  >
>  >

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jul 2000 11:02:52 -0500

Andrew Smith wrote:

> representation of a PHB

It's not just a bad idea; it's a clear violation of RFC 2474.

The canonical representation of a PHB is a PHB ID, and that
is a 16 bit quantity as defined in Proposed Standard RFC 2836.
This is what should be used in protocol messages and policy
repositories.

There could of course be a configuration message saying
what the local mapping from a PHBID to a DSCP value is.

   Brian

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 27 Jul 2000 12:29:36 -0700 (PDT)

There's enough misunderstandings on this mailing-list at the moment.
Let's not fuel the fires by misunderstanding what Michael meant when
he used the term "canonical".

Thanks,
Keith.

---

From: "Michael Fine" <[email-masked]>
Date: Thu, 27 Jul 2000 14:05:47 -0700 (Pacific Daylight Time)

> specific devices - perhaps that's what you meant?). 

I think you are.  The real point of making the qosTargetFilterId a
PolicyTagReference is to allow flexibility in defining and using new
filter classes, most likely new IP filter classes.  My comments were
to answer specifically the question of how qosActionEntry would
suffice in its current form if a layer 2 filter were to be used.

So yes, they would be for specific deployments or devices.

I would agree that this is not necessarily ideal were we trying to
support L2 protocols and other L3 protocols but the clear message from
the last IETF is that this is not in our charter.

 > For (2), I think it is a really bad idea to use DSCP as a canonical

Looks like this was a poor choice of word.  I apologize.  Again, in
the context of answering the original post, the point is that is
suffices to support policies to mark L2 packets with a 802.1p CoS (for
example).

Now, if you want to introduce a canonical  representation of PHB into
the PIB and a mapping to DSCP that is a different issue.

 > should be provided to achieve this.

This comes back to the ongoing discussion we have had as to whether or
not the PIB, which represents user policies needs to have the same
flexibility as the MIB, which represents all possible device
capabilities.  We have obviously not reached closure on this.

Michael

---

From: Andrew Smith <[email-masked]>
Date: Thu, 27 Jul 2000 14:28:49 -0700

Keith,

I don't mean to fuel any fires here (I assume you mean Diffserv list, not RAP
list). But it seems to me, despite you previous note, that using DSCP to select
queues and dropping algorithms is not the right approach. You seem to be
limiting the PIB solution to a single "Diffserv domain" (if that is the correct
term for a set of nodes and links where a DSCP means the same thing) - I think
that is not a good idea. If you are using some other discriminator to support
multiple such domains then I think that needs to be made more explicit in the
draft. 

The draft does also need to explain why PHB ID is not used instead of DSCP.
However, I don't believe that a single integer that has scope over more than a
single node is adequate for this task.

Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jul 2000 16:45:14 -0500

Keith,

I don't understand your point.

It is correct, as you said in your other comment on this thread,
that a DSCP should map to one and only one PHB within a DS domain.
But it is a local mapping, and a DSCP value does not identify a PHB
at inter-domain level; at that level a PHBID is the only
canonical representation of a PHB. 

That much is a matter of fact. As a matter of opinion, I think
it would be a more robust design to use PHBIDs within a domain,
except for a specific configuration command to define the local
PHBID <=> DSCP mapping.

  Brian

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 27 Jul 2000 22:29:11 -0700 (PDT)

Brian,

A PHBID is a formalism, and an indirection, which is necessary between
two different DiffServ domains, because they could well have different
DSCP values for the same PHB.  However, it introduces the extra item
of configuration that you mention, which of course, it is possible to
mis-configure.  Within a single DiffServ domain, where as you say, a
DSCP should map to a single PHB, the use of PHBID is unnecessary and
provides no benefit.  In contrast, the use of the actual DSCP value
avoids that extra configuration, and the possibility of its
mis-configuration.  So, I would argue that the use of DSCP within a
DiffServ domain is a more robust design.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 27 Jul 2000 23:26:49 -0700 (PDT)

Andrew,

> that is not a good idea.

On the contrary, it is a fine idea.  While the *definition* of a PIB
applies to all domains, the *values* within a PIB are intended for one
administration to configure policy within a particular DiffServ domain
that it administers.  If an administration which supports multiple
domains, chooses to use similar policies in those multiple domains,
then it can use the same values (the same policies) within the PIB for
those multiple domains.  If the administration chooses to use different
policies in separate domains, then it will need to use different values
(for the same PRCs) defined in the PIB for the separate domains.

> If you are using some other discriminator to support

Why would you suggest this for the PIB ?  I apologise if I am wrong, but
it sounds to me like a "spur of the moment" objection, because I note that
you are a co-author of all three documents, the model, the MIB and the PIB,
and none of them contain such an explanation.

> single node is adequate for this task.

I find your statement hard to understand because it seems to imply that
you don't believe that the aims of policy management can be applied in
this case, nor do you believe Brian's statement that "DSCP should map to
one and only one PHB within a DS domain".

Using the same analogy as in my previous message, you are thinking of a
need to control the players on a team individally (as the model and the
MIB do).  From a policy perspective, we need to be thinking about how to
control a team (i.e., a DiffServ domain) as a whole.

Keith.

---

From: Andrew Smith <[email-masked]>
Date: Fri, 28 Jul 2000 10:27:04 -0700

Keith,

> (for the same PRCs) defined in the PIB for the separate domains.

I'm still not understanding how a PDP that supports multiple Diffserv domains
communicates which domain a particular rule is meant for to a device that is
also in multiple Diffserv domains. Am I missing some implicit assumption that a
given PDP/PEP combo is entirely within a single Diffserv domain? I think that
would be an overly-limiting assumption.

> and none of them contain such an explanation.

Not sure what you mean by "spur of the moment" - I would guess that 99% of all
messages on this mailing list are spur of the moment discussions. And it's not
an objection, just a comment that you can take or leave as you please. The Model
draft does not address this because it talks only about packet filters without
placing any semantics on their values other than as a pattern match. The MIB
gets down to more specific syntactical things: but it too only addresses packet
filters within a single {device, interface, direction} scope. Within that scope
a DSCP is fine. 

The PIB, however, is attempting to cover a network-wide scope and, I believe, a
DSCP alone is not adequate for that. You can narrow the scope to a single
Diffserv domain if you like but I think that makes it less useful. As I
understood the PHB-ID concept, that was meant to cover network-wide scope across
multiple Diffserv domains: if the PIB is unable to use this concept then, I
would assert, the PHB-ID concept is useless and we should withdraw that document
from the standards' track.

Andrew