Virtual Circuits and Parent/Child Circuits

[jsenecal]

Resuming from a conversation I tried to start on Slack,

I'm faced with a problem, perhaps there is a simple solution but I would like your opinion on the subject.

Currently there is no proper way to "map" a single vlan or virtual interface (think vlan based sub-interface) to a circuit termination

I used to create sub-interfaces of type "other" prior to the introduction of "parent" interfaces, but now if I do that I lose the parent-child relationship as nothing else than a "virtual" interface type is allowed when a parent is selected. It also requires a "fake" cable to be created to link that also "fake" interface to the circuit termination.

Enters the concept of the parent circuit, or parent termination:
An example use-case is with circuits provided by third parties that are delivered as single vlans on a another "Port" or "NNI" circuit.

Each circuit has a physical Z side, but they have a logical (vlan) A side;
The logical A side is usually delivered through what is called an NNI, like so:

Those very familiar with the carrier ethernet concepts will know that these circuits are closer to the new "Overlay/EVPN" stuff than actual physical circuits but some of the the physical aspects are important too....

Would this be a functionality that others would love to see ?

[edugas]

Currently facing the same issue (as an NSP). This would be VERY useful.

[SteveRodrigue]

The impossibility to attach a circuit/service ID to a virtual interface has also been a problem for me. In NB, we can only create physical circuits, but in many use case, the physical circuit is just the carrier/envelope of multiple circuits and services. We would like to find a way to attach virtual interfaces to a circuit/service ID.

Your example is very common: 1 physical port with multiple vlans carrying L2 or L3 services.

Another use case would be attach 2 virtual interfaces (A and Z) to a single circuit to create a logical Layer-2 point-to-point (L2vpn/MPLS x-connect). In those case, we don't need a "trace", but a logical link between 2 logical ports that can be very far away.

[kmorin18]

Great idea Jonathan! All our circuits are attached to a virtual interface of some kind at some point in our network.

I would love to see this

Thanks for your continued involvement and contribution to the netbox community

[shatt79]

This has been a problem in pretty much every F&E/DLR application we've used in telecom. Our workaround in the past was to create a "virtual" generic ethernet switch with 100+ ports in order to "terminate" the virtual circuits thru the NNI with the other carrier. It's ugly, but sort of worked. But you're right... I wish someone would figure out how to accurately model (in software) the types of things us carriers have been doing for the past decade. I won't even mention tag popping, swapping, and translations.

[jsenecal]

I won't even mention tag popping, swapping, and translations.

VLAN Membership is also something I'd like to tackle with this approach, perhaps assigning vlans to those "Virtual circuits" ?

[shatt79]

One option is to create a VLAN Group for each NNI...

[wmclendon]

