RE: host-centric draft

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> The idea is that you build two separate layer 3 networks so that the
> host gets to make a choice in which network they inject the packet and
> then there is no complexity moving packets from the part that talks to
> ISP A to the part that talks to ISP B. The simple way to do this would
> be to have two network interfaces on each host, where one NIC has an
> address from ISP A and talks to routers that eventually connect to ISP
> A, while the other NIC has an address from ISP B and only talks to
> routers connected to ISP B. A slightly more complex way to do this
> would be to have the host use different virtual interfaces over a
> single NIC (using VLANs or some such).

Ok, i see what you mean now, but i am not sure that this approach is very
attractive though.

There are two possibilities, as you explain:

- different physical paths: this is very expensive, i guess and normally,
you don't have to build a parallel network when you add a new ISP. So, while
i can see that some networks, with extreme fault tolerance requirements may
find this attractive, i see it a bit too much for a general solution.

- VLANs approach. this would be an option. However, i am not so sure about
how simple to manage would this be. I mean you will have to create VLANs all
over the multihomed site, which AFAIK would be a manual process, right?. I
don't know, we can explore a bit more this, but i think that it would be
similar than using some sort of source address dependent routing, but even
more complex.


>
> >> The problem that rerouting could invalidate an earlier source address
> >> choice isn't mentioned.
>
> > Could expand this too? perhaps an example?
>
> Host X wants to talk to remote host Y. X sends packets with source
> addresses compatible with ISP A to a router that delivers the packet to
> ISP A and life is good, despite the fact that the router doesn't do
> source address based routing. Now the link to ISP A fails, so the
> router reroutes the packets to Y over ISP B. But now the source
> addresses used by this session are incompatbile with the way the packet
> is routed. Life is not so good, especially if this was a legacy session
> that doesn't support changing addresses during the session.
>
> Now in this example the problem isn't too bad because the session would
> have failed also if the site was single homed to ISP A. But if the site
> uses BGP to determine the best path, it may also reroute traffic over a
> different ISP if the first ISP is still available. So then we're
> breaking sessions that would have worked without multihoming. That
> can't be what we want. So any kind of dynamic best path selection can't
> be used unless ALL sessions can change addresses.

This would is addressed in the draft, since the rules for selecting the path
is first determined by the source address (no matter if the path is
preferred or not) and only if there is no path through the isp associated
with this source address the packet is discarded and the initiating host is
informed.
See the rules detailed in section 7.2.1

But anyway, i think that your concerns about bgp are more general than this
particular case, so let's consider this with a broader approach.


Remember that the draft only deals with the problem of discovering a
reachable locator for initial contact. It does not address the problem of
preserving established communications

There are two approaches proposed in the draft:

- A host based approach, where the host tries with all the possible
combinations of source and destination addresses (probably in parallel) and
it selects the combination that provides faster response.

- an hybrid approach, where the host tries with one combination of source
and destination address and instead of waiting until timeout, it is the
routing system that informs about reachability to the initiating host. That
means, routers close to the exit site run BGP and knows about which
addresses are reachable through which isps. Then the host generates a packet
with a given source and destination address, and when it reaches one of
these routers that run bgp, the routers knows if this packet will probably
make it or not, since it has knowledge about which destinations are
reachable through which providers.
So, if the router knows that the packet won't make it its final destination,
it just discards it and informs the host that it should try with a different
source address, or just abort, because the requested destination is
unreachable. This approach seems to provide a faster answer because the
router already has reachability information, as opposed to the host that has
to discover it through polling.

Now, your concern seems to be (as you have expanded in a following email)
that the information in the router is not really valuable, since most of the
time all the prefixes are in the global routing table, and that aggregation
hides most of the relevant information.

Do you have any data to back this up?

I don't really have a preference here about any of the two approaches, i
only think that running bgp would be too much for small sites, so host based
approach would suit better for this case.
But when considering medium/big sites, i get the feeling that people think
that BGP information is pretty valuable and that an hybrid approach would
provide some value. I mean, is what we use today, and packets make it most
of the time. But as you have mentioned already, as more aggregated the
routing tables are, the less valuable bgp information will be.


>
[...]

> > So the host obtained by the host is more accurate, but the routing
> > system
> > provides it faster, i guess.
>
> So the question is: can we detect the actual reachability using probes
> fast enough that we don't feel we also need to look in the routing
> tables? If end-to-end is 30 seconds while routing table is 30
> microseconds, then sure, I agree that the latter is useful. If
> end-to-end is 3 seconds, maybe having to wait this long some of the
> time is better than importing all this BGP complexity. If it's 300
> milliseconds I'm sure it is.

Actually i think that if we accept that bgp will only provide hints (how
strong they are, we haven't agreed yet), we may still have to rely on end
host probes when using BGP hints.



>
> >> I don't really agree. Applications need to try all addresses for a
> >> correspondent. Some do this today, most don't. And this needs to be
> >> done in a smart way, a four minute timout between trying successive
> >> addresses isn't acceptable.
>
> > Well, rfc 3484 already states that
> > "Well-behaved applications SHOULD iterate through the list of
> > addresses returned from getaddrinfo() until they find a working
> > address."
>
> > But i agree with you, something about this can be included here.
>
> > The other point about this is when considering retrying with different
> > source addresses. If you do this sequentially, i think that it would
> > be up to the app to retry.
>
> > However if you do it in parallel, i think that the ip layer could
> > simply
> > generate multiple packets and send them in parallel, so no need to
> > change
> > the apps.
>
> Agree. But then, we probably want to try multiple destination addresses
> at the same time too, which can't be done without changes. And we
> probably want to have a way to signal to the other side "these are all
> really the same session, don't be worried about the session setup being
> aborted for the alternative ones".
>

YEs but i am focussing only in discoverung a reachable locator for
initiating a communication :-)

Regards, marcelo