Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 7 Jul 2006 15:07:26 -0500

Hi Robert,

Many thanks for your detailed and constructive review of the QSPEC
document
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt.

Please see some initial responses below (will provide further responses
later).

Thanks,
Regards,
Jerry 

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Thursday, July 06, 2006 10:44 AM
> To: [email-masked]; Ash, Gerald R (Jerry), ALABS; 
> [email-masked]
> Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt
> 
> hi all,
> 
> some wglc comments. most are minor/editorial-ish.
> 
> in general, i thought i could understand the document and follow what
> it was defining. however, that might be because i am too close to the
> subject matter to see the ambiguities. i wonder whether there might be
> value in having space in an appendix for more examples (not 
> that I have
> anything specific to contribute here).
> 
> 1) section 4.2 p9 para 3 ("When reserving..."): maybe worth clarifying
> here that the terms ingress/egress apply to the direction of 
> the RESERVE
> rather than the direction of the flow. (possibly applies elsewhere.)

OK, good point, will clarify.
 
> 2) para 4 but also elsewhere: i found the formatting confusing in 
> several places where lists get run together like this. for example,
> i can't immediately tell whether the last sentence in the paragraph
> applies to (c) or to (a) and (b) as well.

Good point, will reformat lists to make it clear.
 
> 3) page 11 last para: this seems to assume that there is an 
> INTSERV-QOSM
> whereas in fact none is being defined. 

This is the reference:
   [INTSERV-QOSM] Kappler, C., "A QoS Model for Signaling IntServ
   Controlled-Load Service with NSIS," work in progress.

This QOSM is being defined, but is not yet a WG draft.

> but it raises a more general
> point:
> where in the document to look for a summary of the QOSM 
> concept. To me,
> it would be good to have a (small) dedicated section 
> somewhere near the
> start.

Agreed, the QOSM discussion is spread around the document right now.
We'll provide a summary of the QOSM concept in a separate section, as
you suggest.
 
> 4) page 12 para 3 ("Case 1"): I would prefer to replace phrasing like
> 'the QNx notifies the QNI' with something like 'the QNx generates a
> RESPONSE'. partly this is because in the past there have been genuine
> proposals that a QNx could send a message directly to the QNI, and
> partly
> because notify may get confused with NOTIFY. people who are fully
> familiar
> with the QoS-NSLP spec may be ok with this, but the casual reader may
> not.
> (also applies elsewhere.)

Good point, will rephrase as suggested (where appropriate) to make it
clear.
 
> 5) section 4.4.1: what treatment is required at the QNR? 

The QNR treatment is the same as the behaviors required of the QNEs;
will make that clear.
 
> 6) section 4.5 page 15 2nd last para, also 4.5.3: I found the 
> tunneling 
> description here rather confusing at first, and eventually came to the
> conclusion that I don't like the T flag in the first place. my 
> reasoning is as follows:
> 
> - there are several cases where a QNE has to make a judgment 
> call about
> whether it has strictly interpreted a parameter or not; in the latter
> case it can set the <NON QOSM Hop> flag to say so.
> 
> - i see the tunnel case as just one more example of this, which is not
> really special in its own right.
> 
> - for example, suppose a reservation goes across an MPLS cloud rather
> than an RSVP aggregation cloud. no T flag would be set in the 
> MPLS case
> since it's just 1 hop across (a.k.a. the tunnelling is not visible at
> the IP level). however, do we really believe that the interpretation 
> is any more accurate because of that?

Interesting point that the T-flag has a similar effect as the <NON QOSM
Hop> flag.  However, the latter is not set per-QSPEC-parameter (although
I've proposed a <QSPEC Parameter Remap> flag that would be set
per-QSPEC-parameter that is remapped).  Hannes also suggested that the
T-flag wasn't useful in his review of the document.  

In another discussion of the T-flag, I pointed out that the T-flag could
be used by a QNE to avoid strictly-interpreting or remapping a mandatory
QSPEC parameter.  That is, it could be used to in-effect 'ignore' a
mandatory QSPEC parameter.  However, this would be an abuse of the
mandatory parameter requirement and our thought is to disallow this in
the document ("MUST NOT").

