Subject: [NSIS] QSPEC document

From: <[email-masked]>
Date: Fri, 19 Jan 2007 06:16:19 -0600

Jerry,

Could you send an update on the current status on the QSPEC? I think we
were wrapping up most of the open issues, but it might be good to have a
summary of where we stand on this.  When do you think that you can
update the document?

thanks,
John
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 19 Jan 2007 15:31:01 -0600

Hi John,
 
Per your request, I provide below a summary of the agreed-to
changes/updates to the QSPEC draft
http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt, based on
the list discussion over the last few weeks.

I plan to update the draft according to these changes and submit in the
next day or two.  Hopefully then we'll be ready to go to WGLC on the
document?

Thanks,
Regards,
Jerry

There were 3 issues being debated at length on the list, summarized here
by Georgios:
http://www1.ietf.org/mail-archive/web/nsis/current/msg07374.html

Editor responses to these 3 issues are here:
http://www1.ietf.org/mail-archive/web/nsis/current/msg07402.html

to which you responded:
http://www1.ietf.org/mail-archive/web/nsis/current/msg07407.html

and further declared consensus on these 3 issues as follows:
1. http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html
2. http://www1.ietf.org/mail-archive/web/nsis/current/msg07409.html
3. http://www1.ietf.org/mail-archive/web/nsis/current/msg07410.html

Based on the declared consensus in 1, 2, and 3 above the following
changes are agreed to:

1. Add the following text to Section 4.3.3 (Traffic Handling
Directives):

"Note that QOSM specifications SHOULD NOT define new RMF functions
required by a QOSM UNLESS such NSIS signaling functionality is defined
in QoS NSLP [QoS-SIG].  That is, a QOSM is not allowed to extend QoS
NSLP signaling functionality; new RMF functions are specified only
within a QoS NSLP signaling framework."

2. Add the following text to Section 5.1 (Local QSPEC Definition &
Processing):

"Note that it is possible to use, at the same time, both a) tunneling a
QSPEC through a local domain by initiating a new RESERVE at the domain
edge, and b) defining a local QSPEC and encapsulating the initiator
QSPEC, as defined above."

3. Add the following text to Section 4.1 (QoS Models):

"Signaling functionality is only defined by the QoS NSLP document
[QoS-SIG] and not by this document."

Also based on list discussion, these changes have been agreed to:

4. Add the following text to Section 4.1 (QoS Models), and also
reference specifically in Section 4.3.3 (Traffic Handling Directives):

"QOSMs are free, subject to IANA registration and review rules, to
extend QSPECs by adding parameters of any of the kinds supported by the
standard QSPEC.  This includes traffic description parameters,
constraint parameters and traffic handling directives. QOSMs are not
permitted, however, to reinterpret or redefine the standard QSPEC  
parameters specified in this document."

5. In Section 5.1 (Local QSPEC Definition & Processing), last paragraph:
 
Change:
"For example, RMD can define a local QSPEC that contains TMOD =
bandwidth (sets r=p, b/m to large)."

Into:
"For example, in RMD the TMOD parameters contained in the original
initiator QSPEC are mapped into the equivalent TMOD parameter
representing only the peak bandwidth in the local QSPEC."

6. In Section 6.1 (General QSPEC Formats):
Remove the sentence
"N Flag: Not-supported QSPEC parameter flag (see Section 5.2.2).  For
QSPEC parameters the value of this flag is always zero."

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 19, 2007 7:16 AM
To: [email-masked]
Subject: [NSIS] QSPEC document

Jerry, 

thanks, 
John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 22 Jan 2007 13:14:38 +0100

Hi Jerry

Please see my updated comments on v. 13 of the QSPEC template draft
that I have sent this morning.
The below paragraph is in contradiction with the agreed NSIS concepts.
Please note that RMF functions are defined by QOS models and not by the 
QOS-NSLP signaling framework.

"Note that QOSM specifications SHOULD NOT define new RMF functions required
by a QOSM UNLESS such NSIS signaling functionality is defined in QoS NSLP
[QoS-SIG].  That is, a QOSM is not allowed to extend QoS NSLP signaling
functionality; new RMF functions are specified only within a QoS NSLP
signaling framework." 

Regarding other issues plese check my e-mail that I have sent this morning.

Best Regards,
Georgios

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: vrijdag 19 januari 2007 22:31
> To: [email-masked]; [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: RE: [NSIS] QSPEC document
> 
> Hi John,
>  
> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt, 
> based on the list discussion over the last few weeks.
> 
> I plan to update the draft according to these changes and 
> submit in the next day or two.  Hopefully then we'll be ready 
> to go to WGLC on the document?
> 
> Thanks,
> Regards,
> Jerry
> 
> There were 3 issues being debated at length on the list, 
> summarized here by Georgios:
> Based on the declared consensus in 1, 2, and 3 above the 
> following changes are agreed to:
> 
> "Note that QOSM specifications SHOULD NOT define new RMF 
> functions required by a QOSM UNLESS such NSIS signaling 
> functionality is defined in QoS NSLP [QoS-SIG].  That is, a 
> QOSM is not allowed to extend QoS NSLP signaling 
> functionality; new RMF functions are specified only within a 
> QoS NSLP signaling framework."
> 
> "Note that it is possible to use, at the same time, both a) 
> tunneling a QSPEC through a local domain by initiating a new 
> RESERVE at the domain edge, and b) defining a local QSPEC and 
> encapsulating the initiator QSPEC, as defined above."
> 
> "Signaling functionality is only defined by the QoS NSLP 
> document [QoS-SIG] and not by this document."
> 
> 4. Add the following text to Section 4.1 (QoS Models), and 
> also reference specifically in Section 4.3.3 (Traffic 
> Handling Directives):
> 
> "QOSMs are free, subject to IANA registration and review 
> rules, to extend QSPECs by adding parameters of any of the 
> kinds supported by the standard QSPEC.  This includes traffic 
> description parameters, constraint parameters and traffic 
> handling directives. QOSMs are not permitted, however, to 
> reinterpret or redefine the standard QSPEC parameters 
> specified in this document."
> 
> "For example, RMD can define a local QSPEC that contains TMOD 
> = bandwidth (sets r=p, b/m to large)."
> 
> Into:
> "For example, in RMD the TMOD parameters contained in the 
> original initiator QSPEC are mapped into the equivalent TMOD 
> parameter representing only the peak bandwidth in the local QSPEC."
> 
> "N Flag: Not-supported QSPEC parameter flag (see Section 
> 5.2.2).  For QSPEC parameters the value of this flag is always zero."
> 
> Could you send an update on the current status on the QSPEC? 
> I think we were wrapping up most of the open issues, but it 
> might be good to have a summary of where we stand on this.  
> When do you think that you can update the document?
> 
> thanks,
> John 
>

---

From: Lars Westberg <[email-masked]>
Date: Mon, 22 Jan 2007 14:18:29 +0100

I don't understand what you suggesting. The resriction that you put on 
the protocl may makes the protocol useless for any future extention. The 
restriction seems to be much more restrict that anyone have put on 
implementation of RSVP.

All of us that have been working with QoS for a long time knows that 
there are no need for QoS-signalling becaue RSVP solves the same problem 
with better performance and more functionality. I think therefore that 
somone have mis-understand the whole task for NSIS. The major was to 
design a new "skeleton" for signalling with increase modularity.

The task that NSIS can solve resides outside the RSVP-application area. 
However, I list some of the previous extention that have been discussed 
for RSVP.

-signalling proxy suppport. Previous work  to define a proxy for 
RSVPshowed a set of difficulties to design a RSVP-proxy because 
infomration element was missing. This will probably implies new 
control-bits.

-indication of header compression. In some links, the status-bits to 
indicate  header compression to let the end-points/edge-routers that 
header comppression is applied to the media stream. This may impact the 
RMF-function becuse less resources are needed for a compressed flow. 
This has ben discussed for RSVP.

- ECN: We will see different marking schemes for ECN implemented. 
Therefore, the PCN-group suggestion that RSVP should be carry 
control-bits for indicating "what type of marking scheme" that should be 
supported. This is a very good example when a certain property are 
carried into the signalling protocol.

Traffic Engineering: For traffic engineering, different routing 
information like explicit routing was included into RSVP. This has a 
major impact of the protocol execution and several additional object was 
included.

I completely disagree with Jerrys suggestion and I think the working 
group has to go back to the design team to re-solve it. This is an basic 
architecture disaster.

regards Lasse

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Jan 2007 14:18:50 +0100

Hi,

As AD I am concerned about the lack of co-operation and consideration 
between dependent charter items and their proponents. In my view, any 
thought of changes that risk affecting the other items must first be 
investigated and discussed with first the proponents and the in the 
whole WG. Especially in these late stages when the goal is to finish up. 
Making major changes to agreed concept affecting other documents should 
do only if necessary and under clear consensus in the WG.

Regards

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Mon, 22 Jan 2007 14:28:58 +0100

Hi Jerry and All, I disagree with statement 1. Defining new RMF function is one of the major goals of QoS Models. I assumed there was a consensus about it previouisly.

Best regards, Attila

>Sent: Friday, January 19, 2007 10:31 PM
>also reference specifically in Section 4.3.3 (Traffic Handling 
>Directives):
>
>Could you send an update on the current status on the QSPEC? I 
>think we were wrapping up most of the open issues, but it

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 22 Jan 2007 08:00:36 -0600

Magnus, 

See below.

> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Monday, January 22, 2007 8:19 AM
> To: Georgios Karagiannis
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: [NSIS] QSPEC document
> 
> Hi,
> 

