[ppml] "Recommended Practices" procedure
Stephen Sprunk
stephen at sprunk.org
Thu Jun 29 12:29:25 EDT 2006
- Previous message: [ppml] "Recommended Practices" procedure
- Next message: [ppml] v6 multihoming and route filters
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Thus spake "Azinger, Marla" <marla_azinger at eli.net> > I hear many comments about "the slippery sloap". And "make them > get PI if they want to multihome". However, my customer's dont want > PI. Just because one person finds this as an ideal solution does not > mean everyone will accept this solution. What makes punching holes in PA space more attractive than PI space for them? This is not an idle question. While there are many obvious technical and business reasons for multihomers getting PI space, I'm unable to identify _any_ reasons for the end site to prefer PA. > Also, a /48 is not a gigantic hole in the filtering opposed to /32. And > to open up /48 for PI only is an unbalanced policy. It's a perfectly balanced policy. Filtering is to be done on RIR allocation boundaries, and those boundaries are currently /32 for PA and /48 for PI. This is no different than what is done in v4. In fact, the whole goal was to make v6 multihoming the same as v4! > If I had known people would be using PI as an excuse not to let > Upstreams multihome with V6 I would have advocated to shut down > that policy proposal. I support PI but for poeple to turn around and > force feed PI is not acceptable. You're missing the point. PIv6 is all about giving people the _ability_ to multihome. Multihoming in PA space (v4 or v6) is not an option for both technical and business reasons. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
- Previous message: [ppml] "Recommended Practices" procedure
- Next message: [ppml] v6 multihoming and route filters
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list