Subject: [NSIS] NE functionality

From: [email-masked]
Date: Mon, 4 Nov 2002 16:14:19 +0100

Hi Melinda, all,

This mail is a follow-up to one of the remarks on the framework draft you
sent a while ago. I have checked the requirements draft like you suggested.
For reference, I included your comment.

[ms] 3.3.2 The first sentence is *excellent* - IETF documents need more of
this kind of thing.  Otherwise section needs to be aligned with
requirements document - currently they're somewhat out of alignment

The framework draft currently states:
More in particular, it is not clear whether:
*) an NF can request, modify or release a reservation. If it cannot, it
needs to notify the NI in order to perform these functions.
*) an NR can modify and release a reservation. Even if the NR can reject or
accept the reservation with modification, it might still be required to
notify the NI to signal the release or modification.

The idea of this section is/was to explore whether all NEs should have
equal capabilities or whether there would be operations on reservations
that could only be performed by the NI and/or NR.

I found three section in the requirements draft that refer to the
capabilities of and/or functions performed by the NEs:
5.3.2 Possibility for automatic release of resources after failure: states
that an NF needs to be able to release reservations in case of a failure
and mentions soft-state as a possible implementation choice.
5.4.1 Mutability information on parameters: states that an NI needs to be
able to control the mutability of NSIS parameters
5.7.5 Hop-by-hop security: states that intermediate nodes may be modifying
the message.

None of these sections preclude or mandate an NF to request a reservation.
The ability to initiate a reservation at the NF is potentially useful in
case of failures. In that case, the NF can request a reservation on an
alternative path on behalf of the NI which reduces the potential service
interruption. The first bullet (request reservation) in section 3.3.2 was
meant to initiate the discussion on that.

The ability to modify a message is clearly desirable at each of the NEs. It
is, however, not the same thing as modifying the reservation. Modifying a
reservation would mean taking the decision to reserve less (or more)
resources. It is not clear that either an NF or an NR would be allowed to
do that. The requirements document talks about control of mutability here
but only as a SHOULD (not MUST). I am not sure what happens when an
implementation chooses not to implement this. I think we saw changing the
reservation request at intermediate nodes as no more than an optimisation
which could save set-up delay. I am not sure if this is worth the
additional complexity. Hence the discussion point in 3.3.2.

The requirements only refer to the possibility for automatic release of
resources after a failure. I am not sure if this covers cases where the
release is due to other issues. The requirements do not state that this
means that the NF would say 'initiating a reservation teardown' rather than
'releasing a reservation'. An NF could then send a notification to the NI
which would initiate the teardown.

Does any of this address your comment?

Cheers,
Sven.

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