It would be good to have other views on the T-flag parameter (see
Section 4.5.3).
 
> 7) section 4.6 last para: i remember this point came up at the last
> IETF and I still hold the view that it would be more sensible for this
> information about Qspec-related codepoints to be in the Qspec 
> document.
> (this information isn't in any case in the extensibility document at
> the moment.)

Can you point us to what "QSPEC-related codepoints" you're referring to
here?
 
> 8) section 5.2.1: i think the grammar of this section could be more
> clear about whether the sets of objects on the right hand side of '='
> are alternatives, things you can have >1 of, options, etc.

Agreed, will clarify.
 
> 9) section 5.2.2, all references to 'queuing delay bound': the
> discussion
> seems to imply that this parameter can be carried in the Qspec
> independently
> of PL, but I don't see how. (two occurrences in this section.)

I think the 'queuing delay bound' language crept in from a cut&paste
artifact.  IMO these references can be removed.
 
> 10) section 5.2.2: there is no discussion of <Path PER>

OK, will add discussion on <Path PER>.
 
> 11) section 5.2.2: there are multiple references to the QNR 
> having to do
> something for the egress link for the cumulative parameters. I don't
> see what this could mean.

I'm not sure what is unclear in the references to QNR actions.  E.g.,
for jitter is says:

" Each QNE MUST add the jitter of its outgoing link, which
   includes the QNR adding the associated jitter for the egress link.
   Furthermore, the QNI MUST add the jitter of the ingress link."

Any suggestions on how to make this clearer?
 
> 12) section 7.1: box diagram says 'Parameter ID' but text says
> 'Parameter Type'
> 
> 13) section 7.2.7: i don't see how to relate the multiple priority 
> parameters. What if someone provides both the rfc3181 parameters
> and the admission/RPH parameters?

This is an interesting comment.  IMO a QNI/QOSM would specify either to
populate in the Initiator QSPEC:

A) <Preemption Priority> & <Defending Priority> 
Or
B) <Admission Priority> & <RPH Priority>

But not both.

Normally both A) and B) would *not* be specified together, and I agree
that it would be unclear how they would get treated together.  IMO the
document should say that A) and B) above MUST NOT be specified together.
 
> 14) section 7.2.8/9/10/11: if N is set in these parameters when 
> a QNE receives the message, does it still have to process the
> parameter value?

Interesting question.  The 'N flag' means that a QSPEC parameter is not
supported.  If a QNE in the path doesn't support <Path Latency> and sets
the N flag, then perhaps downstream QNEs should then ignore the <Path
Latency> parameter.  Alternatively, all QNEs that support the parameter
should update it, even if the N flag is set.  However, the presence of
the N flag will make the cumulative value unreliable, and the QNI/QNR
decides whether or not to accept the reservation with the N-flag set.  I
would support the latter alternative.  It would be good to hear other
opinions on this point.
 
> 15) section 7.2.9: if Y.1541 is needed to define the composition
> function,
> it should be a normative reference, and should be referred to from 
> 7.2.8 and 7.2.10 as well. OTOH since it is not freely available, would
> it be possible to include the corresponding formulae here?

Y.1541 should be normative (this comment has been made before, and
applies to all RFCs/standards that are normative to supporting the QSPEC
parameters).  IMO Y.1541 is 'freely available', since anyone can
download is for free from the ITU-T web-site.  I would not like to be
putting in a lot formulae here if it can be avoided by making the right
normative references.
 
> 16) section 7.2.10/11: i assume the comments about microsecond time
> resolution are cut&paste artifacts.

You're right that these are cut&paste artifacts.  IMO it is OK to delete
these references.

Thanks again,
Jerry

