It is interesting to me that folks have described locator-identifier
split as a *real* problem and source routing as a waste of time. As
I understand it, one driver for recent loc-id work is a concern over
routing system scalability (# of DFZ RIB entries). In the current
routing model, if a multi-homed site wants to influence how their
packets are delivered, it will often advertise multiple, more-
specific prefixes to different peers (leveraging LPM for TE
purposes). Unfortunately, this approach drives a cost in the global
routing system for which most of the nodes (in that global system)
receive little or no benefit. Sites are forced to do this indirect
signaling of their routing interests through BGP because there is no
explicit method for directing traffic over a particular path / link.
This is precisely what source-routing gives you - an explicit method
for signaling path preference, and it does so in a manner that
(potentially) allows the costs to be better localized to the
beneficiaries, rather than incurred by everyone. I do not claim that
the current specification or use of RH0 / RH4 is a complete solution,
but I think it is incorrect to assume loc-id split and source routing
are completely unrelated.
In my opinion, the RH4 draft appears to be heading in the right
direction:
1. Maintains a *general* source routing functionality in IPv6
2. Makes it required functionality in IPv6 implementations
As others have mentioned (or perhaps decided not to mention), source
routing has the potential to disrupt the current pricing / billing
model. I also think, though, that the use(s) of source routing and
any corresponding evolution of pricing / billing models would be
difficult to craft / predict outside the operational network. This
is one reason why I support a general source routing function that
allows for some flexibility, rather than one specifically tailored to
a single purpose. Many people seemed to think RH0 provided too much
flexibility - as I understand it, the RH4 proposal attempts to reduce
the degree of flexibility (i.e. power) to a more acceptable level.
From my (naive?) vantage point, maintaining source routing as a
mandatory part of the spec will help to get the functionality into
implementations *before* a demonstrated (profitable) use case. In
other words, we create an environment where innovation is possible,
and provide a general capability. IP seems to be the right place in
the stack to deal with packet delivery and path selection. If
implementers are already visiting code to remove RH0, it seems like a
reasonable time to add something like RH4. Given the functional
similarity of RH0 and RH4, it may be more a code edit than "tear out
old, add new."
I agree that the cost to uninterested parties should be minimized -
this issue probably needs to be considered at both the node level and
the network (ISP) level:
Node level impacts -
The RH4 draft provides some guidance in this area, but perhaps it
could be expanded. Some thoughts:
Transit nodes (routers): if the current destination address does not
match one of your addresses, don't process the routing header
Destination nodes: if the current destination address does match one
of your addresses and there is a source routing header, but you do
not have source routing enabled, drop the packet.
We may want to make a distinction between intermediate and final
destinations - not sure. Perhaps nodes that are only ever IPv6 hosts
do not need the functionality to act as an intermediate destination,
but should still accept source routed packets if they are the final
destination. In any case, clear implementation guidance should
eliminate a number of the problems voiced over RH0.
Network level impacts -
Another concern raised about source routing is its potential to make
traffic (trend) prediction more difficult, which would threaten the
existing ISP pricing / billing model. This concern seems to be
fairly easy to mitigate, however. By reducing the number of
intermediate destinations, RH4 significantly reduces the degree of
traffic variability resulting from oscillation DOS events (i.e. "bad"
variability).
For traffic variability due to "legitimate" uses of source routing,
upstream providers can simply adjust their billing model. Returning
to the previous example -
A - B -- C - D
If A and D want to support source routing for their customers, but B
and C are concerned over traffic predictability, they (B and C) can
charge A and D a higher rate. i.e. "if your (A) traffic patterns are
less predictable, it makes our (B) statistical capacity planning more
difficult so we must charge you more." If the number of source
routed packets is low, the impact to capacity planning should be
low. As the number of source routed packets increases, the impact to
capacity planning may also increase. However, if source routing were
to become more widely used, it may well be due to its usefulness to
the end-user. In this case, it is reasonable the end-user would be
willing to pay a bit more to A for source routing service, which
could offset the additional cost of A's connection to B. Since the
source route is visible in the IP header (even when encrypted), it is
easy to enforce policy - i.e. drop the packet.
I'm sure it is more complicated than this, so I'd be interested in
hearing from folks familiar more with the ISP / business side.
R,
Dow
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
