> 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. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