> 
> cheers,
> 
> robert h.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > Sent: 26 June 2006 11:31
> > To: [email-masked]; [email-masked]
> > Subject: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt
> > 
> > 
> > Hi all,
> > 
> > Jerry has submitted the QoS NSLP QSPEC Template.  You can find the
> > announcement & Jerry's comments below.
> > 
> > The WGLC will run until July 7th.  After that, Jerry can 
> summarize all
> > issues and we will discuss them at the next IETF meeting in 
> Montreal.
> > 
> > thanks,
> > John 
> > 
> > >-----Original Message-----
> > >From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> > >Sent: 23 June, 2006 23:16
> > >To: [email-masked]
> > >Cc: Ash, Gerald R (Jerry), ALABS
> > >Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt 
> > >
> > >Hi All,
> > >
> > >The updated 'QoS-NSLP QSPEC Template' I-D is available at 
> > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt.
> > >
> > >The updates are in response to comments and discussion 
> since IETF-65:
> > >
> > >1. rewrote Section 2 (Introduction) for clarity 2. added 
> > >clarifications on mandatory parameters in Section 4.2; added 
> > >discussion of forwarding options when a domain supports a 
> > >different QOSM than the QNI 3. expanded Section 4.5 on error 
> > >code handling, including redefined E-Flag and editorial 
> > >changes to the N-Flag and T-Flag discussions 4. made some 
> > >editorial clarifications in Section 4.6 on defining new 
> > >mandatory parameters 5. Section 4.7 added to identify what a 
> > >QOSM specification document must include 6. clarified the 
> > >requirements in Section 5 for defining a new QSPEC Version 7. 
> > >made editorial changes to Section 6 (Procedures), and added 
> > >procedures for handling preemption 8. removed QOSM ID 
> > >assignments in Section 9 (IANA Considerations); clarified 
> > >procedures for defining new mandatory parameters; added 
> > >registry for QOSM error codes
> > >
> > >There are no further outstanding changes/comments pending and 
> > >no open issues currently identified.
> > >
> > >Thanks,
> > >Regards,
> > >Jerry 
> > >
> > >-----Original Message-----
> > >From: [email-masked] [mailto:[email-masked]]
> > >Sent: Friday, June 23, 2006 3:50 PM
> > >To: [email-masked]
> > >Cc: [email-masked]
> > >Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt 
> > >
> > >A New Internet-Draft is available from the on-line 
> > >Internet-Drafts directories.
> > >This draft is a work item of the Next Steps in Signaling 
> > >Working Group of the IETF.
> > >
> > >	Title		: QoS NSLP QSPEC Template
> > >	Author(s)	: J. Ash, et al.
> > >	Filename	: draft-ietf-nsis-qspec-10.txt
> > >	Pages		: 53
> > >	Date		: 2006-6-23
> > >	
> > >The QoS NSLP protocol is used to signal QoS reservations and 
> > >is independent of a specific QoS model (QOSM) such as IntServ 
> > >or DiffServ.  Rather, all information specific to a QOSM is 
> > >encapsulated in a separate object, the QSPEC.  This document 
> > >defines a template for the QSPEC, which contains both the QoS 
> > >description and QSPEC control information. The QSPEC format is 
> > >defined, as are a number of QSPEC parameters.  The QSPEC 
> > >parameters provide a common language to be re-used in several 
> > >QOSMs.  To a certain extent QSPEC parameters ensure 
> > >interoperability of QOSMs.  Optional QSPEC parameters aim to 
> > >ensure the extensibility of QoS NSLP to other QOSMs in the future.
> > >The node initiating the NSIS signaling adds an Initiator QSPEC 
> > >that must not be removed, thereby ensuring the intention of 
> > >the NSIS initiator is preserved along the signaling path.
> > >
> > >A URL for this Internet-Draft is:
> > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 8 Jul 2006 06:19:16 +0200 (MEST)

Hi Jerry, Cornelia and Attila

I have a comment on Section 6.1 of the QSpec template draft that may also
apply to Section 6.2.

In the last paragraph of the section you say:
"Regarding Control Information, the rule is that all parameters that
have been included in the RESERVE message by the QNI MUST also be
included in the RESPONSE message by the QNR with the value they had when
arriving at the QNR."

Note that for the Control Information defined by a QOSM this rule may be
overruled, since the QOSM defines how the control information should be
used by the domain that supports this QOSM. Therefore, I would very much
appreciate if you could modify the paragraph to allow this possibility.
A possible modifiation could be:

