[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03
Hi Iljitsch,
El 01/03/2006, a las 17:12, Iljitsch van Beijnum escribió:
[This message will go into both source address rewriting and traffic
engineering.]
On 27-feb-2006, at 20:48, Erik Nordmark wrote:
There are two problems with allowing routers to rewrite source
addresses:
1. The routers must know which packets are "legacy" and can't have
their source address changed vs which packets are controlled by
shim6 or another mechanism that can handle rewritten source
addresses.
2. In current shim6, only previously negotiated source addresses may
be used, which means the shim6-enabled hosts in a site and the
rewriting routers must coordinate their efforts so correspondent
hosts don't see unexpected source addresses.
FWIW draft-nordmark-shim6-esd-00.txt is on the way to the I-D
directory, and it has some ideas for how to address this.
Right. Lots of good points in there, but unfortunately, I disagree
with the mechanisms proposed. I really hope I'll never have to run
DHCPv6 to configure my hosts, it's a big, fat, unelegant protocol.
otoh, the protocol is already defined and hosts already implement it
and it is nice to only have to run less protocols for configuring hosts
in a site i guess
The first issue is readily solvable by simply having shim6 hosts put
a magic value in the upper 64 bits of the source address that
indicates "rewriting permitted".
Or next hdr = IPPROTO_SHIM6.
I don't find this very suitable. If we're going to send many shimmed
packets, it's more important than ever that we omit the shim header
whenever possible.
i may agree with this but we still don't know how complex would be the
resulting protocol when context tags are carried without the shim
header... i recall that someone was going to write a draft about such a
solution looked like and how complex it was in order to be able to
evaluate it properly....
Apart from that, using the source address to signal that the source
address may be changed is much cleaner. It also has the advantage that
we can now borrow some bits to make the process easier. What we can
do is have shim6 capable hosts emit a "source rewriting information
request". That would be a packet addressed to a shim6 correspondent
that has the magic prefix in the source address that triggers source
address rewriting, and an additional bit combination that tells the
router to send back a list of prefixes it will use to rewrite. The
host can then make sure that the correspondent knows to expect packets
with these source addresses.
but this magic source prefix would not be routable right?
i mean, packets carrying this source prefix MUST be rewritten before
they reach the public internet, right?
if this is so, this is not so great because we need again some form of
coordination between the hosts and the routers i.e. a host must knwo if
there is a router that will rewrite the packets before they are routed
through the public internet.
The nice thing about Erik's mechanism is that it does eliminates the
need for coordination, since if there is a router that can rewrite the
source address, it may do so, but there is none, there is no problem
neither
If this is an ordered list, the host can then use bits in the data
packets with the rewrite prefix in the source address to tell the
router which addresses it may insert. (Not sure what would happen
though if the router wants to rewrite into Y but the host only allows
X and Z.)
I've been thinking about something similar for traffic engineering
ever since my message yesterday where I mentioned A6 records. The
problem is that it's far from inconceivable that at some point, a
disconnect forms between the info in the DNS and the actual state of
the network. The way I see it, we have four ways to convey TE related
info:
1. out of band end-to-end: this would be stuff in the DNS
2. out of band hop-by-hop: BGP is like this
3. in-band end-to-end: measured timing and packet loss information
4. in-band hop-by-hop: feedback from routers
The problem is that 2. needs aggregation to scale. 3. and 4. need to
have contact with the correspondent already, so it's useless in some
cases, like in the case where we want one or more backup addresses
that are only tried if the primary addresses don't work.
I am not sure i understand why this wouldn't work
I mean if many addresses are included in SRV records and different
priorities are included to different prefixes, then if the initiator
honnours the SRV information, it will use the primary unless it is
broken, right?
The only way to convey this is with 1. We can either reuse SRV
records for individual services for this, which has the advantage that
it's already available today, but the disadvantage that this mechanism
isn't really used and it needs to be supported on an
application-by-application basis. Alternatively, we can do some magic
in the resolver library to make this happen.
yes, this would make sense imho
...
But an in-band hop-by-hop TE mechanism would allow exactly this. The
way it would work is that routers are configured to provide feedback
for packets with a shim header, if necessary. This feedback would be
in the form of entries that go into the address selection policy
table. The site egress router would probably want to inform hosts
about which source addresses go well with certain destination
prefixes. All routers between the source and destination (including
the site exit router) would signal back "this prefix (which would be
the prefix that the destination for the packets falls into) preference
value XXX". To avoid trouble, the preference value shouldn't be
allowed to completely override locally configured info.
But how would be the trust model for this, i mean any signaling packet
can configure the preferences of a host in a site, wouldn't this be a
problem?
regards, marcelo