David, I've responded to two of the points raised / questions asked below. Feel free to break these responses into separate threads or to resend any of the points/questions as separate threads as well.
=================== Thanks for the example of the ISP-provided cloud device. I think that I am starting to better understand one of the sources of disagreement on this topic. If one assumes that a host can magically choose the correct source address for a packet, then I think even this example can be handled with default-only SADR. However, if we also want to use SADR to distribute information to the hosts to allow them to choose the correct source address to put on the packet in the first place, then I agree that default-only SADR will not work. If this is the case, then I think we need to be more explicit about how we expect the host to get information about the correct source address to select. This is my best understanding at this point about how this could work. Please correct me if I am wrong. Using the example below, for a host (H55) which is a few router hops away from the ISP A's cloud device, we want to put the route for (D=cloud, S=ISP-A-PA) into the IGP. This IGP advertisement is received by a router (R50) on the same LAN as H55. I assume that R55 would use Neighbor Discovery Router Advertisements to communicate information about (D=cloud, S=ISP-A-PA) to H55. I don't think that PIO and RIO in ND Router Advertisements currently have the semantics to advertise associate arbitrary source and destination prefixes, so I think that ND Router Advertisements would need to be extended. This is basically what draft-sarikaya-6man-sadr-ra-03 is proposing. I think that different participants in this discussion may have different ideas about how this should be done. The homenet architecture principles document (RFC 7368) and draft-ietf-6man-multi-homed-host-06 both point to RFC 6724 as providing a solution for source address selection with multi-homing, but both documents also seem to acknowledge that RFC 6724 doesn't provide a complete answer. In the discussion in RTGWG on Thursday, Fred Baker said that thinks a Happy Eyeballs RFC 6555 should play a roll as well. There was also a mention of having the host use ICMP to detect failures. I think we need to be very explicit about our assumptions about how the host is going to select the source address, especially if we expect the host to use dest/source route information. This is also consistent with Alvaro Retana's more general request in RTGWG that we consider a complete solution to the PA multi-homing problem, as opposed to just considering individual pieces of a potential solution in isolation. ========== Responding to a another question below, I can clarify my concerns about the scalability and implementation of dest/source routing that allows pairing of arbitrary destination and source prefixes. Dest/source routing has been proposed as a solution for several different problems or use cases. So I'll state my concerns for each use case. 1) PA multi-homing for homenet - I don't have much concern regarding scalability and implementation for PA multi-homing for homenet. This is not my area of expertise, but I would expect most forwarding implementations for homenet to be software based. So it seems like existing equipment should be able to deal with new forwarding requirements, possibly with some performance penalty. 2) PA multi-homing for mid-size enterprise networks - My main concern with PA multi-homing for mid-size enterprises is that existing routers deployed in these networks will not be able to support forwarding based on pairing of arbitrary destination and source prefixes. In mid-size enterprise networks, I would imagine that there is a broad range of existing deployed equipment, some of which may have forwarding hardware that cannot be modified to support arbitrary dest/source route lookups on packets. I think it is likely that more deployed equipment would be able to be upgraded via software to support a more simplified form of dest/source routing. 3) Dest/source routing in IGPs as a general tool for service provider infrastructure routing - One example of this kind of use case can be found in draft-baker-rtgwg-src-dst-routing-use-cases-01 under " Intra-domain access control". Slide 4 of https://www.ietf.org/proceedings/95/slides/slides-95-rtgwg-9.pdf also discusses some uses in CERNET2 of dest/source routing in OSPF (draft-xu-ospf-multi-homing-ipv6-00). These use cases are very different from PA multi-homing. My main concern here is that there are existing standardized and deployed solutions addressing these use cases. That doesn't mean that the IETF can't standardize another solution to the same problem, but I think there is generally a higher bar with respect to demonstrating the need for another solution, and analyzing the costs and benefits relative to existing solutions. 4) Dest/source routing in BGP - draft-xu-src-dst-bgp-00 proposes extending dest/source routing to BGP with arbitrary matching of destination and source prefixes. The draft doesn't discuss the use cases, but on the surface, it seems like some uses of this could result in a significant increase in routes in the global internet. Thanks, Chris -----Original Message----- From: David Lamparter [mailto:[email protected]] Sent: Thursday, April 07, 2016 11:55 AM To: [email protected] Cc: Chris Bowers <[email protected]>; Fred Baker (fred) <[email protected]>; Anton Smirnov <[email protected]> Subject: Implications of default-only SADR (was: Re: multi-homing for provider-assigned IPv6 addresses) TL;DR: note at end about "abort as unreachable" as alternative way to get rid of complicated backtracking. (Jump to second/last ----- line.) Hi all, here is another shot at my somewhat confusing (sorry) in-room comment on the policy aspect of limiting to D=::/0. The scenario I'm thinking of is this: User (let's say, small-to-medium-ish business, for illustration let's say the internal network has 2-3 OSPF routers or something.) \- ISP A, assigned PA prefix, internet/default connectivity \- ISP B, assigned PA prefix, internet/default connectivity So far so good, we have two D=::/0 routes with different S. Now, let's say the CEO of the company heard that clouds are great for putting your calendar and mails into. She decides ISP A's "Cirrus Castellanus" product is great because it comes with some great security and confidentiality bulletpoints. For the Cirrus Castellanus service, ISP A installs a separate device in the user's network, which routes a specific prefix for the cloud. Could be some encrypted VPN foobar, physical separate line, doesn't really matter. Since it's ISP A, they're aware of their PA assignment to the customer and push a route for that into the cloud product. The cloud product could implement BCP 38, but it could also just not have a route towards the internet - it doesn't need to and it's "secure". Now, the installation instructions for the product says "this is the prefix your cloud service has, put a route for it in your domain". So, now the User's netadmin is essentially screwed since that's a D!=default S!=default route. More correct, it's in fact 2 routes: - D=cloud, S=ISP-A-PA => via installed cloud termination device - D=cloud, S=::/0 => unreachable Which goes to represent that the cloud service is only reachable from ISP-A's PA prefix assigned to the User. ---------- This, I hope, illustrates how this is a significant policy decision to make. It's IETF consensus (I hope) that NAT is a bad thing. It also seems to be IETF consensus (as discussed in Fred's slides) that PA is preferable over PI, and we want to keep tables small. We've received feedback -the v6ops request- that PA has some issues to be solved. If we now say "we're doing D=::/0 only", we're deciding to solve only part of the problem posed to us. (see note below about divide&conquer / "do D!=::/0 separately") What's the message to operators here? "get PI space for that setup"? "you'll need a cooperative ISP for that setup"? "don't do this setup, it's stupid"? In any case, any solution that resticts to D=::/0 carries an implication of: "If you're using PA, the only thing you can rely on being able to route is the internet as a whole. If we're making this policy assumption (which is really a decision), we need to be aware we're making it. On Divide&Conquer: splitting this up into a two-part approach resulting in the 3 levels: - classic router, (D) lookup - level-1 SADR, (::/0, S) support - level-2 SADR, (D, S) support is certainly possible to write down, but complicates the compatibility mechanisms in the routing protocols since level-1 and level-2 routers are not compatible to be in the same link-state/SPF topology. ---------- If we still want the backtracking behaviour (going to less specific D when not finding a S match under a particular D) gone, I'd prefer looking at specifying "terminate as unreachable" instead of completely removing D!=::/0 support. I haven't thought through use-case impact of this yet, but in any case the backtracking behaviour could be restored by advertising additional routes to the same effect. (The same approach of installing additional routes can be used to eliminate the performance hit of backtracking by consuming more memory / hardware route resources through installing additional synthetic routes. I'll add that to the next version of the draft.) On a closing note, I'll repeat my mic request for feedback: could people provide feedback which part of backtracking they're concerned about? Specification complexity? Implementation complexity? Performance penalities? Something else? -David _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
