Repository: netbox-community/netbox

Issue:
Add PON ports to interface type
### NetBox version

v3.1.7

### Feature type

Data model extension

### Proposed functionality

Add EPON, GPON, X-GPON and other type of PON ports to interface type.

### Use case

These ports are used for OLTs in FTTH scenarios.

### Database changes

_No response_

### External dependencies

_No response_


Discussion:
If #4302 can be reopened then maybe I can work on it.
We would love to have this feature, as we are going to deploy an FttH infrastructure in the near future.
AFAIK, and that's with my relatively limited knowledge of the technology, the list given by @janchrillesen on #4302 seems to be accurate (with the need for adding the '+' for 10G connection), with maybe the exception that DWDM should be TWDM (NG PON 2), but maybe there's a standard I don't know with that name.
A nice to have would also be the ONT equivalents
We too have a Tellabs GPON system in our infrastructure and would love to have this included with NetBox. 
I can try to work on this if no one's opposed
Duplicate of #4302
Can you provide a list of actual physical interface types you wish to model?
Sure, I'll compile those and add them to the original text of this issue.
The list would resemble that : 
GPON:
SFP GPON OLT (2.5G)
SFP+ XG-PON OLT (10G)
SFP+ XGS-PON OLT (10G)
SFP+ CPON OLT (10G/2.5G) *
SFP+ TWDM-PON OLT (10G)
XFP XG-PON OLT (10G)
XFP XGS-PON OLT (10G)
XFP TWDM-PON OLT (10G)

EPON:
SFP EPON OLT (1G)
SFP+ 10G-EPON OLT (10G)

I also think generic ONT PON types could be useful : 
GPON ONT (2.5G)
XG-PON ONT (10G)
XGS-PON ONT (10G)
EPON ONT (1G)
10G-EPON ONT (10G)

* I suggest the removal of this type because it could be modeled by 2 interfaces of the desired combo, if I understood correctly what was intended in the first issue.
I also wander how to model some "weird" PON modules, such as nokia's double GPON XFP module.

Would it be better to scind the PON technology from the module's connectivity ? And therefore be able to model the weird things manufacturers come up with ?
@BrunoBlanes @DorianXGH  So I have a question about this.

How are you expecting to connect these up?  Currently, there is a 1:1 relationship between interface and fiber (1 interface can only connect to either a single interface, front port or rear port with 1 position)
@DanSheps I don't quite follow what you mean. `GPON` would be an interface type and it would have its SFP modules as inventory items.
Yes, but supposedly you would want to connect fiber to this interface at one point.  I am saying that the interface-to-port (front or rear) is a 1:1 relationship.

You can't go out and have 1 interface connect to a rear port which spiders out into multiple "front ports" for each end user.  I just want to make sure you are clear on the limitation of if we did this you would either be limited to a single "strand" end-to-end.  You couldn't model the splitter and CPE devices for example.
Oh, I'm aware of that. Our need is to document the network as long as active devices go, mainly because if we were going to map the fiber with all the splitters, we'd be mapping the entire outdoor fiber network.
We work with OLTs and they have PON ports, that's as far as I'd like to go with this for now.
But hey, that could be a future major release of Netbox, documenting passive optical networks with splitters and all, not a bad idea.
@BrunoBlanes Oh, I thought about modeling splitters like switches, it's not the nicest way of doing it, but doing it cleanly would require a proper decoupling of the L2 and L1 layer.
Otherwise I agree with putting the module connection with the OLT in the inventory. Still, I think having the different PON technologies would be better, to model the bandwidth capabilties.
That would make it :
- GPON
- XGPON
- XGSPON
- TWDM-PON (NG-PON2)
- EPON
- 10G EPON
>  I thought about modeling splitters like switches, it's not the nicest way of doing it, but doing it cleanly would require a proper decoupling of the L2 and L1 layer.

Yeah, it would be messy and might not work as intended for everyone, so I think we'd be better off not doing that. As for the PON technologies, I think that is a great list we might just need to detail it a bit more, for example `GPON (2.5GE)`.

Also I should ask, these would be under any existing interface type category, like `Ethernet (modular)`? Seems like it might be better to define a new one.
Yeah, a new `PON` category seems like a good idea.
This would make the list:
- GPON (2.5G/1.25G)
- XGPON (10G/2.5G)
- XGSPON (10G)
- TWDM-PON (NG-PON2) (4x10G)
- EPON (1G)
- 10G EPON (10G)
Just to throw some more complexity into this...