"Regarding Control Information, the default rule is that all parameters
that have been included in the RESERVE message by the QNI are also
included in the RESPONSE message by the QNR with the value they had when
arriving at the QNR. However, regarding the QOSM specific Control
Information, a QOSM may specify its own processing rules."

Please note that the same comment applies to Section 6.2.

Best Regards,
Georgios

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 10 Jul 2006 16:28:41 -0500

Hi Georgios,

See below. 

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Saturday, July 08, 2006 12:19 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [NSIS] comment on draft-ietf-nsis-qspec-10.txt
> 
> A possible modification could be:
> 

We agree that your suggested change is OK.

Thanks,
Jerry

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 11 Jul 2006 12:57:50 -0400

hi jerry,

some comments on some of the comments:

> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 

> > From: Hancock, Robert [mailto:[email-masked]] 

[snip]

> This QOSM is being defined, but is not yet a WG draft.

true - but it's not an INTSERV QoSM but a CL QoSM only (and 
only for 'pure' CL, not CL/Diffserv or CL/PCN). hence the follow
up question about 'what is a QoSM'. someone reading the text might
get the impression that there is a single QoSM that covers both
CL and GS.

[snip]

> Can you point us to what "QSPEC-related codepoints" you're 
> referring to here?

the paragraph in question is
"   Guidelines on the technical criteria to be followed in evaluating
   requests for new codepoint assignments are given for the overall NSIS
   protocol suite in a separate NSIS  extensibility document
   [NSIS-EXTENSIBILITY]."

This applies to all NSIS codepoints. My point is that it still seems 
preferable (to me) that Qspec related codepoints - i.e. the registries
you define in section 9 - should have the guidelines in the qspec itself.

> Any suggestions on how to make this clearer?

maybe if i understood it...

take the trivial situation of a single link:

QNI ----------- QNR

the draft says (here for jitter): 
  "Each QNE MUST add the jitter of its outgoing link, which
   includes the QNR adding the associated jitter for the egress link. 
   Furthermore, the QNI MUST add the jitter of the ingress link."

my question is, how many contributions to the e2e jitter are there?
i would have thought that for a single link the expression would be
a single term, but the draft implies two terms (one from QNI and one
from QNR). but adding one more link would add only one term. i don't
see how this would work.

[snip]

cheers,

r.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 11 Jul 2006 23:12:19 +0200 (MEST)

I have some additional comments on QSpec template draft:

* Use of X (Exclude) flag for each mandatory QoS parameter to show that a
mandatory parameter
cannot be interpreted.
I like the way of how the notification of not interpreting the
optional parameters is encoded in each QSpec parameter. This is
accomplished
by using the "N" (not supported) flag. It will be good (necessary) to
have a
similar flag for the mandatory parameters, which notifies that a
mandatory parameter
could not be interpreted. Currently, this is done by only one parameter
(<NON QOSM Hop>
parameter. In this case if the QNI receives the <NON QOSM Hop> parameter
set it will
not know which of the mandatory parameters where not interpreted.
Furthermore, note that when at least one manadory parameter cannot be
interpreted,
and when the <NON QOSM Hop> parameter is used to notify this,
then this situation can be considered to be identical with the situation
that the QNE is NSIS unaware and that is definetely not the case.
In this way and probably always the QNI will reject and release the
successful reservation.
If we use a flag like the N flag, say X flag (note that this should be
different
than the N flag), within each mandatory QSpec parameter
then detailed information can be sent to the QNI, which is related to
which mandatory parameters
could not be interpreted. Therefore, the QNI could then more easily
decide when to release
or accept a succesful reservation.

* If X flag is used then, we might not need to have the T flag. This is
because
when the X flag is used, for each QSpec parameter, information can be
sent to QNI
to inform it if the QSpec parameter could be interpreted by a node or by
a domain.
Thus if a mandatory parameter is tuneled and only used by edges then the
X flag parameter for this
parameter can be set.

* Use of D flag for each QSpec mandatory parameter to show that a
mandatory
parameter has been downgraded.

Note that the following paragraph in QSpec template, actually says that
if a QNI uses Token Bucket
as <Traffic Description> and a QOSM remaps the Token Bucket to Bandwidth,
then this is identical
on saying that the QOSM is NSIS unaware and that is definetely not the
case.

   "In the latter case, the remapping of the <Token Bucket> to
   <Bandwidth> must be specified in the QOSM specification document.
   For example, QOSM X exclusively uses the parameter <Bandwidth>. It
   must define a mapping of the mandatory parameter <Token Bucket>.
   The mapping consists of interpreting the Token Bucket Rate as
   the <Bandwidth> parameter and disregarding the other Token Bucket
   parameters. Clearly, some information contained in the <Token
   Bucket> parameter is lost by this mapping, and the resulting QoS may
   not be quite what was intended by the QNI. Therefore, QOSM X also
   specifies that the <NON QOSM HOP> flag be raised."

Thus, in this case if the QNI receives the <NON QOSM Hop>
parameter being set, it will not know which of the mandatory
parameters where downgraded or not interpreted. In this way
and probably always the QNI will reject and release the successful
reservation.
If we use the D flag within each mandatory QSpec parameter
then the detailed information can be sent to the QNI, which is
related to exactly the mandatory parameters that were indeed downgraded.
Therefore, the QNI could then more easily
decide when to release or accept a succesful reservation.

Best Regards,
Georgios

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 11 Jul 2006 17:15:43 -0500

Hi Georgios,

See below. 

> Sent: Tuesday, July 11, 2006 5:12 PM
> To: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: additional comments on draft-ietf-nsis-qspec-10.txt
> 
> 
> could not be interpreted. 

As you know, the QSPEC draft requires that mandatory parameters MUST be
interpreted, which means that they are either a) strictly interpreted
according to referenced specifications, or b) remapped, as specified in
a QOSM specification document.

