Subject: RE: [NSIS] state management and the nsis framework

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 12 May 2003 13:36:18 +0100

hi georgios,

and see my comments too...

[snip]
[GK:]
> I agree with the statement that the NTLP provides a uniform 
> message delivery
> service to signalling
> applications. However, the NTLP protocol should be used to 
> initiate, refresh
> and teardown a NTLP state.
> Therefore different types of NTLP messages are neaded, i.e., 
> to initiate a
> NTLP state,
> to refresh a NTLP state and to tear down a NTLP state.
> 
> Here I also agree with you on the fact that the NTLP does not contain
> explicit timer or message
> sequence information related to the signalling application. 
> However, if the
> NTLP needs this information to manage the
> NTLP states then this information should be allowed.

[reh] Neither of these are ruled out (both covered by the original 'Point 0', i.e. that what goes on inside the NTLP is up to it and its designers. From a framework perspective, I'm not very interested in this aspect (not that it isn't interesting in general, of course).
 
> >> 3. Within any node, it's an implementation decision whether to
> generate/jitter/filter refreshes either
> >> separately within each signalling application that needs this
> functionality, or as part of generic/shared
> >> code (a "soft-state management toolbox") more closely 
> associated with the
> NTLP. The choice doesn't
> >> affect the NTLP specification at all. Implementations 
> might piggy-back
> NTLP soft-state refreshe
> >> information (if the NTLP works this way) on signalling application
> messages, or even combine
> >> soft-state management between layers.
> 
> Okay, but will then the following functionality will also be possible:
> "The NSLP refresh procedure can be a pure NTLP refresh procedure,
> meaning that a refresh NTLP message is periodically sent
> through all the NTLP stateful nodes located between NI (sender) and
> NR (receiver).  If a NTLP state in a NTLP stateful is not refreshed
> on time then the NTLP functionality at this node informs the 
> NSLP state that
> the
> refresh procedure is unsuccessful. "

[reh] I think you are describing a case for a particular NSLP, where an NSLP-aware node just wants to know that it's NSLP peer is alive and kicking. In that case, I would rather think of this as the NSLP generating a rather small, content-free keepalive which it sends via the NTLP to its peer. An implementation would be free to piggyback this information on whatever is going on inside the NTLP, so the end result is identical (in performance/functionality terms) to what you describe. However, I prefer my way of thinking about it for at least 2 reasons:
a. looser coupling between NSLP/NTLP specification
b. cleaner support from multiple NSLPs

> >> 4. It may be helpful for signalling applications to receive
> state-management related 'triggers'
> >> from the NTLP, that a peer has failed or become available ("down/up
> notifications"). These triggers
> >> would be about adjacent NTLP peers, rather than signalling 
> application
> peers. We can consider this
> >> as another case of route change detection/notification 
> (which the NTLP is
> also supposed to do anyway).
> 
> What do you mean by saying that:
> "These triggers
> would be about adjacent NTLP peers, rather than signalling application
> peers."
> 
> I think that the NTLP instance should also be able to trigger a NSLP
> instance also for other reasons.

[reh] this is about the framework section 3.2.1 picture (fig.5). in the picture here:

   NSLP                          NSLP

   NTLP------NTLP------NTLP------NTLP

  node 1    node 2    node 3    node 4

suppose node 3 detects a route change or that node 4 is 'dead'. who does it tell about that? does it tell only its NTLP peer (node 2) or attempt to ensure that the NSLP knows as well, i.e. node 1? and if the latter, where does it stop?

> 
> >> 5. The existence of these triggers doesn't replace NSLP 
> refreshes as the
> mechanism for maintaining
> >> liveness at the signalling application level. In this 
> sense, up/down
> notifications are advisories which allow
> >> faster reaction to events in the network, but shouldn't be 
> built into
> NSLP semantics. (This is essentially the
> >> same distinction - with the same rationale - as SNMP makes 
> between traps
> and normal messages.)
> 
> Do you mean that the functionality described in my remark on 
> your remark
> (bullet) 3, above,
> will not be possible?

[reh] functionality possible so far as i can tell.

> Best Regards,
> Georgios
cheers,

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 12 May 2003 16:10:13 +0200

Hi Robert

Please see the second version of my comments in line:

[GK:]

>> [reh]
>> Neither of these are ruled out (both covered by the original 'Point 0',
i.e. that what goes
>> on inside the NTLP is up to it and its designers. From a framework
perspective, I'm not very
>> interested in this aspect (not that it isn't interesting in general, of
course).

[GK] Okay, is it then possible to mention in the framework draft that these
iussues are not ruled out?

------------------------------------------------------------
[GK]
> The NSLP refresh procedure can be a pure NTLP refresh procedure,
> on time then the NTLP functionality at this node informs the NSLP state
that
> the refresh procedure is unsuccessful.

>> [reh] I think you are describing a case for a particular NSLP, where an
NSLP-aware node
>> just wants to know that it's NSLP peer is alive and kicking. In that
case, I would rather think of this
>> as the NSLP generating a rather small, content-free keepalive which it
sends via the NTLP to
>> its peer. An implementation would be free to piggyback this information
on whatever is going on
>> inside the NTLP, so the end result is identical (in
performance/functionality terms) to what you
>> describe. However, I prefer my way of thinking about it for at least 2
>> b. cleaner support from multiple NSLPs

[GK] No, I am describing a situation where the NTLP state management is
performed by the
NTLP protocol. If needed the NSLP protocol can use this NTLP procedure to
realise the
NSLP soft state management.

------------------------------------
[Original--reh]
> same distinction - with the same rationale - as SNMP makes

[GK]
>  your remark (bullet) 3, above,
> will not be possible?
>
 [reh]
> >functionality possible so far as i can tell.

[GK
Could you then please emphasize it into the text!

Best Regards,
Georgios