Ted Hardie wrote:
The people that are fighting having ULA-C are the same ones that don't
want
PI, and they are trying to force ULA-C == PI so they can turn that
argument
around and say 'we told you PI was a bad idea' when there is no way to
filter out what would have been ULA-C. If you really believe there is
going
to be a routing system problem, then you absolutely have to support
ULA-C
because it is the only way to enforce keeping private space private.
I am totally against ULA-C, and I am not against PI, so please re-
examine
that statement. Your second statement:
f you really believe there is going
to be a routing system problem, then you absolutely have to support
ULA-C
because it is the only way to enforce keeping private space private.
Also doesn't seem to me to make a lot of sense. There is a set prefix
of
ULAs now. Filtering it on is already possible (and I heartily
encourage
same!). Adding ULA-C doesn't make that easier or harder, and it does
nothing
else that would "enforce keeping private space private". None of the
ULA-C proposals I have seen came with a police force or standing army
of clue-bat wielding networking engineers.
It is clear that people on this list have never really run a network as they
appear to be completely missing the point, but there is no reason to respond
to each individually...
Yes any one clueless ISP may announce ULA-C space from a customer, but there
is no need for any of their peers to accept it. If the only choice is PI,
there is no way for the peer ISP to know what should have been filtered out
and the entire system has to deal with the leakage. Claims about cutting off
long prefixes are unrealistic because there will be people in there that
received PI expecting it to be routed so the RIRs would then have to hand
out even larger blocks for routed PI, forcing the cost for renumbering onto
people that had nothing to do with creating the problem.
People want unique private space. If you force them to get it from PI blocks
there is no way to sort out what should be globally routed from what should
be private, or localized to just the customer's ISP. Putting a well-known
label on it allows anyone that does not want the excess to easily identify
it and kill it off. Using ULA-C puts the burden of getting space routed
globally back onto the originating network, because they will either run
both ULA-C & PI, or renumber. Either way people who just want PI are not
impacted by people that start with ULA-C and change their minds later, and
the DFZ does not have to deal with leaked crap because it is easy to
identify.
This should not even be a debated issue, because ULA-C is just a way to
group end site assignments into a block that is easy to filter out of the
global routing system. As I said, those that oppose this are effectively
forcing an unnecessary burden on the DFZ, which will result in the anti-PI
camp saying 'I told you so' when the inevitable leakage happens. Yes 1918
leakage happens, but that is a self-inflicted wound and easy to correct, as
ULA-C leakage would be. Leakage of PI that should have been kept local is
impossible to detect or fix by the recipient.
Tony
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf