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

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

Hi Georgios,

I've created
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue72
to add a comment on aggegation support.

On the RAO setting, I don't think there is a contradiction but 
the language is hard to get right. The intention of the sentence in
draft-loughney-nsis-ext-01.txt (which I wrote, btw) is to say
that the RAO does not have to be identical to the NSLPID or
1:1 related to it; however, the RAO must be derivable from the
NSLPID (uniquely). Indeed, section 9 of the GIST spec says

"Every other NSLPID MUST be associated with a specific RAO value
(multiple NSLPIDs MAY be associated with the same value)."

robert h.

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

Hi Robert

Thank you very much!

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 12:48 PM
Subject: RE: [NSIS] RE: aggregation based GIST bypass 
forwardingfunctionalityneeded