Re: AD review comments of draft-ietf-nsis-qos-nslp-16

Hi Magnus,

I'll try to answer C. and D.

Magnus Westerlund wrote:
> B. Section 3.1.3 contains a reference to draft-manner-nsis-nslp-auth.
> This is an informational reference. But I do wonder about the security
> solution and its need to carry authentication information. No, I don't
> want to make this a normative reference. But I do wonder how the WG
> plans to present the lack of even one fully specified security solution,
> even if this is going for experimental.

This is indeed a good point. Without the session authorization object,
there is only TLS transport security in a hop-by-hop manner, which is
also not related to individual sessions or users. So the above draft
is indeed very useful.

> C. Section 3.2.12.1: How long does it take to detect that a new down
> stream peer exist, or that truncation has happened?

Route change detections depends on the GIST route change detection
mechanisms, at latest the next GIST probing Query message
sent. Details are described in section 4.4.4. of the GIST draft, so
in the default case of 30s routing state validity probing Querys are
sent in the interval [15s...22.5s]. In some cases GIST may detect
route changes faster and thus send a new Query earlier. Route change
detection requires the three-way GIST handshake to be completed first
though (i.e., at least RTT for GIST Query/Response pair).
In case of path truncation, one must distinguish whether the new
next hop is GIST aware or not. The draft describes the former case,
so GIST will respond with "Unknown NSLPID" error in the GIST Response
to the Query and the same duration as above can be expected. In the
latter case of a non GIST-aware hop it takes longer, because the
querying node may perform retransmissions and exponentially backup,
so in this case we get a default 127*500ms=63.5s (T1=500ms, T2=64s)
as worst case. But as indicated in 5.3.3 of the GIST draft, NSLPs may
bound this response time by limiting T2 in the sendmessage() primitive
explicitly.

> D. Section 4.6, page 35, second paragraph. It is not clear to me how (1)
> can be guaranteed to arrive prior to (2), or if both message are sent
> width bound to the other one?

That's exactly the motivation for the message binding. You cannot
guarantee it, so both messages have to wait on each other. This case
is described on p. 36: "Triggering message" (3) arrives before waiting
(bound) message (1). Usually the waiting condition is then already
satisfied, so (1) can be processed immediately. I'm not sure that I
understand the last part of your question correctly, but (1) will
contain a BOUND_MSG_ID and (2) and (3) will carry the corresponding
MSG_ID.

Regards,
 Roland