Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10

From: [email-masked]
Date: Fri, 18 Oct 2002 06:21:31 EDT

In a message dated 10/17/2002 3:02:21 PM W. Europe Daylight Time, 
[email-masked] writes:

> simple answer (in my opinion): yes, you can define priority levels as 
> "low, mediium, and high", though presumably you'll want to be more 
> specific and state "low" in relation to what (e.g., drop precedence).
> 

Thanks for the clarification, but your reference above to "drop precedence" 
is maybe where the confusion is. This implies that it would be okay to define 
a "priority level" for call setup as "low, with a higher packet drop 
precedence", but I have always understood that this was not a good idea, and 
that the point of REQ-7 and Hennings's remarks was to say that this should 
not be done since it was too specific and includes local policy into the 
actual priority value name.

Mike Pierce
Artel

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 18 Oct 2002 12:06:42 +0100

> Thanks for the clarification, but your reference above to "drop 
> precedence" is maybe where the confusion is. This implies that it 
> would be okay to define a "priority level" for call setup as "low, 
> with a higher packet drop precedence", but I have always understood 
> that this was not a good idea, and that the point of REQ-7 and 
> Hennings's remarks was to say that this should not be done since it 
> was too specific and includes local policy into the actual priority 
> value name. 

(keeping in mind that we are viewing "drop precedence" as only an
example -- I'm not advocating or dismissing it, and we are constraining 
our perspective to SIP)....

from my view, there are three things that are not a good idea.  one 
is to articulate the mechanism and rules to *achieve* drop precedence, 
which is something that Henning has been discussing.  we want a
measure of lattitude so that several ways can be used to achieve it.
further, that the measure of drop precedence should also be a local 
policy.

the second is to avoid high level abstract characteristics.

third, when defining a label, one wouldn't want to embed in its
definition the relationship between it and non-related labels -- for 
example, MLPP labels and a NS/EP label are to be viewed as totally
unrelated.  the relationship of non-related labels is strictly a local 
policy issue and subject to the service that has been contracted.

finally, we also want to accept that labels may have additional
constraints or characteristics applied to them as a function of
local policy.  hence, a provider may be contracted to provide a
form of pre-emption for one customer using for example NS/EP, while 
another provider may be contracted to not support pre-emption for 
the same label.  that decision is a matter of local policy.

-ken

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