Several vendors are offering "combo" OLT cards that can run multiple PON technologies simultaneously out the same OLT port using multi-wavelength optics.  Adtran, Calix, and DZS are all doing this.  

These cards can fire both GPON and XGS-PON wavelengths onto a single distribution network (ODN) out to a common splitter.  The technology that is used is entirely dependent upon the ONT installed at the customer premise.  If you install a GPON ONT, it locks onto 1490/1310.  If you install an XGS ONT, it locks onto 1577/1270.  So, you'll have a single ODN and splitter running ONTs on different technologies.  Within the software of the shelf itself, it creates 2 virtual/logical ports for each physical OLT/PON port on the card.  Example:  An Adtran 8 port combo OLT card consists of 8 physical ports.  If you install 8 of the multi-wave optics into the card, the TA-5000 shelf creates 16 PON ports internally.  1-8 are GPON, and 9-16 are XGS-PON.  The internal GPON port 1 and XGS port 9 are logically connected to the physical port 1 on the OLT card.  

So, how does one model this in NetBox?  You can't necessarily have a single port running two "speeds", and you can't really create a module with 16 ports, because there's no way to connect two ports to a single fiber and splitter.   Maybe something clever could be done with the bridging feature?  

From what I understood here and by having taken a look at some of Adtran products, you are talking about a modular 10 Gigabit PON port interface which accepts both a GPON `or` an XGS-PON transceiver.
In that case, I think it is safe to assume that the board itself would contain 8 generic `10G  PON` slots where you can then plug your specific `GPON (2.5G/1.25G)` or `XGS-PON (10G)` transceivers into.
From our previous discussion, I think was discussed that only the logical PON port would be modeled as interfaces, with the underlying modules as inventory items. I don't think netbox can currently model PONs that effectively, so as long as Netbox keeps its L1/L2 representation as is, PONs, especially the ODN part, will be kind of hard to model, but perfect is the enemy of good. The proposed list aims to model the logical PONs for now, and maybe, as we are a few small ISPs wanting to use netbox to model their network, we might later want to work towards more modelling ability.
Bruno... Yes and no.  Adtran has an 8 port Combo OLT card.  
This card can accept three different types of SFPs (and their various flavors) in each physical SFP+ slot:
- GPON SFP:  1490/1310 - Allows only GPON ONTs on the ODN
- XGS-PON SFP+:  1577/1270 - Allows only XGS-PON ONTs on the ODN
- Combo/Multi-Wave SFP+:  1490/1310 AND 1577/1270 - Allows both GPON and XGS-PON ONTs on a single ODN/splitter at the SAME TIME. 

Think about these multi-wave optics as like a DWDM optic that fan transmit and receive multiple wavelengths at the same time.  In this case, its a bi-directional PON SFP that is transmitting two waves (1490 and 1577) and receiving two wavelengths (1310 and 1270).  This is pretty new stuff, so I understand if most aren't familiar with it.  Its much like having multiple vlans on a trunk, but this is at the layer 1 level.   The SFP basically has a built-in mux/demux.

When you insert one of these "8 Port Combo OLT" cards into a TA-5Kx shelf, the shelf will internally create 16 logical ports.  Ports 1-8 will attach themselves to the GPON plane, and ports 9-16 to the XGS-PON plane of the card.  Logical ports 1 and 9 are bridged at layer 1 to physical port 1, regardless of what type of transceiver is installed.  If you install a GPON only SFP into physical port 1, logical ports 1 and 9 will still exist, but you wont be able to provision services to logical port 9 because a layer 1 path won't actually exist for XGS on the ODN.  I mean, you can provision to logical 9, but you won't be able to use an XGS ONT on that ODN.  However, if you install one of the multi-wave SFPs into physical port 1, now you DO have that layer path.  With this, you can install both GPON and XGS-PON ONTs on the same ODN.  You'd provision the GPON ONT to logical port 1, and any XGS ONTs to logical port 9.  

Make sense?

