The IESG has approved the Internet-Draft 'Goals for IPv6 Site-Multihoming Architectures' <draft-ietf-multi6-multihoming-requirements-07.txt> as an Informatinal RFC. This document is the product of the Site Multihoming in IPv6 Working Group. The IESG contact persons are Randy Bush and Bert Wijnen
All, below you will find the draft agenda for the Vienna IETF meeting, for the two multi6 sessions. Presentations are in the order they have asked to present, and time have been allocated as people have asked for it. Notice that this a) Leaves us with an extra hour in the second session b) Although I would like us to save deeper discussions for the open mike in the second slot, I think some of the time estimates in the first slot might be optimistic and if we are getting delayed we might want to move some presentations to the second slot as well. Best regards, kurtis - Monday Slot *********** draft, presenter, time Agenda bashing, welcome, etc, Chairs, 5 min draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min For background:(Continue reading)
Hash: SHA1 Monday Slot *********** draft, presenter, time Agenda bashing, welcome, etc, Chairs, 5 min draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min For background: draft-moskowitz-hip-arch-03.txt draft-moskowitz-hip-07.txt draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min(Continue reading)
[ 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 <at> 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
(Continue reading)
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 <at> ops.ietf.org on behalf of Kenji Ohira Sent: Wed 7/9/2003 3:54 AM To: marcelo bagnulo(Continue reading)
Le mer 09/07/2003 à 12:54, Kenji Ohira a écrit : > 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. > AFAIK the 2 points above were also suggested in Huitema's draft. >From my point of view your suggestion is : 1. Use Huitema's Host-Centric Multihoming with source-base routing 2. Let the end-hosts' applications decide which source address to use, i.e. change end-hosts' API and applications (this is not clear in your draft) Is that correct ? If yes, how do you perform the source address selection ? Does that mean that all applications on the end hosts need to be modified in order to benefit from multihoming ? Cédric
Huitema, > 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. > Another solution is to make sure that hosts always pick the right exit. > The third solution is to use a redirection mechanism from the routers. > The fourth solution is to implement some variation of source dependent routing, > so packets are routed to the right exit. Your analysis is so thorough that the method which I propose is classified into the fourth of your classification. However, I think that the most essential difference between you and me is the goal. As you said above, your goal is to get around ingress filter in multihoming environment. On the other hand, my goal is that end hosts (to be exact, applications which run on those hosts) will be able to select the adequete site exit router even if there are no ingress filters. July 11, 2003 (JST +0900) ---- Kenji Ohira Graduate School of Informatics, Kyoto University, JAPAN mailto: torus <at> tori.cc / ohira <at> net.ist.i.kyoto-u.ac.jp
Cedric, > > My proposal can be summarized as follows. > > 1. Assign IP addresses hierarchically. > > 2. Use source address based routing. > AFAIK the 2 points above were also suggested in Huitema's draft. > >From my point of view your suggestion is : > 1. Use Huitema's Host-Centric Multihoming with source-base routing > 2. Let the end-hosts' applications decide which source address to use, > i.e. change end-hosts' API and applications (this is not clear in > your draft) > Is that correct ? Yes. You are faultlessly correct. > If yes, how do you perform the source address selection ? First of all, I think that multihoming can not nor should not be conclude within IP layer and that the source address selection is not issue in IP layer similarly. So, this issue is out of scope of my draft. Still more, this is why the title of my draft is not 'host-centric' but 'end-to-end' multihoming. Of course, I know that this issue is still difficult in transport or application layer. In my draft, I introduce a naive but workable method that examining each path determined by a pair of source address and destination address one by one in order of match length between the source address and destination address. Here, I would like to introduce more intelligent mechanism of selection such as your NAROS system. > Does that mean that all applications on the end hosts need to be > modified in order to benefit from multihoming ? No. I think that we can assume a certain 'typical model' of application and that(Continue reading)
Kurt; > below you will find the draft agenda for the Vienna IETF meeting, Thanks. There are a lot of ID listed. Can we ignore other IDs or are there any ID which should be read before the meeting? > - - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min > > - - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min The 05 draft is revised from the previous one by including ISP multihoming issues and a design frame work section. Masataka Ohta
>> below you will find the draft agenda for the Vienna IETF meeting, > > Thanks. > > There are a lot of ID listed. > > Can we ignore other IDs or are there any ID which should be read > before the meeting? Well, there is a lot of history but I am not sure that is all that relevant for Monday. Ofcourse, having read the relevant RFCs and other drafts are always a good thing(tm) but we will not put those in the multi6-WG exam..kurtis -
RSS Feed1 | |
|---|---|
5 | |
3 | |
1 | |
4 | |
1 | |
2 | |
5 | |
12 | |
11 | |
41 | |
28 | |
170 | |
102 | |
14 | |
67 | |
175 | |
230 | |
79 | |
82 | |
217 | |
146 | |
245 | |
97 | |
242 | |
184 | |
100 | |
88 | |
227 | |
88 | |
369 | |
165 | |
352 | |
200 | |
85 | |
128 | |
421 | |
326 | |
1 | |
1 | |
23 | |
18 | |
6 | |
3 |