> Currently, this is done by only one 
> parameter
> (<NON QOSM Hop>
> parameter. 

To the contrary, the <NON QOSM Hop> flag only indicates that a) a QNE
supports another local QOSM different from the Initiator QOSM, and b)
some mandatory parameters may have been remapped according to what is
specified by local QOSM specification document.  However, in this
scenario, all mandatory parameters in the Initiator QSPEC still MUST be
interpreted, as specified above (this will normally be done by the
egress QNE in the local domain).

> In this case if the QNI receives the <NON QOSM 
> Hop> parameter
> set it will

As above, all mandatory parameters MUST be interpreted.  However,
currently it is unknown which, if any, mandatory QSPEC parameters have
been remapped.  I've proposed that an R-flag ('remapped flag') be
created per QSPEC parameter to indicate which parameters are remapped
(if any) by a local QOSM.

> Furthermore, note that when at least one mandatory parameter cannot be
> interpreted,
> that the QNE is NSIS unaware and that is definitely not the case.
> or accept a successful reservation.

Again, all mandatory parameters MUST be interpreted.  If your proposed
X-flag is the same as the R-flag (remapped flag) mentioned above, then I
agree that would be useful.  However, if the X-flag means that a
mandatory parameter is not interpreted (i.e., ignored), then that is not
allowed by the QSPEC specification.
 
> Thus if a mandatory parameter is tunneled and only used by 
> edges then the

The T-flag is only intended to indicate that a mandatory parameter in
the initiator QSPEC may not be accurately interpreted if it is tunneled
through a domain.  However, the egress QNE in a local domain MUST still
interpret all mandatory parameters in the initiatory QSPEC.  In
addition, the egress QNE in the local domain MUST NOT use the T-flag to
ignore a mandatory parameter (that needs to be clarified in the QSPEC
document).
 
> on saying that the QOSM is NSIS unaware and that is definitely not the
> case.
> 
> decide when to release or accept a successful reservation.

You proposed D-flag looks the same as the R-flag (remapped flag) I
mentioned above.  In that case, I agree that the D-flag/R-flag would be
useful.

Thanks,
Jerry

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 11 Jul 2006 18:11:43 -0500

Hi Robert,

See below. 

> From: Robert Hancock [mailto:[email-masked]] 
> Sent: Tuesday, July 11, 2006 12:58 PM
> To: Ash, Gerald R (Jerry), ALABS; 'NSIS'

