Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 31 okt 2003, at 13:44, Erik Nordmark wrote:

> > Many routers already support policy routing in hardware. Source 
> > address
> > based routing is a subset of full policy routing. I don't see much of 
> > a
> > problem in the  long run.

> Is it really a subset?

Source address based routing basically boils down to a set of "if 
source address == a then next hop = x" clauses. On a Cisco router, this 
can be implemented using the more general policy routing mechanism that 
can also look at many other fields in the headers and some other stuff. 
I gather that Cisco and some other vendors support doing this in 
hardware and/or the fast path.

> Can existing routers and routing protocols convey, for different source
> prefixes, different nexthops for the same destination?

It is possible that IDPR supports this, but since IDPR has been dead 
for a decade we can safely assume "no". However, modifying routing 
protocols, while not exactly a trivial excercise, isn't as bad as 
modifying ASICs. Also, I'm not sure if routing protocols are really 
required here. A static setup should be enough.

> I thought source routing merely implied that a route might only be 
> applicable
> for certain source prefixes, not that there could be multiple routes
> for a given destination address/prefix that get applied based on the 
> source
> address in the packet.

Please don't use "source routing" in this context as the confusion with 
actual source routing will never end.

There are different ways to approach this. A very general one would be 
to combine header fields (lets assume source and destination for now, 
but it could be more) and the next hop and attach a preference value to 
every such combination. Then routing becomes the process of looking up 
all header/next hop combinations where the header fields match for the 
packet in questgion, select the one with the highest preference and 
forward the packet according to the listed next hop. There is the 
slight issue that the cartesion product of the full sets of destination 
prefixes, source prefixes and next hops could get out of hand, but 
that's a question of optimization.

But we don't have to go this far. We know that if a source address tied 
to ISP A is used, there is no use in forwarding the packet to ISP B, 
and the other way around. So there is no need to even check whether the 
destination is even reachable through the ISP indicated by the source 
address as there is no alternative course of action to forwarding the 
packet to that ISP and hope for the best. So essentially we're just 
taking default routes.