Subject: [NSIS] Update on the QoS NSLP work

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 7 Dec 2005 20:34:08 +0200 (EET)

Hi all,

Georgios, Andrew and I have worked on the QoS NSLP since the Vancouver
meeting. The document is close to being finalized. The main issue left is
a sanity check on whether and how mobility really works with the QoS NSLP.
Apart from that, we should be done.

A diff of the current version against -08 is available at:

http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-08-09.html

All feedback is always appreciated.

Regards,
Jukka

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

---

From: Roland Bless <[email-masked]>
Date: Thu, 08 Dec 2005 17:58:30 +0100

> Apart from that, we should be done.

We slightly disagree here ;-)

> All feedback is always appreciated.
Thanks for the new version, but I guess we have still some more
open issues:
----------------------------------
5.4.1.  RESERVE Messages
   ....

   When a QNE receives a RESERVE message with an unknown SESSION_ID, it
   MAY send a NOTIFY message to its upstream peer, indicating the
   unknown SESSION_ID. If the message was meant as a refresh, the reply
   indicates a downstream route change to the upstream peer.  The
   upstream peer SHOULD send a complete RESERVE on the new path (new
   SII).  It identifies the old signalling association (old SII) and MAY
   start sending complete RESERVE messages for other SESSION_IDs linked
   to this association.

We find this paragraph a little bit strange:
- the paragraph contradicts with sec 5.4.4:
  NOTIFY message do do not directly cause other messages to
  be sent. NOTIFY messages are sent asynchronously, rather than in
  response to other messages.
- the purpose of this mechanism is not getting totally clear:
  if it's only for the case of reduced refreshes along a
  new path (i.e. QSPEC is missing) then we would propose
  to sent rather a RESPONSE with an appropriate error code
  in order to trigger resending a RESERVE with a full QSPEC
  (this would be more consistent with the NOTIFY definition
  in 5.4.4).
  Are there other useful benefits of this proposed NOTIFY?
  Otherwise even every intial RESERVE would cause such a
  NOTIFY to be sent by all QNEs.
- How far should one forward the NOTIFY message?
  Only one hop? (this is generally not very clear)
  What about the use of the scoping flag (currently not used)?
- "If the message was meant as a refresh, the reply..."
  What reply? do you mean the NOTIFY?

------------------------------------------

5.4.1
   If the SCOPING flag is set, or if the QNE is the last QNE on the path
   to the destination, the QNE MUST send a RESPONSE message.

- "is the last QNE on the path to the destination" (isn't this the QNR?)
- if neither ACK nor SCOPING are set and no RII is present
  why MUST (only?) the last QNE generate a RESPONSE?
- we think that a RESPONSE is either triggered by an
  ACK or an RII or an error.

---------------------------------------------

PACKET_CLASSIFIER:
- is it really necessary to specify the PACKET_CLASSIFIER
  even for reduced refreshes?
- Is the value of the MRM exactly the same as in GISTs MRI?
  What should be done in case of a mismatch?

-----------------------------------------------
5.4.3.  RESPONSE Messages
   .....

   In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE
   flag is set or when an error occurs while processing a received
   message.  If the received message contains an RII object, this object
   MUST be put in the RESPONSE, as described above.

- We think that the last sentence should only be true in case
  of an error, but not when an ACK flag is set. In this case
  a RESPONSE should not include the RII (this RESPONSE will usually
  follow from the last QNE later) but the RSN.

That's it for now, possibly more issues later...

P.S.: would be nice if you could include also Markus Ott in the
      Acknowledgments :-)

---

From: [email-masked]
Date: Mon, 12 Dec 2005 14:39:39 +0200

Jukka,

There's been quite a few comments on this current draft. I was thinking
that
a quick rev then a WGLC on this & the QSPEC draft in the new year might
be
a good way to start 2006.

Thoughts?
John 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Jukka MJ Manner
>Sent: 07 December, 2005 20:34
>To: [email-masked]
>Subject: [NSIS] Update on the QoS NSLP work
>
>
>Hi all,
>
>Georgios, Andrew and I have worked on the QoS NSLP since the 
>Vancouver meeting. The document is close to being finalized. 
>The main issue left is a sanity check on whether and how 
>mobility really works with the QoS NSLP.

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 12 Dec 2005 15:02:42 +0200 (EET)

Hi,

The comments from Roland are being dealt with as we speak, and Jerry had a
few simple comments about references. Has there been other comments?

I would like people to comment now on my current editor's version. I
could, e.g., submit an official new version next week, or after Christmas,
and we could start a WGLC in early January, sure.

Regards,
Jukka

---

From: [email-masked]
Date: Mon, 12 Dec 2005 15:06:20 +0200

Jukka,

>The comments from Roland are being dealt with as we speak, and 
>Jerry had a few simple comments about references. Has there 
>been other comments?
>
>I would like people to comment now on my current editor's 
>version. I could, e.g., submit an official new version next 
>week, or after Christmas, and we could start a WGLC in early 
>January, sure.

Sorry, drop the 'quite' and leave 'a few comments.' Anyhow,
if folks could send in comments, so that Jukka could do
an update in early January for WGLC.

thanks,
JOhn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 14 Dec 2005 15:02:46 +0100

Hi Roland

I will provide some observations only on the latter four of your
comments. We will provide observations on the first comment later on!

-//-  snip

