RE: survivability, rewriting

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

Hi Iljitsch,

I very much agree with you here.
Some comments below...

>
> I maintain that having the transport layer provide hints to the
> multihoming layer about when a rehoming would be desired is the right
> approach.

At least we should explore what we can achieve following this path.

> Yes, this will give us some trouble in the beginning, as
> existing upper layer protocols don't provide these hints yet. So we
> implement additional heuristics so the multihoming layer can rehome on
> its own. But this is never going to be as efficient as having the
> transport layer do it, as transport protocols have very good knowledge
> about what's happening end-to-end.

Agree

> One thing we haven't discussed so far: if upper layers provide us with
> a hint, what exactly does the multihoming layer do after receiving such
> a hint?

I thought this was what we were discussing with Erik in the Preserving
established sessiones thread :-)

 It would make sense to peform some kind of check to see what
> kind of reachability exists, but this means we need some kind of
> ping-like functionality. Is it reasonable to depend on such a mechanism
> in this age of ICMP paranoia?
>

IMHO, i would like to explore alternative approaches first.
What about when recieving a ULP hint that there is a problem, change both
source and destiantion locators and send the packet with rewrite ok bit not
set?
A more aggresive option would be to send multiple packets in paralel, each
one with a different combination of source and destiantion address, and see
which reply comes first.

> About the rewriting: why again are we making life difficult for
> ourselves? The obvious place to put an indication that the address may
> be rewritten is... in the address. Is there any reason why we can't
> have one or more special prefixes that indicate that a router should
> fill in the source address?
>
> However, this doesn't solve what we should do when rewriting isn't
> permitted. Obviously we could come up with a multihoming mechanism
> where rewriting is always allowed,

I don't see how.

I mean, we are going to have two mechanisms, one based on bgp + rewriting
and the other one is based on ULP hints.
Now it is expected that the ULP hints mechanism will be have a better
response time i.e. it will detect problems faster, right?
However, the ULP hints mechanism works in the host itself and the
bgp+rewrite mechanism is in the routers. This means that even if the ULP
hint mechanism has detected a problem and changed the locator, if the final
word about this belongs to the routing system, the bgp+rewriting mechanism
will overrule the decisions made by the ULP hint mechanism which is exaclty
what we don?t want, since the ULP hint mech is faster)
So we need a mechanism to force the routing system to accept choices made by
the host, since the host is better detecting problems in the path.
Such a mechanism seems to require the capability to express that rewriting
is not permited.

Note that only the ULP hints mechanism is not enough, since for a while we
will have ULP that don`t provide hints, so we need a fallback mechanism


 trading off complexity in this area
> against complexity in recognizing a correspondent and accepting some
> types of spoofed packets. But "legacy" IPv6 also doesn't permit
> rewriting, so we must be prepared to handle this. The obvious solution
> is source address based routing, but it doesn't seem like everyone is
> convinced.
>
> I don't really see any workable alternatives, though.

Well, we could use a routing header. Even we could define a routing headers
that is elimated by the exit routers, in order to addresss the MTU reduction
problem.

> Even if we can do
> ICMP or NAROS magic to make sure that new sessions magically use the
> right source address so initially they're able to pass ingress
> filtering, it's always possible that halfway through the session is
> rerouted over another ISP and the source address is filtered. This
> means we can't reroute traffic based on changes in BGP the way we're
> used to, the ultimate consequence of which is that we must hardcode all
> routing decisions. In practice this probably means using one ISP as a
> primary and the other one only as a backup.
>

agree

> Another problem is that if we depend on BGP to determine which ISP
> provides the shortest path to a destination, this effectively blocks us
> from using the other ISP to reach the same destination. For instance,
> if X has ISPs A and B, and Y has ISPs C and D, then it's entirely
> possible that X will use ISP A to reach both Y(C) and Y(D), so that
> when something bad happens with ISP A both of Y's addresses become
> unreachable. With source address based routing this isn't an issue as X
> can reach each of Y(C) and Y(D) over both A and B by simply using a
> different source address.
>

agree (again)

> I do agree that source address based routing (which is in effect a
> limited form of source routing) doesn't mesh well with our hop by hop
> forwarding paradigm, but again: I don't see any alternatives.
>

An obvious comment about source address based routing is that source address
based routing only has to be implemented within the multihomed site.

Thanks, marcelo

>