[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LIN6 i-d for multihoming and mobility support
> - Latency due to query to MA: The MA is accessed only when a node
> starts communication. This would be insignificant.
I guess that whether this is insignificant or not will depend on the user,
but anyway let's just say that this is part of the cost of this solution.
>
> - MA for multihoming: It would be unnecessary only to support
> multihoming. However, LIN6 aims to solve not only multihoming
> but also mobility and other issues. The MA makes the Internet
> more flexible.
>
Mobility and multihoming problems share some issues. In particular they are
both caused by the dual role of the IP address (loc and id).
So some approaches that split the loc and the id can be used to address both
mobility and multihoming. So far i guess we agree.
OTOH a rendezvous point is only required to support simultaneous movement
(it is not even required to support client mobility)
So imposing the usage of a rendez vous point in a multihoming solution is
not natural and i cannot understand how it would make the internet more
flexible
I can see many problems introduced by it, though, as i mentioned in my
previous posting (delay, overhead, additional single point of failure for
which additional fault tolerance mechanism are to be implemented)
So, IMHO solutions for mh and mobility should share only the common parts
(i.e. loc/id split) and not devices specifically designed for one of the
problems.
What about the Otha's proposal of using the lin6 loc/id split without using
the MA?
Regrds, marcelo
> - We will revise Section 8 of our draft.
>
> Regards,
>
> Fumio Teraoka
>
> At 04/01/04 16:17 -0300, marcelo bagnulo wrote:
> >Hi Fumio,
> >
> >Some comments about this draft.
> >
> >My main concern about this proposal is about the Mapping Agent
> >
> >The mapping agent becomes a critical part since it is required
> to establish
> >the communication, so in a multi-homed environment, where do you
> place it?
> >do you place it in the multihomed site or in the isps? what
> happens if the
> >path to the MA is down? i guess that since one of the goals of
> multihoming
> >is the provision of a more resilient network, the inclusion of
> an additional
> >critical device must be very well justified and the potential failures of
> >such device must be studied in depth
> >
> >Besides, the usage of a mapping agent introduces additional latency and
> >traffic since, if i understood it correctly, several new round trips are
> >required i.e. a query to the MA from the initiator and a reverse
> DNS query
> >and a direct DNS query and a MA query from the receiver is also required.
> >These are a lot of additional packets and time required to initiate the
> >communication
> >
> >Finally, i really don't understand why the mapping agent is needed in the
> >multi-homed environment. I mean, i do understand that the MA is
> needed for
> >mobility, but i think it is not needed for multihoming. In the noid
> >proposal, the mechanism is similar (i think) but only the dns is
> used. This
> >is good because you don't add an additional critical device and
> you reduce
> >the packet exchanges (you don't have to query the MA)
> >
> >Additionally, there are multiple issues that are not addressed
> in the draft
> >and that IMHO it would be important to understand how they can
> be addressed
> >when using LIN6 like ingress filtering (you claim that this is
> not an issue
> >but i disagree), address selection for initial contact (especially source
> >address selection and how is this compatible with the ingress filtering
> >solution that you are planning to use), failure detection (how
> do you know
> >that you have to change the address that it is being used, and how do you
> >know if you have to change the destination or the source address)
> >IMHO all this problems have to be addressed in order to obtain a complete
> >multihoming solution and an analysis about how LIN6 is compatible with
> >proposed solutions for these issues would be interesting.
> >Additionally, i think it would be interesting to include a
> descrition of how
> >lin6 can cope with the threats described in the threats draft. I
> mean, lin6
> >introduces the MA which is susceptible to be attacked. In the security
> >section, it is claimed that this solution is not less secure
> than MIPv6, but
> >no comments are included for the multi-homing environment where
> no MIPv6 is
> >used.
> >
> >Regards, marcelo
> >
> >> -----Mensaje original-----
> >> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> >> nombre de Fumio Teraoka
> >> Enviado el: martes, 30 de diciembre de 2003 10:25
> >> Para: multi6@ops.ietf.org
> >> Asunto: LIN6 i-d for multihoming and mobility support
> >>
> >>
> >> Hi all,
> >>
> >> I have just submitted draft-teraoka-multi6-lin6-00.txt that describes
> >> multihoming and mobility support based on LIN6. Sec.8 discusses
> >> the features of LIN6 based on RFC3582.
> >>
> >> The draft is available from the following URL:
> >>
> >> http://www.tera.ics.keio.ac.jp/person/tera/multi6/draft-teraoka-mu
> >lti6-lin6-00.txt
> >
> >Comments are welcome.
> >
> >Fumio Teraoka
>
>