Subject: [NSIS] Call for consensu on admission priority changes in QSPEC

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 13 Mar 2008 16:41:41 +0100

Hi all,

There have been discussions with respect to QoS NSLP QSPEC Template (draft-ietf-nsis-qspec-19.txt) on the nsis mailing list, offline between involved parties, and also during the NSIS session here at the IETF#71 in the NSIS session (see minutes).

The QSPEC document shares the IANA registries for RPH priority and the admission priority with these drafts out of the DIME and TSVWG:
- draft-ietf-dime-qos- parameters
- draft-ietf-tsvwg-emergency-rsvp

While the IANA registry for the RPH priority has not been disputed, the admission priority has been. 

Therefore we run a call for consensus on these three choices for the admission priority in the QSPEC. Note well, that the decision of this can have an impact to the still running IETF last call for draft-ietf-tsvwg-emergency-rsvp.

Please hum on the NSIS list for one of the three options listed below until Monday, March 17th, 12pm UCT. This is to confirm the humming of the NSIS WG during the NSIS session at the IETF meeting.

1) Keep Y.2171 admission prioty in draft-ietf-nsis-qspec-19.txt as is:

2) Change in draft-ietf-nsis-qspec-19.txt to admission priority as in draft-ietf-tsvwg-emergency-rsvp-05.txt and remove Y.2171 admission prioty;

3) Keep Y.2171 admission priority and add admission priority as in tsvwg-rsvp-emergency to draft-ietf-nsis-qspec-19.txt. 

For choice 3) these changes are currenlty proposed:

1) the emergency-RSVP draft should pretty much stay the same.  There is no "L" bit addition, and its "Admission Priority" field has local significance within a domain, and no pre-existing values are defined for it, nor is there any associated IANA registry assigned to it.

2) The QSPEC draft will have a similar "Admission Priority" field with the same characteristics as that defined above in (1).

3) The QSPEC draft will add a new field, titled "Y.2171 Admission Priority", that will be associated with the current 3 values defined in the Y.2171. This field is considered globally significant on an end- to-end basis.  Note that the emergency-RSVP document will NOT have this additional field.

4) Given the presence of two admin priority fields for the QSPEC, additional rules are added to clarify their application and usage for NSIS domains.

4.1)  if the source domain does NOT support Y.2171, then it sets a locally significant value in the "Admission Priority" field, and places all "1"s in the "Y.2171 Admission Priority" to indicate that this field is to be ignored.  Downstream domains MUST NOT alter the value of the "Y.2171 Admission Priority"  field.

4.2)  if the source domain DOES support Y.2171, then a value (eg, 0, 1, or 2) is placed in the "Y.2171 Admission Priority" field AND the "Admission Priority" field.  Downstream NSIS domains MUST NOT change the value in the "Y.2171 Admission Priority" field so that end-to-end consistency is maintained.  Downstream routers act upon the value placed in the "Admission Priority" field.

4.2.1)  Furthermore, if a downstream NSIS domain does not support Y. 
2171, it MAY place a locally significant different value in the "Admission Priority" field, which is used by downstream routers within its domain.  Subsequent downstream domains that do support Y.2171 make sure that the "Admission Priority" field contains the same value as the "Y.2171 Admission Priority" field.

Thanks,

  Martin

[email-masked]   <== 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 
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Thu, 13 Mar 2008 12:57:03 -0400

Hi, Martin:

I hum for choice 2.

I do NOT hum for choice 1 or 3 for the following reasons because of the serious technical problems:

a. QSPEC is "NOT" ITU-T QOS-specific draft.

b. Any reference to ITU-T QOS-specific definitions and/or any "values" as Y.xxxx-series do, is out-of-scope in the "generic" QSPEC draft. If someone wants ito nclude anything realted to ITU-T QOS-specific things, it MAY only be done in the sections specific to ITU-T Y.xxxx QOS "values." In fact, no "values" will be defined directly or indirectly (e.g. providing references to Y.xxxx) in this draft.

c. It will be more appropriate, to make a separate draft (stand-alone) of QSPEC that is specific to ITU-T QOS models, values, and other things. So, it is better to DELETE all references specific to ITU-T QOS fro mthe "generic: QSPEC draft. In this case, no "apples" will be mixed with any "oranges." This would be taken as the 4th "options" - as the best one.

Best regards,
Radhika

----- Original Message -----
From: Martin Stiemerling 
Date: Thursday, March 13, 2008 11:42
Subject: [NSIS] Call for consensu on admission priority changes in QSPEC
To: nsis 

> Hi all,
> 
> There have been discussions with respect to QoS NSLP QSPEC 
> Template (draft-ietf-nsis-qspec-19.txt) on the nsis mailing list, 
> offline between involved parties, and also during the NSIS session 
> here at the IETF#71 in the NSIS session (see minutes).
> 
> The QSPEC document shares the IANA registries for RPH priority and 
> the admission priority with these drafts out of the DIME and TSVWG:
> While the IANA registry for the RPH priority has not been 
> disputed, the admission priority has been. 
> 
> Therefore we run a call for consensus on these three choices for 
> the admission priority in the QSPEC. Note well, that the decision 
> of this can have an impact to the still running IETF last call for 
> draft-ietf-tsvwg-emergency-rsvp.
> 
> 
> 
> Please hum on the NSIS list for one of the three options listed 
> below until Monday, March 17th, 12pm UCT. This is to confirm the 
> humming of the NSIS WG during the NSIS session at the IETF meeting.
> 
> 2) Change in draft-ietf-nsis-qspec-19.txt to admission priority as 
> in draft-ietf-tsvwg-emergency-rsvp-05.txt and remove Y.2171 
> admission prioty;
> 
> 3) Keep Y.2171 admission priority and add admission priority as in 
> tsvwg-rsvp-emergency to draft-ietf-nsis-qspec-19.txt. 
> 
> 
> 
> 
> 1) the emergency-RSVP draft should pretty much stay the same. 
> There is no "L" bit addition, and its "Admission Priority" field 
> has local significance within a domain, and no pre-existing values 
> are defined for it, nor is there any associated IANA registry 
> assigned to it.
> 
> 2) The QSPEC draft will have a similar "Admission Priority" field 
> with the same characteristics as that defined above in (1).
> 
> 3) The QSPEC draft will add a new field, titled "Y.2171 Admission 
> Priority", that will be associated with the current 3 values 
> defined in the Y.2171. This field is considered globally 
> significant on an end- to-end basis. Note that the emergency-RSVP 
> document will NOT have this additional field.
> 
> 4) Given the presence of two admin priority fields for the QSPEC, 
> additional rules are added to clarify their application and usage 
> for NSIS domains.
> 
> 4.1) if the source domain does NOT support Y.2171, then it sets a 
> locally significant value in the "Admission Priority" field, and 
> places all "1"s in the "Y.2171 Admission Priority" to indicate 
> that this field is to be ignored. Downstream domains MUST NOT 
> alter the value of the "Y.2171 Admission Priority" field.
> 
> 4.2) if the source domain DOES support Y.2171, then a value (eg, 
> 0, 1, or 2) is placed in the "Y.2171 Admission Priority" field AND 
> the "Admission Priority" field. Downstream NSIS domains MUST NOT 
> change the value in the "Y.2171 Admission Priority" field so that 
> end-to-end consistency is maintained. Downstream routers act upon 
> the value placed in the "Admission Priority" field.
> 
> 2171, it MAY place a locally significant different value in the 
> "Admission Priority" field, which is used by downstream routers 
> within its domain. Subsequent downstream domains that do support 
> Y.2171 make sure that the "Admission Priority" field contains the 
> same value as the "Y.2171 Admission Priority" field.
> 
> 
> Thanks,
> 
> Martin
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014

---

From: <[email-masked]>
Date: Thu, 13 Mar 2008 13:52:19 -0500

WG chair hat off, I support 3.