I'm not sure I parse your above statement correctly.  However, I think
you should see John's statement of consensus at
http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html.  The
text in question is exactly the same as in John's message.  All this is
saying is that the QoS-NSLP document is the only document that can
define new QoS signaling functionality, not QOSM specification
documents, and not the QSPEC document.  

Dave Oran, John, and others have made this same point several times on
the list, over a long period of time.  John has declared consensus on
this point and on the specific text.  There is no 'major change'
introduced here.  So I'm not sure what 'lack of co-operation' you are
referring to here?

Jerry

> functions required

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Mon, 22 Jan 2007 15:05:39 +0100

Comments inline

There are no consensus about it.

I disagree about it.

Regards Lasse 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
Sent: den 22 januari 2007 15:01
To: Magnus Westerlund (KI/EAB)
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: RE: [NSIS] QSPEC document

Magnus, 

See below.

> Making major changes to agreed concept affecting other documents 
> should do only if necessary and under clear consensus in the WG.

Jerry

> >> I plan to update the draft according to these changes and submit in

> >> the next day or two.  Hopefully then we'll be ready to go to WGLC 
> >> on the document?
> >>
> >> Thanks,
> >> Regards,
> >> Jerry
> >>
> >> There were 3 issues being debated at length on the list, summarized

> >> here by Georgios:
> >> required by a QOSM UNLESS such NSIS signaling functionality is 
> >> defined in QoS NSLP [QoS-SIG].  That is, a QOSM is not allowed to 
> >> extend QoS NSLP signaling functionality; new RMF functions are 
> >> specified only within a QoS NSLP signaling framework."
> >>
> >> extend QSPECs by adding parameters of any of the kinds supported by

> >> the standard QSPEC.  This includes traffic description parameters, 
> >> constraint parameters and traffic handling directives. QOSMs are 
> >> not permitted, however, to reinterpret or redefine the standard 
> >> QSPEC parameters specified in this document."
> >>
> >> "N Flag: Not-supported QSPEC parameter flag (see Section 5.2.2).  
> >> For QSPEC parameters the value of this flag is
> always zero."
> >>
> >> I think we were wrapping up most of the open issues, but it might 
> >> be good to have a summary of where we stand on this.

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 22 Jan 2007 08:12:11 -0600

Attila, 

> From: Attila Báder (IJ/ETH) [mailto:[email-masked]] 
> Sent: Monday, January 22, 2007 8:29 AM
> To: Ash, Gerald R (Jerry), ALABS; [email-masked]; 
> [email-masked]
> Hi Jerry and All, I disagree with statement 1. Defining new 
> RMF function is one of the major goals of QoS Models. I 
> assumed there was a consensus about it previously.

I think that you and perhaps others are misreading the text in statement 1.  QOSM specifications can certainly define RMF functions.  The statement says that the QoS-NSLP document is the only document that can define new QoS signaling functionality, not QOSM specification documents, and not the QSPEC document.  

See John's statement of consensus at http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html.  The text in question is exactly the same as in John's message.  Dave Oran, John, and others have made this same point several times on the list, over a long period of time, and John has declared consensus on this point and on the specific text.

Thanks,
Jerry

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Mon, 22 Jan 2007 15:11:15 +0100

The latest version 13 should not be consered as a working group
document.
It has not discussed in the design team and therefore not valid as a
working group docunment. Therefore, we have to toll back to the previous
document and we should start from that to discuss the evolutio.

An editorship does not mean that the documetn is written by the editor
and therefore a fundamental wrong way of working has happen.

Regards Lasse 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
Sent: den 22 januari 2007 15:01
To: Magnus Westerlund (KI/EAB)
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: RE: [NSIS] QSPEC document

Magnus, 

See below.

Jerry

---

From: <[email-masked]>
Date: Mon, 22 Jan 2007 08:19:31 -0600

Lars,

As chair, I have declared rough consensus on the issue. There is no
consensus that each QoSM would be able to change the signaling of the
QoS NSLP.  Additionally, only the RMD authors have a problem with this
issues. Implementors of the QoS NSLP have commented that allowing QoSMs
to modify the QoS NSLP behavior would create a huge amount of complexity
for implementations. 

I judge that there has been consensus on this issue, and I have judged
that there is rough consensus from the working group on the current
editing of the QSPEC document.

John
>From: ext Lars Westberg (KI/EAB) [mailto:[email-masked]] 
>Sent: 22 January, 2007 16:11
>To: Ash, Gerald R (Jerry), ALABS; Magnus Westerlund (KI/EAB)
>Cc: [email-masked]
>The latest version 13 should not be consered as a working 
>group document.
>It has not discussed in the design team and therefore not 
>valid as a working group docunment. Therefore, we have to toll 
>back to the previous document and we should start from that to 
>discuss the evolutio.
>
>An editorship does not mean that the documetn is written by 
>the editor and therefore a fundamental wrong way of working has happen.
>
>
>Regards Lasse 
>
>I'm not sure I parse your above statement correctly.  However, 
>I think you should see John's statement of consensus at 
>http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.htm
>l.  The text in question is exactly the same as in John's 
>message.  All this is saying is that the QoS-NSLP document is 
>the only document that can define new QoS signaling 
>functionality, not QOSM specification documents, and not the 
>QSPEC document.  
>
>Dave Oran, John, and others have made this same point several 
>times on the list, over a long period of time.  John has 
>declared consensus on this point and on the specific text.  
>There is no 'major change'
>introduced here.  So I'm not sure what 'lack of co-operation' 
>you are referring to here?
>
>Jerry
>
>> 
>> Regards
>> 
>> Magnus
>> 
>> 
>submit in
>summarized
>> >> 1. 
>http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html
>> >> 2. 
>http://www1.ietf.org/mail-archive/web/nsis/current/msg07409.html
>> >> 3. 
>http://www1.ietf.org/mail-archive/web/nsis/current/msg07410.html
>> >>
>functions 
>rules, to 
>original

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Mon, 22 Jan 2007 15:20:42 +0100

Comments inline 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
Sent: den 22 januari 2007 15:12
To: Attila Báder (IJ/ETH); [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: [NSIS] QSPEC document

Attila, 

> Hi Jerry and All, I disagree with statement 1. Defining new RMF 
> function is one of the major goals of QoS Models. I assumed there was 
> a consensus about it previously.

The major problem is the statment makes the protocol useless. Why should we develop a solution that has less flexibillity than RSVP ???

See John's statement of consensus at http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html. 

There are no consensus that's a mis-understanding by John. The major problem is that the development of the draft have not been done according of the norma procedures and therefore not valid. 

 The text in question is exactly the same as in John's message.  Dave Oran, John, and others have made this same point several times on the list, over a long period of time, and John has declared consensus on this point and on the specific text.

Thanks,
Jerry

> >the next day or two.  Hopefully then we'll be ready to go to WGLC on 
> >the document?
> >
> >Thanks,
> >Regards,
> >Jerry
> >
> >"Note that it is possible to use, at the same time, both a) tunneling 
> >a QSPEC through a local domain by initiating a new RESERVE at the 
> >domain edge, and b) defining a local QSPEC and encapsulating the 
> >initiator QSPEC, as defined above."
> >
> >Could you send an update on the current status on the QSPEC? I think 
> >we were wrapping up most of the open issues, but it might be good to 
> >have a summary of where we stand on this.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 22 Jan 2007 15:20:55 +0100

Hi Jerry

I think that you are contradicting yourself.
Please check the text that you are writing.

My e-mail sent this morning (with subject: 
updated comments on draft-ietf-nsis-qspec-13.txt)
explains clearly my concerns on v. 13 
of the QSPEC template draft. 
That e-mail proposes also solutions 
to these concerns. Please read them!

Best regards,
Georgios

> Sent: maandag 22 januari 2007 15:12
> I think that you and perhaps others are misreading the text 
> in statement 1.  QOSM specifications can certainly define RMF 
> functions.  The statement says that the QoS-NSLP document is 
> See John's statement of consensus at 
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.ht
> ml.  The text in question is exactly the same as in John's 
> message.  Dave Oran, John, and others have made this same 
> point several times on the list, over a long period of time, 
> and John has declared consensus on this point and on the 
> specific text.
> 
> Thanks,
> Jerry
> 
> > 
> > Best regards, Attila
> > 
> 5.2.2).  For

---

From: <[email-masked]>
Date: Mon, 22 Jan 2007 08:24:41 -0600

Hi Jerry & Attilla,

>>within a QoS NSLP signaling framework."

I would say that the real restriction is that QOSM should not modify
the QoS NSLP state machine & operation.  The QoS NSLP <-> RMF interface 
is out-of-scope of NSIS in my opinion.  

I am misunderstanding something here?

thanks,
John

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Mon, 22 Jan 2007 15:27:54 +0100

Commenst inline 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: den 22 januari 2007 15:20
To: Lars Westberg (KI/EAB); [email-masked]; Magnus Westerlund (KI/EAB)
Cc: [email-masked]
Subject: RE: [NSIS] QSPEC document

Lars,

Rough consensus of what ?
You seems to utilize the vacation period to try to make formal
statement. I dont' think that this is good way of working.
First of all!!! No-one have asked for these changes and I wonder about
the source for these chanages. We have been working during four years
and noone have com-up with this concerns.
This is the same basic mis-understanding of the architectural as the
interoperbillity discussion for "bearer service".  

How should we solve NSIS-proxy, indication of header compression without
re-writing the whole QoS-NSLP ???

I still don't understand how this discussion has come-up. Someone seem
not follow the discussion from the beginning!!!

