[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03



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. 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.

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.

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.

Hope this helps a bit,

regards, marcelo