Subject: Re: [NSIS] Plans for the protocol drafts

From: [email-masked]
Date: Thu, 18 Mar 2004 10:36:34 +0100

Hi Allison, John, all,

We have had a first discussion of the comments among the authors and this
is how we see the current status (per comment).

Best regards,
Sven

NSLP comments
=============

1. Need for explicit teardown invoked by the AAA element?

I think aspect is already possible. To clarify, we can extend the
description of what may trigger the NSLP handler with AAA in addition to
e.g. RMF. Teardown by an external element can be handled by a combination
of a NOTIFY and a tearing RESERVE.

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

In the current sender-initiated model you can do a QUERY/RESPONSE/RESERVE.
This costs 0.5xRTT more than a PATH/RESV. As possible optimization here
could be to do a QUERY send the RESERVE and RESPONSE in parallel. This
would have no impact on the protocol (only intelligence on the receiver
side). We will provide an example on receiver-initiated reservation in the
next version.

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

We discussed about a RESERVE/COMMIT model in QoS NSLP. At the moment, we
feel that this might be solved at the QoS model level which is opaque to
QoS NSLP.

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

There is, but maybe not for a general case. Two flows with the same session
ID but different flow ID will share resources. This is used in special
cases of mobility and route changes. GIMPS does have some wildcarding of
flow IDs, which would probably get you to the same level of resource
sharing as RSVP (to be checked).

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

Within QoS NSLP, you could regard this as a policy decision taken by a QNE.
However, we could think about a SESSION_FATE_SHARED object similar to
BOUND_SESSION_IP. Is there any interest in fate sharing between different
NSLPs (e.g. qos-nslp/natfw-nslp)?

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

We would like to receive input on this from the WG. Why do they think it is
needed, what are the requirements, ...

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

We have thought about a possible extensions of the SII object, but
reservations on future paths conflict with the current NSIS charter. With
the current spec, it is not obvious how this functionality could be
provided. An extension of the SII would conceivably impact the GIMPS
requirements as well.

8. How does bi-dir reservation enforce symmetric routing?

At present, we imagine that it should not enforce symmetric routing but
make assumptions on one-end being on the path for both directions (whether
it is sender+receiver initiated reserve, or remote initiated model).
Binding of both reservation would happen at the end points.

9. State refresh reduction (a la rfc2961): this is vital.

We agree with the comment. The current draft hints at a solution with
RESPONSE message. We will make this explicit in the next version.

10. Don't like multiple qos models. (Complicated, and can't work.)

The proposal here is to see what the QoS model draft teams come up with and
clarify exactly what is achieved when the QoS model work has progressed a
bit.

Allison Mankin <[email-masked]>@ietf.org on 16/03/2004 17:41:31

Sent by:    [email-masked]

To:    [email-masked]
cc:    [email-masked]
Subject:    Re: [NSIS] Plans for the protocol drafts

Hi, all,

There should be mailing list discussion for each
protocol draft of the Early Review comments and how they
will be addressed.

Allison

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

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

---

From: "Cheng Hong" <[email-masked]>
Date: Wed, 24 Mar 2004 10:26:19 +0800

Hi Sven, 

Please see some comments below inline.

Best regards

Cheng Hong

<snip>
> I think aspect is already possible. To clarify, we can extend 
> the description of what may trigger the NSLP handler with AAA 
> in addition to e.g. RMF. Teardown by an external element can 
> be handled by a combination of a NOTIFY and a tearing RESERVE.

I think the teardown decision has to be made with more than a single 
information source. The AAA element could trigger the teardown, but other 
issues also need to be considered. As what we discussed in the mailing 
list, to support the multi-homing, indication from the end node should also
be considered in decision making.

<Snip>
> 3. some talk about 2-phase operation for RSVP. Any thought of 
> the same for NSLP?
> 
> We discussed about a RESERVE/COMMIT model in QoS NSLP. At the 
> moment, we feel that this might be solved at the QoS model 
> level which is opaque to QoS NSLP.

This may not be opaque to QoS NSLP.With this RESERVE/COMMIT model, 
QoS NSLP should include messages that could do the roll-back action. 

> There is, but maybe not for a general case. Two flows with 
> the same session ID but different flow ID will share 
> resources. This is used in special cases of mobility and 
> route changes. GIMPS does have some wildcarding of flow IDs, 
> which would probably get you to the same level of resource 

The resource sharing is only meaningful inside each individual NSLP.
Therefore, the GIMPS may not be able to provide the necessary function
unless it is mandated that the session-ID would be unique across all
the NSLPs. 

<snip> 
> 6. 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.
> 
> We would like to receive input on this from the WG. Why do 
> they think it is needed, what are the requirements, ...

This could be useful if we want to differentiate the flows, and assign
different priority for different flows. In that case, reservation for
the corresponding flows could also be assigned with priority.

> 7. 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.
> 
> We have thought about a possible extensions of the SII 
> object, but reservations on future paths conflict with the 
> current NSIS charter. With the current spec, it is not 
> obvious how this functionality could be provided. An 
> extension of the SII would conceivably impact the GIMPS 
> requirements as well.

Similar to the first question, it also relates to the decision of the tear
down.
In this make-before-break case, the reservation over the old path should not
be
torn down before the handover finished. Therefore, a method has to be
incorporated
into the signaling for that. 

As what we discussed earlier, a notification from the MN could be useful for
that. 

> At present, we imagine that it should not enforce symmetric 
> routing but make assumptions on one-end being on the path for 
> both directions (whether it is sender+receiver initiated 
> reserve, or remote initiated model). Binding of both 
> reservation would happen at the end points.

Does this imply that at least one end of the flow would be the QoS NSLP
node?

> We agree with the comment. The current draft hints at a 
> solution with RESPONSE message. We will make this explicit in 
> the next version.
> 
> The proposal here is to see what the QoS model draft teams 
> come up with and clarify exactly what is achieved when the 
> QoS model work has progressed a bit.
>