John
>working group docunment. Therefore, we have to toll back to the 
>previous document and we should start from that to discuss the 
>evolutio.
>
>l.  The text in question is exactly the same as in John's message.  All

>this is saying is that the QoS-NSLP document is the only document that 
>can define new QoS signaling functionality, not QOSM specification

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 22 Jan 2007 15:32:34 +0100

Hi John

I think that here is a misunderstanding that has been created 
in the e-mail discussions, having as consequence that no-one knows 
how and on what a WG consensus has been taken.
The main problem that I have had with the QOSM definitions
is related to the following paragraph 
In Section 4.1 of v.13 of QSPEC template draft:

"QOSMs affect the operation of the RMF in NSIS-capable nodes, the
   information carried in QSPEC objects, and may under some
   circumstances (e.g. aggregation) cause a separate NSLP session to be
   instantiated by having the RMF as a QNI. QOSMs all utilize the common
   data, state machines, and APIs of the underlying NSIS protocols and
   are not expected to re-define or extend these in any way."

The last sentence is vague and one could interpret it as a limitation of
what a QOSM is able to specify. As described in the QOS-NSLP draft the
QOS-NSLP function, and thus also the QOS-NSLP state machine depends on the
output events produced by the RMF operation. As already  mentioned in this
version of the QSPEC template draft the QOSMs affects the operation of the
RMF in NSIS-capable nodes, thus the QOS-NSLP state machine can be affected
in different ways by events generated by different RMFs.

Therefore, I would like that you add the following sentence after the second
paragraph given in section 4.1:

 "However, the events generated by the operation of different RMFs may
affect the QoS-NSLP common state machine in a different way. Therefore, a
QOSM MUST define how and when the events generated by the RMF operation
affect the operation of the QoS-NSLP state machine."

Furthermore, please add the following bullet in the list starting with the
sentence "A QOSM specification MUST include the following":

"it specifies how and when the events generated by the RMF operation affect
the QOS-NSLP state machine."

In order to motivate the above I will give two examples that could be used
when for example, a new QOSM has to define the operation of a RMF that is
similar to the RMF model defined in the RFC 3175 (Aggregation of RSVP for
IPv4 and IPv6 Reservations).
http://www.ietf.org/rfc/rfc3175.txt?number=3175

First example: 
Similar to the scenario given in "APPENDIX 1: Example Signalling Flow For
First E2E Flow", specified in RFC 3175, the following scenario can be
defined for NSIS. For more details on the RMF operation please see APPENDIX
1 of RFC 3175.
>From this example can be seen that the events of the RMF operation
described for the below scenario will impact the QOS-NSLP processing from
the point of view of when and how the different QUERY, RESERVE and RESPONSE
messages have to be initiated and sent.

             Aggregator (ingress)          Deaggregator (Egress)

    E2E QUERY
   ---------------->
                (1)
                           E2E QUERY
                     ------------------------------->
                                                        (2)
                      E2E RESPONSE(New-agg-needed, DCLASS=x)
                     <-------------------------------
                      E2E RESPONSE(New-agg-needed, DCLASS=y)
                     <-------------------------------
                (3)
                           Aggregated QUERY(DSCP=x)
                     ------------------------------->
                           Aggregated QUERY(DSCP=y)
                     ------------------------------->
                                                        (4)
                                                           E2E QUERY
                                                           ----------->
                                                        (5)
                           Aggregated RESERVE (DSCP=x)
                     <-------------------------------
                           Aggregated RESERVE (DSCP=y)
                     <-------------------------------
               (6)
                           Aggregated RESPONSE (DSCP=x)
                     ------------------------------>
                           Aggregated RESPONSE (DSCP=y)
                     ------------------------------>
                                                        (7)
                                                           E2E RESERVE
                                                           <----------
                                                        (8)
                           E2E RESERVE (DCLASS=x)
                     <-----------------------------
               (9)
       E2E RESERVE
   <---------------

Second example: 
Similar to the scenario given in "APPENDIX 2: Example Signalling Flow For
Subsequent E2E Flow Without Reservation Resizing", specified in RFC 3175,
the following scenario can be defined for NSIS. 
For more details on the RMF operation please see APPENDIX 2 of RFC 3175.
>From this second example can be seen that the events of the RMF
operation described for the below scenario are different than the ones given
in the first example and will impact the QOS-NSLP processing in a different
way than the way described in the first example given above. 

          Aggregator (ingress)           Deaggregator (egress)

    E2E QUERY
   ---------------->
                (10)
                           E2E QUERY
                       ------------------------------->
                                                      (11)
                                                         E2E QUERY
                                                         ----------->
                                                          E2E RESERVE
                                                         <-----------
                                                      (12)
                           E2E RESERVE (DCLASS=x)
                     <-----------------------------
                 (13)
       E2E RESERVE
   <---------------

Note that the same effect can be seen in the RMD-QOSM specification related
to the different reservation scenarios explained in detail in Section 4.6,
see:
http://www.watersprings.org/pub/id/draft-ietf-nsis-rmd-08.txt 

Note that the above described text is a part of the e-mail that I have sent
this morning with 
Subject:
"updated comments on draft-ietf-nsis-qspec-13.txt"

Best Regards,
Georgios

> Sent: maandag 22 januari 2007 15:20
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> As chair, I have declared rough consensus on the issue. There 
> is no consensus that each QoSM would be able to change the 
> signaling of the QoS NSLP.  Additionally, only the RMD 
> authors have a problem with this issues. Implementors of the 
> QoS NSLP have commented that allowing QoSMs to modify the QoS 
> NSLP behavior would create a huge amount of complexity for 
> implementations. 
> 
> I judge that there has been consensus on this issue, and I 
> have judged that there is rough consensus from the working 
> group on the current editing of the QSPEC document.
> 
> John
> the editor 
> >> whole WG. Especially in these late stages when the goal is 
> to finish 
> >> up.
> message.  All

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 22 Jan 2007 08:32:51 -0600

Hi John, 

> Sent: Monday, January 22, 2007 9:25 AM
> To: [email-masked]; Ash, Gerald R (Jerry), ALABS; 
> [email-masked]
> the QoS NSLP state machine & operation.  

I agree.  What this is saying is that QOSM specifications can define
whatever new RMF functionality they wish, but must not define new QoS
NSLP signaling functionality and should not modify QoS NSLP state
machine and operation.

Thanks,
Jerry

> The QoS NSLP <-> RMF 
> interface

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 22 Jan 2007 15:46:49 +0100

Hi John

Regarding your below question:

> I would say that the real restriction is that QOSM should not 
> modify the QoS NSLP state machine & operation.  The QoS NSLP 
> <-> RMF interface is out-of-scope of NSIS in my opinion.  
> 

As described in all NSIS documents the QOS-NSLP function, 
and thus also the QoS-NSLP state machine depends on the 
output events produced by the RMF operation.
Furthermore in all NSIS documents is emphasized that 
a QoS Model defines the behavior of the RMF, including inputs and
outputs, and how QSPEC information is used to describe resources
available, resources required, traffic descriptions, and control
information required by the RMF. 

This means that the QOSM specification 
can affect the operation of the RMF in NSIS-capable nodes, 
thus the QOS-NSLP state machine can be affected in 
different ways by events generated by different RMFs.
Thus the QOS-NSLP state machine remains the same but 
it has to consider the events that are generated by the 
RMF functionality.

Therefore, a QOSM MUST define how and when the events 
generated by the RMF operation affect the operation of the 
QoS-NSLP state machine.

Best regards,
Georgios

> Sent: maandag 22 januari 2007 15:25
> To: [email-masked]; [email-masked]; [email-masked]
> I would say that the real restriction is that QOSM should not 
> modify the QoS NSLP state machine & operation.  The QoS NSLP 
> <-> RMF interface is out-of-scope of NSIS in my opinion.  
>

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Mon, 22 Jan 2007 16:20:34 +0100

Hi John and Jerry, I think there is a misundersatnading here. The QoS NSLP functionality surely cannot be changed without modifying QoS NSLP. 

Regarding the QoS-NSLP state machine, I think it is not definitive and it is determined by QoS NSLP and QOSM together. The RMF functions are clearly determined the QOSM. It does not mean to define new QoS NSLP signaling functionality.

Best regards, Attila

>Sent: Monday, January 22, 2007 3:33 PM
>To: [email-masked]; Attila Báder (IJ/ETH); [email-masked]
>I agree.  What this is saying is that QOSM specifications can 
>define whatever new RMF functionality they wish, but must not 
>define new QoS NSLP signaling functionality and should not 
>modify QoS NSLP state machine and operation.
>
>Thanks,
>Jerry
>
>> The QoS NSLP <-> RMF
>> interface

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 22 Jan 2007 09:47:08 -0600

Georgios,

See below. 

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Monday, January 22, 2007 7:15 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]

Please see the responses to Attila and Magnus on this text.  I agree
that RMF functions are defined by QOSM specifications and not by the
QoS-NSLP signaling document.  The above statement does not contradict
that fact.
 
> Regarding other issues please check my e-mail that I have sent 
> this morning.

I have read your email and it re-raises most of the below points that
have been agreed by consensus and modified accordingly in the -14 QSPEC
document.  It would be best IMO to discuss any new comments during the
WGLC on the -14 QSPEC document (should be published by the I-D Editor
soon, perhaps today).

