Last Mile Design

Sat Feb 9 18:44:29 UTC 2019

On 2/9/19 11:22 AM, Sander Steffann wrote:
> Same for me. I like the architecture where the PON splitters are in 
> powered roadside cabinets (even though the splitter is passive). That 
> way the ISP can convert it to AE at any time they want. The architectures 
> where PON has been hardcoded into the design has always felt like a huge 
> risk regarding future developments.

I agree that PON with splitters where you can't put Active Ethernet 
equipment is largely equivalent to solution lock-in.  But is that in and 
of itself a bad thing?  Especially when viewed in within the lifecycle 
of the network?

 From an outsider n00b point of view, the things that I'm reading it 
seems that people don't like about PON are largely it's inflexibility to 
be able to be converted to Active Ethernet without careful forethought 
and planning at construction time of the fiber network to allow it to 
change in the future.

In some ways, I've heard of the industry having this, or a very similar 
discussion for 25 years.  Twisted pair (Cat 3 vs Cat 5 vs Cat 5e vs Cat 
6) vs coax (RG 59 vs RG 6 vs F-11) vs fiber (OS1 vs OS2 vs OM1 vs OM2 vs 
OM3 vs OM4 vs OM5) vs RF (myriad of options).  Included to topology 
designs equating to lock-in.

However, none of this seems to be related to how functional any given 
design is.  I guess perhaps that the subject "Last Mile Design" does 
encourage discussions about topology and technology.

So let me ask this:  Are there any functional reasons to favor AE over 
PON /within/ the lifecycle of a deployment?  Does one methodology offer 
any significant advantages or disadvantages over the other?  If so, is 
(are) the pro(s) / con(s) applicable to specific use case(s)?

Remember that there are LOTs of ways to do things.  I'm trying to glean 
what makes one method better or worse than another, possibly for 
different types of deployments.

-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190209/b9e9c286/attachment.bin>