Re: Review of draft-ietf-nsis-qspec-18.txt

Jerry,

> This is confusing to me because admission priority has nothing to do  
> with Y.1541.  Y.1541 is associated with the <Y.1541.QoS Class> field  
> (see Section 5.2.14 of the updated -19 QSPEC document or Section  
> 6.2.14 of the current -18 QSPEC document).

mea culpa!!!  in my ramblings, I meant Y.1571, so just swap all  
reference of Y.1541 with Y.1571 from my previous postings

>
> QSPEC admission priority is simply using the 3 priority levels  
> already standardized by Y.2171.  Admission priority is a generic  
> concept, not invented by the ITU, so this is not 'ITU admission  
> priority', just plain ole' admission priority.

I beg to differ.  We are in agreement that admission priority is a  
generic concept, but in Section 6.2.9 of the QSPEC you have bound an  
Admission Priority field with pre-existing values defined in Y.1571   
as written in the following:

	High priority flows, normal priority flows, and best-effort priority
	flows can have access to resources depending on their admission
	priority value, as described in [Y.1571], as follows:

	Admission Priority:

	0 - best-effort priority flow
	1 - normal priority flow
	2 - high priority flow

And now we're told these values are to be updated by Y.2171.  By the  
way, could you tell us what these new values are?  Some of the members  
of the NSIS list are not members of the ITU, and so don't have that  
information on hand.

> What's missing here is an explanation of what the approach is in  
> [EMERGENCY-RSVP].  As I posted earlier in http://www.ietf.org/mail-archive/web/nsis/current/msg08231.html 
> :

as stated by francois:

 >> o Regarding Admission Priority:
 >> 	* every protocol spec will only indicate that "higher value means
 >> higher priority".
 >> 	* there is no attempt to define what specific values should be
 >> used for what. this is left outside the scope of the protocol specs.
but to get to the specifics of what you ask below...

>  "QSPEC is ... standardizing 3 priority levels to have end-to-end  
> cross-domain significance.
>
> If we elimate this standardization, as is proposed (in [EMERGENCY- 
> RSVP]), then different admission priority values can be assigned in  
> different Admin domains, and will have no end-to-end significance.   
> For example, Admin-domain 1, Admin-domain 2, and Admin-domain 3  
> assign admission priority=2,  admission priority=4, admission  
> priority=10 for the highest level priority, respectively.  Admin- 
> domain 1 and Admin-domain 2 try to initiate end-to-end flows via  
> Admin-domain 3 for a 'high priority' flow.  However, Admin-domain 3  
> has no idea how to treat the flow admission priority since all 3  
> domains are using different encodings of high priority."
>
> I've not seen a response to the above example and/or an explanation  
> of how the [EMERGENCY-RSVP] approach achieves end-to-end cross- 
> domain standardization?

[emergency-rsvp] has a policy element that contains numeric-only  
namespace & priority values that can be used as a standard cross- 
domain agreement of sets of priorities.  from this tuple, one can map  
to a locally defined Admission Priority set.  if we take an example  
namespace of "FOO-A", we'll assume: (a)  some set of domains have been  
contracted to support it, and (b) initially, that set of domains  
choose to support the service models of Y.1571.  Here we have an exact  
end-to-end consistency that is agreed to  on a per-domain basis.

later, a subset of these domains (AD-2, AD-3) decide to support  
another namespace "FOO-B", which specifically calls for support of a  
service lower than best effort.  These set of domains then decide to  
support SUPER-Admission-Priority-SET, which is not defined by the ITU  
but includes the values defined Y.1571 along with lower-than-best- 
effort Admission Priority in order to support FOO-B.

policy decision points at the domain edges would do the mappings  
between namespace.priority tuple to admission priority.  and in the  
case of rfc-3181, this would include preemption priority if so needed.

>  Perhaps it is some different approach to priority more like  
> preemption priority?

preemption and defending priority for RSVP is already covered by  
rfc-3181, as mentioned in [emergency-rsvp]

> Perhaps the [EMERGENCY-RSVP] approach should be called "RSVP- 
> priority"?

why?  lets take a step back and see what you are requesting.  you are  
taking what we agree to be a generic named field of Admission Priority  
and asking all of us to only populate it with values defined by the  
ITU.  perhaps I see things oddly, but to me, this field is no longer  
generic but rather explicitly bound to an ITU document.  and please  
note I have no qualms about binding a field to an ITU document, but I  
don't consider that field to be generic.

now, I'll re-ask my question.  if we follow your original approach  
concerning the Admission Priority field, how do we know what priority  
set is to be supported if the ITU comes back and updates Y.2171 with a  
different set of values?  the QSPEC document started with Y.1571, and  
now we have Y.2171.  Certainly a flag day is not what is expected as a  
solution to support Y.<next-priority-set>.

-ken

ps, all is not lost from the original agreement back in Nov/Dec.  All  
three documents are (I believe :-) still in agreement about the  
Namespace.Priority fields and their IANA registration.  If we cannot  
come to consensus about the Admission Priority, then we drop that from  
the agreement.

_______________________________________________
nsis mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/nsis