As John stated, it seems that only the RMD authors have a problem with
this, but it is quite unclear what the problem(s) might be for RMD
implementation in regard to the current QSPEC document.  If additional
QoS-NSLP functionality is needed to support RMD, then the proper place
is to propose extensions to the QoS-NSLP document, as you seem to have
alluded to in your postings at 
http://www1.ietf.org/mail-archive/web/nsis/current/msg07455.html
http://www1.ietf.org/mail-archive/web/nsis/current/msg07457.html

Going on endlessly with word-smithing the QSPEC document does not seem
the way to resolve whatever RMD issues you perceive IMO.

Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 22 Jan 2007 17:03:08 +0100

Hi Jerry

Well, this is not the way of how a WG should work.
I have expressed my concerns in a clear way and I am not getting any useful 
and constructive remarks.

What you actually say is:
"Well only RMD-QOSM requires this functionality and therefore I decide 
that we will not use this functionality anymore."

The functionality that I am talking about has been decided 4/5 years 
ago and you cannot just change it.

Furthermore, please explain to me how someone will be able to 
define the QOS model that should translate the RSVP aggregation 
concept (RFC 3175) into NSIS when the changes and limitations that you are 
now proposing will be included in NSIS.

Or are you also saying to me that it is not possibe to translate and use
the RSVP aggregation concept (RFC3175) into NSIS!

Best regards,
Georgios

> Sent: maandag 22 januari 2007 16:47
> To: Georgios Karagiannis
> > Please note that RMF functions are defined by QOS models and not by 
> > the QOS-NSLP signaling framework.
> > 
> Please see the responses to Attila and Magnus on this text.  
> I agree that RMF functions are defined by QOSM specifications 
> and not by the QoS-NSLP signaling document.  The above 
> statement does not contradict that fact.
>  
> > Regarding other issues please check my e-mail that I have sent this 
> > morning.
> 
> I have read your email and it re-raises most of the below 
> points that have been agreed by consensus and modified 
> accordingly in the -14 QSPEC document.  It would be best IMO 
> to discuss any new comments during the WGLC on the -14 QSPEC 
> document (should be published by the I-D Editor soon, perhaps today).
> 
> As John stated, it seems that only the RMD authors have a 
> problem with this, but it is quite unclear what the 
> problem(s) might be for RMD implementation in regard to the 
> current QSPEC document.  If additional QoS-NSLP functionality 
> is needed to support RMD, then the proper place is to propose 
> extensions to the QoS-NSLP document, as you seem to have 
> Going on endlessly with word-smithing the QSPEC document does 
> not seem the way to resolve whatever RMD issues you perceive IMO.
> 
> Jerry
> 
> > 
> > Best Regards,
> > Georgios
> > 
> > 
> > > tunneling a QSPEC through a local domain by initiating a 
> new RESERVE 
> > > at the domain edge, and b) defining a local QSPEC and 
> encapsulating 
> > > I think we were wrapping up most of the open issues, but 
> it might be 
> > > good to have a summary of where we stand on this.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 22 Jan 2007 11:12:17 -0500

Georgios:

You are right. Why does it be so now?

Let us see what response comes out of your questions from the document
editor.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Georgios Karagiannis
Sent: Monday, January 22, 2007 11:03 AM
To: 'Ash, Gerald R (Jerry), ALABS'
Cc: [email-masked]
Subject: RE: [NSIS] QSPEC document

Hi Jerry

Well, this is not the way of how a WG should work.
I have expressed my concerns in a clear way and I am not getting any
useful 
and constructive remarks.

Furthermore, please explain to me how someone will be able to 
define the QOS model that should translate the RSVP aggregation 
concept (RFC 3175) into NSIS when the changes and limitations that you
are 
now proposing will be included in NSIS.

Best regards,
Georgios

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Jan 2007 17:09:30 +0100

Hi,

To be clear, I think it is problematic that the editors of one the WG 
documents says that the latest round of changes in another WG document 
has swept away parts of the foundation which they have built on. I 
definitely don't like to see such thing happen. Thus I request that you 
improve the communication between each other. Editors you are not 
working in a vacuum, you have other WG drafts with relations to the one 
you are working on. That must be considered when doing changes.

> editing of the QSPEC document.

Well, I would recommend that you take one step back here. There is 
evident that there is a lot of confusion on what the consensus was. It 
seems that in another part of this thread there at least has been some 
identification of some part of the issue.

So please everyone. Be clearer in the communication what you mean. 
Please write what you think are overly clear statements. It will at 
least help this AD to keep track of what you actually mean.

The WG needs to work these issues out, and soon.

Cheers

Magnus Westerlund

---

From: Lars Westberg <[email-masked]>
Date: Mon, 22 Jan 2007 17:20:30 +0100

I still do not get your statement.  I need more clarifications.

If we want to additional functionality to cope with a proxy and want to
add functionality to indicate for the end-point that a proxy are 
answering the the messages sequence, this will require a new object with 
control bits that can be set by the proxy.
This indication can be used by the initiating party to add more 
infomration that makes the proxy operation better. Is this ok within the 
your statement or not ?

2) Can we indicate add control infomration into NSIS to select 
ECN-marking or indicate if the marking are not supported by the router????

3) Is it allowed to add explicit route object as they have made within 
RSVP for traffic engineeering ???

4) Is it allowed to extend the protocol to establish tunnels with NSIS 
as they do with RSVP-TE ?
I consider in this case that different kinds of tunnels should be 
possible so a number of control bits are required.

regards Lasse

---

From: <[email-masked]>
Date: Mon, 22 Jan 2007 22:23:44 -0600

Georgios,

At this point, please avoid such mails. We should not turn
this into an over-heated debate. Please provide more light
and less heat.

John
>I have expressed my concerns in a clear way and I am not 
>getting any useful and constructive remarks.
>
>"Well only RMD-QOSM requires this functionality and therefore 
>I decide that we will not use this functionality anymore."
>
>The functionality that I am talking about has been decided 4/5 
>years ago and you cannot just change it.
>
>define the QOS model that should translate the RSVP 
>aggregation concept (RFC 3175) into NSIS when the changes and 
>limitations that you are now proposing will be included in NSIS.
>
>Or are you also saying to me that it is not possibe to 
>translate and use the RSVP aggregation concept (RFC3175) into NSIS!

---

From: <[email-masked]>
Date: Mon, 22 Jan 2007 22:25:05 -0600

Georgios / Lars,

How do you feel about the text that Jerry states below.  Does this 
cause more or less problems to you?

John 