OK, we can change the reference to [CL-QOSM].
 
> you define in section 9 - should have the guidelines in the 

OK.  Do you have any suggested guidelines or pointer to guidelines that
should be included in the QSPEC document?
 
> from QNR). but adding one more link would add only one term. i don't

I think you picked up a problem with the text that I hadn't noticed
before:

  "Each QNE MUST add the jitter/delay of its outgoing link, which
   includes the QNR adding the associated jitter/delay for the egress
link. 
   Furthermore, the QNI MUST add the jitter/delay of the ingress link."

Should say:

  "Each QNE MUST add the jitter/delay of its outgoing link (if it
exists).
   Furthermore, the QNI MUST add the jitter/delay of the ingress link
   (if it exists)."

The diagram we had in mind for your 'single link trivial situation' is a
follows:

    a                b               c
----------- QNI ----------- QNR -----------

The QNI adds the jitter/delay of links a and b (if it exists), and the
QNR adds the jitter/delay of link c (if it exists).  If link a and/or
link c do not exist, then the delay/jitter is not included of course in
the cumulative value.

Thanks,
Regards,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 12 Jul 2006 01:19:04 +0200 (MEST)

Hi Jerry

Please note that I think that the semantic of X flag might be not clear!
What I meant by the X flag is to include it in each mandatory parameter
and use it in the same way as the N flag is used for the optional
parameters.
Thus not excluding the processing of any mandatory parameter.
 * Therefore, I think that the X flag (you may call it differently) I
think taht it is needed.

* Regarding the R flag, yes it is similar to the R flag that you
mentioned.

* I do not have any objection on also keeping the T flag.

* Regarding the <Non QoSM Hop> parameter, I think that it must only be
set if a non NSIS aware received the RESERVE message. In all other cases
this parameter must not be set.
When a mandatory parameter is downgraded then the R flag is set, but the
<Non QOSM Hop> parameter must remein unset (if it was unset).

Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 13 Jul 2006 15:20:29 +0200 (MEST)

The Qspec template draft does not describe how a non QOSM aware hop can
be detected. I think that a similar solution as followed by RSVP should
be followed, see text from RFC2205:
"RSVP must also test for the presence of non-RSVP hops in the path
      and pass this information to traffic control. From this flag bit
      that the RSVP process supplies and from its own local knowledge,
      traffic control can detect the presence of a hop in the path that
      is not capable of QoS control, and it passes this information to
      the receivers in Adspecs [RFC 2210].

      With normal IP forwarding, RSVP can detect a non-RSVP hop by
      comparing the IP TTL with which a Path message is sent to the TTL
      with which it is received; for this purpose, the transmission TTL
      is placed in the common header. However, the TTL is not always a
      reliable indicator of non-RSVP hops, and other means must
      sometimes be used. For example, if the routing protocol uses IP
      encapsulating tunnels, then the routing protocol must inform RSVP
      when non-RSVP hops are included. If no automatic mechanism will
      work, manual configuration will be required."

The same way must be used by the QSPEC template draft!

Best Regards,
Georgios

---

From: Andrew McDonald <[email-masked]>
Date: Thu, 13 Jul 2006 14:48:45 +0100

Hi Georgios,

I've also been thinking about this one over the last few days. I think 
the problem is about QoS NSLP unaware hops (which includes GIST-unaware 
hops), rather than what is referred to in the QSpec draft as a "non QOSM 
hop".

There are two parts to this problem:
a) identifying that a non QoS NSLP hop exists
b) signalling this end-to-end

The core part of (a) is covered by GIST, by providing TTL information 
over the API. I'm not sure what special things (if anything) we need to 
do to handle tunnels. If we need something here then it probably needs 
to go in the QoS NSLP document.

In previous versions of the QSpec draft I had interpreted the <NON QOSM 
HOP> flag as providing the functionality necessary for (b). However, 
following further clarifications of the document I now think this isn't 
the case. A separate flag may, therefore, be needed.

regards,

Andrew

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 13 Jul 2006 15:54:15 +0200 (MEST)

Hi Andrew

