Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D

From: Martin Stiemerling <[email-masked]>
Date: Tue, 6 Feb 2007 14:55:24 +0100

Well, I have not yet seen consensus about this issue.

Georgios proposed this text:

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

I personally also see that sentence 1 and 2 are contradicting each  
other at least partially. The first sentence is not allowing to  
extend the state machinery of the underlying NSIS protocols, where  
the second sentence is is opening the door for extending it.

However, I don't see any real technical issue here, but more a  
wording issue.

I'm not a good wording expert here, but the base lines seems to be:
1) QOSMs cannot change the semantics (and thus state machine) of the  
underlying QoS NSLP and GIST. (A standards track document is required  
for doing so).
2) QOSMs can send triggers to the QoS NSLP. These trigger can cause  
the QoS NSLP to run its semantics. Basically the " affect the QoS- 
NSLP state machine." is not very clear to readers. Yes, it affects  
the state machine, but only by giving a reason for an initial state  
transition (e.g., send RESERVE).

So, I'm now waiting for the big, loud scream of what is wrong here. :-)

   Martin

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

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 6 Feb 2007 15:59:07 +0100

Hi Martin

> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: dinsdag 6 februari 2007 14:55
> To: nsis
> Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D
> 
> 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."
> 
> I personally also see that sentence 1 and 2 are contradicting 
> each other at least partially. The first sentence is not 
> allowing to extend the state machinery of the underlying NSIS 
> protocols, where the second sentence is is opening the door 
> for extending it.
> 
> However, I don't see any real technical issue here, but more 
> a wording issue.
> 
> 1) QOSMs cannot change the semantics (and thus state machine) 
> of the underlying QoS NSLP and GIST. (A standards track 
> document is required for doing so).
> 2) QOSMs can send triggers to the QoS NSLP. These trigger can 
> cause the QoS NSLP to run its semantics. Basically the " 
> affect the QoS- NSLP state machine." is not very clear to 
> readers. Yes, it affects the state machine, but only by 
> giving a reason for an initial state transition (e.g., send RESERVE).

I think that you have emphasized what I was thinking of.
However, note that these RMF triggers are internal triggers and according to
the NSIS concepts
they should be able to initiate and maintain the
unidirectional/bidirectional and sender/receiver 
reservation intiation, refresh, tear, modification of:
 * bound and parallel end-to-end and end-to-end sessions 
 * bound and parallel end-to-end and edge-to-edge sessions 
 * bound and parallel end-to-end and end-to-edge sessions

* Examples of QOSMs that support end-to-end sessions can be:
  ** Intserv like Controlled Load QOSM
  ** Intserv like Guaranteed Service QOSM

* Examples of QOSMs that can support 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.
  ** RSVP-TE like QOSM

* Examples of QOSMs that can support end-to-edge sessions: 
 ** IEEE 802.16

Best regards,
Georgios

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Tue, 6 Feb 2007 10:41:31 -0600

Hi Martin,

I agree with your clarified text, slightly edited here:

"RMF/QOSMs cannot change the semantics and thus the state machine of the
underlying QoS NSLP and GIST (a standards track document is required for
doing so), although RMF/QOSMs can send triggers to the QoS NSLP that
cause the QoS NSLP to run its semantics."

Thanks,
Regards,
Jerry 

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2007 8:55 AM
To: nsis
Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D

   Martin

---

From: <[email-masked]>
Date: Tue, 6 Feb 2007 11:43:51 -0600

Jerry,

I was thinking of text along the lines of the following:

 QoSMs define the RMF triggers for the underlying QoS NSLP and
 GIST signaling state.  A QoSM works with the messaging 
 processing rules of the QoS NSLP (defined in section 5.2).
 If the QoSM defines new QoS NSLP processing rules, the QoSM
 MUST define a fallback to the standard QoS NSLP processing 
 rules.  New QoS NSLP message processing rules can only defined
 in Standards Track extensions to the QoS NSLP.

Does this make sense?

John

