I agree with Vince here. In fact, hop-by-hop forwarding
not only affects the set of implementable policies, but
also implicitly constrains the set of solutions.
This question has actually been brought up at the RRG
meeting today, and my opinion is that the requirements
should not limit the forwarding model, but should
require support for IPv4 and today IPv6 forwarding models.
Which scheme is used to forward packets and setup the
forwarding state in a specific architecture is a separate
issue.
-- Alex ZininThursday, December 13, 2001, 1:15:57 PM, David Meyer wrote:
> I didn't see any comment on this question. Did I miss it?
> Dave
> On Thu, Dec 13, 2001 at 08:42:19AM -0800, Vince Fuller wrote: >>> > > 3.9 Rich Policy >>> ... >>> > >>> > One of the problems with this whole area is that I've attempted >>> > to come up with a good, useful, crisp, definition of policy >>> > that covers what people are trying to do today with 'policy'. >>> > Unfortunately, policy is one of those N! things -- get N people >>> > in a room and you get N! definitions of policy. The lack of >>> > specificity and crispness of this section may be, I fear, >>> > a reflection of similar lacks in deployed networks. The >>> > only real requirement might be "operators have to be able >>> > to reach in and diddle with things"... >>> >>> One question: is the next-generation routing system constrained to preserve >>> the pure hop-by-hop forwarding model that we've all grown to know and love? >>> I've read through section 3.9 of the draft so far between IETF sessions and >>> don't see anything that states that thus far. >>> >>> Why is this question relavent? Because it directly affects the set of >>> policies that can be supported and how those policies are applied. On >>> today's Internet, "policy" is primarily about setting the next hops that >>> traffic uses when it exits a particular domain, with brute-force methods >>> used to try and engineer end-to-end paths on a per-prefix granularity. >>> But this isn't really what providers of edge or transit services really >>> want; they want to be able to specify how traffic flows to the customers >>> of their service - those who pay more should get better service. In today's >>> world, the mapping between what the routing system can deliver and what >>> the services that ride on top of that system would like to see don't match >>> well at all, which is why horrible, non-scalable kludges such as more- >>> specific route propagation are used in the name of "traffic engineering". >>> >>> Is it within the scope of the next-generation routing system to solve this >>> problem or does that properly belong at layer-4 or above (which, I would >>> argue, is the only place that it can scalably be addressed, no pun intended, >>> today)? >>> >>> --Vince
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT