[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: failure detection



Paul Jakma wrote:

But here is where the out-of-the-box behavior of the hosts doesn't match your expectations. The host will pick a source address that is appropriate for the network interface,


Right.

but apart from that there isn't any correlation between the source address and the 1st hop router it is using.


In practice, there likely is a very strong correlation between the output interface and the address(es) on that interface, the latter of which were used to decide which interface is appropriate for the chosen next-hop. So in practice, there's a very strong correlation between next-hop used and source address selected for addr-any sockets sending packets that will go via that next-hop.

My point is that the correlation is for the chosen interface. If there are two different first-hop routers out the same interface, then which router is used does not effect the next-hop.


So I think we are in violent agreement on this one.


Tunnels between routers in the /same/ IGP AS does not seem ideal. Just distribute the required source-routing information to those routers which need to be aware of it, eg using Opaque-LSAs. Have each border router originate a "I am a packet-sink for address-range X" LSA. Would require OSPF though - which isn't ideal.

Even if you extend your favorite IGP to carry information that helps the routers do source address based exit selection, it would be nice if you didn't have to fork-lift upgrade all the routers in the routing domain to know about this new feature.


Having the exit routers implement the new IGP thingy and encapsulate the packets across any routers that are between them means that the non-exit routers don't need to route packets on the source address.


This could be combined with some automatic protocol by which the border routers can inform the interior routers of which prefixes have failed, and the interior routers can advertise that in their RAs. (Something like an extension to RFC 2894 "router renumbering protocol" could be made to work.) However, such a protocol requires some security configuration, otherwise anybody on the Internet could use this to reconfigure the RAs your interior routers send.


One would hope this would this be a link-local protocol at least.. preferably with an HMAC or IPSec AH.

I don't understand how a link-local protocol can be used to carry information from a set of border routers to all the routers in the IGP.


Thus I don't think we can assume that some such, not yet invented mechanism for propagating information from border routers to interior routers, exist.


This leads me to conclude that we can't assume that source address selection can solve the ingress filtering interaction.


I disagree with this. Just because the required router protocol infrastructure does not exist is not a good reason to try bypass developing such infrastructure.

Develop all you want; I have no problem with that.

My problem is that you want to assume that what you've developed must be deployed in order to deploy shim6. I think shim6 should be deployable with just two hosts on the Internet being able to speak shim6, and not require that the IGP domains those hosts are in have deployed some new IGP and/or router renumbering protocol.

If there's customer demand for IPv6 multihoming (eg cause of shim6 ;) ) and then customers require facilities for steering packets to right ISP according to the source, and require a way to reflect prefix-availability AS-wide, the router vendors will respond.

Still doesn't make the customer's deploy it. If we want a solution that can be easily deployed then ideally it should only require touching one box in the Internet. We can do multi6 solutions with that property as long as it is acceptable that connections fail and need to be restarted; when new communication starts a host can be made to try the different destination and source addresses until it finds a working one.
But if we want connection survivability, then we must at a minimum touch the two hosts at the end.
I'm arguing that *requiring* that more than those two boxes are touched (upgraded to some new software, reconfigured, etc) is a bad idea.
Making shim6 work better if additional boxes are touched is fine.


And surely it's more sane to have border-routers be able to affect which prefixes are posted as 'available' by interior routers within an AS, to the hosts *before* they ever try pick a source?

I think it is a useful optimization, but we shouldn't make it be a requirement that such technology is deployed before shim6 can be deployed.


That prefix-propogation protocol could, at the same time, be used to install the required source-routes in the routers concerned to direct the packets to the border-router appropriate for the prefix concerned.

That seems achievable and also more proactive and sane than having hosts sending a multitude of packets with every combination of source and destination they have to hand, simply for the reason that "well, the routers don't have that mechanism yet".

When there is a deployed mechanism to convey failed prefixes to the hosts, then the effect will be that the hosts will not try the source address that are known not to work. Thus as such a mechanism is deployed, shim6 would more rapidly find a working address pair.


You seem to argue that shim6 should not be allowed to have the capability to explore all n^2 address pairs, which doesn't make sense to me. Having that capability is useful to remove the constraints on the order of the deployment of shim6 and source-based routing, and the end result is still an efficient exploration of the possible paths to which shim6 can failover.

I don't understand why a protocol for /tomorrows/ networks should be trying to hack around a lack of functionality in /todays/ interior routing, when the correct place is obviously to extend capabilities of interior routing (and IPv6 RAs).

Deployment considerations.
As well as the end2end argument; the network can't reliably indicate which address pairs are known to work and which are not known to work. As a result the hosts must be prepared to explore the different address pairs when the current address pair is no longer working.



Did it work without any manual configuration of the host?


*hosts*, and yes it did.

   ISP1-gw  ISP2-gw
        |    |
        |    |
        R    R
        |    |
     -----------
      | | | | |
       <hosts>

The hosts were configured with an address for each PA range, the routers did the magic.

Ah - I should have asked "did it work without any manual configuration?" ;-)

   Erik