moving to IPv6

Sean M. Doran smd at clock.org
Mon Nov 3 15:56:35 UTC 1997


Rodney Joffe <rjoffe at genuity.net> writes:

> It seems to me that if there is going to be a change in the way that we
> look at addresses, routing, and NAT, it would be in everyone's interest
> if we were able to build border NAT devices that besides telling an
> incoming packet where to go, was also able to tell it what route to take
> through the internal network. Not just relying on the internal routing
> data, but also making decisions based on the real-time performance
> inside the network, and the nature of the traffic (TCP vs. UDP, HTTP vs
> FTP vs TELNET vs MAIL). I know it touches on QOS, but QOS is reactive,
> this could be proactive.
> 
> Once the box has to do the work, and look at each packet and address,
> why not add smarts?

Note that with respect to the idea that one can make
interesting forwarding decisions across a routing domain
based on such things as source address, input interface, 
packet size, protocol, etc., there is a strong conceptual
affinity between NAT and MPLS.

Wheras MPLS is a protocol-neutral map-and-encapsulate
system, NAT is a protocol-specific translation.  There are
enormous potential synergies between the two, particularly
when, as Rodney suggests, one starts considering policy
based on what MPLS calls FECs (Forwarding Equivalency Classes).

However, the two are not interchangeable; MPLS should not
modify payloads (it should not KNOW what the payload is)
and doing lots of packet-munging at the NAT level is a
poor (and in some cases extremely difficult) way to
propagate policy information from router to router.

You are the second sound person recently to suggest
routing based on observed load.  This sort of thing scares
me (cf. Peter Lothberg's
101-is-full-use-280-280-is-full-use-101-repeat 
San Francisco Bay Area highway analogy in the past, and Radia
Perlman's "congestion control is a very difficult problem
in a network" et succ., s. 9.12 in _Interconnections_).
Frankly I am worried that the amount of control traffic
and processing needed to implement fine-grain congestion
avoiding forwarding will overwhelm network devices.

A better approach is probably to run with Van Jacobson's
recent appeals to use intelligence in gateways to make
non-high-quality traffic fairer so that for that traffic
no congestion-avoiding forwarding needs to be done.
High-quality (i.e., extra $) traffic could then be dealt
with in a variety of ways ranging from queue manipulation
and selective disabling of fairness-enforcement to using
MPLS or an equivalent to direct traffic across different
infrastructure.

	Sean.



More information about the NANOG mailing list