[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: about draft-ohira-assign-select-e2e-multihome-00.txt (was :Re: Callfor presentations)
There are really four classes of solutions to the conflict between site multi-homing and ingress filtering.
The simplest solution is to inform each provider about all the valid prefixes for the site. This is probably OK for large sites, when the providers have a willingness to cooperate. It is probably not a good solution for very small sites, unless we can somehow automatize the management of these filters. That solution does not require any change in either hosts or routers.
Another solution is to make sure that hosts always pick the right exit. For example, if a host hears announcements from several routers, it could decide to perform some level of source routing, essentially considering each separate router announcement as defining a different "sub interface". This is OK for single link networks, but will not work for routed sites. It require some change to the host implementation, no change to the exit router implementation.
The third solution is to use a redirection mechanism from the routers. It requires that exit routers be aware of ingress filtering, and of each other. In a single link network, routers listen to each other router announcements. When an exit router receives a packet bound to an exit route, it checks whether there would be an ingress filtering violation. If yes, the router redirects the packet to the proper exit -- a simple forwarding decision in a single link network. The router could send an ICMP redirect to the host, but there is a small problem of semantics -- redirection is normally based on the destination address, while ingress filtering decisions are based on the source address. If we forget redirection, the solution does not require any change in the host software.
The fourth solution is to implement some variation of source dependent routing, so packets are routed to the right exit.
________________________________
From: owner-multi6@ops.ietf.org on behalf of Kenji Ohira
Sent: Wed 7/9/2003 3:54 AM
To: marcelo bagnulo
Cc: multi6@ops.ietf.org; FUJIKAWA Kenji
Subject: Re: about draft-ohira-assign-select-e2e-multihome-00.txt (was :Re: Callfor presentations)
[ post by non-subscriber. with the massive amount of spam, it is easy to miss
and therefore delete posts by non-subscribers. if you wish to regularly
post from an address that is not subscribed to this mailing list, send a
message to <listname>-owner@ops.ietf.org and ask to have the alternate
address added to the list of addresses from which submissions are
automatically accepted. ]
Marcelo,
Please forgive me for my late reply.
At the beginning, I revised my draft. So please read my revised draft.
It can be downloaded from
ftp://ftp.ietf.org/internet-draft/draft-ohira-assign-select-e2e-multihome-01.txt .
> What do you mean by "the proposed way to multi-home"?
> I mean, I couldn't find in the draft a description of any mechanisms to
> multi-home...
My proposal can be summarized as follows.
1. Assign IP addresses hierarchically.
e.g.: When a site A subscribes to a local ISP L and M, a host H in
the site A has addresses L:A:H and M:A:H.
2. Use source address based routing.
In case of the above example, a packet with L:A:H as source
address will go through ISP L and a packet with M:A:H as source
address will go through ISP M. End hosts (further more, end
applications) can select which ISP a packet will go through.
> I guess that there should be a reference to a concrete mechanism
> proposal, Otha's e2e multihoming perhaps? but there are no references in
> the draft, could you clarify this form me?
Too right. My draft is based on Ohta's e2e multihoming.
It is my mistake that the old draft did not have reference to Ohta's
draft. So I added the reference to my revised draft.
Then, some points are different from Ohta's draft.
First, I think that if we assign IP addresses hierarchically then all
nodes do not have to know full routes.
Second, we proposed to use source address based routing.
It allows end hosts to select prefer route without full routes.
At this time, it should be noted that source address based routing is applied
only to default routes because if a node have some explicit route then
it is reasonable to use that explicit route.
> Besides, if i understand the draft correctly, it is about ingress
> filtering and source address based routing, so have you checked C.
> Huitema's draft about host centric multi-homing?
Following your indicate, I read Huitema's draft and I understand that
Huitema's solution is using tunnel at site exit router.
It sounds good because Huitema's solution does not require any
changes on end hosts and routers in a site (except for site exit routers).
However, using tunnel sometimes causes routers to select not prefer
route. Still more, site exit router may become single point of failure.
And then, it is the most important point, we regard selecting source
address as selecting route. Selecting source address is no less important
for end hosts (furthermore, applications on the end hosts) to select proper
route than selecting destination address. Even if there is no ingress filter,
each packet should go through adequate site exit router according to its
source address.
At this time, it should be noted that Huitema's proposal is considerable
as an option while routers and/or hosts do not support source address
based routing enough.
Best regards,
July 9, 2003 (JST +0900)
----
Kenji Ohira
Graduate School of Informatics, Kyoto University, JAPAN
mailto: torus@tori.cc / ohira@net.ist.i.kyoto-u.ac.jp