Yes I agree with your remarks!
I also thought that the <NON QOSM
HOP> flag as providing the functionality necessary for (b), but this is
not the case. Regarding where this should be handled, I am not sure of!
Anyway the current semantics of the Non QoSm Hop parameter in the QSepc
template is wrong and it has to be changed!

Best Regards,
Georgios

---

From: Andrew McDonald <[email-masked]>
Date: Thu, 13 Jul 2006 15:00:07 +0100

> template is wrong and it has to be changed!

Is it wrong, or is it just doing a different job?
i.e. does the definition of <NON QOSM HOP> need to change, or is a 
separate flag needed?

My perception was that a new flag was needed.

regards,
Andrew

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 13 Jul 2006 16:07:20 +0200 (MEST)

Hi Andy

The only useful functionality of this NON QOSM Hop parameter is to
emphasi\e that a node has been passed that was not able to process the
QOSM QSpec or the QoS-NSLP message.
In order to show if some parameters are downgraded or not interpreted
additional flags can be used, such as:
N flag: shows that an optional parameter could not be interpreted
M flag (not yet available): shows that a mandatory parameter could not be
interpreted
R flag (not yet available): shows that a parameter has been downgraded
T flag: shows that a parameter has been tunelled.

Based on the above information a QNI will be able to make the right
decission on accepting or rejecting a succesful reservation.

Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 13 Jul 2006 16:52:13 +0200 (MEST)

Hi all

Please note that instead of flag M listed below, I meant flag X:
X flag (not yet available): shows that a mandatory parameter could not be
interpreted

Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 13 Jul 2006 17:09:15 +0200 (MEST)

I do not understand the following sentence in Section 4.5.5:
"The QSpec in the RESPONSE message includes the QSPEC <QoS Reserved>
object with all parameters values set to zero (or equivalent)."

What equivalent means?

I think that Section 6.1 is also unclear  on this point, where it says:
"The parameter types included in QoS Reserved in the RESPONSE MUST be
the same as those in QoS Desired in RESERVE."

Do you here mean parameter values, instead of parameter types?

If so then please include this also in the first cited sentence, see
above!

Best Regards,
Georgios

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Jul 2006 10:56:46 -0400

Hi all,

in a chat with Hui-Lan Lu she pointed me to something that I also 
noticed in my review: It is difficult for a reader to figure out what 
parameters are mandatory.

It would be good to state this more explicitly in the text.

Ciao
Hannes

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 13 Jul 2006 16:28:21 -0500

Hi Andrew, Georgios,

See below. 

> From: Andrew McDonald [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 9:49 AM
> To: Georgios Karagiannis
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: [NSIS] how a non QOSm node can be detected?
> 
> Hi Georgios,
> 

I agree that GIST and QoS NSLP would be the right way to detect problem
a) (i.e., that a non QoS NSLP hop exists in the path).

> the case. A separate flag may, therefore, be needed.

I'm not quite sure what is meant by problem b) above.  Maybe there is
misunderstanding about the <NON QOSM Hop> flag and how/when it is set.
The <NON QOSM Hop> parameter is set whenever a local QOSM different from
the initiator QOSM is encountered.  IMO this is useful for the QNI to
know that a QOSM is encountered in the path that is different from the
initiator QOSM (and that some parameters may have been remapped).  

For example, if the RMD-QOSM is encountered in the path and the
initiator QOSM is the Y.1541-QOSM, then the egress QNE in the local RMD
domain would set the <NON QOSM Hop> flag.  However, if the initiator
QSPEC is RMD and all the QNEs in the path use the RMD-QOSM, then the
<NON QOSM Hop> flag is *not* set.

Again, I think an R-flag (remapped flag) per QSPEC parameter would be
useful to denote that a QSPEC parameter had been remapped by a local
QOSM rather than strictly interpreted.  The <NON QOSM Hop> flag is then
set when the initiator QSPEC (e.g., Y.1541-QOSM) sets the <Token Bucket>
parameter and the egress QNE in the local domain (e.g., RMD-QOSM) remaps
<Token Bucket> to bandwidth (and ignores setting the other parameters in
<Token Bucket>). 

