RE: failure detection

[Paul Jakma <paul@clubi.ie>]

On Mon, 15 Aug 2005, john.loughney@nokia.com wrote:

> I think we should avoid any transport layer functions in the shim 
> layer (or at least as much as possible).  I'm leaning more towards 
> the rich-api type of functionality, where the shim provides as much 
> info as it can to the transport layers, and let the transport 
> layers make decisions.

Hear hear.

I'd also like to potentially add source-address-selection (for the 
globally routable shim address) to this list.

That's something which (my gut feeling right now tells me) belongs 
*under* shim, in the final output stage of IP. Let shim specify use 
of either:

- INADDR_ANY per default for its local source and the OS
  + administratively specified or dynamically specified routes do
  their job
- an admistratively specified address (or even a set of addresses,
  but that shouldn't be required)

for the endpoint locator/outside/globally-routable address.

Again, SAS is simply *not* something shim6 should do, or something 
which it has remotely near enough information to do. Let normal IP 
routing and SAS handle this task.

I'd suggest it would be more fruitful to ensure state between two 
shim6 speakers /not/ depend on the 'outside' (ie globally routable) 
addresses, and let shim6 be able to handle messages between two 
endpoints arrive with any 'outside' source address.

It also eliminates the need for hideous n^2 address-to-address 
probing which is being considered.

Case to consider in support for this:

Shim6 endpoint, A, with 2 links to 2 ISPs, keeping some kind of 
shim6 mapping up to a remote endpoint, B:

	    B
	   /|\
    [ye olde internet cloud]
	ISP1  ISP2
           \ /
	    A

A has two 'locator' addresses, one for each ISP.

If shim6 cares not a jot which locator address A uses to send 
packets, then shim6:

- can leave local routing policy to IP routing, as $DEITY intended
  eg:
	- A may prefer to use ISP1 for outbound packets
   	- A may run some kind of reachability-determining protocol
	  on its ISP links and update routing to suit
	- A may load-balance outbound packets between the two ISPs

  If shim6 assumes *nothing* about the 'outside' IP state, then shim6
  could deal very nicefully with the above.

- has no need to specify complex and/or n^2 algorithms for source
  address selection

	- let IP output decide
	- automatically take advantage of any local reachability
	  information (eg routing protocols, or even a script that
	  pings links)
	- can cope with locator addresses changing (eg link to ISP1
	  goes down and hence the ISP1 related locator address is
	  unreachable to B. A's messages, if stateless from IP
	  routing layer POV, start being sent with locator of ISP1, B
	  gets messages from A still. If shim6 has heartbeat control
	  messages, then state can be updated between the two
	  reasonably quickly)

Note that this does *not* preclude A doing more sophisticated address 
selection, if it desires (eg, to work around path failures somewhere 
in "ye olde internet cloud"). However, I would suspect most 
implementations would /not/ bother trying hard to solve this.

However, I feel it is a *really* bad idea to even consider trying to 
solve the problem of "internet cloud" path failures, if it's going to 
involve horridly unscaleable algorithms, cause:

	- This WG isn't here to solve problems of internet routing
	- Existing protocols already live with this today, and
	  generally we're happy
	- Even in a shim6 world, internet-cloud path failures will
	  still affect non-shim6 destinations.
	- It can be solved/mostly-mitigated by running a routing
	  protocol (ie BGP)
	- If you don't need to specify complexity, don't -> KISS
	- In trying to specify such a thing in shim6 you'll have to
	  consider interaction with underlying IP routing, yet
	  another layering violation.

Please drop the locator-selection crap for now. It's just not needed, 
certainly not for an initial shim6 specification, and if shim6 is 
designed right (no assumptions made of outside IP state), it can be 
an implementation detail, if desired.

- Keep it simple.
- Don't try to reinvent transport layers
- Don't try to tackle the problems of internet routing
- Defer the problem of solving world hunger to another day

regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
printk(KERN_WARNING "Hey who turned the DMA off?\n");
        linux-2.6.6/drivers/net/wan/z85230.c