[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03
El 22/02/2006, a las 16:50, Erik Nordmark escribió:
- OTOH, another option is to use the routing system for policy, in
particular, we allow source address rewriting by exit routers and we
use the intra site routing to divert the outgoing traffic according
to policy and we use the source address rewriting to make the source
address compatible with ingress filters and eventually if the peer is
willing to reply to the address it received as source locator in
incoming packet, this mechanism could be used to influence the
locator selection of the other end. In any case, i think that the
host may need to be allowed to avoid address rewriting especially due
to fault tolerance issues, since the host probably knows better.
There certainly are interactions between the hosts' knowledge of what
is working and an implicit or explicit signal from the routers. Did
you have specific fault tolerance issues in mind?
Well, i was worried about aggregation and the limitations that this may
have w.r.t. fault tolerance, but now thinking it over, i am not sure if
this would be a problem.
I was thinking about the following scenario:
Suppose that we allow site exit routers to rewrite source address
prefixes.
Suppose now that we inject BGP feed to the multihomed site routers
Now, through BGP routers know which egress path is available and
preferred to reach a given destiantion and if this egress path brokes
they can select another one through BGP route selection. This would
provide BGP fault tolerance. (Clearly when BGP decides to use a
different egress path, a different source address prefix is to be used
in order to deal with ingress filters, hence we need source address
prefix rewriting)
The limitation of BGP fault tolerance is aggregation. I mean, BGP will
continue announcing a prefix as reachable, even if a particular address
of that prefix just went down.
My concern was that BGP may prefer a given route to a prefix, even if
the particular address where the traffic is addressed to is
unreachable.
However this may not such a problem, since in order to overcome this
failure, what is probably needed is to change the _destiantion_ address
(not the source address, which is influenced by BGP).
So, probably the distribution of tasks would be:
- both host and routers work on fault tolerance
- the site routers through BGP information select the best available
exit path (and select the source address prefix rewriting it
accordingly to the exit path selected)
- when the host detects a failure, it just selects an alternative
destination address (and then the site routing system will select a new
egress route accordingly)
I am not sure if additional host-router interaction is needed (i.e. not
sure if need to allow the host to disable rewriting as i was claiming
before)
In addition, we can configure routers to express policy, like
preferring some egress routes towards certain destiantion, just as is
currently done. this would affect how the traffic for a given
destiantion is routed.
In addition, we may need to influence the host when it performs the
destiantion address selection, in order to be able to express policy
with respect to which destiantion addresses to prefer. This can
probably be done with the RFC3484 policy table (if it is considered
when performing locator selection, which we haven't discussed yet)
Allowing rewriting the shim6 control packets could be useful
especially to benefit from the knowleddge available in the routing
system of which routes are available to the destiantion and not
forcing the usage of the ISP associated to the source address
selected by the host, but i am not sure about the complexity of
supporting this...
Which is why I was going to try to write it up in a separate I-D - to
see how complex it might be and also understand the issues and
benefits around it a bit more.
yes, this would be helpful indeed
regards, marcelo
Erik