Subject: Review request for "Two Dimensional IP Routing Architecture"

From: 杨术 <[email-masked]>
Date: Wed, 7 Mar 2012 23:02:14 +0800

Dear all,

We are looking for your comments on the new draft "Two Dimensional IP
Routing Architecture".

This document describes Two Dimensional IP (TwoD-IP) routing, a new
Internet routing architecture which makes forwarding decisions based
on both source address and destination address. This presents a
fundamental extension from the current Internet, which makes
forwarding decisions based on the destination address, and provides
shortest single-path routing towards destination. Such extension
provides rooms to solve fundamental problems of the past and foster
great innovations in the future.
We present the TwoD-IP routing framework and its two underpinning
schemes. The first is a new hardware-based forwarding table
structure for TwoD-IP, FIST, which achieves line-speed lookup with
acceptable storage space. The second is a policy routing protocol
that flexibly diverts traffic.

We plan to give a presentation on this in the upcoming IETF83. The
draft can be found at
http://tools.ietf.org/html/draft-xu-rtgwg-twod-ip-routing-00.

We would really appreciate any comments and questions about the document.

Thank you,
 Shu Yang

---

From: Russ White <[email-masked]>
Date: Fri, 09 Mar 2012 09:15:37 -0500

> We are looking for your comments on the new draft "Two Dimensional IP

Some thoughts...

:-)

Russ

==
Due to the important semantics of source address, recent years see
increasing works on adding source addresses into routing controls.

Could you point to some more recent efforts than source routing (which
is years old)? I'm not certain source addresses would actually need to
be added to a routing protocol to use them for anything --it might be
worth discussing under what circumstances adding such addresses might be
add information that's not already present in the routing system.

==
If the host is using address A, and the link l1 or l3 fails.  Then the
host can immediately detect the failure, then switch to address B, and
continue to communicate with the Internet via ISP2.

How would you see the host detecting and reacting to the failure more
quickly than the routed control plane, itself, could detect and react to
the failure?

==
Within destination-based routing, traffic towards the same destination
has to travel along the same path in the network.

This really isn't true --in reality, almost every implementation load
shares based on the some bits or another in the packet header today. One
of those sets of bits can be the source address in many implementations
(if not all?). I'm not certain how your proposal adds anything to this.

==
If there is congestion on the link between b and d, and router b moves
the traffic towards d to the north path via c.  Thus, the probe packets
will flow on the path a-b-c-d, which does not include the link between b
and d.

This seems like a more specific case of traffic engineering, which is
actually covered in the next section.

==
The section on FIST is interesting, but it's at the implementation
level, rather than the protocol level, so I'm not certain how applicable
is within an IETF draft.

==
With these preconditions, each edge router can announce the foreign
Internet prefixes combined with its own router identification to the
network, each PE router can announce the customer prefixes combined with
the corresponding customer domain number, PE routers are also
responsible for announcing the preference of customer networks on edge
routers.

Figuring out how to advertise sources/destination pairs isn't really a
problem overall.. What I don't understand is how this is different than
the information already in the table today --every source and
destination is already there, just not matched together. What is the
value in matching them together in a single piece of control plane
information? None of the use cases supplied in the draft seem to require
the information to be paired in this way, nor does building a
source/destination pair routing table (that I can see, at any rate).

==
TwoD-IP routing will enhance the security level of the networks, because
routers will check source addresses, which is an important identity of
the senders.

I'm not certain I understand why this would be, given the ease with
which source addresses can be spoofed. I suppose you could say that you
could do an rpf check at every ingress interface, but you can already do
that (to the degree that aggregation and load sharing allow). You could
claim that the additional state provided in pairing source and
destination addresses in the routing table would allow more specific
checks --but probably no more than simply getting rid of all
aggregation, or even flooding host routes throughout the network --and I
don't know if there would be more state in pairing source/destination
sets, or flooding host routes, so it's hard to analyze the actual case
for this claim.

---

