Subject: [NSIS] RE: possible GIST open issues

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 4 Oct 2005 14:42:11 +0100

hi georgios, all,
 
for the issues:
 
SetStateLifetime: agreed, this should be related to the NSLP in
question. 
added
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue69
 
For the other two, I am not sure these are GIST issues. To be specific,
GIST
does not really have a concept of aggregation; it only has the concept
of 
different NSLPs, and that different NSLPs can be associated with
different
RAO values. How a set of NSLPIDs and RAO values is chosen by a 
signalling application to achieve aggregation is up to the signalling 
application, GIST doesn't know about the different levels or the
relationships
between them.
 
Do you think some additional functionality is required, or just more
explanation?
 
r.

	-----Original Message-----
	From: Georgios Karagiannis [mailto:[email-masked]] 
	Sent: 04 October 2005 10:52
	To: Nsis (E-mail); [email-masked]; Hancock, Robert
	Cc: [email-masked]; Martijn Swanink
	Subject: possible GIST open issues

	Hi Robert
	 
	Mayi  Zoumaro Djayoon, Martijn Swanink and myself are
implementing the 
	NSIS protocol suite using the QoS-NSLP and GIST
	(v.05) specification. This also includes the stateless/statefull
	functionalities as well as the RMD-QOS model.
	
	During this implementation phase we identified certain GIMPS
(GIST)
	issues that we consider that they are still open, even in the
last
	version of GIST.
	
	These issues are as follows:

	Issues related to NSLP-GIST API:
	--------------------------------
	Issue_1: (SetStateLifetime): Among the information that the
	SetStaLifetime's parameters provides to GIMPS, there is none
that
	enables GIMPS to identify the SetStaLifetime's initiator (the
NSLP
	which has initiated the SetStateLifetime's primitive).
	We think that it will be useful to include the NSLP-ID in this
service
	primitive. This service primitive will then become:
	SetStateLifetime(MRI, StateLifetime, NSLP-ID)

	Issue_2: When the GIST aggregation operation is applied in a
node then it
	is necessary that QoS-NSLP should have the possibility to notify
GIST
	the message aggregation level. In other words the QoS-NSLP must
be able
	to identify which QoS-NSLP messages are associated with a higher
	aggregation level and which QoS-NSLP messages are associated
with a
	lower aggregation level. In order to accomplish this a variable,
e.g.,
	"AggLevel" must be carried by the SendMessage primitive

	Issue related to bypass/forwarding level
	---------------------------------------
	Issue_3: (bypassforwarding): The exact information that should
be
	encapsulated in the router alert value is still an open issue.

	Best Regards,
	Georgios

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 5 Oct 2005 08:27:31 +0200 (MEST)

Hi Robert

I have seen that in the current version of the GIST draft you have
removed the description of the bypass forwarding functionality (see
section 4.3.4  in previous version of GIMPS
(http://www.watersprings.org/pub/id/draft-ietf-nsis-ntlp-07.txt).

What is the reason of this huge modification?

Please note that this GIST functionality is needed in when GIST has to
support the QoS-NSLP aggregated and stateless operation!

My comment regarding the "GIST aggregation operation" is associated
with the  bypass forwarding functionality that is needed in the
situation that aggregation or stateless operation is required by
QoS-NSLP.

Best Regards,
Georgios