Subject: [NSIS] RE: GIST API: Adding SessionID to NetworkNotification, SetStateLifetime, InvalidateRoutingState?

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 1 Dec 2005 11:48:43 -0000

hi,

although it's true that GIST knows the mapping between
MRI (flow) and SID, at the moment my instinct is that
these primitives should continue to work in terms of the
MRI only. 

the rationale is that these primitives all (basically)
refer to changes in layer 3 (network topology) state, 
which should not depend on the SID. however, there may
be several SIDs for the same MRI. therefore, if you put
the SID in the API primitive, you inevitably end up 
looping over the SIDs/MRI. my main concern about this 
would be understanding the pathological cases, e.g. where
you only get API calls about a subset of the SIDs, or
GIST/NSLP operations about a SID get mixed up in time
with a sequence of API events (quite apart from any 
efficiency considerations). 

i assume the motivation is that you don't want the NSLP
to have to maintain an index of its state by MRI but
only by SID? i am not sure whether it is possible to
eliminate this functionality from the average NSLP.

r.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 29 November 2005 16:15
> To: [email-masked]; Hancock, Robert
> Subject: GIST API: Adding SessionID to NetworkNotification, 
> SetStateLifetime, InvalidateRoutingState?
> 
> 
> Hi,
> 
> our implementation experience suggests that it might
> be a good thing to add the SessionID to the above API
> calls. So in case GIST wants to issue a NetworkNotification
> to an NSLP, this NSLP has no idea to which session the flow
> belongs. GIST should have that information anyway.
> In the other direction (SetStateLifetime, InvalidateRoutingState) GIST
> must loop over all sessions.
> 
> Any objections?
> 
> Roland
> 

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

---

From: "Thomas Herzog" <[email-masked]>
Date: Thu, 1 Dec 2005 16:44:42 +0100 (MET)

Hi, see inline!

> eliminate this functionality from the average NSLP.

The motivation was, that GIST maintains state per-MRI, per-SID and
per-NSLPID.

It is logically inconsistent, to signal the state of one specific entry via
a primitive which refers to SEVERAL entries (all SIDs of a flow).

This does only apply to the NetworkNotification primitive, the other
primitives are directed from NSLP to GIST and it is feasible to not discern
between SIDs in this direction.

The NSLP is of course free to discard the SessionID information, but from
GISTs perspective, it should include the SessionID?

Cheers,
Thomas

-- 
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++