Re: AD review comments of draft-ietf-nsis-qos-nslp-16
Roland Bless <[email protected]>
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Organization | Institute of Telematics, University of Karlsruhe |
| Message-ID | <[email protected]> |
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