John 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Martin Stiemerling
>Sent: 13 March, 2008 17:42
>To: nsis
>Template (draft-ietf-nsis-qspec-19.txt) on the nsis mailing 
>list, offline between involved parties, and also during the 
>NSIS session here at the IETF#71 in the NSIS session (see minutes).
>
>The QSPEC document shares the IANA registries for RPH priority 
>and the admission priority with these drafts out of the DIME and TSVWG:
>Therefore we run a call for consensus on these three choices 
>for the admission priority in the QSPEC. Note well, that the 
>decision of this can have an impact to the still running IETF 
>last call for draft-ietf-tsvwg-emergency-rsvp.
>
>
>
>Please hum on the NSIS list for one of the three options 
>listed below until Monday, March 17th, 12pm UCT. This is to 
>confirm the humming of the NSIS WG during the NSIS session at 
>the IETF meeting.
>
>2) Change in draft-ietf-nsis-qspec-19.txt to admission 
>priority as in draft-ietf-tsvwg-emergency-rsvp-05.txt and 
>remove Y.2171 admission prioty;
>
>3) Keep Y.2171 admission priority and add admission priority 
>as in tsvwg-rsvp-emergency to draft-ietf-nsis-qspec-19.txt. 
>
>
>
>
>There is no "L" bit addition, and its "Admission Priority" 
>field has local significance within a domain, and no 
>pre-existing values are defined for it, nor is there any 
>associated IANA registry assigned to it.
>
>2) The QSPEC draft will have a similar "Admission Priority" 
>field with the same characteristics as that defined above in (1).
>
>3) The QSPEC draft will add a new field, titled "Y.2171 
>Admission Priority", that will be associated with the current 
>3 values defined in the Y.2171. This field is considered 
>globally significant on an end- to-end basis.  Note that the 
>emergency-RSVP document will NOT have this additional field.
>
>4) Given the presence of two admin priority fields for the 
>QSPEC, additional rules are added to clarify their application 
>and usage for NSIS domains.
>
>4.1)  if the source domain does NOT support Y.2171, then it 
>sets a locally significant value in the "Admission Priority" 
>field, and places all "1"s in the "Y.2171 Admission Priority" 
>to indicate that this field is to be ignored.  Downstream 
>domains MUST NOT alter the value of the "Y.2171 Admission 
>Priority"  field.
>
>4.2)  if the source domain DOES support Y.2171, then a value 
>(eg, 0, 1, or 2) is placed in the "Y.2171 Admission Priority" 
>field AND the "Admission Priority" field.  Downstream NSIS 
>domains MUST NOT change the value in the "Y.2171 Admission 
>Priority" field so that end-to-end consistency is maintained.  
>Downstream routers act upon the value placed in the "Admission 
>Priority" field.
>
>2171, it MAY place a locally significant different value in 
>the "Admission Priority" field, which is used by downstream 
>routers within its domain.  Subsequent downstream domains that 
>do support Y.2171 make sure that the "Admission Priority" 
>field contains the same value as the "Y.2171 Admission Priority" field.
>
>
>Thanks,
>
>  Martin
>
>NEC Laboratories Europe - Network Research Division NEC Europe 
>Limited | Registered Office: NEC House, 1 Victoria Road, 
>London W3 6BL | Registered in England 2832014

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Thu, 13 Mar 2008 15:50:07 -0400

Option 3 negates the main spirit of the IETF QSPEC draft. It implies, as if, ITU-T Yxxxx QOS mechanisms have been the primarily objectives of the draft (indirectly). Is it NOT true?

In this case, the OLD spirit of going backward becomes the primary QOS mechanisms indirectly - that is, non-IETF-specific NGN-centric QOS schemes are getting the primary recognition (indiectly).

Has this been the primary objective of NSIS WG while QSPEC draft was accepted as the working draft? 

Can the authors of this draft do the better job by modifying the write-up focusing the IETF QOS model has been the primary objectives as the NSIS WG has been working on without making the ITU-T QOS models as the primary objectives directly as well as indirectly?

Who is gaining most from this approach # 3 if the draft is not modified?

Best regards,
Radhika

BR/Radhika

----- Original Message -----
From: [email-masked]
Date: Thursday, March 13, 2008 14:53
Subject: Re: [NSIS] Call for consensu on admission priority changes in QSPEC
To: [email-masked], [email-masked]

> >and the admission priority with these drafts out of the DIME and 
> TSVWG:>- draft-ietf-dime-qos- parameters
> >field contains the same value as the "Y.2171 Admission Priority" 
> field.>
> >
> >Thanks,
> >
> > Martin
> >

---

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 13 Mar 2008 21:19:37 +0100

