Subject: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early review comments update

From: [email-masked]
Date: Tue, 11 May 2004 13:55:04 +0200

Hi all,

We have submitted draft-ietf-nsis-qos-nslp-03.txt. While it is working its
way through the repositories you can find it at:
http://nsis.srmr.co.uk/~adm/draft-ietf-nsis-qos-nslp-03.txt

Please find below a point-by-point discussion of how the early review
comments were addressed.

Best regards,
Sven

Comments on NSLP

- in general this doc is not as well written as NTLP and needs some
editorial work. Parts are pretty hard to understand.

Sven>> We tried to clarify the document. Section 5 (message formats and
processing) is restructured.

- Policy control may involve "envelope resource utilitzation" policy in
addition to simple AAA. This means that hard synchronization with the AAA
policy state and the NSLP element may be necessary.
- Is there a need for explicit teardown invoked by the AAA element?

Sven>> We updated section 1.2 to The 'local application case' includes not
only user applications (e.g. multimedia applications) but also network
management (e.g. initiating a tunnel to handle an aggregate, or
interworking with some other reservation protocol - such as RSVP) and the
policy control module (e.g. for explicit teardown triggered by AAA).

- How is receiver selection based on ADSPEC done if resources are reserved
in the forward direction with RESERVE?

Sven>> The draft describes receiver-initiated reservations in section
3.5.3. It basically uses QUERY as PATH. The QUERY message
(sender->receiver) contains a QSPEC to can be used to provide ADSPEC to
receiver.

- some talk about 2-phase operation for RSVP. Any thought of the same for
NSLP?

Sven>> Section 8.2 states that we assume reserve/commit functionality to be
implemented by the QoS model.

- Didn't see any way to do resource sharing across flows.

Sven>> Section 4.2.4 discusses state handling. It states that resource
sharing between flows within a session and between sessions (with
BOUND_SESSION_ID) is assumed to be the responsability of the QoS model.
This is captured in section 8.1.

- Ditto for fate-sharing across flows (if you tear one down you tear the
fate-shared ones down)

Sven>> Section 4.2.6 discusses session binding. It introduces a
NO_FATE_SHARING flag that enables/disables fate sharing between flows
within a session and between sessions (with BOUND_SESSION_ID)

- Reservation priority is declared out of scope but is critically
important. We can't just punt this. One thought is to have it be part of a
set of "common facilities" that go across all the GIMPS applications. I bet
there are a number of such common things which are not part of the
transport but aren't specific to a particular signaling appication.

Sven>> This was raised as a question to the mailing list. We received 3
views, mainly stating that reservation priority (preemption) was not a QoS
NSLP function. This is captured in section 4.5. Message priority is in
scope for the QoS NSLP but relies on GIMPS. This is captured in a GIMPS
requirement (section 7.7). We will seek to confirm this position at the
interim meeting.

- Is there any capability for make-before-break so that reservations can be
installed on multiple paths at the same time to deal with graceful
mobility? It seems that the notion of flow/session separation captures part
of this, but I don't see how it solves the double-booking problems on the
common links.

Sven>> This issue was raised on the mailing list. The answers were not
conclusive although the main stream seems to be that this would require a
charter extension. The proposal is to summarize pros and cons at the
interim and decide on a way forward there.

- how does bi-dir reservation enforce symmetric routing?

Sven>> It doesn't. Bidirectional reservations are explained in section
3.5.4.

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

---

From: "Cheng Hong" <[email-masked]>
Date: Thu, 20 May 2004 11:21:04 +0800

Hi all,

Regarding the section 4.2.6 session binding, I have a question about the
first example given. In the second to last paragraph on Page 33, it states: 

"For this purpose, the end-to-end session contains a BOUND_SESSION_ID
carrying the SESSION_ID of the aggregate session", 

It is further stated in the first paragraph on page 34,:

"By default, a session that is bound to another session with the
BOUND_SESSION_ID object shares fate with it. This means that if a bound
session is torn down, every binding session should be torn down as well".

Shouldn't this be the other way around? Obviously, the tearing down of the
aggregate session doesn't mean that every end-to-end session should be also
torn down. But if there is an end-to-end session torn down, the aggregated
session should be torn down as well. 

cheers

Cheng Hong