Subject: [NSIS] Re: qos-nslp-00

From: [email-masked]
Date: Wed, 24 Sep 2003 08:55:38 +0200

Hi Ruediger,

Thanks for your comments. I have tried to address them inline.

Cheers,
Sven

"Geib, Ruediger" <[email-masked]> on 23/09/2003 15:08:55

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:    [email-masked]
Subject:    qos-nslp-00

Hi Sven,

Chapter 7 tells the reader that the draft-nsis-qos-nslp-00 is rather drafty
yet. Some issues I've identified:

- The rather flexible NSLP defined by the document
  more seems to be a generic NSLP than a QoS NSLP.

Sven>> I would rather say it is intended to be a QoS NSLP that is flexible
  enough to support different QoS architectures. We have chosen to decouple
  the QoS NSLP machinery from the underlying QoS model that is being
  signaled for. For this reason, all QoS model related parameters will be
  carried in the QSpec.

- Chapter 7.1 misses "security" as a refinement
  required for this version. I doubt it's a good
  idea to define a protocol and worry about
  security afterwards.

Sven>> We are very concerned about security (note that Hannes is also
  involved ;-) ). In fact, we have two security sections; one will cover
  security components (NSLP-specific security measures, e.g. to protect QoS
  NSLP objects), the other will cover the security solution more in
  general, taking into account what is available from the NTLP. Obviously,
  we can't write that section just yet but note that there are references
  to some drafts that contain discussion on this and that we will include
  the outcome of these discussions.

- Retransmitted "Reservation Sequence Numbers"
  serve as a Session ID. Why aren't
  the tradeoffs and benefits of combining both
  functions discussed?

Sven>> We took special care not to use the RSN for anything else but
  ensuring that QoS NSLP message reordering could be detected. They have
  nothing to do with any session ID at the NTLP. Afaik, it is an open issue
  how NTLP sessions will relate to NSLP message exchanges. Also note that
  the RSN has local significance only. It is not end-to-end unique.

- A table listing the maximum per session state
  maintenance requirements is missing.

Sven>> I think it is a bit early for that. I am not completely sure what
  you mean: an analysis of the maximum amount of reservation state
  associated with a QoS reservation maybe? That might depend on the QoS
  model though.

- Error messages don't remove state but they may
  trigger state removal (see 4.5). Besides an
  notify message, a Reservation/Tear may travel
  in parallel. What's the benefit of this solution?

Sven>> We chose to let every QNE consider his immediate neighbour as the
  requestor of the reservation. The requestor of the reservation is the one
  that is allowed to tear it down. Therefore, tearing RESERVEs travel in
  one direction (say 'downstream'). The QNE that initiates the tearing
  RESERVE indicates the fact that it is tearing down to its requestor (say
  'upstream'). This QNE then has to decide for itself whether it wants to
  tear down its state as well and whether it wants to notify its upstream
  neighbour.

- 2.7 and 6.2 seem to specify NTLP functionalities.

Sven>> You are certainly right about 6.2. In fact the whole section states
requirements/desires we have for the NTLP and is meant as input for the
NTLP design. Section 2.7 introduces the fact that some QoS models supported
by the QoS NSLP might not keep (per-flow) state. This operation makes most
sense when the NTLP is able to . It makes the most sense when the NTLP is
able to make use of the fact that e.g. the QoS NSLP will never use reverse
path state. This is explained in section 6.1

A general comment (not related to this draft):
The Interface between NTLP and NSLP doesn't seem to be defined well. NSLP
may need some IP and local topology information (e.g. incoming and outgoing
IF). It should be clearly defined where it gets it from.

Sven>> Section 6 is an effort in this direction. It states requirement for
the NTLP in this version but we assume it will evolve to a description of
the interface between the two once NTLP becomes more clear.

Regards, Rüdiger

Rüdiger Geib
T-Systems
Systems Integration
Senior Expert, Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 832138
http://www.t-systems.com

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

---

From: "Rute C. Sofia" <[email-masked]>
Date: Wed, 24 Sep 2003 07:26:51 -0400 (EDT)

Hi Sven,

great work for a 00 version. Some general comments:

- Abstract:
* would change "provides functionality similar to RSVP and extends it" to
something less RSVP-oriented :)

* would change "it is simplified by the elimination of support for
multicast" to something as "it does not address multicast support" (which
you actually say a couple of paragraphs after)

- section 1.1, 2nd paragraph:
* soft-state is mentioned as "the primary state management". Which are the
other options? From what I've read, it seems that qos-nslp is thought to
operate in either a state or stateless mode; for the former, soft-state is
the only choice.

- section 1.3 Terminology:
would simply change the order of the items, so the QNE would appear as the
first item;

- section 2. Protocol design
this part is a bit confusing; 2.1 simply describes the set of messages;
section 2.2 describes the concept of "QoS model" (which again, seems
confusing and out of place here). Perhaps an example would help here.

- section 3. messages
*couldn't the four messages used be simplified to two? It seems to me that
a Notify or a Response purpose could be served by a Reserve.
* also, this section overlaps a bit with 2., in the sense that the
reservation setup, queries, notifications and so on are exemplified
here...perhaps these two sections should be re-written...

Regards,
Rute