>From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>Sent: 22 January, 2007 16:33
>To: Loughney John (Nokia-NRC/PaloAlto); 
>[email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Mon, 22 Jan 2007 22:32:45 -0600

Georgios,

>As described in all NSIS documents the QOS-NSLP function, and 
>thus also the QoS-NSLP state machine depends on the output 
>events produced by the RMF operation.
>Furthermore in all NSIS documents is emphasized that a QoS 
>Model defines the behavior of the RMF, including inputs and 
>outputs, and how QSPEC information is used to describe 
>resources available, resources required, traffic descriptions, 
>and control information required by the RMF. 

I agree with you on this.

>thus the QOS-NSLP state machine can be affected in different 
>ways by events generated by different RMFs.
>
>Thus the QOS-NSLP state machine remains the same but it has to 
>consider the events that are generated by the RMF functionality.

I am confused by this. If the state machines are the same,
then how does a state machine consider events? Do you mean
that there would new states, new messages, new parameters?
How differ would you see this being?

John

---

From: <[email-masked]>
Date: Mon, 22 Jan 2007 22:34:40 -0600

Hi Attila,

>Hi John and Jerry, I think there is a misundersatnading here. 
>The QoS NSLP functionality surely cannot be changed without 
>modifying QoS NSLP. 

I think we agree here.  I think we are trying to discuss
how much change is possible.

>Regarding the QoS-NSLP state machine, I think it is not 
>definitive and it is determined by QoS NSLP and QOSM together. 
>The RMF functions are clearly determined the QOSM. It does not 
>mean to define new QoS NSLP signaling functionality.

I agree.

John

---

From: <[email-masked]>
Date: Mon, 22 Jan 2007 22:49:56 -0600

Lars,

>First of all!!! No-one have asked for these changes and I 
>wonder about the source for these chanages. We have been 
>working during four years and noone have com-up with this concerns.
>This is the same basic mis-understanding of the architectural 
>as the interoperbillity discussion for "bearer service".  
>
>How should we solve NSIS-proxy, indication of header 
>compression without re-writing the whole QoS-NSLP ???
>
>I still don't understand how this discussion has come-up. 
>Someone seem not follow the discussion from the beginning!!!

The changes came because we found out (and discussed extensively
at the last IETF) that there were severe interoperability
problems with the QSPEC as previously defined. We are trying
to fix this issue and move forward.  I think you can look
at some of Dave Oran's mails to the mailing list that has
prompted the discussion. I can provide pointers, if you 
would need them.

thank you,
John

---

From: Lars Westberg <[email-masked]>
Date: Tue, 23 Jan 2007 07:51:43 +0100

I have sent a technical question to Jerry that I expect to get an answer.

I would like to know if we can extend the protocol in the same way as 
RSVP has been extended.

I think the whole statement should be deleted because I haven't see any 
such statement within any other RFC.
If a protocol spec has to be change, the protcol-spec has to be updated. 
This is the normal way of designing protocols. Many protocol have been 
extended without re-writing the basic protocol spec so this statement 
are very strange. 

regards Lasse

---

From: Lars Westberg <[email-masked]>
Date: Tue, 23 Jan 2007 08:00:54 +0100

comments inline

> how much change is possible.
why are we discussing it ??

If we need to add a new function in the future ?
should we have statement into the protocol spec how this should be 
solved without knowing about the problem to solve?

I have never seen any statements within RFCs how extention of future 
protocol problems should be solved. So what are we discussion ????

> >mean to define new QoS NSLP signaling functionality.

First of all, does internal desing model determine the protocol operation?
According to my understanding, the standard only covers the protocol 
operation between routers, not how they are implemented.

I do not know but I thought that API:s does not make sense as a 
restriction and internal implementation model is only as an information 
and does not determine a standard track.

I would appreciate to more clarification of this.

---

From: Lars Westberg <[email-masked]>
Date: Tue, 23 Jan 2007 08:03:23 +0100

> prompted the discussion. I can provide pointers, if you
Yes, I would appreciate that.

---

From: <[email-masked]>
Date: Tue, 23 Jan 2007 01:25:22 -0600

Hi Lars,
 
I think my coffee might be kicking in this morning. What it seems that you are asking is 'What are the extensibility rules for QoSMs (that affect the QSPEC & QoS NSLP)?'
 
As far as extensibility goes, of course we can extend the QoS NSLP in similar ways to RSVP.
 
What we discussed earlier was that any QoSM that modifies the behavior of the QSPEC and/or needs to be a standards track document.  
 
Would you agree with that?  If so, then I think that we have a possible solution.  If we just add a text stating some of the extensibility assumptions in the IANA Considerations, would that be OK?  If so, then we probably can remove the text that you are objecting to, and replace it with extensibility considerations.
 
thanks,
John

	From: ext Lars Westberg [mailto:[email-masked]] 
	Sent: 23 January, 2007 08:52
	To: Loughney John (Nokia-NRC/PaloAlto)
	Cc: [email-masked]; "Attila Báder (IJ/ETH)"; [email-masked]
	Subject: Re: [NSIS] QSPEC document

	I would like to know if we can extend the protocol in the same way as RSVP has been extended. 
	
	I think the whole statement should be deleted because I haven't see any such statement within any other RFC. 
	If a protocol spec has to be change, the protcol-spec has to be updated. This is the normal way of designing protocols. Many protocol have been extended without re-writing the basic protocol spec so this statement are very strange.  

	regards Lasse

		Georgios / Lars,

		John

---

From: <[email-masked]>
Date: Tue, 23 Jan 2007 01:32:26 -0600

Hi Lars,
 
All Standards Track documents are required to have an IANA Considerations section, which describes how protocols can be extended.
 
You might be familiar with RFC 3936 "Procedures for Modifying the Resource reSerVation Protocol"

The IETF has certain rules with respect to protocol extensibility.
You cand find some of them in (for example)  RFC3692 & RFC2434.

John

	From: ext Lars Westberg [mailto:[email-masked]] 
	Sent: 23 January, 2007 09:01
	To: Loughney John (Nokia-NRC/PaloAlto)
	Cc: "Attila Báder (IJ/ETH)"; [email-masked]; [email-masked]
	Subject: Re: [NSIS] QSPEC document

	comments inline

		Hi Attila,

	
	If we need to add a new function in the future ? 
	should we have statement into the protocol spec how this should be solved without knowing about the problem to solve?
	
	I have never seen any statements within RFCs how extention of future protocol problems should be solved. So what are we discussion ????

		
		I agree.

	First of all, does internal desing model determine the protocol operation?
	According to my understanding, the standard only covers the protocol operation between routers, not how they are implemented.
	
	I do not know but I thought that API:s does not make sense as a restriction and internal implementation model is only as an information and does not determine a standard track.

		
		
		John

---

From: Lars Westberg <[email-masked]>
Date: Tue, 23 Jan 2007 09:25:41 +0100

sure, extendabillity is  the key thing.
Thats why I have problems with statement into a new protocol without any 
deployment and experience of commercial acceptance. Especially if the 
statement is unclear.

from my view, the QoS-model template should be a template and each 
QoS-model should be registered by IANA. I think that's according to the 
normal rule.

regards Lasse

[email-masked] wrote:

> Hi Lars,
>
> All Standards Track documents are required to have an IANA 
> Considerations section, which describes how protocols can be extended.
>
>         should we have statement into the protocol spec how this 
> should be solved without knowing about the problem to solve?
>        
>         I have never seen any statements within RFCs how extention of 
> future protocol problems should be solved. So what are we discussion ????
>        
>
>                
>         According to my understanding, the standard only covers the 
> protocol operation between routers, not how they are implemented.
>        
>         I do not know but I thought that API:s does not make sense as 
> a restriction and internal implementation model is only as an 
> information and does not determine a standard track.
>

---

From: <[email-masked]>
Date: Tue, 23 Jan 2007 02:30:58 -0600

Hi Lars,

I think we are approaching agreement on this issue, so I'll give people a chance to comment and then see if we can get text.
 
I have been concerned about different QoS Models introducing too many changes to the basic operation that it becomes hard to deploy end-to-end, or that implementations would have to be customized quite heavily for each QoS Model.
 
But I think we are getting close to resolving this.
 
thanks,
John

	Sent: 23 January, 2007 10:26

	sure, extendabillity is  the key thing.
	Thats why I have problems with statement into a new protocol without any deployment and experience of commercial acceptance. Especially if the statement is unclear.
	
	from my view, the QoS-model template should be a template and each QoS-model should be registered by IANA. I think that's according to the normal rule.

	regards Lasse

		Hi Lars,

		

		John

		        comments inline

		                Hi Attila,

		       

		               
		               
		                I agree.

		       

		               
		                John

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Tue, 23 Jan 2007 10:07:28 +0100

Hi John, Jerry, Georgios,

If we agree in this can we probably could agree in a text that reflects this. 

I think the control information (or traffic handling directives) that we have in RMD does not change the QoS NSLP functionality. Thus I do not see problems having a similar definition that is proposed by Georgios. 

Best regards, Attila

>Sent: Tuesday, January 23, 2007 5:35 AM
>To: Attila Báder (IJ/ETH); [email-masked]; [email-masked]
>>The QoS NSLP functionality surely cannot be changed without modifying 
>>QoS NSLP.
>
>I think we agree here.  I think we are trying to discuss how 
>much change is possible.
>
>definitive and 
>>it is determined by QoS NSLP and QOSM together.
>>The RMF functions are clearly determined the QOSM. It does 
>not mean to 
>>define new QoS NSLP signaling functionality.
>
>I agree.
>
>John
>

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 23 Jan 2007 11:16:15 +0200 (EET)

John et al., 

Isn't the fundamental issue here that a new QOSM _MUST NOT_ break the 
future QSPEC and QoS NSLP standards, nor harm the provision of e2e QoS. 
The QOSM, or other documents,_MAY_ introduce new extensions - that is why 
we have the so-called AB-flags in GIST and the two NSLPs.

Jukka

On Tue, 23 Jan 2007, [email-masked] wrote:

> Hi Lars,
> 
> I think we are approaching agreement on this issue, so I'll give people 
> a chance to comment and then see if we can get text.
>  I have been concerned about different QoS Models introducing too many 
> changes to the basic operation that it becomes hard to deploy 
> end-to-end, or that implementations would have to be customized quite 
> heavily for each QoS Model.
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 23 Jan 2007 10:21:18 +0100

Hi John

Yes, it causes more problems!
The email that I have provided yesterday with subject:
"updated comments on draft-ietf-nsis-qspec-13.txt" will solve all the
problems 
that have been caused by these unnecessarry changes introduced in 
draft-ietf-nsis-qspec-13.txt.

Best regards,
Georgios

> Sent: dinsdag 23 januari 2007 5:25
> To: [email-masked]; [email-masked]; [email-masked]
> How do you feel about the text that Jerry states below.  Does 
> this cause more or less problems to you?
> 
> John 
> 
> >To: Loughney John (Nokia-NRC/PaloAlto); [email-masked]; 
> >[email-masked]

---

From: <[email-masked]>
Date: Tue, 23 Jan 2007 03:22:53 -0600

Attila,

Could you remind me about the definition proposed by Georgios?  There
are a lot of emails on this thread, and I am having trouble keeping up.

John

>From: ext Attila Báder (IJ/ETH) [mailto:[email-masked]] 
>Sent: 23 January, 2007 11:07
>To: Loughney John (Nokia-NRC/PaloAlto); [email-masked]; [email-masked]
>I think the control information (or traffic handling 
>directives) that we have in RMD does not change the QoS NSLP 
>functionality. Thus I do not see problems having a similar 
>definition that is proposed by Georgios. 
>
>Best regards, Attila
>
>modifying 
>>I think we agree here.  I think we are trying to discuss how much 
>>change is possible.
>>

---

From: <[email-masked]>
Date: Tue, 23 Jan 2007 03:34:00 -0600

Jukka,

>Isn't the fundamental issue here that a new QOSM _MUST NOT_ 
>break the future QSPEC and QoS NSLP standards, nor harm the 
>provision of e2e QoS. 
>The QOSM, or other documents,_MAY_ introduce new extensions - 
>that is why we have the so-called AB-flags in GIST and the two NSLPs.

Yes basically.  We want to ensure that we have e2e interoperability
and good interworking between different QoS domains.  Unbounded
flexibility (and I am not claiming anyone is planning unbounded
flexibility) doesn't help with interoperability.

John

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 23 Jan 2007 11:38:47 +0200 (EET)

Good. Don't we then have quite a clear statement as to what is allowed by 
a QOSM to define, and what is not?

Jukka

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Tue, 23 Jan 2007 10:38:14 +0100

Hi John, this was the text that was proposed by Georgios, 

Best regards, Attila

-----

4.3.3  Traffic Handling Directives

The <Traffic Handling Directives> parameter is used for providing signaling support for QSPEC/QOSM specific RMF functions, such as initiation, refresh, release, modification for unidirectional and
bi-directional: per traffic class RMF reservation states, per flow RMF reservation states, per aggregated RMF reservation states, specified for example, in [RMD-QOSM].

An example of the <Traffic Handling Directives> parameter is the <Excess Treatment> parameter, see below:

   <Traffic Handling Directives> = <Excess Treatment>

   The <Excess Treatment> parameter describes how the QNE will process
   excess traffic, that is, out-of-profile traffic.  Excess traffic MAY
   be dropped, shaped and/or remarked. The excess treatment parameter is
   initially set by the QNI and is read-only.
 
----------

>Sent: Tuesday, January 23, 2007 10:23 AM
>Could you remind me about the definition proposed by Georgios? 
> There are a lot of emails on this thread, and I am having 
>trouble keeping up.
>
>John
>
>>If we agree in this can we probably could agree in a text 
>that reflects 
>>this.
>>
>>functionality. Thus I do not see problems having a similar definition 
>>that is proposed by Georgios.
>>
>>Best regards, Attila
>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 23 Jan 2007 10:55:46 +0100

Hi John

I agree that the interoperability problem has been solved during the IETF in
San Diego. 

The new changes are completely different than the ones that have been 
discussed and been solved during the IETF in San Diego.

These new changes cause new problems, please see my e-mail that I have sent 
yesterday with subject:
"updated comments on draft-ietf-nsis-qspec-13.txt"

Best Regards,
Georgios

> Sent: dinsdag 23 januari 2007 5:50
> wonder about 
> >How should we solve NSIS-proxy, indication of header compression 
> >without re-writing the whole QoS-NSLP ???
> >
> The changes came because we found out (and discussed 
> extensively at the last IETF) that there were severe 
> interoperability problems with the QSPEC as previously 
> defined. We are trying to fix this issue and move forward.  I 
> think you can look at some of Dave Oran's mails to the 
> mailing list that has prompted the discussion. I can provide 
> pointers, if you would need them.
> 
> thank you,
> John
>

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Tue, 23 Jan 2007 10:51:18 +0100

Hi All, Yes, I think we can agree in this.

I do not think that the original definition of control info breaks the interoperability of QoS NSLP and QoS Models. Thus I do not see reason to change it in a way that suggests much less flexibility.  

Best regards, Attila 

>From: Jukka MJ Manner [mailto:[email-masked]] 
>Sent: Tuesday, January 23, 2007 10:39 AM
>To: [email-masked]
>Cc: [email-masked]
>Good. Don't we then have quite a clear statement as to what is 
>allowed by a QOSM to define, and what is not?
>
>Jukka
>
>break the 
>> >The QOSM, or other documents,_MAY_ introduce new extensions 
>- that is 
>> >why we have the so-called AB-flags in GIST and the two NSLPs.
>>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 23 Jan 2007 10:41:49 -0500

John:

You are right that QOS models must NOT introduce any changes to the
basic operation of the end-to-end QSPEC template that is used by NSIS
QOS signaling protocol.

This is our concern too.

Best regards,

Radhika

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, January 23, 2007 3:31 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] QSPEC document

