Subject: RE: [NSIS] RE: aggregation based GIST bypass forwarding functionalityneeded

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

Hi Georgios,

I think the text you are referring to was removed between 
v06 and v07, not between v07 and v08. (RFC3175 was still
in the v07 references section, but never used in the text.)

In any case, I don't think any functionality has changed.
GIST has always had the concept that it will skip over nodes
which don't process an NSLPID, which is what 4.3.4 is (still)
about. If signalling applications want to use a sequence of
NSLPIDs to handle different aggregation levels, that is just
a particular use of that functionality by that signalling 
application. 

Are you looking for a sentence somewhere to point out the 
existence of that possibility, or something more?

Robert H.

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: 05 October 2005 10:15
> To: Hancock, Robert; [email-masked]; [email-masked]
> Cc: [email-masked]; Martijn Swanink
> Subject: Re: [NSIS] RE: aggregation based GIST bypass 
> forwarding functionalityneeded
> 
> 
> 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
> 
> 
> > 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
> > 
> 
> 

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 5 Oct 2005 12:35:32 +0200

Hi Robert

I think a sentence will anyway be necessary to emphasize that the bypassing 
of a node is also
applied when for example, a QOS-NSLP aggregation region has to be bypassed.

Regarding the described aggregation based bypassing solution you assume that 
a NSLPID must be associated
with a unique RAO  value.

This is however not consistent with what is emphasized in Section 3.9 of
 http://www.ietf.org/internet-drafts/draft-loughney-nsis-ext-01.txt

This section emphasizes that:
"These considerations imply that the RAO value should not be tied
   directly to the NSLPID, but should be selected for the application on
   broader considerations of likely deployment scenarios."

Best Regards,
Georgios

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