Subject: RE: [NSIS] GIMPS connection mode and network re-routing

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 30 Jan 2004 09:00:55 +0100

Robert, 

|Therefore, we would propose to get rid of 5.3.4, leaving us with
|simple D mode and raw C mode. The consequence would be a final
|acceptance within the group that the lack of automatic route change
|detection in C mode is something we can all live with.

Absolutely correct. My personal preference is to separate route 
change detections (D mode, high frequency or asynchronus, network 
specific, probably no AAA requirements) from service state 
maintenance (C mode, medium frequency, session specific, 
high security requirements). Of course both must be linked. 
I didn't analyse details. If anybody is aware of studies 
comparing above attempt with an RSVP like (where both functions 
are combined in a single protocol), I'd be happy for a url.

Regards, Rüdiger

Rüdiger Geib
T-Systems
Systems Integration
Senior Expert
Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 937-2138
http://www.t-systems.com

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 30 Jan 2004 16:34:47 -0000

hi marcus,

> > Therefore, we would propose to get rid of 5.3.4, leaving us with
> > simple D mode and raw C mode. The consequence would be a final
> > acceptance within the group that the lack of automatic route change
> > detection in C mode is something we can all live with.
> >
> 
> I have no problem to get rid of this as long as the 
> specification defines how route changes are handled.
> 
> Marcus
> 

there are two parts to 'handled':
1. detected
2. repaired (in general, "reacted to")

and (1) can be subdivided into
1a. detected as possibly having occurred
1b. confirmed (and the new route discovered)

my view (but i am thinking aloud here) is that 
1a - GIMPS will describe one method for this (periodic re-issue
of D-mode query/response exchanges); might include protocol 
elements which assist other mechanisms (e.g. TTL measurements);
but certainly won't be comprehensive. there is important
stuff to be done here (cf. zappala's routing interface for
RSVP) but not as part of the basic GIMPS spec.

1b - GIMPS defines this already (it's the D mode 
discover/query), or at least we know it has to.

2 - the main point is that GIMPS doesn't carry out
the repair operation itself, it notifies NSLPs that they
may need to do it. so, the main issue from a protocol
perspective is: where (at which node) to deliver the
notification. there are some subtleties here (sections
6.1.2 and 6.1.3 of the GIMPS draft) which some comments
on would be nice.

r.