>From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:[email-masked]] 
>Sent: 06 February, 2007 08:42
>To: Martin Stiemerling; nsis
>Cc: ASH, GERALD R (JERRY), ATTLABS
>Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D
>
>Hi Martin,
>
>"RMF/QOSMs cannot change the semantics and thus the state 
>machine of the underlying QoS NSLP and GIST (a standards track 
>document is required for doing so), although RMF/QOSMs can 
>send triggers to the QoS NSLP that cause the QoS NSLP to run 
>its semantics."
>
>Thanks,
>Regards,
>Jerry 
>
>readers. Yes, it affects the state machine, but only by giving 
>a reason for an initial state transition (e.g., send RESERVE).
>

---

From: <[email-masked]>
Date: Tue, 6 Feb 2007 11:45:20 -0600

Georgios,

>* Examples of QOSMs that can support end-to-edge sessions: 

However, do you feel that the current QoS NSLP currently limits any of
the above?
If not, then I think we are done. If it does, we need to either fix or
extend
the QoS NSLP to meet your concerns.  The QoSMs are not the place to
extend
the QoS NSLP.

John

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Tue, 6 Feb 2007 13:35:55 -0600

Hi John,

How about this text:

"QOSM specifications may define RMF triggers that cause the QoS NSLP to
run semantics within the underlying QoS NSLP signaling state and
messaging processing rules, as defined in Section 5.2 of [QoS-SIG].  New
QoS NSLP message processing rules can only be defined in Standards Track
extensions to the QoS NSLP.  If a QOSM specification defines triggers
that deviate from existing standard QoS NSLP processing rules (must be
standards track in that case), the fallback for QNEs not supporting that
QOSM is to use the standard QoS NSLP state transition/message processing
rules."

Is that consistent with your proposal?

Thanks,
Jerry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2007 12:44 PM
To: ASH, GERALD R (JERRY), ATTLABS; [email-masked];
[email-masked]

Jerry,

Does this make sense?

John

---

From: <[email-masked]>
Date: Tue, 6 Feb 2007 14:21:41 -0600

I think that looks fine. What do others thing about this?

John 

>Sent: 06 February, 2007 11:36
>To: Loughney John (Nokia-NRC/PaloAlto); 
>[email-masked]; [email-masked]
>"QOSM specifications may define RMF triggers that cause the 
>QoS NSLP to run semantics within the underlying QoS NSLP 
>signaling state and messaging processing rules, as defined in 
>Section 5.2 of [QoS-SIG].  New QoS NSLP message processing 
>rules can only be defined in Standards Track extensions to the 
>QoS NSLP.  If a QOSM specification defines triggers that 
>deviate from existing standard QoS NSLP processing rules (must 
>be standards track in that case), the fallback for QNEs not 
>supporting that QOSM is to use the standard QoS NSLP state 
>transition/message processing rules."
>
>>"RMF/QOSMs cannot change the semantics and thus the state machine of 
>>the underlying QoS NSLP and GIST (a standards track document is 
>>required for doing so), although RMF/QOSMs can send triggers 
>to the QoS 
>>NSLP that cause the QoS NSLP to run its semantics."
>>
>>Thanks,
>>Regards,
>>Jerry
>>
>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."
>>
>>other at least partially. The first sentence is not allowing 
>to extend 
>>the state machinery of the underlying NSIS protocols, where 
>the second 
>>sentence is is opening the door for extending it.
>>
>a wording 
>>issue.
>cause the 
>>QoS NSLP to run its semantics. Basically the "
>readers. Yes, 
>>it affects the state machine, but only by giving a reason for an 
>>initial state transition (e.g., send RESERVE).
>>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 6 Feb 2007 17:37:50 -0500

John:
 
I also agree with Jerry's proposed text.
 
Radhika

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Tue 2/6/2007 3:21 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D

John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 7 Feb 2007 11:43:39 +0100

Hi John

Please see  in line!

> Sent: dinsdag 6 februari 2007 18:45
> To: [email-masked]; [email-masked]; [email-masked]
> >However, note that these RMF triggers are internal triggers and 
> >according to the NSIS concepts they should be able to initiate and 
> >maintain the unidirectional/bidirectional and sender/receiver 
> However, do you feel that the current QoS NSLP currently 
> limits any of the above?
> If not, then I think we are done. If it does, we need to 
> either fix or extend the QoS NSLP to meet your concerns.  The 
> QoSMs are not the place to extend the QoS NSLP.

