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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 29 Jan 2004 15:50:55 -0000

dear all,

This is the second of two mails which proposes the elimination
of some options in the GIMPS design space; it's intended to find 
out if there is any objection to removing these options (i.e. 
are people happy to live with the resulting limitations on GIMPS 
functionality).

All of the following refers to
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt
(mainly section 5.3).

BACKGROUND: GIMPS has a datagram ("D") mode (basically unsecured 
UDP transport) and a connection ("C") mode (which can use connection
oriented transport protocols like TCP, SCTP, DCCP and channel
security mechanisms like IPsec, TLS - details TBD). C-mode is 
supposed to be used between adjacent peers for a given signalling
application, where that signalling application needs industrial-strength 
transport or security services.

[==== from this point on, this mail starts to look different from
the previous one =========]

Because of the way that the 'component' connection mode protocols
have (quite reasonably) been designed, it is practically impossible
to run a C-mode session except between the (fixed, physical) IP
addresses of the adjacent GIMPS peers. Therefore, these addresses 
have to be discovered (in one procedure) before they are used in
C-mode messages.

The consequence of this is that, once you have started using C-mode,
downstream signalling messages will not be sensitive to route
changes. Instead, you have to use other techniques (like looking
at routing protocols; there are many other possibilities listed in
the framework) to find out that a route change has taken
place, and then repeat the initial discovery. If nothing else, you
can just repeat the discovery process periodically.

There is an (ugly) alternative to this, which is essentially to use
a sort of C-mode-inside-D-mode encapsulation (5.3.4 of the GIMPS
draft). This shows that it is logically possible to get some of 
the benefits of C-mode and still have automatic route change 
detection; but I really don't like this approach in practice
(although it is kind of interesting to think about).

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.

Comments aree, as always, welcome,

robert h.

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

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 30 Jan 2004 10:50:46 +0100

> 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