(chair's hat off)

I'm also for option 3.

  Martin

> Behalf Of Martin Stiemerling
> Sent: Thursday, March 13, 2008 11:42 AM
> To: nsis
> The QSPEC document shares the IANA registries for RPH 
> priority and the admission priority with these drafts out of 
> the DIME and TSVWG:
> QSPEC, additional rules are added to clarify their 
> application and usage for NSIS domains.
> 
>  Downstream routers act upon the value placed in the 
> "Admission Priority" field.
> 
> routers within its domain.  Subsequent downstream domains 
> that do support Y.2171 make sure that the "Admission 
> Priority" field contains the same value as the "Y.2171 
> Admission Priority" field.
> 
> 
> Thanks,
> 
>   Martin
> 
> NEC Laboratories Europe - Network Research Division NEC 
> Europe Limited | Registered Office: NEC House, 1 Victoria

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Fri, 14 Mar 2008 09:18:29 -0400

Martin and all:

Is there any consensus on this topic? I only see two persons, co-chairs of the NSIS WG, are replying on option 3 taking their chair's-hat-off.

I disagree with them because of technical inconsistencies for which this QSPEC draft was accepted as the WG draft in the first place. There is no technical reasons why Option 2, that is the best one, will not be taken as consensus of the NSIS WG. 

I like to hear "technical" (not "political" one) pros and cons of both options 2 and 3.

Is there anyone in the WG who oppose Option 2? If so, please voice your technical reasons in the list.

Best regards,
Radhika

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 14 Mar 2008 14:20:45 +0100

I also think option 3 is preferred.
Xiaoming

---

From: ken carlberg <[email-masked]>
Date: Fri, 14 Mar 2008 09:45:06 -0400

please keep in mind that some involved are in transit from the IETF in  
philly.  There have been some technical discussions on this topic on  
the NSIS list in the past two weeks (regrettably mired in some  
arguments).  I'll try and respond to some of your points within the  
next few days.

-ken

On Mar 14, 2008, at 9:18 AM, Roy, Radhika R Dr CTR USA USAMC wrote:

> Martin and all:
>
> Is there any consensus on this topic? I only see two persons, co- 
> chairs of the NSIS WG, are replying on option 3 taking their chair's- 
> hat-off.
>
> I disagree with them because of technical inconsistencies for which  
> this QSPEC draft was accepted as the WG draft in the first place.  
> There is no technical reasons why Option 2, that is the best one,  
> will not be taken as consensus of the NSIS WG.
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 14 Mar 2008 10:08:58 -0400

Hi,
My vote would go for 2 (or 4 as proposed by Roy below).
I can live with 3.
Francois

On 13 Mar 2008, at 12:57, Roy, Radhika R Dr CTR USA USAMC wrote:

> b. Any reference to ITU-T QOS-specific definitions and/or any  
> "values" as Y.xxxx-series do, is out-of-scope in the "generic"  
> QSPEC draft. If someone wants ito nclude anything realted to ITU-T  
> QOS-specific things, it MAY only be done in the sections specific  
> to ITU-T Y.xxxx QOS "values." In fact, no "values" will be defined  
> directly or indirectly (e.g. providing references to Y.xxxx) in  
> this draft.
>
> c. It will be more appropriate, to make a separate draft (stand- 
> alone) of QSPEC that is specific to ITU-T QOS models, values, and  
> other things. So, it is better to DELETE all references specific to  
> ITU-T QOS fro mthe "generic: QSPEC draft. In this case, no "apples"  
> will be mixed with any "oranges." This would be taken as the 4th  
> "options" - as the best one.
>
> Best regards,
> Radhika
>

---

From: David R Oran <[email-masked]>
Date: Fri, 14 Mar 2008 10:14:48 -0400

> My vote would go for 2 (or 4 as proposed by Roy below).
+1.
Dave Oran

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 14 Mar 2008 14:42:54 +0000

Hi all

I support option 3.

Best regards,
Georgios

---

From: ken carlberg <[email-masked]>
Date: Mon, 17 Mar 2008 11:50:31 -0400

Radhika,

I'll state up front that I don't wish to get into a protracted  
argument on this subject, but I'll try and put some perspective into  
the various options.  A review of the NSIS archives from the past 3  
weeks will show that the topic of the Admission Priority field has  
been discussed to near ad nauseam, so I don't wish to repeat or recap  
those discussions.

The one observation I'll bring up is that there was an argument  
against the Nov agreement because it did away with: (a) an end-to-end  
value, and (b) a predefined set of values defined by an ITU document.   
The former is a technical position.  I don't know how to describe the  
latter, though I feel uncomfortable saying that it is "political".   
Now from the recent archives, one will see that I personally don't  
agree with positions (a) and (b).  However, if people are still  
willing to argue for these positions, then I think some weight and  
respect needs to be offered in return.

Obviously, option 1 below is a non-starter if we decide to achieve a  
measure of interoperability between the three drafts (from three  
groups).  Option 2 below is one I feel most comfortable with since it  
exactly mirrors a draft that I have co-authored.

> tsvwg-rsvp-emergency to draft-ietf-nsis-qspec-19.txt.

However, I'll prefer option 3 because satisfies a path to  
interoperability as well as retaining characteristics in the QSPEC  
that some are continuing to argue for, and that reflects previously  
agreed upon positions within NSIS.  In other words, it represents a  
measure of give-and-take that does not prevent opposing points of view  
and does allow the old mantra of "let the market decide" to be  
experienced.

regards,

-ken

---

From: "TARAPORE, PERCY S, ATTLABS" <[email-masked]>
Date: Mon, 17 Mar 2008 13:18:23 -0500

I support option (3).

Percy S. Tarapore

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Martin Stiemerling
Sent: Thursday, March 13, 2008 11:42 AM
To: nsis
Subject: [NSIS] Call for consensu on admission priority changes in QSPEC

Hi all,

There have been discussions with respect to QoS NSLP QSPEC Template
(draft-ietf-nsis-qspec-19.txt) on the nsis mailing list, offline between
involved parties, and also during the NSIS session here at the IETF#71
in the NSIS session (see minutes).

The QSPEC document shares the IANA registries for RPH priority and the
admission priority with these drafts out of the DIME and TSVWG:
- draft-ietf-dime-qos- parameters
- draft-ietf-tsvwg-emergency-rsvp

While the IANA registry for the RPH priority has not been disputed, the
admission priority has been. 

Therefore we run a call for consensus on these three choices for the
admission priority in the QSPEC. Note well, that the decision of this
can have an impact to the still running IETF last call for
draft-ietf-tsvwg-emergency-rsvp.

Please hum on the NSIS list for one of the three options listed below
until Monday, March 17th, 12pm UCT. This is to confirm the humming of
the NSIS WG during the NSIS session at the IETF meeting.

2) Change in draft-ietf-nsis-qspec-19.txt to admission priority as in
draft-ietf-tsvwg-emergency-rsvp-05.txt and remove Y.2171 admission
prioty;

