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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 2 Dec 2005 11:14:02 -0000

hi thomas,

i think the question here is how one sees the relationship
between
- the GIST routing state table
- API events
- the 'external' network events (e.g. IP-level re-routing)

if you regard the NetworkNotification API as a signal that
there has been a change in the GIST routing state table, it
is also logical to that it should include the session ID.

however, if you regard the NetworkNotification API as a 
signal to signalling applications that something has changed
in the network, it probably doesn't - since the network 
level changes are detected (in general) with session ID
independent means (e.g. a forwarding table change is SID
independent).

i tend to see the second as more fundamental; NSLPs should 
not care about the GIST routing table structure, but do care
about the more fundamental re-routing (and other) events. so
i see GIST as manipulating the routing state table and 
issuing API events as logically independent activities, both
of them triggered by events in the network.

robert h.

> -----Original Message-----
> From: Thomas Herzog [mailto:[email-masked]] 
> Sent: 01 December 2005 15:45
> To: Hancock, Robert
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] RE: GIST API: Adding SessionID to 
> NetworkNotification, SetStateLifetime, InvalidateRoutingState?
> 
> 
> Hi, see inline!
> 
> > 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.
> 
> 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 +++
> 

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

---

From: "Thomas Herzog" <[email-masked]>
Date: Fri, 2 Dec 2005 16:04:55 +0100 (MET)

Hi, thanks, this sounds OK, but I have one small point to argue:

Assume 2 GIST signaling paths for the same MRI but 2 different Sessions.

Assume that one signaling path has another GIST next hop.

This link may break, but it may happen that the second path via another GIST
next hop is not influenced.

This scenario may happen if one would implement e.g. Aggregation and a
specific GIST has been told by it's NSLP to drop out of the path for one
Session, but stay in the path for another Session.

In this case, GIST would signal "this Flow in this direction is broken", but
it would only be the case for one of its Sessions.

What about this case?

e.g.:

A --- B --- C --- D  breaks because of something happening to B

A --------- C --- D  stays intact, as B is irrelevant

Of course, the Flow itself may also be broken for the second path, but this
cannot be decided by the GIST on node A. It could also happen that the flow
stays intact, simply rerouting around B and converging back in C.

Cheers, Thomas

> --- Ursprüngliche Nachricht ---
> Von: "Hancock, Robert" <[email-masked]>
> An: "Thomas Herzog" <[email-masked]>
> Kopie: <[email-masked]>, <[email-masked]>
> Betreff: RE: [NSIS] RE: GIST API: Adding SessionID to
> Datum: Fri, 2 Dec 2005 11:14:02 -0000
> 
> hi thomas,
> 

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 9 Dec 2005 15:16:05 -0000

hi thomas,

it's a reasonable question; in parallel to the discussion,
i have also updated the API text for NetworkNotification
to clarify that it gets delivered to a particular NSLP,
i.e. that the NSLPID is part of the notified information.

(Routing state genuinely is NSLP dependent, not only 
because peering state depends on which NSLPs are implemented
in which nodes, but also because there are discussions that
in some cases, NSLPs may decide to change which flows they
are interested in. This is potentially the case with the
metering NSLP, for example.)

The routing state then has to be re-established for each NSLP
independently. The signalling applications have to operate
in parallel with each other from this point of view.

cheers,

r.

> Sent: 02 December 2005 15:05
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: RE: [NSIS] RE: GIST API: Adding SessionID to 
> This link may break, but it may happen that the second path 
> via another GIST next hop is not influenced.
> 
> This scenario may happen if one would implement e.g. 
> Aggregation and a specific GIST has been told by it's NSLP to 
> drop out of the path for one Session, but stay in the path 
> for another Session.
> 
> In this case, GIST would signal "this Flow in this direction 
> is broken", but it would only be the case for one of its Sessions.
> 
> What about this case?
> 
> e.g.:
> 
> Of course, the Flow itself may also be broken for the second 
> path, but this cannot be decided by the GIST on node A. It 
> could also happen that the flow stays intact, simply 
> rerouting around B and converging back in C.
> 
> 
> Cheers, Thomas
> 
> 
> > i think the question here is how one sees the relationship between
> there has 
> > been a change in the GIST routing state table, it is also 
> logical to 
> > that it should include the session ID.
> > 
> 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.
> > > 
> > > primitives are directed from NSLP to GIST and it is 
> feasible to not 
> > > discern between SIDs in this direction.
> > > 
> Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne 
> Risiko! Satte Provisionen für GMX Partner: 
> http://www.gmx.net/de/go/partner
>