One of the immediate benefits of using a /126, is that it's not a /64! Also, a /126 is the smallest non-64 size with the highest likeliness to get the job done from an interoperability perspective (not the /127). Another example: when you use a /120, the advantage again is that it is not a /64, and you can make a bunch of routers talk BGP with each other on a layer-2 segment. This is why /126, /125, /124 etc end up being used.
An Addressing Architecture that does not admit this has been common practice for 15+ years, is disassociated from reality and thus inconsequential and no good. It does not follow that because you don't see enough advantages, the idea and practice are bad.
An Addressing Architecture that does not admit this has been common practice for 15+ years, is disassociated from reality and thus inconsequential and no good. It does not follow that because you don't see enough advantages, the idea and practice are bad.
Kind regards,
Job
On 22 Feb 2017, 04:52 +0100, Lorenzo Colitti <lorenzo@xxxxxxxxxx>, wrote:
On Wed, Feb 22, 2017 at 12:12 PM, Christopher Morrow <christopher.morrow@xxxxxxxxx> wrote:
But the configuration cost and management overhead is not proportional to the hosts that are served by those interconnections, it is proportional to the number of interconnections. A 10x100G peering interconnection that serves X million hosts is one interface that has to be managed.isn't the dicsussion here really:
"If you want to use /64 go ahead, if you want to use /121 go for it, if you want to use SLAAC you'll get a /64 and like it"Not sure. I for one wouldn't agree with that position, because I don't see that /121 has enough advantages over /127 and /64 - and few enough downsides for general-purpose hosts - to make it a good idea in general.