Again, this may be impossible to model in NetBox.  However, this is what all of the primary PON vendors (Adtran & Calix) have moved to, so I felt it was important enough to at least mention it before a whole bunch of work goes into modeling the obsolete PON model we've been used to for 15+ years.  Pretty soon, you won't be able to get "GPON only" cards.  This new way gives providers the ability to easily - and inexpensively - make their networks 10G-PON ready from the start without having to use PON coexistence elements (the industry's fancy word for a PON WDM) or rework the fiber infrastructure in the headend/CO/RT.  Vendors like it because they dont have to engineer or manufacture 15 different flavors of cards.  Those who work for ISPs that are just now getting into PON... you should ask your vendors why they're NOT telling you about this.  My assumption is that they want to get rid of all the backstock of legacy/obsolete stuff in their warehouses.  The cost difference between the old and new way is only 5-10%. 

Shelf
 - OLT Card
   - Physcal PON Port 1 with multi-wave SFP    --->  Splitter ---> ONT (can be GPON and XGS)
      - Logical GPON Port 1:  GPON ONTs provisioned here
      - Logical XGS PORT 9:  XGS ONTs provisioned here
      
   - Physical PON Port 2 with GPON SFP   ---> Splitter ---> ONT (GPON only)
      - Logical GPON Port 2:  ONTs provisioned here
      - Logical XGS Port 10:  Nothing provisioned here
      
   - ...
   
   - Physical PON Port 8 with XGS SPF   ---> Splitter ---> ONT (XGS Only)
      - Logical GPON Port 8:  Nothing provisioned here
      - Logical XGS Port 16:  ONTs provisioned here


    
I have seen those modules before and my answer was in light of this knowledge. There are so many different physical modules with each their own interfaces that listing them all exhaustively would be really difficult, thus our proposal of having "logical" PON ports. In the case of multiwave modules, they'd be modelled by 2 "logical" PON interfaces, a GPON one and an XGSPON one.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
We have a ZTE  XGPON system in our infrastructure and would love to have this included with NetBox.
Now I'm trying to add some devices type.

How to model a single GPON port (GBIC) that can mount different types of modules?


Has a consensus been reached on this proposal? Does anyone want to own its implementation?
@jeremystretch 
Most comments regarding the proposal seem to stem from the difficulty to model the weirdness that some manufacturers come up with, but as we said, it is possible to model it with out proposal, even if it is in the same way combo ports are currently modeled.
I can write a PR to implement this if needed.
I think that the main problem about GPON is (was) the splitter logic (one-to-many-cables). With version v3.3-beta1 - 2022-07-14 of netbox this problem vanish. 
> I think that the main problem about GPON is (was) the splitter logic (one-to-many-cables). With version v3.3-beta1 - 2022-07-14 of netbox this problem vanish.

I don't think that was ever a problem since this proposal is not related to mapping passive GPON equipment like splitters and such.

Resolving patch:
diff --git a/netbox/dcim/choices.py b/netbox/dcim/choices.py
--- a/netbox/dcim/choices.py
+++ b/netbox/dcim/choices.py
@@ -814,6 +814,14 @@ class InterfaceTypeChoices(ChoiceSet):
     # ATM/DSL
     TYPE_XDSL = 'xdsl'
 
+    # PON
+    TYPE_GPON = 'gpon'
+    TYPE_XG_PON = 'xg-pon'
+    TYPE_XGS_PON = 'xgs-pon'
+    TYPE_NG_PON2 = 'ng-pon2'
+    TYPE_EPON = 'epon'
+    TYPE_10G_EPON = '10g-epon'
+
     # Stacking
     TYPE_STACKWISE = 'cisco-stackwise'
     TYPE_STACKWISE_PLUS = 'cisco-stackwise-plus'
@@ -950,6 +958,17 @@ class InterfaceTypeChoices(ChoiceSet):
                 (TYPE_XDSL, 'xDSL'),
             )
         ),
+        (
+            'PON',
+            (
+                (TYPE_GPON, 'GPON (2.5 Gbps / 1.25 Gps)'),
+                (TYPE_XG_PON, 'XG-PON (10 Gbps / 2.5 Gbps)'),
+                (TYPE_XGS_PON, 'XGS-PON (10 Gbps)'),
+                (TYPE_NG_PON2, 'NG-PON2 (TWDM-PON) (4x10 Gbps)'),
+                (TYPE_EPON, 'EPON (1 Gbps)'),
+                (TYPE_10G_EPON, '10G-EPON (10 Gbps)'),
+            )
+        ),
         (
             'Stacking',
             (


Test patch: