[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: addition of TLV to locator ID or locator ID set
Brian,
I'm certainly not opposed to your suggestion. In fact it makes the shim6
more like site multihoming and less like host multihoming and probably
removes one big operator concern that they don't want to manage the
network level traffic engineering on every host.
I think I would like to be more clear on your approach.
>
> Exactly - that's what I mean by using a policy mechanism - have the site
> boundary routers distribute address selection policy. That is orthogonal
> to the shim and we probably need it anyway, for exit router selection.
One interpretation is to configure the inbound link preferences on all
border routers. There would be some protocol to signal these preferences
to all local hosts. When a host is acting as a destination, it would have
to signal its inbound link preference (that was learned from the border
routers) to the source host who is sorting the locators.
Having site boundry routers that are local to the source instructing the
source host how to order the destination locators will only work if we
de-aggragate the IPv6 routing. Without de-aggragation, the site boundry
routers that are local to the source will lack the needed state to make a
correct choice.
It is possible to have the site boundry routers that are local to the
destination instruct the source how to order the dstination locators.
You can also take the approach of moving the shim function to the border
routers.
You can leave the shimming function on the end hosts and allow
intermediate routers the ability add or change information in the shim
You can leave the shimming function on the end hosts and insert an
additional shim by intermediate routers such as Paul Jakma suggets.
___Jason
==========================================================================
Jason Schiller (703)886.6648
Senior Internet Network Engineer fax:(703)886.0512
Americas' Network Engineering schiller@uu.net
UUNET, an MCI brand jason.schiller@mci.com
Keeping the spirit of UUNET engineering alive!
On Thu, 29 Sep 2005, Brian E Carpenter wrote:
> Date: Thu, 29 Sep 2005 13:07:17 +0200
> From: Brian E Carpenter <brc@zurich.ibm.com>
> To: shim6@psg.com
> Subject: Re: addition of TLV to locator ID or locator ID set
>
> See below... this piece of the conversation accidentally went
> off-list.
>
> Jason Schiller (schiller@uu.net) wrote:
> > Brian,
> >
> > Feel free to drop this to the list.
> >
> > ___Jason
> > ==========================================================================
> > Jason Schiller (703)886.6648
> > Senior Internet Network Engineer fax:(703)886.0512
> > Americas' Network Engineering schiller@uu.net
> > UUNET, an MCI brand jason.schiller@mci.com
> >
> > Keeping the spirit of UUNET engineering alive!
> >
> > On Fri, 23 Sep 2005, Brian E Carpenter wrote:
> >
> >
> >>Date: Fri, 23 Sep 2005 08:39:57 +0200
> >>From: Brian E Carpenter <brc@zurich.ibm.com>
> >>To: "Jason Schiller (schiller@uu.net)" <jason.schiller@mci.com>
> >>Subject: Re: addition of TLV to locator ID or locator ID set
> >>
> >>I see that I accidentally dropped the list from my message -
> >>that wasn't intentional. Is it OK if I reply to you on the list?
> >>
> >> Brian
> >>
> >>Jason Schiller (schiller@uu.net) wrote:
> >>
> >>>Brian,
> >>>
> >>>This certainly is an important point that I have thought about.
> >>>
> >>>The point I have been trying to make is that this trafic engineering
> >>>functionality is needed. It seems that people are not interesting in this
> >>>problem partly because they feel it doesn't impact the protocol.
> >>>
> >>>So I am attempting to break through by approaching the problem of getting
> >>>traffic engineering functionality into shim6 not as an opperational
> >>>requirment, but from the oppsite direction of protocol changes which are
> >>>needed to support this.
> >>>
> >>>You point out an interesting mis-match. The problem is that the current
> >>>traffic engineering in IPv4 is done at the network level. Shim6 is
> >>>between two end hosts. Shim6 is not site multihoming, it is host
> >>>multihoming.
> >>>
> >>>How do you add network wide traffic engineering preferences to the host to
> >>>host shim6 solution?
> >>>
> >>>It seems to me there are three approaches:
> >>>1. Some how get the source end system to sort the locators in the correct
> >>>order by giving it additional information and having it do forwarding
> >>>plane measurements.
>
> I think this asks too much of the hosts. We've always tried to avoid
> the hosts requiring real routing knowledge, as a matter of principle.
>
> >>>
> >>>2. Let the end systems choose what ever locator and allow the routers to
> >>>record locator set information. Allow routers to recognize a destination
> >>>address as one out of the locator set, and replace it with a different
> >>>destination address if there is a different locator which is better (or
> >>>at least forward towards a different address if a different locator is
> >>>better).
>
> I have concerns about this. It takes us straight back to 8+8
> and all the resultant concerns. (As I already said, if this is viewed
> as part of a network stack offload, it could work, but that's not
> what you are describing here.)
>
> >>>
> >>>3. Let the routers reach into the locator set exchange and add additional
> >>>information or modify the locator set exchange in some way.
>
> Exactly - that's what I mean by using a policy mechanism - have the site
> boundary routers distribute address selection policy. That is orthogonal
> to the shim and we probably need it anyway, for exit router selection.
>
> >>>
> >>>Mangeling packets on the fly by routers seems a bit scary. I think that
> >>>this sort of a solution was intorduced early on and has been rejected.
>
> Exactly.
>
> >>>
> >>>
> >>>But you are right, adding traffic engineering capabilites to the end hosts
> >>>does creates three interesting problems.
> >>>
> >>>1. Configured in the right place
> >>>
> >>>It is not clear to me that the folks who operate the Internet facing
> >>>routers also own the configuration of the end systems. Even if they do,
> >>>its likely that they would rather administrate the traffic engineering
> >>>policy on a few Internet facing routers than on every end host in the
> >>>network. And what about end-user who think they know better about what
> >>>link they want to use, will they be able to over ride the network wide
> >>>preferences?
>
> That is indeed part of the discussion of a policy mechanism - who wins
> when policies conflict?
>
> >>>
> >>>So If this needs to be administrated at the network level, are we talking
> >>>about deploying a TE server, or adding functionality to routers so that
> >>>they can instruct end systems on what the network wide in bound traffic
> >>>engineer preference is? This seems like an awful lot of complexity, and
> >>>what security concerns does this bring up?
>
> Yes, there's complexity, which is a worry, and a reason to separate this
> conceptually from the basic shim logic. And it would have to be immune to
> active attack.
>
> >>>
> >>>2. Shortest exit out bound
> >>>
> >>>Today in IPv4 if two routes are equal, the BGP tie breaker is IGP distance
> >>>to the exit point of the network. Operators will often tweak IGP metrics
> >>>to slightly modify out-bound traffic loading charastics. If the source is
> >>>choosing destination A over destination B and the source has no IGP
> >>>information to base this decesion on, then this functionality is lost.
>
> Right. So the policy mechanism needs at least that much power.
>
> >>>
> >>>3. Transit AS traffic engineering
> >>>
> >>>Transit ASes lack useful traffic engineering for transit traffic.
> >>>
> >>>In the diagram below take that the source AS is sending traffic to the
> >>>destination AS.
> >>>
> >>>Assume that in the IPv4 world the destination is using the default BGP
> >>>configuration (not setting any MED, local pref, etc). Also assume that
> >>>the destination is advertising a /24 which appears in the global routing
> >>>table as a /24.
> >>>
> >>>In this case the source can choose to send the traffic to transit AS1 or
> >>>transit AS2. If the traffic reaches If the traffic reaches AS1, then AS1
> >>>can choose to send the traffic via AS3 or AS4. This can be based and exit
> >>>cost to AS3 and AS4 or based on some policy such that AS3 is a peer and
> >>>AS4 is a transit provider.
> >>>
> >>>AS1 can choose to distance some of the routes or all of the routes behind
> >>>AS3. AS1 can choose to make some of the entrance points closer or farther
> >>>to AS3 as compaired to AS4.
> >>>
> >>>
> >>>
> >>> ---AS1-----AS3---
> >>> / \ / \
> >>> / \ / \locator 3
> >>>source AS X dest AS
> >>> \ / \ /locator 4
> >>> \ / \ /
> >>> ---AS2-----AS4---
> >>>
> >>>
> >>>In the case of shim6, the source chooses to build the IP packet with a
> >>>source of either locator 3 or locator 4. When the traffic reaches AS1,
> >>>there is no choice. AS1 only knows that locator 3 is behind AS3 and
> >>>locator 4 is behind AS4. AS1 has no mapping to know that it can
> >>>substitute locator 3 for locator 4.
> >>>
> >>>So if traffic with a destination of locator 3 then AS1 must always deliver
> >>>traffic to AS3.
> >>>
> >>>AS1 has no ability to distance some of the customers of AS3 without
> >>>distancing all of the customers of AS3 since they all share the same
> >>>aggrgate, and the more specifics are not in the global routing table.
> >>>
> >>>AS1 has no ability to compair IGP metrics between the exit point to AS3
> >>>and the exit point to AS4 as it does not know that locator 3 and locator 4
> >>>are the same host.
>
> That's certainly correct. I would tend to say it's a feature rather than
> a bug that the intermediate AS doesn't know that two locators refer to the
> same host - it's not due to shim6. As far as I can see it can happen today
> in IPv4 if someone cares to set it up that way. So I have nothing to
> offer here...
> >>>
> >>>
> >>>Personally at the moment, I am more concerned with getting people to agree
> >>>that the functionality needs to be supported. This is the first
> >>>step. Then we can argue about the best way to support it.
>
> Yes, and I do see the need.
>
> Brian
>
> >>>
> >>>___Jason
> >>>
> >>>==========================================================================
> >>>Jason Schiller (703)886.6648
> >>>Senior Internet Network Engineer fax:(703)886.0512
> >>>Americas' Network Engineering schiller@uu.net
> >>>UUNET, an MCI brand jason.schiller@mci.com
> >>>
> >>>Keeping the spirit of UUNET engineering alive!
> >>>
> >>>On Thu, 22 Sep 2005, Brian E Carpenter wrote:
> >>>
> >>>
> >>>
> >>>>Date: Thu, 22 Sep 2005 14:16:05 +0200
> >>>>From: Brian E Carpenter <brc@zurich.ibm.com>
> >>>>To: "Jason Schiller (schiller@uu.net)" <jason.schiller@mci.com>
> >>>>Subject: Re: addition of TLV to locator ID or locator ID set
> >>>>
> >>>>Jason Schiller (schiller@uu.net) wrote:
> >>>>
> >>>>
> >>>>>Summary: support for an additional TLV is required in order to allow for
> >>>>>a destination (sink) to signal to a source which links should be utilized
> >>>>>to carry traffic inbound to the destination (sink).
> >>>>>
> >>>>
> >>>>Jason, I understand your goal here and it is very reasonable.
> >>>>
> >>>>However, I would like to ask whether this policy-like information should be
> >>>>signalled in-band with the locator set (which is host to host) or
> >>>>whether it should be signalled out of band as a policy mechanism, and in
> >>>>that case signalled site to site. I'm assuming that the real requirement
> >>>>is to apply site to site preferences.
> >>>>
> >>>> Brian
> >>>>
> >>>
> >>>
> >>>
> >
>
>