If you consider that the two following points MUST be satisfied then I 
I think that not all the NSIS concepts listed above can be supported by 
the QoS-NSLP state machine:
 * the reaction of the QOS-NSLP caused by RMF triggers 
  is considered to be a part of the QOS-NSLP state machine
* the QOSM is allowed to specify RMD triggers but these RMF triggers should
not 
  modify the QoS-NSLP state machine (which includes the reaction of the
QoS-NSLP
  caused by RMF triggers) 

The reason of this is that has been considered from the beginning that 
the QOS-NSLP does not go into lot of details with any 
local node dependent functions, including QOSM functionality and RMF
triggers, 
security and AAA interactions. 
  
Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 7 Feb 2007 11:59:39 +0100

Hi John and Jerry

I think that the text looks much better and is acceptable for me
if you can guarantee that the RMF triggers that are acceptable to you
and are considered by you as being compliant to the QoS-NSLP 
should be able to initiate and maintain the unidirectional/bidirectional 
and sender/receiver reservation intiation, refresh, tear, modification of:
 * bound and parallel end-to-end and end-to-end sessions
 * bound and parallel end-to-end and edge-to-edge sessions
 * bound and parallel end-to-end and end-to-edge sessions

Best Regards,
Georgios

> Sent: dinsdag 6 februari 2007 21:22
> >To: Loughney John (Nokia-NRC/PaloAlto); [email-masked]; 
> >[email-masked]
> QoS NSLP to 
> >messaging processing rules, as defined in Section 5.2 of [QoS-SIG].  
> >New QoS NSLP message processing rules can only be defined in 
> Standards 
> >Track extensions to the QoS NSLP.  If a QOSM specification defines 
> >triggers that deviate from existing standard QoS NSLP 
> processing rules 
> >(must be standards track in that case), the fallback for QNEs not 
> > QoSMs define the RMF triggers for the underlying QoS NSLP and  GIST 
> >signaling state.  A QoSM works with the messaging processing 
> rules of 
> >the QoS NSLP (defined in section 5.2).
> > If the QoSM defines new QoS NSLP processing rules, the QoSM MUST 
> >define a fallback to the standard QoS NSLP processing rules. 
>  New QoS 
> >NSLP message processing rules can only defined  in Standards Track 
> >extensions to the QoS NSLP.
> >
> >Does this make sense?
> >
> >John
> >
> machine of

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 7 Feb 2007 12:06:13 +0100

Hi John

This e-mail is a duplication of a previous e-mail that 
I have sent on this issue, but with a minor change:
Instead of :
"the QOSM is allowed to specify RMD triggers but these RMF triggers .."

It should be:
"the QOSM is allowed to specify RMF triggers but these RMF triggers .."

Sorry about that! 
In line you can see the right version of my comments!

> extend the QoS NSLP to meet your concerns.  The QoSMs are not the 
> place to extend the QoS NSLP.

If you consider that the two following points MUST be satisfied then I I
think that not all the NSIS concepts listed above can be supported by the
QoS-NSLP state machine:
 * the reaction of the QOS-NSLP caused by RMF triggers
  is considered to be a part of the QOS-NSLP state machine
* the QOSM is allowed to specify RMF triggers but these RMF triggers should
not
  modify the QoS-NSLP state machine (which includes the reaction of the
QoS-NSLP
  caused by RMF triggers) 

The reason of this is that has been considered from the beginning that the
QOS-NSLP does not go into lot of details with any local node dependent
functions, including QOSM functionality and RMF triggers, security and AAA
interactions. 
  
Best Regards,
Georgios

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Wed, 7 Feb 2007 07:15:22 -0600

Georgios, All,

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Wednesday, February 07, 2007 6:00 AM
> To: [email-masked]; ASH, GERALD R (JERRY), ATTLABS; 
> and sender/receiver reservation initiation, refresh, tear, 
> modification of:
>   ** PCN like congestion notification and preemption QoS model.
>   ** RSVP-TE like QOSM
> 