Georgios:
I think that here, the last node can be either the QNR, but it could also be
a node that is configured to be the last node, which is not the QNR, e.g., a
boundary of a
domain. I think that only this last node SHOULD send the RESPONSE,
due to the fact that we are also using scoping by configuration, where the
SCOPING flag does
not have to be set!

Georgios:
About using the PACKET_CLASSIFIER for reduced refreshes, why should we not 
use it?
Regarding the MRM, I think taht it should be exactly the same as the GIST 
MRI, since the
QOS-NSLP processing must use the GIST MRI at each node.
However, if this is not the same, then the additional paramaters have to be 
included in
the PACKET_CLASSIFIER object.

>  follow from the last QNE later) but the RSN.

Georgios:
I think that I agree with your proposal!
Other thoughts?

> P.S.: would be nice if you could include also Markus Ott in the

Georgios: It think that it will be good to do that!

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 14 Dec 2005 15:21:26 +0100

Hi Roland

-//-  snip

Georgios:

Georgios:

Georgios:

Best regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Mon, 19 Dec 2005 23:28:26 +0100

Hi Georgios,
> due to the fact that we are also using scoping by configuration, where the

Hmm. this sounds like a special configuration that you have in mind.
Your proposed behavior would IMHO contradict with the default behavior
when an RII is set... Nevertheless this paragraph needs clarification.

> About using the PACKET_CLASSIFIER for reduced refreshes, why should we
> not use it?

Because it will not change and is thus redundant.

> Regarding the MRM, I think taht it should be exactly the same as the
> GIST MRI, since the
> However, if this is not the same, then the additional paramaters have to
> be included in

Does this really make sense? Any examples or other opinions?

> I think that I agree with your proposal!

Yep, more input?

Regards,
 Roland.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 20 Dec 2005 10:06:34 +0100

Hi Roland

----- Original Message ----- 
From: "Roland Bless" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>
Cc: "Jukka MJ Manner" <[email-masked]>; <[email-masked]>
Sent: Monday, December 19, 2005 11:28 PM
Subject: Re: [NSIS] Update on the QoS NSLP work

> when an RII is set... Nevertheless this paragraph needs clarification.

Georgios: Thanks, we will do that!

> Roland: Because it will not change and is thus redundant.

Georgios: I think that you are right!
Other thoughts

> Does this really make sense? Any examples or other opinions?
Georgios: Othre thoughts?

>> I think that I agree with your proposal!

Georgios: Other thoughts?

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 20 Dec 2005 11:22:42 +0200 (EET)

Hi boys,

two comments:

a) Roland, if you think the paragraph in 5.4.1 needs to be more clear, 
would you send us the proposed text, eg. "switch paragraph X with the 
following".

b) I couldn't find the text where it says that a reduced refresh must
include the PACKET_CLASSIFIER. At least I have not added such text
explicitly, as to me leaving out the PACKET_CLASSIFIER, or at least, leave
it as optional in reduced refreshes, is the way to go.

In general, I would really appreciate that if people send 
comments/questions about unclear/wierd parts of basically any I-D, they 
would also send the proposed text that fixes the problem. Thanks.

Cheers,
Jukka

---

From: Andrew McDonald <[email-masked]>
Date: Tue, 20 Dec 2005 10:13:17 +0000

Hi Roland,

There may have been some logic to this when it was written, but I can't 
work out what it might have been. Changing this to a RESPONSE message 
seems reasonable to me.

I'm not sure whether it might also be worth noting that the NSLP may 
notify the GIST layer using the InvalidateRoutingState, though this is a 
node-internal action.

regards,

Andrew

---

From: Andrew McDonald <[email-masked]>
Date: Tue, 20 Dec 2005 10:35:50 +0000

> due to the fact that we are also using scoping by configuration, where the

I find that statement a bit confusing. The last node (signalling 
endpoint) is the QNR by definition, but the QNR is not necessarily the 
flow endpoint (receiver/sender). See definitions in section 2, and fig 2 
in particular.

Andrew

---

From: Roland Bless <[email-masked]>
Date: Wed, 21 Dec 2005 13:23:02 +0100

Hi Jukka
> would you send us the proposed text, eg. "switch paragraph X with the 

I thought it would be good to hear the reasons why the text was
included. Georgious gave some hints.

> it as optional in reduced refreshes, is the way to go.

I gues that there is no such text, but:
it stems from the inconsistency between the definition
of RESERVE messages in 5.1.2.1. and 5.4.1. In the latter section
PACKET_CLASSIFIER is not optional so one cannot leave it out for
refreshes.

5.1.2.1.  RESERVE

   The format of a RESERVE message is as follows:

   RESERVE = COMMON_HEADER
             RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
             [ POLICY_DATA ] *2QSPEC

5.4.1

   RESERVE = COMMON_HEADER
             RSN PACKET_CLASSIFIER [ RII ]
             [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
             [ POLICY_DATA ] *2QSPEC

I suggest to check the other copies of the format in section 5.4 as
well.

> would also send the proposed text that fixes the problem. Thanks.

We'll do that. However, we thought it would be good to hear
any reasons why certain features are included instead of simply
omitting things.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 21 Dec 2005 19:01:48 +0200 (EET)

Hi boys,

I'll try to fix the question b. I'll let Georgios think about the question
a.

Cheers,
Jukka