[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03
Hi Erik,
El 17/02/2006, a las 19:53, Erik Nordmark escribió:
The total size of the policy would be large. But if it is mostly
static then it might be manageable.
We can still do load spreading and primary/fallback with a static
policy; the policy can be expressed akin to DNS SRV records with a
priority (for primary/fallback) and a weight (for load spreading), and
the client of the policy evaluates this.
I think this approach is quite attractive, especially becuase it not
only applies to SHIM6 traffic (i.e. the traffic of those communications
that have established a SHIM6 session) but it would affect to all the
_incoming_ traffic of a multihomed site.
I mean, having a TE tools based on the usage of the SHIM6 protocol
(like using the SHIM6 locator prefernces) it would only affect the
traffic of the SHIM6 enabled communications, but it would not affect
the packets of those communications that will not use or are not yet
using the shim6 protocol. OTOH, if the shim6 protocol proves to be a
useful TE tool, this may encourage users to establish shim6 sessions,
not just to obtain fault tolerance but also to achieve some form of TE.
However, there are tools that may apply to both non-shim and shim
traffic, especially:
- DNS SRV records for affecting the traffic of those communications
that are externally initiated
- configuring the RFC3484 policy table to affect the traffic of those
communications that are internally initiated
more about shim6 based policy below...
If you want the policy to change due to dynamic events, even if it is
just based on different policies for different times of day, then
things get hard.
But this also assumes that anybody that connects is allowed to see the
policy to be able to do the evaluation of what locator to use. That
might run into trouble with existing practices.
An alternative would be to have some TBD mechanism (some new DHCP
option?) for the destination site to distribute its policy (e.g., in
the form of priorities and weights) to all the hosts in the site, and
then use shim6 to express those to every peer that connects to a host
in the site.
Thus at a gross level I see two different ways to factor the system:
A. An ID->loc lookup system which takes some policy into account.
I am not sure what do you have in mind for this.... are you thinking
about something like Naros?
B. An ID->loc lookup system without policy, plus
policy distribution within each end site and host-to-host exchanging
of preferences when they start communicating.
For both approaches there is the question how useful it is to allow
routers to rewrite the source locators.
I know how to build B out of existing components. But B doesn't allow
a transit ISP to express their policy; only the end sites can do it.
On the other hand, I have no idea what the threat model is for A; how
to make a distinction between a legitimate ISP on the path, and an
attacker?
Hmm - perhaps we should write this up in an I-D?
I'm sure there are more details to discuss, and I'd really like to
explore this more to determine whether we need to do shim6
differently.
And, from my understanding of approach B, the only open question in my
mind is whether we need to make shim6 allow locator rewriting on its
I1, R1, etc control messages.
I think i am not completelly following you...
I mean i can see two different approaches to shim6 policing:
- on one hand, an endpoint based approach where, somehow the policy is
pushed to the hosts themselves (e.g. using a DHCP option). In this
case, the policy is used by the host at two instances: first, when it
starts a communication, it uses the policy information to select the
ULIDs and eventually its own locators. Second, the host may try to push
the policy to the peer, using the locator preference option. In this
option, there is no need to support address rewriting by the exit
routers, since policy is pushed from the policy manager to the hosts
themselves.
- 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.
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...
Regards, marcelo
Erik