[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-shim6-proto-03
On Thu, 16 Feb 2006, Erik Nordmark wrote:
> Yes, but that isn't a property of "host centric" - it is a property of
> any scheme that would have multiple prefixes for a multihomed site (even
> for instance if the multiple prefixes are handled by some
> routers/proxies at the site boundaries).
> You end up with multiple addresses in the DNS so that the initial
> contact can be robust against a single failure.
The problem here is not not the multiple addresses, but rather a partial
ID / locator split. As long as DNS contains information about both the
identity of the host and the location of the host then the ID and the
locator are not completely split. This creates the problem of sifting
through DNS, and making the solution non-useful for short lived
sessions. Also, this problem is what is creating the push for provider
independent (PI) IPv6 space to avoid "provider lock-in".
Imagine instead DNS only has knowledge of the identity, say the host
address, local subnetting and a way to uniquely identify the site. The
source host builds a packet and kicks it to the network without the
locator information. The network needs some mechinism to map the site
identity to one or more locators. In this model the source host,
destination host, and DNS system don't care about location. This is left
up to some protocol in the network. On ingress this could be easy for the
source, just pre-pend your routing locator. For the destination there
would need to be some mapping of site ID to one or more locators. The
network could pick the most convient locator for the destination.
This same site ID to locator mapping protocol could be used by transit
ASes to rewrite the destination locator information and forward the
packet towards the destination at an alternate location. Transit ASes
that don't wich to perform TE can simply forward the packet and do not
require the added site/locator state.
I'm not sure this scales any better than de-aggregation as all ingress
routers and any transit routers that want TE will need state to map one or
more locators to every site.
___Jason
==========================================================================
Jason Schiller (703)886.6648
Senior Internet Network Engineer fax:(703)886.0512
Public IP Global Network Engineering schiller@uu.net
UUNET / Verizon jason.schiller@verizonbusiness.com
The good news about having an email address that is twice as long is that
it increases traffic on the Internet.
On Thu, 16 Feb 2006, Erik Nordmark wrote:
> Date: Thu, 16 Feb 2006 11:06:08 -0800
> From: Erik Nordmark <erik.nordmark@sun.com>
> To: Shinta Sugimoto <shinta@sfc.wide.ad.jp>
> Cc: shim6@psg.com
> Subject: Re: comments on draft-ietf-shim6-proto-03
>
> Shinta Sugimoto wrote:
>
> >> Inherent in a scalable multihoming mechanism that separates locators
> >> from identifiers is that each host ends up with multiple locators.
> >> This means that at least for initial contact, it is the remote peer that
> >> needs to select which peer locator to try first. In the case of shim6
> >> this is performed by applying RFC 3484 address selection.
> >>
> >> This is quite different than the common case of IPv4 multihoming where
> >> the site has a single IP address prefix, since in that case the peer
> >> performs no destination address selection.
> >>
> >> Thus in "single prefix multihoming" the site, and in many cases its
> >> upstream ISPs, can use BGP to exert some control of the ingress used to
> >> reach the site. This capability can't easily be recreated in "multiple
> >> prefix multihoming" such as shim6.
> >
> > I am not sure if I understand the above texts correctly, but my
> > interpretation of above texts is that the host centric approach
> > (or the concept of id-locator split) of SHIM6 in which a host should
> > deal with multiple locators at a time has implications on source &
> > destination address selection to be done by the end nodes.
>
> Yes, but that isn't a property of "host centric" - it is a property of
> any scheme that would have multiple prefixes for a multihomed site (even
> for instance if the multiple prefixes are handled by some
> routers/proxies at the site boundaries).
> You end up with multiple addresses in the DNS so that the initial
> contact can be robust against a single failure.
>
> > In contrasts, under single prefix multihoming environment, there is
> > no such requirements for the end nodes but routers inside the network
> > are required to somehow manage routing information so that the IP
> > packets destined to the node which has IP address derived from the
> > multihomed prefix. But,, I wonder how this relates to Traffic
> > Engineering. I should admit that I don't have deep insight into
> > Traffic Engineering, though.
>
> It does have implications on traffic engineering.
>
> But any scalable multihoming approach needs to have multiple prefixes
> for a site in order to avoid a route in the Default-free zone for every
> multihomed site. So as a first order approximation, this impact on TE is
> fundamental to the problem we are trying to solve and not specific to shim6.
>
> There are differences on how a site administrator or an ISP can
> influence the locators that are used, for instance Mike O'Dell's
> original GSE proposal has locator rewriting as a way for routers to
> influence the choice *after* the first packets have been exchanged. I
> don't know if such a capability would be useful for shim6.
>
>
> >>>> o Some heuristic on A or B (or both) determine that it might make
> >>>> sense to make this communication robust against locator failures.
> >>>> For instance, this heuristic might be that more than 50 packets
> >>> s/heuristic/heuristics/
> >> Singular form is without the 's' AFAIK.
> >
> > I am not a native English speaker but my dictionary says that "heuristic"
> > is adjective and "heuristics" is noun (uncountable).
>
> Neither am I. But the dictionary doesn't seem to match common computer
> science usage. "a heuristic" is used in
> http://en.wikipedia.org/wiki/Heuristic_%28computer_science%29
>
> Erik
>
>
>