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

From: 杨术 <[email-masked]>
Date: Sat, 10 Mar 2012 17:13:11 +0800

Hi, John,

Yes, there are many ways to achieve the same thing, and there are many
path-like solutions that can be used
to replace two dimensional routing under some circumstance.

Thanks,

Best Regards,
Shu Yang

On Sat, Mar 10, 2012 at 3:20 AM, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/rtgwg
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send rtgwg mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/rtgwg
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of rtgwg digest..."
>
>
> Today's Topics:
>
>   1. Re: Review request for "Two Dimensional IP Routing
>      Architecture" (Russ White)
>   2. Re: Review request for "Two Dimensional IP Routing
>      Architecture" (Fred Baker)
>   3. Re: Review request for "Two Dimensional IP Routing
>      Architecture" (??)
>   4. RE: Review request for "Two Dimensional IP Routing
>      Architecture" (John E Drake)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 09 Mar 2012 09:15:37 -0500
> From: Russ White <[email-masked]>
> To: [email-masked]
> Subject: Re: Review request for "Two Dimensional IP Routing
>        Architecture"
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=UTF-8
>
>
> > We are looking for your comments on the new draft "Two Dimensional IP
> > Routing Architecture".
>
> 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.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 9 Mar 2012 23:33:31 +0900
> From: Fred Baker <[email-masked]>
> To: ?? <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Review request for "Two Dimensional IP Routing
>        Architecture"
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
>
> 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".
> >
> >       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.
>
> My first suggestion would be to compare/contrast with
>    http://tools.ietf.org/html/draft-baker-fun-routing-class
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/rtgwg/attachments/20120309/477671df/attachment.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Sat, 10 Mar 2012 02:25:14 +0800
> From: ?? <[email-masked]>
> To: Fred Baker <[email-masked]>, [email-masked]
> Subject: Re: Review request for "Two Dimensional IP Routing
>        Architecture"
> Message-ID:
>        <[email-masked]
> >
> Content-Type: text/plain; charset="utf-8"
>
> 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
>
>
>
> On Fri, Mar 9, 2012 at 10:33 PM, Fred Baker <[email-masked]> wrote:
>
> >
> > 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".
> >
> > 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.
> >
> >
> > My first suggestion would be to compare/contrast with
> >     http://tools.ietf.org/html/draft-baker-fun-routing-class
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/rtgwg/attachments/20120310/32515265/attachment.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Fri, 9 Mar 2012 11:18:38 -0800
> From: John E Drake <[email-masked]>
> To: ?? <[email-masked]>, Fred Baker <[email-masked]>,
>        "[email-masked]" <[email-masked]>
> Subject: RE: Review request for "Two Dimensional IP Routing
>        Architecture"
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
>
> 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
>
>
>
> On Fri, Mar 9, 2012 at 10:33 PM, Fred Baker <[email-masked]<mailto:
> [email-masked]>> wrote:
>
> 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".
>
> 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.
>
> My first suggestion would be to compare/contrast with
>    http://tools.ietf.org/html/draft-baker-fun-routing-class
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/rtgwg/attachments/20120309/a292ea6e/attachment.htm
> >
>
> ------------------------------
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>
> End of rtgwg Digest, Vol 87, Issue 6
> ************************************
>

---

From: 杨术 <[email-masked]>
Date: Sat, 10 Mar 2012 17:17:58 +0800

Hi, Russ White,

Thanks for your detailed advices.

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

(Strict/loose) source routing is rarely used due to that it hands most
control to end users, and faces security risks. We need a more network
controllable solution. Recent years, there are lots of effots on giving
sources
control over routing, such as: MPLS, policy-based routing,
customer-specific
routing, multi-topology routing where traffic can flow on user-specific
topology,
and DAGs (directed acyclic graph) routing that provides multiple paths
between
the given source and destination. Besides, many schemes based on overlay
routing
are designed, due to the limitations in the network-layer.

Yes, we try to point out under what circumstances adding source address
is useful. Two Dimensional routing does not aim to solve anything, we will
charify this more clearly in our next version.

==
2. 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.

It may need some experiments. For the multi-homing case, the paper "The
Case for
Source Address Dependent Routing in Multihoming" illustrates well, however,
it
is based on multiple routing tables.

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

There are many variations (or improvements) for destination-based routing.
Checking some bits in source addresses can be seen as a scheme of two
dimensional routing, where source addresses are aggregated to several
bits. Here, destination-based routing refers to the traditional pure
destination
based routing system.
==
4. 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.

We take measurement & diagnosis into considerations, because we discussed
with some people who are in trouble with that. Such as, when network
implement
TE or policy routing, it is difficult for them to measure/diagnose some
element
in the network, because they do not know where the path will lead to
after sending probe packets. Previously source routing is often adopted for
measurement (pls refer to "Efficiently monitoring bandwidth and latency in
IP networks"),
however, source routing is always disabled on routers.
==
5. 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.

Thank you for your advices. We place FIST here for completeness of
the architecture. If it is not proper, we will remove or abstract this
part.
==
6. 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.

problem overall. What I don't understand is how this is different than

Here, the policy protocol points to a specific problem, that diverts
traffic from part of the whole source prefixes to part of the whole
destination prefixes. PE routers are responsible for announcing which
part of source prefixes, edge routers announce which part of destination
prefixes, should be diverted. And the preference indicates which
path the traffic should be diverted to.
The protocol is not general, it is used to illustrate the routing protocols
of two dimensional routing. We have developed the prototype of it,
although the FIB currently is based on software.

==
7. 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.

Yes, SAVI (source address validation improvement) is our previous work.
We deployed SAVI in our network (CERNET/CERNET2). Now, for two dimensional
routing, we suppose that the blacklist already exists (can be constructed
either by time-series model or neighborhood models), and routers across the
network can cooperatively filter the source addresses in the blacklist, if
source checking function is deployed deeper in the network. This can be
seen
as a kind of distributed attack-defense scheme.

Shu Yang