From: Fred Baker <[email-masked]>
Date: Fri, 9 Mar 2012 23:33:31 +0900

On Mar 8, 2012, at 12:02 AM, 杨术 wrote:

> Dear all,
>  
> We are looking for your comments on the new draft "Two Dimensional IP Routing Architecture".
>  
> 	draft can be found at http://tools.ietf.org/html/draft-xu-rtgwg-twod-ip-routing-00.
>  

My first suggestion would be to compare/contrast with 
    http://tools.ietf.org/html/draft-baker-fun-routing-class

---

From: 杨术 <[email-masked]>
Date: Sat, 10 Mar 2012 02:25:14 +0800

Hi, Fred Baker,

Thanks for your advices.

We have discussed your draft in our group meeting, because your
draft is strongly related with two dimensional routing. Your draft
illustrates detaiedly that how to devise a new protocol, that can make
forwarding decisions based on destination and source addresses.

Our draft differs from yours in that:
1. We try to illustrate the huge benefits from deploying two dimensional
routing, that makes forwarding decisions based on both destination and
source addresses. The network will be more flexible if routers can divert
 traffic based on source address. Thus, policy routing, traffic engineering,
 path/link protection, multi-path, multi-homing can be achieved more easily.
 For example, with two dimensional routing, we can express "deliver traffic
from source A towards destination B to router C" explicitly and easily.

2. We focus on the architecture of two dimensional routing. We try to
properly
divide the whole routing system into several components, and point out how
to devise each component to achieve efficiency and consistency.

3. We have designed a new forwarding table structure called FIST, and we are
 developing it based on a commercial router. With one more address to lookup
 during routing, we believe that the FIB is a key component considering
scalability
 issues. FIST is different with previous FIB structure in that, 1) it has
two TCAMs,
 one stores destination prefixes, the other stores source prefixes; 2) in
SRAM,
 there is a two dimensional table that stores the next hop information.
Such that
 we can achieve fast lookup speed, and avoid explosion problem in TCAM.

Shu Yang

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Mar 2012 11:18:38 -0800

Hi,

I think you missed several of the points Russ White made, viz, most routers can already be programmed to do this as part of their ECMP support and that this does not require any protocol changes.

Thanks,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of ??
Sent: Friday, March 09, 2012 10:25 AM
To: Fred Baker; [email-masked]
Subject: Re: Review request for "Two Dimensional IP Routing Architecture"

Hi, Fred Baker,

Thanks for your advices.

2. We focus on the architecture of two dimensional routing. We try to properly
divide the whole routing system into several components, and point out how
to devise each component to achieve efficiency and consistency.

3. We have designed a new forwarding table structure called FIST, and we are
 developing it based on a commercial router. With one more address to lookup
 during routing, we believe that the FIB is a key component considering scalability
 issues. FIST is different with previous FIB structure in that, 1) it has two TCAMs,
 one stores destination prefixes, the other stores source prefixes; 2) in SRAM,
 there is a two dimensional table that stores the next hop information. Such that
 we can achieve fast lookup speed, and avoid explosion problem in TCAM.

Shu Yang

On Fri, Mar 9, 2012 at 10:33 PM, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

---

From: Fred Baker <[email-masked]>
Date: Sat, 10 Mar 2012 04:22:17 +0900

> forwarding decisions based on destination and source addresses. 

It also explicitly mentions DSCP as an option, and in homenet discussion (might have been offline, I don't remember), Brian Carpenter suggested flow label (although I think that would differ from the random number his current document puts into it). Yes, it has overlaps.

>  we can achieve fast lookup speed, and avoid explosion problem in TCAM.

That's one implementation approach, and it sounds like it has value. While most routers have some concept of a forwarding information base, the IETF has never particularly commented on how the FIB was structured. That has been viewed as a competitive angle - different implementations might do it different ways with different effects. The last discussion I recall about FIB design was a BOF at IETF 14 or 15 led by Craig Partridge.

When I started working to regularize this, folks back at *my* ranch told me that I was re-inventing Multi-Topology Routing.