this feature described here would absolutely be valuable - my use case I mentioned today in slack is slightly different, I think (unless i'm missing something).

In my example from slack today, I have a single L2 p2p circuit between two sites, but the provider (Comcast, in this case) supplies me with three IDs -- one is the EVC ID which is the "circuit", and then two UNI IDs - one for site A, the other for site B. All of these are useful to have documented -- the tact i'm looking at taking right now is the Netbox Circuit ID will be the EVC ID, and i'm putting the UNI ID's in the comments. I'm not sure if comment content gets searched where if someone just searched for the UNI ID they would find it.

[jsenecal]

UNI IDs in this case are like "legs" of the same circuit ? are these services vlan-transparent ?

[wmclendon]

from Comcast's perspective in this example I think each UNI represents their physical attachment at a given site. i.e. UNI ID abc-0001 for Site A, and UNI ID xyz-0001 for Site B. in Metro Ethernet lingo UNI means "User Network Interface" - definition from https://wiki.mef.net/pages/viewpage.action?pageId=54762710 - "The User Network Interface (UNI) is the physical demarcation point between the responsibility of the Subscriber and the responsibility of the Service Provider".

as I said i am not sure that my use case I referenced is exactly applicable to this issue's goal -- but I will reiterate what this Issue is looking to solve would absolutely help us for other things too!

[jsenecal]

So, to recap the few types of "virtual" circuits:

• EVPL (Ethernet Virtual Private Line) variant - Point to Point:
  1. Most of the time has a VLAN ID, not BPDU transparent but could be untagged at both ends and thus be represented by the current models.
  2. Can be physical at both ends and thus be represented by the current models.
  3. Can be logical at both ends (tagged VLAN) (Requires a parent circuit/termination)
  4. Can have a physical side and a logical side (see iii). (Requires a parent circuit/termination)
• EPL variant Point to Point:
  Physical to physical. Already supported by the current models.
  A distinction should be made between an "EPL-Like" ethernet circuit (Wave/Electro-Optical/Sonet circuit) and something like a Dark Fiber pair which is like a cable and behaves like a cable (wavelength transparent, etc.).
• Ethernet Virtual Private LAN or E-Tree - Point to Multi-Point:
  Similar to EVPL above, but has multiple end-points, which is not represented with the current models
• IP Based - IPsec, IP-IP, GRE, etc... :
  Do we want to document these in any way ? I believe those would be better represented in the IPAM models, so, a different use-case.

[shatt79]

E-Tree and E-LAN are different things.

For E-Line (P2P) you have EP-Line (port based) and EVP-Line (VLAN based).

For E-LAN (P2MP) you have EP-LAN (port based) and EVP-LAN (VLAN based).

For E-Tree (rooted multipoint) you have EP-Tree (port based) and EVP-Tree (VLAN based).

Any type of port based service should never be associated with a sub-interface, service instance or VLAN.

Any type of VLAN based service should never use physical interfaces as an endpoint or EFP (ethernet flow point). Sub-interfaces, service instances and VLANs must always be used.

[DanSheps]

So, if we are just extending the Circuits model, I don't think there is a need to worry too much about the "Type". That is covered by Circuit Type. I think the only model needed is the parent/child model.

[fatman00]

We have lot EVPL type iv circuits as you describe. Some way to connect them to the sub interface we use or VLAN interfaces would be great.

[DanSheps]

Are we modelling this from the SP perspective or the customer perspective?

I ask, because from the SP side, this is already handled by the L2VPN model, and I don't think we need much more beyond that TBH.

[jsenecal]

The intent was to model the customer perspective. Circuits and "virtual circuits" purchased from a third party

[davidgwatkins]

This is absolutely something that I would like to see, yes. My current workaround for this functionality is to use an unscoped VLAN Group per NNI Interface (or as is common in my deployment, a redundant pair of NNIs), with the attached cables connecting the parent NNI port to the NNI Circuit Termination, then use a pair of custom field linking the VLAN to the EVC Circuit, and back.

My suggestion would be to:

• Enable additional scoping for VLAN Groups, to port(s)
• Enable optional ForeignKey between Circuit and VLAN
• Enable parent-child relationships between Circuits (ForeignKey to self?)
• For the sake of completeness, perhaps another optional ForeignKey between L2VPN and CircuitID -- to account for deviations between L2VPN operational identifiers and customer billable identifiers

[iunderwood]

Let's kick up dust on an old thread!

This came up on the hangout after this month's community call ... and I was thinking about how this can be achieved. I don't think it would be too costly to do, but it would require allowing circuits to be associated to an interface similar to how L2VPNs can be associated to interfaces.

Anyway, the whole idea which I don't feel like re-editing at this hour:

---

In an Ethernet infrastructure from a service provider, there are commonly a few different circuits in place.

A circuit identifying the physical line itself is often defined and connects to a given provider network interface device (NID) and can provide a user network interface (UNI) or a network to network interface (NNI). Documenting these circuits is straightforward.

However, sometimes VLANs are trunked over these circuits which represent different connections. A remote site may have a physical circuit with two separate VLANs. These VLANs could connect to two headend sites for an enterprise, for instance, or to the enterprise and another service that the provider offers. These would be tracked as two separate circuits from the provider, running over a common physical circuit.

These VLANs may be configured as subinterfaces (e.g. TenGigabitEthernet1/0/15.925), VLANs (Vlan925), or BDIs (BDI925), or some other variety of virtual interface as properly modeled within NetBox. However, it would be incredibly useful to be able to attach circuits to these virtual interfaces, not unlike how L2VPN Terminations can be added to an interface for association.

For example, a headend location for an enterprise may have an NNI with circuit ID 123456-NNI-NDHMMAIO and a number of other associated circuits. This NNI would physically be connected to the interface defined on the device in NetBox. This circuit carries multiple ENET circuits, each terminating with a separate VLAN coming over the same parent trunk. For example: 234560-ENET-MCF, 234234-ENET-MCF, 235423-ENET-MCF, etc.

The only way to mimic the connection modeling to support this today is to configure the subinterface, vlan, or bridge interfaces as physical interfaces and connect the circuits accordingly. This is suboptimal for many reasons, including the inability to correctly tie the interfaces to their appropriate parent interfaces.

While I used point-to-point circuits in my example, there is no reason this can't also be tied to circuits that connect to other provider network services that are multipoint.

[jsenecal]

FYI I created #13086 to address this feature.