Re: Admission field in QSPEC -- was RE: Review ofdraft-ietf-nsis-qspec-18.txt

Martin and all:

I believe that the part of the problems of the QSPEC draft is mixing of two things: 1. A generalized QOS scheme that does not specify and particular "values" used by Y.xxx (ITU-T), MPLS QOS (IETF), etc. and 2. Implementation-specific schemes that mandate some specific values by ITU-T Y.xxx, IETF MPLS QOS, etc.

In the beginning, I already raised the same issue and proposed that the draft needs to be split into two parts: Part I: A generalized QSPEC draft that does not mandate any values in any fields and Part II: Implementation-specific QSPEC draft - a. IETF MPLS QOS Model, b. IETF DiffServ QOS Model, c. ITU-T Y.xxx models, etc.

Now, we are seeing that the discussions and proposals are bouncing back and forth between the two parts: Part I and Part II.

In the past, I also suggested that Part I QSPEC draft can be a standard-track RFC while Part II may have several "Informational RFCs."

I suggest that we have still time to follow the above guidance by splitting the draft. I would be extremely glad if people would prove that my suggestion is the wrong one.

Best regards,
Radhika

----- Original Message -----
From: Martin Stiemerling 
Date: Thursday, February 28, 2008 8:41
Subject: Re: [NSIS] Admission field in QSPEC -- was RE: Review ofdraft-ietf-nsis-qspec-18.txt
To: ken carlberg , Gerald Ash 
Cc: John Loughney , nsis 

> [writing as WG member, i.e. WG chair's hat off]
> 
> Hi,
> 
> I took a while to wrap my head around it, as this touches not only 
> NSIS' business but also other WG's business. 
> 
> I see the benefits of the end-to-end approach in general and also 
> in particular for the QSPEC draft. The IETF is good in doing end-
> to-end protocols but has some issues in defining end-to-end QoS 
> solutions (note the diffence between 'protocols' and 'solutions'). 
> Having end-to-end QoS and signalling of it, is definitetly 
> beneficially but is also troublesome.
> 
> We are doing protocols and not architectures, so it is hard to 
> mandate which QoS scheme is used in the Internet or any other 
> closed deployment. This lead to the concept of local QSPEC in the 
> QSPEC draft which solves this at least on the signalling side but 
> not on the semantics side (i.e., what do different bits mean in 
> different domains).
> 
> ITU Y.2171 (Admission control priority levels in Next Generation 
> Networks) is manadated for the admission priority in QSPEC 
> regardless of the used admission priority scheme in a single 
> domain. It is intended for NGN networks (which is ITU specific) 
> but does not apply IMHO to the whole Internet as such. This does 
> not excluded in general, but I don't regard ITU Y.2171 as the 
> single scheme for all deployments.
> 
> The current definition of the Admission Priority in the QSPEC 
> draft contradicts also the local QSPEC mechanism. A local domain 
> that uses ITU Y.2171 can do this by using a local QSPEC. However, 
> the general Admission Priority in the QSPEC must be free of ITU 
> semantics, as this is from an IETF perspective just one of the 
> possible admission schemes that can be used. 
> 
> Long story short: I'm in favour of Francois' proposal for the 
> Admission Priority, posted on Dec 3, 2007:
> http://www.ietf.org/mail-archive/web/nsis/current/msg08155.html
> 
> Martin
> 
> [email protected] <== NEW ADDRESS
> 
> NEC Laboratories Europe - Network Research Division
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On 
> > Behalf Of ken carlberg
> > Sent: Wednesday, February 27, 2008 8:59 PM
> > To: Gerald Ash
> > Cc: John Loughney; nsis
> > Subject: Re: [NSIS] Admission field in QSPEC -- was RE: 
> > Review ofdraft-ietf-nsis-qspec-18.txt
> > 
> > 
> > On Feb 27, 2008, at 12:56 PM, Gerald Ash wrote:
> > 
> > 
> > Obviously one option is for emergency-rsvp to adopt the 
> > approach being taken all along in QSPEC. We are not being 
> > told why this is not considered. 
> > 
> > 
> > oh come on. how many times must be said and in how many 
> > ways? on February 25, 2008 2:50:24 PM EST I stated the following
> > 
> > "and as far as the current values set by Y.1541, I wish there 
> > was support for Scavenger Service, which is considered less 
> > than Best Effort (already defined as "0" in Y.1541). Since 
> > I'm not a member of the ITU, I can't advocate this position 
> > nor accomplish it if the Admission field of all three drafts 
> > , and are 
> > subject to values defined by the ITU."
> > 
> > 
> > Put another way, Francois and I have said that we don't want 
> > an Admission Priority field to be constrained (limited, 
> > burdened,....pick the word of your choice) with pre-existing 
> > values, and in particular those that come from a different 
> > standards body. And we are not condemning all other similar 
> > practices. We are not even saying that those of Y.2171 
> > cannot be used.
> > 
> > as for as the agreement that was passed around in nov/dec, 
> > you are not a newbie to think that agreements are etched in 
> > stone. they exist to be commented on, hence our letting 
> > others on the diameter/tsvwg/nsis list know the results of 
> > private discussions.
> > 
> > 
> > 
> > IMO we should retain the standardized admission 
> > priority levels as included in QSPEC for a long time. If 
> > emergency-rsvp cannot adopt the same approach, then for now 
> > retain 2 approaches.
> > 
> > 
> > and I brought this up a while back as well. we have no 
> > intention of steam rolling the agreement. if part of the 
> > agreement breaks, it breaks and we'll go our separate ways. 
> > 
> > and I apologize if this note is sounding a bit rude, but part 
> > of this is getting a bit much.
> > 
> > -ken
> > 
> > 
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis
>