Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt

From: "McDonald, Andrew" <[email-masked]>
Date: Tue, 18 Nov 2003 11:18:25 -0000

Cheng Hong wrote:
> I have the similar question as Nary about the RII. Is that the same
> as SII? Can it be just replace by the SII or using the same value?

No, they are different.

The RII (Requestor Identification Information) is something that goes in
a message when you want to get a response (and is included in the
response). It means: when the response gets passed back along the path
it should not be forwarded beyond me. (It's a form of scope identifier.)

The SII is an identifier between NSLP peers. The primary purpose is for
working out if your NSLP neighbour has changed. (And possibly as an
identifier for use with some form of NTLP explicit routing to allow
removal of resources on an old path.)

They are created (and used) by different nodes along the path and have
different properties. So, they can't be the same thing.

> Besides that, I have a few more comments on the -01 draft.
> 
> a) Section 1.2 says "Only messages related to QoS are passed to the
> QoS-NSLP. The NTLP may also generate triggers to the QoS-NSLP
> (e.g.indications that a route change has occurred)."
> 
> I don't think QoS-NSLP would be the only QoS related Signaling
> Application. It is somehow confusing. Therefore, I think it maybe
> better to clarify that as:
> 
> "Only messages related to the particular QoS NSLP, e.g. indicated by
> the Signaling Application Identifier defined in 4.6.3 of [3], are
> passed to the QoS-NSLP.The NTLP may also generate triggers to the
> QoS-NSLP (e.g.indications that a route change has occurred)."

Yes, that could probably do with some clarification.

> b) In Section 2.1, it says "Messages are normally passed from the
> NSLP to the NTLP via an API,which also specifies the signaling
> application (as QoS-NSLP), the flow/session identifier, and an
> indication of the intended direction - towards data sender or
> receiver." 
> 
> It sounds that the session identifier is provided through the NTLP.
> And other than here, there is no mentioning about the session
> identifier. My feeling is that it is better for the NSLP to actual
> maintain the session ID, since there my be several session come from
> the same NSLP instance, and only NSLP knows how to correlate the
> session and flows. Therefore, it would be better to provide some
> description about the operation on session ID in the NSLP draft.

Again, extra text will be needed on the workings on flow/session
identifiers. This is currently mentioned only in passing in the Open
Issues section on Mobility. I think the current belief is that the
session identifier is in the NTLP part of the message (and in some sense
maintained by the NTLP). The NSLP however needs to perform whatever
processing is necessary when multiple flows are associated with a single
session.

> c) In section 3.1 RESERVE, it is mentioned that "Note that the
> potential initiation of (reverse path) state removal at the NTLP is a
> separate issue. This will be signaled over the API between NTLP and
> QoS-NSLP." 
> 
> Shouldn't the state removal a business of the NSLP only? NTLP could
> provide hint/trigger for that, but the decision should still be made
> by the NSLP. Also, whether to use API for this purpose is purely
> implementation issue, e.g. we could use loopback message instead.

There are a number of different levels at which state might exist. The
NTLP may have some, besides what is needed by the NSLP (e.g. it's
'routing' state). It's not necessarily obvious that the NSLP should say
to the NTLP: "get rid of that state". For example, it might also be in
use by another NSLP at the time, or be needed to finish the NSLP state
removal.

Andrew

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