The combination of the <NON QOSM Hop> flag and R-flag provide useful
information for the QNI to decide whether to accept or reject a
reservation.

Thanks,
Regards,
Jerry

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 13 Jul 2006 16:29:32 -0500

Hi Hannes, 

See below.

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 10:57 AM
> To: [email-masked]
> Subject: [NSIS] Indicating Mandatory Parameters
> 
> Hi all,
> 

I agree, this is a good suggestion.

Thanks,
Jerry

---

From: Andrew McDonald <[email-masked]>
Date: Fri, 14 Jul 2006 01:13:31 +0100

Hi Jerry,

> a) (i.e., that a non QoS NSLP hop exists in the path).

Good.

> initiator QOSM (and that some parameters may have been remapped).  

In this case we're not talking about a different QOSM being encountered, 
but a node where no QOSM (no QoS NSLP, no GIST, etc) is available at all.

e.g. the situation where we have:
A -- B -- C
A and C support QoS NSLP (and same QOSM as identified in QSpec)
B doesn't have any NSIS support

My interpretation of the Non QOSM Hop text in the QSpec is that it is 
set if (and only if) QoS NSLP is supported but the QOSM identified in 
the QSpec is not supported. It would not be set in the the case above 
where there are no QOSM 'mismatches' but a non-NSIS hop is identified.

The situations are a bit different since in one case we're identifying 
that the QoS description has been reinterpreted, in the other we're 
identifying that the QoS request hasn't been processed at all.

Does that make sense?

regards,

Andrew

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 13 Jul 2006 23:39:46 -0500

Hi Andrew,

Please see below. 

> Sent: Thursday, July 13, 2006 8:14 PM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: Georgios Karagiannis; [email-masked]
> the QSpec is not supported. 

Yes, exactly.

> It would not be set in the case above 

Agreed.  Also, I'm not sure how node B could set the <NON QOSM Hop> flag
anyway, since it does not support QoS NSLP/QSPEC.  So other methods of
detecting this situation are need in GIST and QoS NSLP, as you point
out.
 
> identifying that the QoS request hasn't been processed at all.

Yes, it makes perfect sense.

Thanks,
Regards,
Jerry

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 14 Jul 2006 16:10:17 +0300 (EEST)

Hi,

so what does this mean for the QoS NSLP? Is there a need to change text 
somewhere? If so, please provide the text that is needed, and indicate the 
place for it.

Jukka

---

From: Andrew McDonald <[email-masked]>
Date: Fri, 14 Jul 2006 14:22:31 +0100

Hi Jerry,

> detecting this situation are need in GIST and QoS NSLP, as you point

Ah, I see the possible confusion. I'm not expecting B to set a flag - 
I'm expecting C to do it.

Information is available at C from the GIST layer about the number of IP 
hops between A and C. C can use this to determine that it is not 
adjacent to B and so set a flag.

regards,

Andrew

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 14 Jul 2006 16:50:00 +0200 (MEST)

Hi Andrew and Jerry

Yes, I agree with Andrew's opinion on this.
Therefore, I think that the best way is to leave the definition of
<NON QOSM Hop> as is defined now and then define a new flag in the QSepc
template or QoS-NSLP to emphasize when a node in the path did not
process the QOS-NSLP/QOSM information.

Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Jul 2006 12:33:48 +0200 (MEST)

Hi all

If we include an additional flag into the QOS-NSLP draft to show that a
non QoS-NSLP Hop, say "Non QoS-NSLP Hop", has been passed during the
end-to-end path followed by a RESERVE, then regarding the QSpec
template, I agree to:

* add the R bit flag proposed by Jerry, where each parameter will carry
such a flag and it will be used in the situation that a parameter,
mandatory or optional is downgraded.
* use the "Non QOSM Hop" flag as currently used!
* use the T flag as currently used
* use of N flag as currently used
* use of E flag as currently used
* try to use as less as possible mandatory parameters

Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 31 Jul 2006 16:02:41 +0200 (MEST)

Hi Jerry, Cornelia, Attila

At the moment I am on holidays!
Some time ago I have sent the below e-mail, but I have not received any
reply!

Please comment on the below e-mail!

Best Regards,
Georgios