[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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