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. 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. (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. 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? 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. 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. 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. This seems like a more specific case of traffic engineering, which is actually covered in the next section. 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. 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). 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. 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. 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
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
