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
