[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