Hi Jukka,
Jukka Manner wrote:
Hi Roland, thanks for the note, we'll fix this one, too.
I have additional comments you might consider, mainly
for consistency and clarification:
A) Multiple Upstream RSNs
Sec 5.2.1 State Manipulation:
RSN from the upstream peer
=> One must allow for keeping multiple RSNs from different upstream
peers
Reasoning: this is along the same line as the reasoning for keeping
multiple Flow IDs in case of mobility. Usually if R=1 (Replace Flag)
is set, you only need to consider one RSN for an upstream peer, but
if R=0, you will usually simply dismiss the RESERVE from the new
upstream peer in most cases. The new peer however, cannot know which
is the latest valid RSN that was used with the previous peer.
It's not clear to me whether this will also affect the interface in
A.1. I cannot find any SII-Handle which could be used as qualifier
for the RSN.
B) Receiver-initiated reservations:
Sec. 3.2.12, p.20:
"If routing changes in the middle of the path, the QNE that notices
that its downstream path changed, the divergence point, ..."
change to:
"If routing changes in the middle of the path, the QNE that notices
that its downstream path changed (indicated by a NetworkNotification
from GIST), the divergence point, ..."
I didn't find any text that states anything about repeating the
QUERY message. State refreshes are performed by sending RESERVE
messages upstream. So basically it is not necessary to repeat
the QUERY from the sender in order to detect route changes,
since GIST probing will discover the route change even without
the QoS NLSP QUERY sent by the sender. This is a difference to
RSVP for example, where the PATH message was periodically
repeated, too.
Thus I'd like to propose adding clarifying text at the
end of sec. 4.3:
As GIST will indicate re-routing events by NetworkNotification,
it is not necessary to periodically repeat the QUERY message
for route change detection (cf. Sec 3.2.12).
more NITS:
----------
There is a typo on p.91:
" o authorization_info: the AUTHO_SESSION object"
=>
" o authorization_info: the AUTH_SESSION object"
and p. 77: spacing:
stateful QoS NSLP QNE receives a QUERY message with the RESERVE- INIT
=>
stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT
Regards,
Roland