You have said in your previous message:
"If you consider that the two following points MUST be satisfied then I
think that not all the NSIS concepts listed above can be supported by
the QoS-NSLP state machine:
* the reaction of the QOS-NSLP caused by RMF triggers is considered to
be a part of the QOS-NSLP state machine
* the QOSM is allowed to specify RMD triggers but these RMF triggers
should not modify the QoS-NSLP state machine (which includes the
reaction of the QoS-NSLP caused by RMF triggers)"

If that is the case then as John said:
"(If) the current QoS NSLP currently limits any of the above..., we need
to either fix or extend the QoS NSLP to meet your concerns."

I agree with John.  The QSPEC draft is not the place to extend the QoS
NSLP.  Please propose any changes/extensions to the QoS NSLP document
you feel are necessary.

Jerry

> > >>sentence is opening the door for extending it.
> > >>

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 7 Feb 2007 14:57:19 +0100

I'm fine with this text!

   Martin

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 8 Feb 2007 09:45:52 +0100

Hi Jerry

Thanks, I assume then that you agree then that we should anything possible
to ensure
that NSIS supports  should be able to initiate and maintain the
unidirectional/bidirectional and 
sender/receiver reservation initiation, refresh, tear, modification 
of:
 * bound and parallel end-to-end and end-to-end sessions
 * bound and parallel end-to-end and edge-to-edge sessions
 * bound and parallel end-to-end and end-to-edge sessions

As being co-editor of the QoS-NSLP draft I will do anything possible to
assure this!

Best Regards,
Georgios

> From: ASH, GERALD R (JERRY), ATTLABS [mailto:[email-masked]] 
> Sent: woensdag 7 februari 2007 14:15
> To: Georgios Karagiannis; [email-masked]; 
> > I think that the text looks much better and is acceptable for me if 
> > you can guarantee that the RMF triggers that are acceptable 
> to you and 
> > are considered by you as being compliant to the QoS-NSLP should be 
> > able to initiate and maintain the unidirectional/bidirectional and 
> > sender/receiver reservation initiation, refresh, tear, modification 
> > of:
> "If you consider that the two following points MUST be 
> satisfied then I think that not all the NSIS concepts listed 
> above can be supported by the QoS-NSLP state machine:
> * the reaction of the QOS-NSLP caused by RMF triggers is 
> considered to be a part of the QOS-NSLP state machine
> * the QOSM is allowed to specify RMD triggers but these RMF 
> triggers should not modify the QoS-NSLP state machine (which 
> includes the reaction of the QoS-NSLP caused by RMF triggers)"
> 
> "(If) the current QoS NSLP currently limits any of the 
> above..., we need to either fix or extend the QoS NSLP to 
> meet your concerns."
> 
> I agree with John.  The QSPEC draft is not the place to 
> extend the QoS NSLP.  Please propose any changes/extensions 
> to the QoS NSLP document you feel are necessary.
> 
> Jerry
> 
> > 
> > Best Regards,
> > Georgios
> > 
> > 
> processing 
> > > >rules of the QoS NSLP (defined in section 5.2).
> > > >>"RMF/QOSMs cannot change the semantics and thus the 
> state machine 
> > > >>of the underlying QoS NSLP and GIST (a standards track 
> document is 
> > > >>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
> > > >>the second sentence is opening the door for extending it.
> > > >>
> > > >>underlying QoS NSLP and GIST. (A standards track document is 
> > > >>required for doing so).
> > > >>affect the QoS- NSLP state machine." is not very clear 
> to readers. 
> > > >>Yes, it affects the state machine, but only by giving a 
> reason for 
> > > >>an initial state transition (e.g., send RESERVE).
> > > >>

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Thu, 8 Feb 2007 15:35:47 +0100

Sounds good to me, too. 

Cornelia

> -----Ursprüngliche Nachricht-----
> Von: Martin Stiemerling [mailto:[email-masked]] 
> Gesendet: Mittwoch, 7. Februar 2007 14:57
> An: ASH, GERALD R (JERRY), ATTLABS
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [NSIS] QSPEC2: State machine text part in QSPEC I-D
> 
> I'm fine with this text!
> 
>    Martin
> 
> > standards track in that case), the fallback for QNEs not 
> supporting  
> > that