1) the emergency-RSVP draft should pretty much stay the same.  There is
no "L" bit addition, and its "Admission Priority" field has local
significance within a domain, and no pre-existing values are defined for
it, nor is there any associated IANA registry assigned to it.

2) The QSPEC draft will have a similar "Admission Priority" field with
the same characteristics as that defined above in (1).

3) The QSPEC draft will add a new field, titled "Y.2171 Admission
Priority", that will be associated with the current 3 values defined in
the Y.2171. This field is considered globally significant on an end-
to-end basis.  Note that the emergency-RSVP document will NOT have this
additional field.

4) Given the presence of two admin priority fields for the QSPEC,
additional rules are added to clarify their application and usage for
NSIS domains.

4.1)  if the source domain does NOT support Y.2171, then it sets a
locally significant value in the "Admission Priority" field, and places
all "1"s in the "Y.2171 Admission Priority" to indicate that this field
is to be ignored.  Downstream domains MUST NOT alter the value of the
"Y.2171 Admission Priority"  field.

4.2)  if the source domain DOES support Y.2171, then a value (eg, 0, 1,
or 2) is placed in the "Y.2171 Admission Priority" field AND the
"Admission Priority" field.  Downstream NSIS domains MUST NOT change the
value in the "Y.2171 Admission Priority" field so that end-to-end
consistency is maintained.  Downstream routers act upon the value placed
in the "Admission Priority" field.

4.2.1)  Furthermore, if a downstream NSIS domain does not support Y. 
2171, it MAY place a locally significant different value in the
"Admission Priority" field, which is used by downstream routers within
its domain.  Subsequent downstream domains that do support Y.2171 make
sure that the "Admission Priority" field contains the same value as the
"Y.2171 Admission Priority" field.

Thanks,

  Martin

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,

---

From: Al Morton <[email-masked]>
Date: Mon, 17 Mar 2008 22:19:21 -0400

can live with 3)
Al

At 11:41 AM 3/13/2008, Martin Stiemerling wrote:
>...

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 18 Mar 2008 06:07:05 +0100

Dear all,

The call for for consensus for the proposed change on the admission priority in QSPEC ended Monday.  The majority voted for option 3 (7 in total) while option 2 got 1 vote.

So we have consensus for option 3. 

To the QSPEC authors: Please update the spec accordingly and submit the new version. Once we have the new version, we can give it a short review and if the WG is fine we go for AD review. 

Thank you,

  Martin

> Sent: Thursday, March 13, 2008 4:42 PM
> To: nsis

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Thu, 20 Mar 2008 15:57:09 -0400

Ken:

Sorry for the delay as I had been in DoD Architecture Conference for the last 3 days.

You and other members can take the lead in finalizing the QSPEC draft.

Best regards,
Radhika