Subject: [NSIS] RE: aggregation based GIST bypass forwarding functionality needed

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 5 Oct 2005 09:33:16 +0100

Georgios,

The *title* of section 4.3.4 has changed, but the concept of
bypassing has not been removed from the spec. The description
just depends on whether it involves the NSLP or not (the case
where it involves the NSLP is treated earlier.)

robert h.

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: 05 October 2005 07:28
> To: Hancock, Robert; [email-masked]; [email-masked]
> Cc: [email-masked]; Martijn Swanink
> Subject: aggregation based GIST bypass forwarding functionality needed
> 
> 
> 
> 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
> 
> 
> 
> On 10/4/2005, "Hancock, Robert" <[email-masked]> wrote:
> 
> >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 11:14:52 +0200

Hi Robert

>From what I can read from the text is that only the GIST bypassing 
functionality
is supported on bypassing nodes not hosting a NSLP.
The description of bypassing a node due to the fact a QoS-NSLP aggregation 
region has
to be bypassed is removed from the text, i.e., reference [17] is not used in 
the text anymore.

I think that it is needed that both bypassing methods should be supported 
and that this should be made
clear in the text.

I have seen that the discussion regarding the selection of the RAO values is 
moved to the draft below
http://www.ietf.org/internet-drafts/draft-loughney-nsis-ext-01.txt
This draft explains how the aggregation based bypassing is notified, see 
section 3.2,  and section 3.9.
However, I think that there is an inconsistency on this point between these 
two sections .
I will send a separate e-mail on this!
I think that the description of bypassing a node due to the fact that a 
QoS-NSLP aggregation region has
to be bypassed has to be briefly explained in the GIST draft.

Best regards,
Georgios

----- Original Message ----- 
From: "Hancock, Robert" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>; "Martijn Swanink" 
<[email-masked]>
Sent: Wednesday, October 05, 2005 10:33 AM
Subject: [NSIS] RE: aggregation based GIST bypass forwarding 
functionalityneeded