Hi Lars,

thanks,

John

---

From: David R Oran <[email-masked]>
Date: Wed, 24 Jan 2007 12:56:36 -0500

> a QOSM to define, and what is not?
That's what I thought, but reviewing the mailing list, there are four  
people who do not think we've got it right. To some extent we may be  
just talking past each other, but to some extent I think there is in  
fact real technical disagreement. The best way I can think of to  
capture that disagreement is whether:

a) The QSPEC and the RMF that operates on it have some basic,  
universally known semantics. Particular QOSMs can provide different  
semantics, but the RMF for such a QOSM is not permitted to admit  
traffic unless the parameters in the well-known QSPEC parameters that  
have been marked "mandatory" by the QNI can be satisfied by the QNE.  
In addition, a QNE wishing to be QOS-NSLP-compliant for whatever QOS  
Model it implements must either map its operation directly onto the  
existing API and state machine operation of the QOS-NSLP, or, must  
have a standards-track RFC which extends the QOS-NSLP in a backward  
compatible and interoperable way. A QOSM is *not* allowed to simply  
require that the QOS-NSLP operate in a different way than is  
specified in the standards track RFC(s).

b) The QSPEC is a set of suggested useful parameters than an RMF can  
decide to use or not use at its discretion and the QOSM is free to  
add new parameters or re-interpret existing parameters as long as  
such is documented in an RFC. Further, if the QOSM requires new  
signaling functionality or a change to the way the QOS-NSLP operates  
(message flows and state machines) it is free to specify those as  
part of the QOSM without explicitly extending QOS-NSLP and  
demonstrating both interoperability and backward compatibility.

I am firmly in camp (a). I think the existing words in the QSPEC  
document (with the exception of the one glitch we've already  
discussed and resolved) capture (a).

If we have consensus around (a) I think we can move forward and do  
more word smithing if really necessary. If we don't and what a  
significant fraction of the WG wants is (b), then I think we really  
do have a problem and we are more-or-less back where we were before  
the San Diego IETF.

Dave Oran.

---

From: David R Oran <[email-masked]>
Date: Wed, 24 Jan 2007 13:02:47 -0500

On Jan 23, 2007, at 4:51 AM, Attila Báder (IJ/ETH) wrote:

> I do not think that the original definition of control info breaks  
> the interoperability of QoS NSLP and QoS Models. Thus I do not see  
> reason to change it in a way that suggests much less flexibility.
>
My problem is that "QSPEC Control" is a grab bag that doesn't mean  
anything to me and invites creation of a swamp of random parameters.  
I similarly can see that trying to map everything into "handling  
directives" could be viewed as un-necessarily restrictive and  
unnatural for some of the parameters used by RMD (like the bandwidth  
usage per hop that would go into the "QOS available" part of the  
QPSEC as it traverses the domain with RMD QNEs).

I personally didn't have a problem with the term "handling  
directives" for such things in addition to the one well-known  
parameter of "excess treatment", but I'm sympathetic with the folks  
who do. It frankly was just a categorization in how the spec was  
written and has no direct presence in the wire encoding anyway.

If somebody wants to suggest a different name for such things that  
are not traffic parameter, constraints, or handling directives, I'm  
all ears.

Dave.

---

From: Lars Westberg <[email-masked]>
Date: Thu, 25 Jan 2007 09:00:25 +0100

The basic problem is that end-2-end QoS-model is a separate problem 
space. Everyone has tried to define their favourite QoS-solution during 
the years and everyone of the has failed.
Overprovisioning is the only commenrcial successfull end-2-end Qos Model.

In the development of RSVP IETf had one group discussing QoS-parameters 
denoted Int.serv. If someone would like work with this, it should be 
done in a separate working group rather than be a part of the basic 
protocol specification.
All experience in from Int.serv working group has shown the difficulties 
to define such models.
I suggest that we standard track document  end-2-end QoS-model  so we 
can have a separate discussion from developping the template.

regards Lasse

Roy, Radhika R. wrote:

> ------------------------------------------------------------------------
>
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> I think we are approaching agreement on this issue, so I'll give 
> people a chance to comment and then see if we can get text.
>
>  
>

---

From: Lars Westberg <[email-masked]>
Date: Thu, 25 Jan 2007 09:42:16 +0100

comments inline

> >break the future QSPEC and QoS NSLP standards, nor harm the
As I replied, the only end-2-end QoS model is overprovisioning.
The second level of from a telecom perspective seems to be 
Class-Of-Service.

Therefore, NSIS can not harm end-2-end QoS.

> flexibility) doesn't help with interoperability.
I can not understand your comment. For me, it is obvious that QoS-NSLP 
can not be changed by QoSM but a QoSm should be able to extend the 
control for specific usage that are needed for that QoSM.

The discussion about standardizing parameter set should taken out from 
the QoSM-template and define in another document. In this way, we follow 
the same structure as RSVP.

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 25 Jan 2007 10:46:29 +0200 (EET)

Hi Dave,

it seems people are truly talking past each other. I hope no one belongs 
to camp (b).

Camp (a) is truly what we are aiming for, and we should end this 
discussion, and move forward.

Jukak

On Wed, 24 Jan 2007, David R Oran wrote:

