[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,
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
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).
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.
| | | | |
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?" ;-)