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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf