Subject: [NSIS] Summary of QSPEC call

From: Martin Stiemerling <[email-masked]>
Date: Thu, 1 Feb 2007 17:05:09 +0100

Dear all,

Here is the short summary of the QSPEC phone conference call of  
January 31st. The call had been announced on the NSIS mailing list on  
January 23
(http://www1.ietf.org/mail-archive/web/nsis/current/msg07527.html).

The participants of the call were:
Georgios Karagiannis,
Lars Westberg,
Attila Bader,
Magnus Westerlund,
Jerry Ash,
Bernd Schloer,
Hannes Tschofenig <[email-masked]>,
Cornelia Kappler,
John Loughney,
Andrew McDonald
Jukka Manner
Luis Cordeiro
Lars Eggert
Tom Phelan
Martin Stiemerling

After all we agreed to these points that need to be changed in QSPEC  
or QoS NSLP document:

- There is text required in the QoS NSLP about the relationship  
between the QoS NSLP and the RMF, i.e., how can the RMF trigger  
actions of the QoS NSLP. For instance, that the RMF can trigger a  
RESERVE.
- The text in Section 4.1 "QoS Models", 2nd paragraph of the QSPEC  
draft needs to be changed so that "state machine" clearly references  
to "QoS NSLP state machine"
- The QSPEC draft needs an informational section describing the API  
between QSPEC and QoS NSLP. This informational section should be in  
the spirit of the API description in GIST, i.e., giving guidance to  
implementers.

Please confirm the points or send your objection with a reason to the  
NSIS working group list.

Thanks,

   Martin

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

---

From: "ASH, GERALD R \(JERRY\), SBCLABS" <[email-masked]>
Date: Thu, 1 Feb 2007 12:07:12 -0600

Hi Martin, 

Thanks a lot for the summary.  Please see below.

> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: Thursday, February 01, 2007 11:05 AM
> To: nsis
> Subject: [NSIS] Summary of QSPEC call
> 
> Dear all,
> 

OK.

> to "QoS NSLP state machine"

OK.

> the spirit of the API description in GIST, i.e., giving guidance to  

Regarding the informational appendix on QoS-NSLP <--> QSPEC/RMF API, I
had not understood that this was agreed to be added to the QSPEC
document.  IMO this belongs in the QoS NSLP document since it is
primarily signaling related and analogous to the GIST Appendix B ("API
between GIST and Signaling Applications").  Note that the GIST Appendix
B describes several (signaling) primitives (SendMessage, RecvMessage,
MessageStatus, NetworkNotification, SetStateLifetime,
InvalidateRoutingState), analogous signaling primitives would better be
illustrated in QoS NSLP.

Thanks,
Jerry

---

From: Andrew McDonald <[email-masked]>
Date: Thu, 01 Feb 2007 21:57:10 +0000

Hi,

> InvalidateRoutingState), analogous signaling primitives would better be

I'm in agreement with Jerry here - I believe the discussion was about 
this going in to the QoS NSLP document.

Andrew

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 2 Feb 2007 07:58:58 +0100

Hi all,

Am 01.02.2007 um 22:57 schrieb Andrew McDonald:

>>> - The QSPEC draft needs an informational section describing the  
>>> API  between QSPEC and QoS NSLP. This informational section  
>>> should be in  the spirit of the API description in GIST, i.e.,  
>>> giving guidance to  implementers.
> I'm in agreement with Jerry here - I believe the discussion was  
> about this going in to the QoS NSLP document.

Yes, Jerry and you are right. I actually thought the same after  
pressing the send button...

Thanks,

   Martin

> Andrew

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 2 Feb 2007 13:39:10 +0100

Hi Martin

In big lines I agree with the listed outcomes, but I thought 
that I also proposed to include a sentence that is associated 
with what we mean by QoS-NSLP protocol state machine.
In particular, I proposed to add something like:
"Note that the reactions of the QOS-NSLP to triggers from a QOSM are 
not considered to be a part of the QoS-NSLP state machine."

Thus I would also like to see the following modification on the QSPEC
template draft:
Modify the following sentence in all sections of the QSPEC template draft:

FROM:
"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."

INTO:
"QOSMs all utilize the
state machines of the underlying NSIS protocols and are not expected 
to re-define or extend these in any way.
Note that the reactions of the QOS-NSLP to triggers from a QOSM are 
not considered to be a part of the QoS-NSLP state machine."

Note that common data and API are internal features that cannot be 
standardised and therefore must be Removed. The note that I have added 
is required to clarify what we mean by QOS-NSLP state machine! 

Regarding the control information, we did not have to discuss them, but:
I hope that the old 
semantics of control information will be reincluded in the next 
version of QSPEC template  draft.

Best Regards,
Georgios

> Sent: donderdag 1 februari 2007 17:05
> To: nsis
> Here is the short summary of the QSPEC phone conference call 
> of January 31st. The call had been announced on the NSIS 
> mailing list on January 23 
> Hannes Tschofenig <[email-masked]>, Cornelia 
> Kappler, John Loughney, Andrew McDonald Jukka Manner Luis 
> Cordeiro Lars Eggert Tom Phelan Martin Stiemerling
> 
> After all we agreed to these points that need to be changed 
> in QSPEC or QoS NSLP document:
> 
> - There is text required in the QoS NSLP about the 
> relationship between the QoS NSLP and the RMF, i.e., how can 
> the RMF trigger actions of the QoS NSLP. For instance, that 
> the RMF can trigger a RESERVE.
> - The text in Section 4.1 "QoS Models", 2nd paragraph of the 
> QSPEC draft needs to be changed so that "state machine" 
> clearly references to "QoS NSLP state machine"
> - The QSPEC draft needs an informational section describing 
> the API between QSPEC and QoS NSLP. This informational 
> section should be in the spirit of the API description in 
> GIST, i.e., giving guidance to implementers.
> 
> Please confirm the points or send your objection with a 
> reason to the NSIS working group list.
> 
> Thanks,
> 
>    Martin
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 2 Feb 2007 14:32:37 +0100

Hi all

I also agree with Jerry here!
However, I had a comment on some paragraphs that are currently included 
in the QSPEC draft and refer to the API and common data, please see my
previous e-mail
that has been sent as reply to Martin's e-mail!

Regarding the QSPEC control information please reintroduce the old semantics

in the next QSPEC version.

Best Regards,
Georgios

> Sent: vrijdag 2 februari 2007 7:59
> To: Andrew McDonald
> Cc: ASH, GERALD R (JERRY), SBCLABS; nsis
> Subject: Re: [NSIS] Summary of QSPEC call
> 
> Hi all,
> 
> >> Regarding the informational appendix on QoS-NSLP <--> 
> QSPEC/RMF API, 
> >> I had not understood that this was agreed to be added to the QSPEC 
> >> primarily signaling related and analogous to the GIST Appendix B 
> >> ("API between GIST and Signaling Applications").  Note 
> that the GIST 
> >> Appendix B describes several (signaling) primitives (SendMessage, 
> >> RecvMessage, MessageStatus, NetworkNotification, SetStateLifetime, 
> >> InvalidateRoutingState), analogous signaling primitives 
> would better 
> >> be illustrated in QoS NSLP.
> >
> Yes, Jerry and you are right. I actually thought the same 
> after pressing the send button...
> 
> Thanks,
> 
>    Martin
> 
> >
> >
> > Andrew
> 
> 
> 
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL 
> | Registered in England 2832014
> 
> 
> 
>

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Fri, 2 Feb 2007 15:22:16 +0100

Hi Georgios, 

obviously, the reaction of QoS NSLP to triggers from QOSM would influence the QoS NSLP statemachine. Furthermore, the reactions are part of what QoS NSLP does. So how should I interpret the meaning of "they are not part of the QoS NSLP state machine"? 

Cornelia

> -----Ursprüngliche Nachricht-----
> Von: Georgios Karagiannis [mailto:[email-masked]] 
> Gesendet: Freitag, 2. Februar 2007 13:39
> An: 'Martin Stiemerling'; 'nsis'
> Betreff: RE: [NSIS] Summary of QSPEC call
> 
> Hi Martin
>

---

From: David R Oran <[email-masked]>
Date: Fri, 2 Feb 2007 09:35:56 -0500

> not considered to be a part of the QoS-NSLP state machine."
I think there's a language problem here. If by "triggers from a QOSM"  
you mean "event inputs to from RMF to QOS-NSLP protocol machine", and  
by "not considered part of the state machine" you mean "such inputs  
do not appear in the global FSM for QOS-NSLP", then if I suggested  
such in CS301 on finite autonoma  I would have been flunked from the  
course.

Could you take another crack at what you mean here?

Thanks, Dave.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 2 Feb 2007 16:21:41 +0100

Hi Cornelia and Dave

Agree that the last added sentence is a bit vague!
What I am trying to say is that a QOSM is allowed to define new 
RMF triggers that could influence the reaction of the QOS-NSLP.

Maybe the following changed paragraph is more clear:

"QOSMs all utilize the
state machines of the underlying NSIS protocols and are not 
expected  to re-define or extend these in any way.
Note that a QOSM can however, extend the RMF triggers 
to/from the QOS-NSLP functionality,
which might affect the QoS-NSLP state machine."

Best Regards,
Georgios

> From: Kappler, Cornelia [mailto:[email-masked]] 
> Sent: vrijdag 2 februari 2007 15:22
> To: Georgios Karagiannis; Martin Stiemerling; nsis
> Subject: AW: [NSIS] Summary of QSPEC call
> 
> Hi Georgios, 
> 
> obviously, the reaction of QoS NSLP to triggers from QOSM 
> would influence the QoS NSLP statemachine. Furthermore, the 
> reactions are part of what QoS NSLP does. So how should I 
> interpret the meaning of "they are not part of the QoS NSLP 
> state machine"? 
> 
> Cornelia
> 
> > In big lines I agree with the listed outcomes, but I thought that I 
> > also proposed to include a sentence that is associated with what we 
> > mean by QoS-NSLP protocol state machine.
> > > January 31st. The call had been announced on the NSIS 
> mailing list 
> > > on January 23 
> > > 
> > > John Loughney, Andrew McDonald Jukka Manner Luis Cordeiro Lars 
> > > Eggert Tom Phelan Martin Stiemerling
> > > 
> > > draft needs to be changed so that "state machine"
> > > Please confirm the points or send your objection with a reason to 
> > > the NSIS working group list.
> > > 
> > > Thanks,
> > > 
> > >    Martin
> > >

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 02 Feb 2007 11:25:56 -0500

Hi all,

let me repeat again what I said during the phone conference call.

The QoS NSLP implicitly contains a state machine and an explicit 
description of the QoS NSLP state machine can be found in:
http://tools.ietf.org/wg/nsis/draft-fu-nsis-qos-nslp-statemachine-05.txt
http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-statemachine-05.pdf

The QoS NSLP alone is not useful. In order todo something it needs to 
(a) carry some QoS parameters with the corresponding meaning and (b) the 
state transitions need to be triggered. These triggers might come from 
various sources. Some of the triggers have been discussed in the context 
of RMD when an edge node of an RMD domain receives an end-to-end 
signaling message. Some actions might have to be taken within the RMD 
domain based on this incoming message. The type of message, the content 
of the QoS parameters, security parameters, the reservation state within 
the RMD domain, etc. influence the decision making process.

The QoSM has its own state machine and it interacts with the QoS NSLP 
whereby these actions have to fit to the QoS NSLP state machine but 
there is a lot of freedom since the QoS NSLP just defines basic message 
patterns.

Hence, when someone says that the QoSM MUST NOT modify the QoS NSLP 
state machine it would be good to be very explicit what that actually 
means.

This procdure of interworking between different state machines at 
different components is nothing new. Diameter (RFC 3588 and the 
applications) and EAP - EAP methods do the same.

Ciao
Hannes

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 2 Feb 2007 18:02:13 +0100

Hi Hannes

Thank you for the clarification!
I totally agtree with the below statements!

> The QoSM has its own state machine and it interacts with the 
> QoS NSLP whereby these actions have to fit to the QoS NSLP 
> state machine but there is a lot of freedom since the QoS 
> NSLP just defines basic message patterns.

> Hence, when someone says that the QoSM MUST NOT modify the 
> QoS NSLP state machine it would be good to be very explicit 
> what that actually means.

That is why I tried to emphasize that an existing or future QOSM is allowed
to 
extend the RMF triggers that can affect the QoS-NSLP state machine.

Best Regards,
Georgios

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: vrijdag 2 februari 2007 17:26
> To: Kappler, Cornelia
> Cc: Georgios Karagiannis; Martin Stiemerling; nsis
> Subject: State Machines .... was [NSIS] Summary of QSPEC call
> 
> Hi all,
> 
> The QoS NSLP implicitly contains a state machine and an 
> explicit description of the QoS NSLP state machine can be found in:
> (a) carry some QoS parameters with the corresponding meaning 
> and (b) the state transitions need to be triggered. These 
> triggers might come from various sources. Some of the 
> triggers have been discussed in the context of RMD when an 
> edge node of an RMD domain receives an end-to-end signaling 
> message. Some actions might have to be taken within the RMD 
> domain based on this incoming message. The type of message, 
> the content of the QoS parameters, security parameters, the 
> reservation state within the RMD domain, etc. influence the 
> decision making process.
> 
> The QoSM has its own state machine and it interacts with the 
> QoS NSLP whereby these actions have to fit to the QoS NSLP 
> state machine but there is a lot of freedom since the QoS 
> NSLP just defines basic message patterns.
> 
> Hence, when someone says that the QoSM MUST NOT modify the 
> QoS NSLP state machine it would be good to be very explicit 
> what that actually means.
> 
> This procdure of interworking between different state 
> machines at different components is nothing new. Diameter 
> (RFC 3588 and the

---

From: <[email-masked]>
Date: Fri, 2 Feb 2007 15:46:46 -0600

Hannes,

The issue is that if any QoSM deviates (for example having some
signaling
optimizations within the QoSM) from the defined QoS NSLP State Machine, 
then those MUST be optional, and the QoSM needs to describe how the QoSM
falls back to the standard State Machine.  If the QOSM has a different
state machine, then that QoSM MUST be a Standards Track document that
extends the QoS NSLP.

All QoSM must be able to handle 'standard' QoS NSLP messaging flows. If
they modify (or introduce) new messaging flows, these flows should be
optimizations (which are optional) and need to discuss how to fall back
to standard messaging sequences.

I believe we discussed this on the call and people seemed to agree.

John

>From: ext Hannes Tschofenig [mailto:[email-masked]] 
>Sent: 02 February, 2007 08:26
>To: Kappler, Cornelia
>Cc: Martin Stiemerling; Georgios Karagiannis; nsis
>triggers might come from various sources. Some of the triggers 
>have been discussed in the context of RMD when an edge node of 
>an RMD domain receives an end-to-end signaling message. Some 
>actions might have to be taken within the RMD domain based on 
>this incoming message. The type of message, the content of the 
>QoS parameters, security parameters, the reservation state 
>within the RMD domain, etc. influence the decision making process.
>
>state machine but there is a lot of freedom since the QoS NSLP 
>just defines basic message patterns.
>
>Hence, when someone says that the QoSM MUST NOT modify the QoS 
>NSLP state machine it would be good to be very explicit what 
>that actually means.
>
>This procdure of interworking between different state machines 
>at different components is nothing new. Diameter (RFC 3588 and the

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 5 Feb 2007 10:40:31 +0100

Hi John

But any QOSM describes the functionality of RMF, thus it uses a different
QOSM state machine 
that is different than the QoS-NSLP state machine. Thus I do not understand
what you 
want to say in your e-mail!

Furthermore, as Hannes emphasized in his e-mails the current QoS-NSLP 
state machine document is an Informational RFC and it does not go into lot
of details 
with any local node dependent functions, including QOSM, 
security and AAA interactions.  

Note that what we have decided in the meeting is to emphasize that:

QOSMs all utilize the
state machines of the underlying NSIS protocols and are not expected  
to re-define or extend these. Note that a QOSM can however, 
extend the RMF triggers to/from the QOS-NSLP functionality, which 
might affect the QoS-NSLP state machine.

Maybe the last sentence is not exactly the same as the words that 
I have proposed during the meeting, but the semantics are.

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: vrijdag 2 februari 2007 22:47
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call
> 
> Hannes,
> 
> The issue is that if any QoSM deviates (for example having 
> some signaling optimizations within the QoSM) from the 
> defined QoS NSLP State Machine, then those MUST be optional, 
> and the QoSM needs to describe how the QoSM falls back to the 
> standard State Machine.  If the QOSM has a different state 
> machine, then that QoSM MUST be a Standards Track document 
> that extends the QoS NSLP.
> 
> All QoSM must be able to handle 'standard' QoS NSLP messaging 
> flows. If they modify (or introduce) new messaging flows, 
> these flows should be optimizations (which are optional) and 
> need to discuss how to fall back to standard messaging sequences.
> 
> >(a) carry some QoS parameters with the corresponding meaning and (b) 
> >the state transitions need to be triggered. These triggers 
> might come 
> >from various sources. Some of the triggers have been 
> discussed in the 
> >context of RMD when an edge node of an RMD domain receives an 
> >end-to-end signaling message. Some actions might have to be taken 
> >within the RMD domain based on this incoming message. The type of 
> >message, the content of the QoS parameters, security parameters, the 
> >reservation state within the RMD domain, etc. influence the decision 
> >making process.
> >
> QoS NSLP

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Mon, 5 Feb 2007 10:45:24 -0600

Georgios, 

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Monday, February 05, 2007 4:41 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> But any QOSM describes the functionality of RMF, thus it uses 
> a different QOSM state machine 
> that is different than the QoS-NSLP state machine. Thus I do 
> not understand what you want to say in your e-mail!
> 
> state machine document is an Informational RFC and it does 
> not go into lot of details 

The 2 sentences are diametrically opposite.  In the conference call most
agreed that the QoS-NSLP state machine should *not* be dependent on
which QOSM is in use by the RMF (as detailed in Cornelia's slide 2, last
bullet, in the post I sent out in
http://www1.ietf.org/mail-archive/web/nsis/current/msg07561.html).  

See also Martin's notes on the QSPEC conference call
http://www1.ietf.org/mail-archive/web/nsis/current/msg07548.html.  There
it says that we agreed that text is required in the QoS NSLP about the
relationship between the QoS NSLP and the RMF, i.e., how can the RMF
trigger actions of the QoS NSLP.  That is what was 'decided' regarding
clarifying text related to the QoS NSLP state machine.

Jerry