Using /31 for router links

Frank Bulk frnkblk at
Tue Jan 26 03:56:32 UTC 2010

We use 5 PVCs for the IP video and one for Internet.  Not as uncommon as you


-----Original Message-----
From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] 
Sent: Saturday, January 23, 2010 12:53 PM
To: nanog at
Subject: Re: Using /31 for router links

Mark Smith <nanog at>

> What about NAT, ATM cell tax, unnecessary addressing fields in PTP
> protocols (including your beloved HDLC), SSAP, DSAP fields not being big
> enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1
> through AAL4, PPPoE "dumbell" MTUs and MSS hacks? Some of those are far
> worse sins in my opinion.


As for ATM...  The part that totally baffles me about the use of ATM on
xDSL lines is that I have never, ever, ever seen an xDSL line carrying
more than one ATM VC.  OK, there may be someone out there who has set up
a configuration like that just for fun, but 99.999% of all ATM'd xDSL
lines out there carry a single PVC at 0*35 or 0*38.  So what then is the
point of running ATM?!?!  All the hyped benefits of ATM (a little cell
can squeeze in the middle of a big packet without waiting for it to
finish, yadda yadda yadda) are contingent upon having more than one
VPI/VCI going across the interface!  If every single non-idle cell going
across that ATM interface is 0*35 or 0*38, the interface will never
carry anything other a direct succession of cells making up an AAL5
packet, strictly in sequence and without interruption.  So what's the
point of ATM then?  Why chop that packet up into cells only to transmit
those cells in direct sequence one after another?  Why not simply send
that same packet in plain HDLC over the same copper pairs/fiber?  OK,
the backhaul network upstream of the DSLAM may be ATM and that one does
have many VCs, so ATM *might* be of use there, but even in that case why
not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul,
sending HDLC down the copper pairs?

<off the soapbox for the moment>


More information about the NANOG mailing list