On Thu, Feb 16, 2006 at 03:39:07PM +0100, marcelo bagnulo braun wrote: > Hi Shinta, > > El 15/02/2006, a las 6:25, Shinta Sugimoto escribió: > > > >>>>1.7 Traffic Engineering > >>>> > >>>> At the time of this writing it is not clear what requirements for > >>>> traffic engineering make sense for the shim6 protocol, since the > >>>> requirements must both result in some useful behavior as well as > >>>>be > >>>> implementable using a host-to-host locator agility mechanism like > >>>> shim6. What is clear that whatever they are, shim6 will not be > >>>>able > >>>> to provide identical capabilities to traffic engineering using > >>>>BGP > >>>> and Provide Independent IP addresses. > >>> > >>>It was not clear to me what the above paragraph means. > >>>Could someone elaborate more on this ? > >> > >>Let me know if this is more clear: > >> > >>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. > >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. > > > > Well, i would say that Traffic engineering is about how to influence > routing (i.e. path selection) based on policy considerations > > So, as Erik points out above, in the IPv4-BGP-style multihoming, TE and > path selection is performed by changing BGP knobs when announcing > routes. In particular, it is the guy that is configuring the BGP router > the one that will try to influence the path selection (using stuff like > AS path prepending, more specific routes, MED attributes, > communities...). Moreover, because each direction of the packet flow is > influenced by the route announcement, TE is likely to be set per > direction. Yep. > OTOH, in the SHIM model, each egress path of the multihomed site is > associated with a given prefix. This basically means that selecting a > prefix of a multihomed host, implies the selection of the path of the > multihomed site used to reach that host. This selection is performed by > the host, so it is up to the host admin to actually select the path. Also true. > So, in BGP-IPv4-PI style multihoming, the elements involved in TE is > router configuration, BGP attributes and Network admin of the > multihomed site. > In SHIM6-multiple PA style multihoming, the elements involved is the > host itself, address selection techniques and policies, and even DNS > information published and the host admin. Again, true. > Another difference is that in BGP style multihoming, the traffic is > influenced in a per direction basis i.e. all the traffic flowing in one > direction is affected by a given set of knobs. OTOH, in the shim model, > the traffic is influenced by the endpoint that initiates the > communication, since it is the one that performs address selection in > the first place, so, it doesn't matter so much in which direction the > traffic is flowing but rather which endpoint had initiated the > communication. > Have folks seen Jason Schiller's slides from NANOG 35? Might be useful to review those for some of the issues that (some set of) providers are seeing: http://www.nanog.org/mtg-0510/pdf/schiller.bof.pdf Dave
Attachment:
pgpoYyz0WwGoY.pgp
Description: PGP signature