> That's what I thought, but reviewing the mailing list, there are four people
> who do not think we've got it right. To some extent we may be just talking
> past each other, but to some extent I think there is in fact real technical
> disagreement. The best way I can think of to capture that disagreement is
> whether:
> 
> a) The QSPEC and the RMF that operates on it have some basic, universally
> known semantics. Particular QOSMs can provide different semantics, but the
> RMF for such a QOSM is not permitted to admit traffic unless the parameters
> in the well-known QSPEC parameters that have been marked "mandatory" by the
> QNI can be satisfied by the QNE. In addition, a QNE wishing to be
> QOS-NSLP-compliant for whatever QOS Model it implements must either map its
> operation directly onto the existing API and state machine operation of the
> QOS-NSLP, or, must have a standards-track RFC which extends the QOS-NSLP in a
> backward compatible and interoperable way. A QOSM is *not* allowed to simply
> require that the QOS-NSLP operate in a different way than is specified in the
> standards track RFC(s).
> 
> b) The QSPEC is a set of suggested useful parameters than an RMF can decide
> to use or not use at its discretion and the QOSM is free to add new
> parameters or re-interpret existing parameters as long as such is documented
> in an RFC. Further, if the QOSM requires new signaling functionality or a
> change to the way the QOS-NSLP operates (message flows and state machines) it
> is free to specify those as part of the QOSM without explicitly extending
> QOS-NSLP and demonstrating both interoperability and backward compatibility.
> 
> I am firmly in camp (a). I think the existing words in the QSPEC document
> (with the exception of the one glitch we've already discussed and resolved)
> capture (a).
> 
> If we have consensus around (a) I think we can move forward and do more word
> smithing if really necessary. If we don't and what a significant fraction of
> the WG wants is (b), then I think we really do have a problem and we are
> more-or-less back where we were before the San Diego IETF.
> 
> Dave Oran.
> 
> >Jukka
> >

---

From: Lars Westberg <[email-masked]>
Date: Thu, 25 Jan 2007 11:34:15 +0100

comments inline
I don't care about thee naming of the parameters and I agree that a 
QoS-model should not change the QoS-NSLP operation. However, what a 
future QoS-model should contains is difficult to know in advance. The 
evolution of RSVP has shown a pretty large extendabillity of the 
protocol from the original use.
"Handling directive" sounds like that only traffic-managment parameters 
are only allowed into the QoS-model. I have a big difficult with this 
kind of limitation.

I suggest the following way forward:
1) definition of a standard track QoS-model (denoted end-2-end QOSM or 
inter-domain QoSM??) into a specific document which is required to be 
handled. This standard track QOSM includes a specific set of paramters 
that are mandatory for inter-domain QoS-signalling. If this is end-2-end 
or not is hard to predict but it should ensure interoperabillity across 
interdomain borders.
This should be developped separateley from the basis protocols standards 
so we can finish the development of the basic protocol specfications.

2) make the template describing design guidlines, describe how the 
process of standardizing QoS-models and include some basic parameter 
description.

3) Treat the current  QoSm as examples of QoS-model.

-Lasse
David R Oran wrote:

> QPSEC as it traverses the domain with RMD QNEs) 

I am open for a better name than QSpec-control.

I think we general agree about the following:

QOSM should not perform "violation" of the basic QoS-NSLP protocol 
operation. That is accoridng to RSVP. IF QoS-NSLP need to be 
extended/modified, a new protocol spec. needs to be written.

> personally didn't have a problem with the term "handling  directives" 
> for such things in addition to the one well-known  parameter of 
> "excess treatment", but I'm sympathetic with the folks  who do. It 
> frankly was just a categorization in how the spec was  written and has 
> no direct presence in the wire encoding anyway.
>

---

From: Lars Westberg <[email-masked]>
Date: Thu, 25 Jan 2007 11:38:07 +0100

comments inline

> discussion, and move forward.
May someone can correct me if I am wrong, but I think that the standard 
track document specifies the operation between two routers and not how 
it is  implemented.

The API is part of the implementation space.

-lasse

> universally
> decide
> document
> more word

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Jan 2007 13:16:45 +0100

Hi Jukka

What we aimed from the beginning is a combinbation of a) and b)!

Best Regards,
Georgios 

> Sent: donderdag 25 januari 2007 9:46
> To: David R Oran
> Cc: [email-masked]; [email-masked]
> it seems people are truly talking past each other. I hope no 
> one belongs to camp (b).
> 
> Camp (a) is truly what we are aiming for, and we should end 
> this discussion, and move forward.
> 
> Jukak
> 
> 
> > require that the QOS-NSLP operate in a different way than 
> is specified in the standards track RFC(s).
> > 
> > decide to use or not use at its discretion and the QOSM is 
> free to add 
> > new parameters or re-interpret existing parameters as long 
> as such is 
> > documented in an RFC. Further, if the QOSM requires new signaling 
> > functionality or a change to the way the QOS-NSLP operates (message 
> > flows and state machines) it is free to specify those as 
> part of the 
> > QOSM without explicitly extending QOS-NSLP and 
> > document (with the exception of the one glitch we've 
> already discussed 
> > and resolved) capture (a).
> > 
> > significant fraction of the WG wants is (b), then I think 
> we really do 
> > have a problem and we are more-or-less back where we were 
> before the San Diego IETF.
> > 
> > Dave Oran.
> > 
> > >Jukka
> > >
> > > > >Isn't the fundamental issue here that a new QOSM _MUST 
> NOT_ break 
> > > > >the future QSPEC and QoS NSLP standards, nor harm the 
> provision 
> > > > >of e2e QoS.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Jan 2007 13:19:38 +0100

Hi all

What actually Lars proposes is what we wanted 
to do in NSIS from the beginning.
Thus I agree!

Best Regards,
Georgios

> From: Lars Westberg [mailto:[email-masked]] 
> Sent: donderdag 25 januari 2007 11:34
> To: David R Oran; [email-masked]
> Cc: Jukka MJ Manner; [email-masked]; "Attila Báder (IJ/ETH)"
> I don't care about thee naming of the parameters and I agree 
> that a QoS-model should not change the QoS-NSLP operation. 
> However, what a future QoS-model should contains is difficult 
> to know in advance. The evolution of RSVP has shown a pretty 
> large extendabillity of the protocol from the original use.
> "Handling directive" sounds like that only traffic-managment 
> parameters are only allowed into the QoS-model. I have a big 
> difficult with this kind of limitation.
> 
> 
> 1) definition of a standard track QoS-model (denoted 
> end-2-end QOSM or inter-domain QoSM??) into a specific 
> document which is required to be handled. This standard track 
> QOSM includes a specific set of paramters that are mandatory 
> for inter-domain QoS-signalling. If this is end-2-end or not 
> is hard to predict but it should ensure interoperabillity 
> across interdomain borders.
> This should be developped separateley from the basis 
> protocols standards so we can finish the development of the 
> basic protocol specfications.
> 
> 2) make the template describing design guidlines, describe 
> how the process of standardizing QoS-models and include some 
> basic parameter description.
> 
> > usage per hop that would go into the "QOS available" part 
> of the QPSEC 
> > as it traverses the domain with RMD QNEs)
> 
> QOSM should not perform "violation" of the basic QoS-NSLP 
> protocol operation. That is accoridng to RSVP. IF QoS-NSLP 
> need to be extended/modified, a new protocol spec. needs to 
> be written.
> 
> > If somebody wants to suggest a different name for such 
> things that are 
> > not traffic parameter, constraints, or handling directives, I'm all 
> > ears.
> >
> > Dave.
> >
> >> Best regards, Attila
> >>
> >>>>> future QSPEC and QoS NSLP standards, nor harm the 
> provision of e2e 
> >>>>> QoS.

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 25 Jan 2007 14:30:33 +0200 (EET)

Hi Georgios,

Could you specify a bit? :)

We can't have unbounded flexibility, especially regarding interoperability 
and e2e QoS provisioning. But we do already provide flexibility in adding 
new objects to the protocols, which, obviously as a result change typical 
message processing rules.

Jukka

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Jan 2007 13:31:18 +0100

Hi Dave

Parts of these two proposals are new to me!

In order to uderstand the impact of these two proposals, 
it might be important if you emphasize what is the impact of these 
two proposals on the ongoing 
NSIS specifications (QOS-NSLP, GIST, QSPEC and all QOSMs).

Furthermore, it will also be interesting if you could investigate and
discuss
the impact of these 
two proposals on the following NSIS concepts:

* Unidirectiona/bidirectional reservation intiation, tear, modification of:
  - bound and parallel end-to-end and edge-to-edge sessions
  - bound and paralele end-to-end and end-to-edge sessions

Note that examples of an end-to-end sessions can be:
* Controlled Load QOSM
* Guaranteed Servuce QOSM

Note that examples of such edge-to-edge sessions can be:
* RSVP aggregation like QOSM
* RMD-QOSM
* interdomain and intra-domain ITU-T RACF QoS model
* PCN like congestion notifictaion and preemption QoS model.

Best Regards,
Georgios

> From: David R Oran [mailto:[email-masked]] 
> Sent: woensdag 24 januari 2007 18:57
> To: Jukka MJ Manner
> > Good. Don't we then have quite a clear statement as to what 
> is allowed 
> > by a QOSM to define, and what is not?
> >
> That's what I thought, but reviewing the mailing list, there 
> are four people who do not think we've got it right. To some 
> extent we may be just talking past each other, but to some 
> extent I think there is in fact real technical disagreement. 
> The best way I can think of to capture that disagreement is whether:
> 
> universally known semantics. Particular QOSMs can provide 
> different semantics, but the RMF for such a QOSM is not 
> permitted to admit traffic unless the parameters in the 
> well-known QSPEC parameters that have been marked "mandatory" 
> by the QNI can be satisfied by the QNE.  
> In addition, a QNE wishing to be QOS-NSLP-compliant for 
> whatever QOS Model it implements must either map its 
> operation directly onto the existing API and state machine 
> operation of the QOS-NSLP, or, must have a standards-track 
> RFC which extends the QOS-NSLP in a backward compatible and 
> interoperable way. A QOSM is *not* allowed to simply require 
> that the QOS-NSLP operate in a different way than is 
> b) The QSPEC is a set of suggested useful parameters than an 
> RMF can decide to use or not use at its discretion and the 
> QOSM is free to add new parameters or re-interpret existing 
> parameters as long as such is documented in an RFC. Further, 
> if the QOSM requires new signaling functionality or a change 
> to the way the QOS-NSLP operates (message flows and state 
> machines) it is free to specify those as part of the QOSM 
> without explicitly extending QOS-NSLP and demonstrating both 
> interoperability and backward compatibility.
> 
> I am firmly in camp (a). I think the existing words in the 
> QSPEC document (with the exception of the one glitch we've 
> already discussed and resolved) capture (a).
> 
> If we have consensus around (a) I think we can move forward 
> and do more word smithing if really necessary. If we don't 
> and what a significant fraction of the WG wants is (b), then 
> I think we really do have a problem and we are more-or-less 
> back where we were before the San Diego IETF.
> 
> Dave Oran.
> 
> > Jukka
> >
> >>> Isn't the fundamental issue here that a new QOSM _MUST NOT_ break 
> provision of 
> >>> e2e QoS.
> >>> The QOSM, or other documents,_MAY_ introduce new 
> extensions - that 
> >>> is why we have the so-called AB-flags in GIST and the two NSLPs.
> >>

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 25 Jan 2007 14:30:33 +0200 (EET)

Hi Georgios,

Jukka

On Thu, 25 Jan 2007, Georgios Karagiannis wrote:

> > whatever QOS

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Jan 2007 13:31:18 +0100

Hi Dave

Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Jan 2007 13:48:37 +0100

Hi Jukka

I think that we actually agree, but in my opinion 
the changes that Dave proposes are going beyond that:

In particular I do not agree with the last 
paragrap of a), see: 
"A QOSM is *not* allowed 
to simply require that the QOS-NSLP operate in a different way 
than is specified in the standards track RFC(s)."

This is very vague that could mean:

If the QOS-NSLP does not specify the exact 
message flow charts and the associated protocol state machines 
of the following scenarios, then no QOSM can use and apply 
such message flow charts and protocol state machines:

* Unidirectiona/bidirectional reservation intiation, refresh, 
  tear, modification of:
  - bound and parallel end-to-end and edge-to-edge sessions
  - bound and paralele end-to-end and end-to-edge sessions

If the above is the case then NSIS is much less felxible and modular than
RSVP.
In other words, NSIS can only be used to support Y.1541 QOSM.

I think that in this case NSIS could also not support the Controlled Load
QOSM.

Best Regards,
Georgios

> Sent: donderdag 25 januari 2007 13:31
> To: Georgios Karagiannis
> Cc: [email-masked]
> We can't have unbounded flexibility, especially regarding 
> interoperability and e2e QoS provisioning. But we do already 
> provide flexibility in adding new objects to the protocols, 
> which, obviously as a result change typical message processing rules.
> 
> Jukka
> 
> > > it seems people are truly talking past each other. I hope no one 
> > > belongs to camp (b).
> > > 
> permitted 
> > > > to admit traffic unless the parameters in the well-known QSPEC
> > > parameters that
> > > > Model it implements must either map its operation directly onto 
> > > > the existing API and state machine operation of the 
> QOS-NSLP, or, 
> > > > must have a standards-track RFC which extends the QOS-NSLP in a 
> > > > backward compatible and interoperable way. A QOSM is 
> *not* allowed 
> > > > to simply require that the QOS-NSLP operate in a different way 
> > > > than
> > > > functionality or a change to the way the QOS-NSLP operates 
> extensions -

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 25 Jan 2007 20:21:05 -0500

Geogios:
 
It will be a serious concern for all of us, as you have pointed out, if only so-called Y.1541 QOSM can use NSIS protocol while the other QOSM models cannot use it.
 
Rather, what we are proposing as follows:

1.	
	We must examine how only the standard-based QOSMs what exist today in the IETF - DiffServ QOSM, CL-QOSM, Guaranteed-QOSM, RMD-QOSM, and RSVP-Ext-QOSM can use NSIS NSLP operations.
2.	
	All QOSMs of item 1 must be able to operate with NSIS NSLP as those are standards QOSM of the IETF.
3.	
	If NSIS NSLP operations do not support items 1 and 2, we have to revisit the NSIS NSLP spec what is the real problem and how we can solve this issue including QSPEC template.
4.	
	We must NOT care what is happening to Y.1541 as we have seen that as it is not a QOS Model. Y.1541 is an implementation-specific value-based QOS-SLA and does NOT need any support of signaling scheme including NSIS QOS protocols. Any support of NSIS for Y.1541 is out-of-place.
5.	
	It is extremely unfortunate, as you have found out, that NSIS NSLP can operate only for so-called Y.1541, but not for IETF standard-based QOSMs. What else can be most disappointing for all IETF members if this nightmare really becomes true at the end of all hard works?

Best regards,

Radhika

From: [email-masked] on behalf of Georgios Karagiannis
Sent: Thu 1/25/2007 7:48 AM
To: 'Jukka MJ Manner'
Cc: [email-masked]
Subject: RE: [NSIS] QSPEC document

Hi Jukka

Best Regards,
Georgios

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 31 Jan 2007 13:22:12 +0100

Hi Georgios, all,

I'm jumping late in this discussion as I have had problems in getting  
to the core of the problems discussed here. While I'm not fully  
confident that I have managed to grasp issues I have still a question:

> than is specified in the standards track RFC(s)."

I'm actually for Dave's text suggestion, because it reflects my  
understanding on how the QOSM/QSPEC/NSLP interworking is actually  
working. However, I'm willing to learn more why it is a technical  
issue. More below.

>   - bound and paralele end-to-end and end-to-edge sessions

I know that the QoS NSLP is defining semantics on when and which  
message should be sent.  But the trigger, i.e., when a message  
sequence is fired, is at the discretion of the RMF).

One example: If the RMF decides to tunnel the original NSLP message  
and start a new domain-locally signalling session in parallel, the  
RMF needs to tell this the QoS NSLP.

[...]

> I think that in this case NSIS could also not support the  

An easy example could help me to follow this conclusion.

Thanks

   Martin

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 31 Jan 2007 14:29:22 +0100

Hi Martin 

Regarding the below:

 > I know that the QoS NSLP is defining semantics on when and 
> which message should be sent.  But the trigger, i.e., when a 
> message sequence is fired, is at the discretion of the RMF).
> 
> One example: If the RMF decides to tunnel the original NSLP 
> message and start a new domain-locally signalling session in 
> parallel, the RMF needs to tell this the QoS NSLP.
> 
> [...]

You are right! But this is what I am trying to emphasize.
The the externally observable semantics of the QOS-NSLP protocol 
should not be changed by the 
QOSM, but the interior (within a node) semantics can be changed.

The following paragraph included in v.14 (that is actually causing more
confusion
than the one included in QSPEC v,13) which mainly emphasizes that the QOSMs
are not expected 
to extend common data, state machines, and APIs of NSIS protocols.

"QOSMs all utilize the common
   data, state machines, and APIs of the underlying NSIS protocols and
   are not expected to re-define or extend these in any way."

Note that API and the part of a state machine that describes the internal 
behaviour of a node, such as the interaction 
with the RMF are in my opinion implementation matters that should 
not be used in any text that is meant to limit the flexibility of a
specifrication.

Note that in the example that you gave the 
QOS-NSLP protocol state machine (the part that might cover the interaction 
between QOS-NSLP function and RMF) will change. 
Thus this will mean that a QOSM is not able to decide to tunnel the original
NSLP 
message and start a new domain-locally signalling session in 
parallel, and to to tell this to the QoS NSLP.

Therefore, such internal behavior semantics should not impose any
restriction 
on what a QOSM might be able to specify.

What about using the following paragraph, instead of the one included in
v.14.

"In order to preserve the end-to-end interoperability the end-to-end
semantic 
and end-to-end QoS NSLP messaging by the QNI, or any peer QNE must be
preserved, 
and within those bounds a QOSM must operate. Furthermore, a QOSM should 
not change the externally observable semantics of the QOS-NSLP protocol." 

Best Regards,
Georgios

> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: woensdag 31 januari 2007 13:22
> To: Georgios Karagiannis
> Cc: 'Jukka MJ Manner'; [email-masked]
> I'm jumping late in this discussion as I have had problems in 
> getting to the core of the problems discussed here. While I'm 
> not fully confident that I have managed to grasp issues I 
> have still a question:
> 
> > I think that we actually agree, but in my opinion the changes that 
> > Dave proposes are going beyond that:
> >
> > In particular I do not agree with the last paragrap of a), see:
> > "A QOSM is *not* allowed
> > to simply require that the QOS-NSLP operate in a different 
> way than is 
> > specified in the standards track RFC(s)."
> 
> I'm actually for Dave's text suggestion, because it reflects 
> my understanding on how the QOSM/QSPEC/NSLP interworking is 
> actually working. However, I'm willing to learn more why it 
> is a technical issue. More below.
> 
> >
> > If the QOS-NSLP does not specify the exact message flow 
> charts and the 
> > associated protocol state machines of the following 
> scenarios, then no 
> > QOSM can use and apply such message flow charts and protocol state 
> > machines:
> >
> I know that the QoS NSLP is defining semantics on when and 
> which message should be sent.  But the trigger, i.e., when a 
> message sequence is fired, is at the discretion of the RMF).
> 
> One example: If the RMF decides to tunnel the original NSLP 
> message and start a new domain-locally signalling session in 
> parallel, the RMF needs to tell this the QoS NSLP.
> 
> [...]
> 
> >
> > If the above is the case then NSIS is much less felxible 
> and modular 
> > than RSVP.
> > I think that in this case NSIS could also not support the 
> Controlled 
> > Load QOSM.
> 
> >> interoperability and e2e QoS provisioning. But we do 
> already provide 
> >> flexibility in adding new objects to the protocols, which, 
> obviously 
> >> as a result change typical message processing rules.
> >>
> >> Jukka
> >>