Subject: Re: [Ieprep] policy & labels

From: [email-masked]
Date: Wed, 9 Oct 2002 15:53:51 EDT

In a message dated 10/9/2002 12:08:24 PM Eastern Standard Time, 
[email-masked] writes:

> there has been a recurring discussion about policy and labels -- people
> for it, against it, confused by its separation, etc.  so it may be helpful
> to have a separate discussion about the subject so that we can put it to 
> rest andmove on to other stuff.
> 
> so, to start the fun, lets see how the following statement grabs folks...
> 
> -------------------------------
> 
>   The process of distinguishing traffic by means of a label can be
>   accomplished in one of two ways.  The first is with a single label, 
>   which acts as a binary on/off indicator distinguishing a set of
>   data/flows from all other data/flows.  The characteristics (e.g., drop 
>   precedence) that one may apply to this single labeled traffic versus 
>   all other traffic is what is refered to as policy.  In addition, the 
>   type of traffic (VoIP, ftp, http, etc.) associated with a label is a
>   separate issue and defined via a policy.  
> 
>   Another way of distinguishing traffic is to use a set of *related* 
>   labels. This set may convey various measures of a characteristic that 
>   is internal to that set.  An example of this case is the Assured 
>   Forwarding (AF) Per-Hop-Behavior (PHB) group of code points defined in
>   RFC2597.  Within each AF class, M different levels of drop level 
>   precedence may be assigned to an IP packet.  Note that the exact level 
>   of drop precendence is not defined for any level.  Further, different 
>   classes, and different PHBs, are unrelated.
> 
>   From this example, we can make a more general statement and say that 
>   one may choose to attribute a type of characteristic to a related set 
>   of labels.  However, the characteristics between one set of defined 
>   labels to all other sets of unrelated labels is separate and not part 
>   of the defined label set.  
> 
> -------------------------------
> 
> 
> Does the above seem reasonable statement to make?  Does it need to be
> more precise, more constrained, less constrained? 
> 
> let thine arrows fly forth :-)
> 
> -ken
> 

I'm sure there will be a lot of responses, which will only point out the 
confusion on this issue.

Mine: The above doesn't help me understand the point. This discussion started 
with "indication" and "policy" and my question related to what it means to 
say that there must be a "separation" between them. I know that there have 
been previous statements about "labels" and "policy" and I've been trying to 
understand what that means for some time. I've worked on signaling protocols 
for many years and no one ever had to make such a distinction. We defined 
protocols with data fields, defined values to go in those fields, and defined 
meanings for those values. And the protocol usually defined the procedures to 
go along with those meanings/values. Never a problem.

So why is this now such a big deal? I think this whole thing about "policy" 
vs" "label" (or "indication") is a non-issue and should be dropped so we can 
get on with defining what is needed.

Henning noted that the old IPv4 TOS bits ("low delay" and "high reliability") 
were examples of not satisfying this requirement, I presume meaning that the 
"indication" and "policy" are not separated. I still don't know what that 
means. If the signaling requirement is to signal two things: "low delay 
needed" or "normal delay acceptable", it makes sense to define a bit where 
the "true" value means "low delay needed". Maybe this is short-sighted if 
there were later a need to signal "medium delay required", but that doesn't 
make it wrong. In this case, it seems to me that "separation" of the 
"indication" and the "policy" would mean that the protocol definition 
(standard) would have to say:
0 = treatment a
1 = treatment b

and the "policy" in each device (not in the standard) would somehow know that:
a = normal delay
b = low delay needed

If that approach were followed for every field or piece of information in the 
protocol, the specification would look pretty silly, and I seriously doubt 
that sufficient interoperability would ever occur.

I question what this requirement means, since I think some will use it to say 
that the protocol can't define a priority parameter with values like "low", 
"medium", and "high".

Mike Pierce
Artel

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 11 Oct 2002 13:41:25 +0100

> vs" "label" (or "indication") is a non-issue and should be dropped so we
> can get on with defining what is needed. 

the consensus on this list and at meetings has been that policy vs
label is an issue.  so, its not going to be dropped.  my hope is that
the added comments from Henning were helpful in explaining the issue.

> If that approach were followed for every field or piece of information 
> in the protocol, the specification would look pretty silly, and I 
> seriously doubt that sufficient interoperability would ever occur. 

no, this is a poor interpretation of my previous message.  i purposely
mentioned articulating a set of characteristics for a related set of
labels such as those that one would expect with MLPP.  I also mentioned
AF as a particular example that one could use in defining labels.

-ken

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep