12

Most of the discussion for what was on/off topic by this community took place early in the life of the community before many of the currently active members had joined us here. While there have been a number of discussions in the years since, most of the changes have been more along the lines of clarifications than actual changes in policy.

Over five years have passed since our community joined the SE network of sites. In that time, our community has graduated from beta, continued to grow and changed. The professional networking field itself has changed in this time. Reasons for early decisions were based on how to best serve our community as well as users/visitors/guests to both our community and the wider SE community. These reasons may still be valid, but they may also no longer apply.

We as moderators thought this may be a good time to allow the community to take some time to re-evaluate those early decisions to get a sense of what will best serve our community today and into the future. This may be include both topics that are currently off topic that you believe should be on topic or topics that are currently on topic that you feel should be off topic.

How to contribute to this question. If these rules are not followed, your contributions may be modified or deleted to fit within the rules.

  1. In all things, keep in mind the purpose of the community: Network Engineering Stack Exchange is for asking questions about professionally managed networks in a business environment. Let this help guide your contributions and voting.
  2. Answers should be limited to a single topic to be voted on and a statement that it "should" or "should not" be on topic.
  3. Reasoning for the topic to be on/off topic should be carried out in comments or preferably in chat. If you post your reasoning with the topic, votes may reflect people's agreement with your reasoning rather than whether they believe it should be on/off topic.
  4. Please check back frequently and vote on answers. An up vote would indicate that you agree the topic should be on/off topic, a down vote would indicate that you believe the current policy should remain as it stands.

After giving some time for the community to contribute answers and votes, topics the community has indicated they feel strongly should be changed may have follow up meta discussions to define the scope of any such changes. Keep in mind that just because a topic is voted up does not necessarily mean it will result in a change and before any changes are made, a follow up discussion on the topic would likely take place.

We look forward to the community's input in this process.

For reference, if you haven't seen it (recently), our Help Page covering topics.

18

Advanced routing protocols like BGP, OSPF, IS-IS, VXLAN and EVPN on platforms without a paid support option (like Quagga, Mikrotik, FRR).

To me it feels 'wrong' that questions about these protocols, which this people on SE should be able to answer best, are considered off topic only based on the fact that there's no commercial support.

Currently off topic, should be on topic.

  • For information: Mikrotik's business model is built on paid support through a network of "Certified Consultants" who have passed various Mikrotik certifications; there's a sense in which this is exactly paid commercial support, albeit semi-detached from the manufacturer. – jonathanjo Nov 21 '18 at 15:26
  • I have no problem with this, in general, but I'm concerned about how to exclude the really consumer-grade devices (Linksys, Netgear, D-Link, etc.). Even MikroTik, that makes enterprise-grade equipment, makes routers targeted at home users. I think we need to somehow distinguish between the consumer-grade devices and the equipment meant for businesses, even if a particular vendor makes both. I also think that consumer-grade devices used in a business should still be off-topic. – Ron Maupin Nov 24 '18 at 19:18
  • I'd also like to add something here - there are likely a set of issues around interoperability between the platforms mentioned and the traditional commercially supported options. As an example - it's entirely possible in EVPN for a given implementation to be compliant with published RFC's and also incompatible with implementations from other vendors (hint - already an issue with Cisco vs Juniper vs Alcatel). TL;DR I agree that the suggestion above is potentially a useful line of discussion. – rnxrx Nov 25 '18 at 22:36
  • 1
    @RonMaupin as we concluded in various chats now, its hard to draw the line between consumer and enterprise, whatever system we come up with. I added this answer specifically to see if a (perhaps partially) different approach (the way something is used instead of if there's commercial support for it) would be an approach supported by the community. – Teun Vink Nov 26 '18 at 6:02
  • 1
    Right, but I'm wondering if we could say something like excluding devices sold primarily for home/residential/consumer networking, even if used in a business. That is still a pretty gray area, and there will still be a lot of pushback, but we get that anyway. That could open up things like the MikroTik enterprise/business-class equipment, while excluding the MikroTik home networking equipment. – Ron Maupin Nov 26 '18 at 22:55
14

Cloud-based networking, such as Amazon VPC configuration, NAT gateways, VPN configurations, BGP routing, load balancing, etc. Also Azure virtual networking, and similar offerings by other cloud providers.

Admittedly, there will be overlap with questions on the basic compute and application services these vendors offer, and those would best be answered on Server Fault. But the networking technologies involved in cloud computing are the same ones we deal with everyday, and they would generate the same sorts of questions we answer daily.

One could also make the argument that in a few years that will be where most of our careers are headed anyway.

Currently off-topic; should be on-topic.

Other related meta discussions here and here.

  • 1
    AWS networking is in my opinion pretty much like Cisco networking: there are a load of tips and tricks and terminology and particular ways of doing this. My clients regularly need to connect for example a database server in AWS zone X to physical location Y; it's the network people's job to deal with addressing, tunnelling, routing etc, and it would be much better if these topics were therefore on-topic here. – jonathanjo Nov 19 '18 at 20:17
12

Services that are required for normal operation of a network such as DHCP, DNS, RADIUS, etc.

Currently mostly off topic (unless on a platform such as IOS), and should be on topic.

Other related meta discussions: here, here, and here.

  • One of the topics that has been discussed several times, so works as a good example post. – YLearn Nov 19 '18 at 19:55
  • I guess I would like to understand more about what this entails. Is it only the protocols, or does it include server configurations on the various different server platforms, perhaps limited to certain platforms? – Ron Maupin Nov 19 '18 at 19:57
  • As noted in the original post, the exact scope of any changes for topics the community feels strongly about will be determined in a topic specific post once the community has time to provide feedback. So consider this more in a general sense. My fear on making topics like this more specific at this stage is that we would end up with half a dozen (or more) answers around a topic like this with competing ideas on what is exactly on topic. – YLearn Nov 19 '18 at 20:01
  • 1
    In most environments I've worked in, there have been separate people/groups responsible for networks and servers; DHCP, DNS, RADIUS, TACACS, NTP have almost always sat with those responsible for routing, buying network lines, and not with those responsible for ensuring disk space, file servers, web servers, etc. So I completely agree, these network support protocols should be on topic, regardless of platform. – jonathanjo Nov 19 '18 at 20:13
  • 1
    The flip side to the on/off topic coin has always been that this is a community on the smaller side and that people with questions may get answers faster (and possibly better) on sites such as Server Fault. This has often been one of the reasons for having these topics largely off topic on this site. – YLearn Nov 19 '18 at 20:20
  • 2
    So take the example of DNS hosted on a classic Microsoft/AD environment. Is there a line drawn between supporting basic DNS configuration issues vs configuration problems that tie to a deeper AD design/layout problem? Do we get into resource pointers and such? Similarly, would we agree that there's still a distinction to be drawn between RADIUS servers and the back-end auth infrastructure? I'm actually generically in favor of opening up the rules a bit on this topic but there still needs to be limits, IMO. – rnxrx Nov 25 '18 at 22:43
  • @rnxrx, agreed. We would need a follow up post deciding those limits. This is more to get a general sense of where the community stands on issues and those they would like to see changed. – YLearn Nov 26 '18 at 7:01
10

Clarification of "protocols above L4 in the OSI model are off-topic" to specifically mention routing and tunnelling protocols, which should all be on-topic.

  • L2TP is on top of UDP
  • BGP is on top of TCP

I don't know that anyone would disagree: I'm just trying to make the rules clearer.

  • 1
    As far as BGP goes, that is a routing protocol, so it is on-topic based on: "design or theory of protocols used to operate a network (e.g. IP, TCP, routing protocols, STP, etc);" – Ron Maupin Nov 28 '18 at 21:21
  • 1
    I am only suggesting we word it a little better than currently, which reads as if the off-topic list overrides the on-topic list. – jonathanjo Nov 28 '18 at 21:27
  • 2
    Agreed. Protocols above L4 in the OSI model is too ambiguous. Different folks categorize protocols at different layers of the OSI model. Some routinely ignore / avoid classifying anything strictly within one layer of the OSI model. – Eddie Dec 5 '18 at 2:07
  • 1
    See also OpenFlow and other weird SDN stuff, which is already on-topic. – Kevin Dec 14 '18 at 3:25
  • 2
    If it helps, L2TP is Link Layer protocol. Just because L2TP is carried by a Transport Layer doesn't magically make it offer Session Layer services. A trickier issue is DNS, the naming application, which needs to be in scope despite other network applications (HTTP, SSH, etc) being excluded. – vk5tu Dec 16 '18 at 11:09
6

Overlay networks, such as torrent or bitcoin, should be explicitly off-topic.

There have also been questions about other proprietary or open source overlay networks, but this topic has not been explicitly addressed in the past.

  • 1
    For the same reasons, TOR should be explicitly off-topic – jonathanjo Nov 28 '18 at 19:48
  • Yes. I meant this to be a broad subject that is off-topic. – Ron Maupin Nov 28 '18 at 19:51
  • @jonathanjo, I just saw something that reminded me that we need to distinguish between TOR (The Onion Router) and ToR (Top of Rack). The former being off-topic, while the latter is on-topic. – Ron Maupin Nov 28 '18 at 21:28
  • Goodness there's TLA for everything! Obviously switches on topic, wherever you put them! – jonathanjo Nov 28 '18 at 22:23
  • @jonathanjo, all I had to do was mention it, and we get a question about ToR, but it says TOR: networkengineering.stackexchange.com/q/55076/8499. – Ron Maupin Nov 29 '18 at 15:15
  • 4
    I would suggest clarifying the definition of overlay network. Although I would agree that torrent/bitcoin don't make the grade, SDWANs are typically overlays of some sort, and most likely should become or remain an allowable topic, in my view. – Jeremy Gibbons Dec 7 '18 at 6:51
  • This may exclude discussion of faults with Content Distribution Networks. Over half of an ISP's bytes come from a CDN. – vk5tu Dec 16 '18 at 10:37
5

I'd like to see virtual host switches (VMware ESXi and MS Hyper-V) added to the 'on' topics.

These switches share a lot of logic with their physical cousins - and need to interface with them - but do have their own flavor.

On-topicness (is that a word?) should be limited to the switch configuration on the host, not including other host configuration items.

Other related meta discussions here and here.

  • I can see this, but we would need to make sure that it is for a business network, and problems with a host OS are not covered. – Ron Maupin Nov 25 '18 at 0:59
  • 1
    I would also suggest adding container networking to this category. – Jeremy Gibbons Dec 7 '18 at 8:03
  • 1
    And maybe also clarify the status of overlay technologies such as VMWare NSX and other SD-Datacenter tech. It is not obvious to me in the current definition whether that is on or off topic here. – Jeremy Gibbons Dec 7 '18 at 8:08
4

Linux based and/or open source products often used as routers/gateways/access control for small to medium business (or larger enterprises in niche conditions).

These come to mind quickly as possible examples, but this is not a definitive list: Vyatta, MikroTik, pfSense, PaketFence, or OPNsense.

How to define the scope of such products would have to be a follow up topic.

  • This seems to be related to Teun's answer above. I think we have been answering for Vyatta and pfSense because they offer optional, paid support. This would be fine if we can define a scope. – Ron Maupin Nov 24 '18 at 19:22
  • @RonMaupin, Teun's answer specifies advanced network features on the platforms, this is instead asking about the platforms themselves being on topic in a more general sense. Figured this should be added since we have had a number of questions about this over the years. As for the examples, yeah they aren't perfect but my intent was to provide examples of the type of product without actually looking into what might/might not be on topic already. – YLearn Nov 26 '18 at 7:06
  • 1
    The essential problem is that network management is moving into a special case of systems administration. Consider the workflow of a modern ISP: YAML templates in Git, manipulated from programs in Docker containers run from Jenkins continuous deployment, outputting Ansible playbooks which apply YANG configurations via NETCONF. This can be expected to increasingly become evident in enterprise deployments and yet most of the topics are currently out of scope. – vk5tu Dec 16 '18 at 10:51
  • 3
    @vk5tu, not sure how your comment addresses anything in this answer or it's comments. Perhaps you meant to add it to a different answer? – YLearn Dec 16 '18 at 16:13
1

Enterprise Internet access architectures, including peering arrangements, use of Internet Exchanges, performance & path monitoring, etc... should be on-topic.

  • These networks are not usually under our direct control, but they are a huge (and growing) part of what an enterprise networking team needs to deal with when they engineer a modern global corporate WAN. – Jeremy Gibbons Dec 7 '18 at 7:00
  • The reasoning behind limiting to networks under direct control is that allowing questions like the ones you suggest leads to questions that can only be answered by opinion and/or guesses. Questions where your network is connecting to the larger network at least allows a poster to provide information about their side of the connection. For example, you mention peering arrangements and to get an answer to "what kind of peering arrangement do X and Y have" could only be answered by someone from X or Y unless either X or Y have made details public, which is highly uncommon. – YLearn Dec 7 '18 at 7:10
  • I don't necessarily want "is X peered with Y" discussions, I understand why that's not desired here. However I believe there are legitimate question around the design of a corporate WAN that involve networks that are not under our direct technical control and that are relevant for this community. One example that comes to mind is how to handle Internet egress from China. Or maybe which solutions can be used to measure peering performance between two points on the Internet to optimize Internet-based WAN performance. – Jeremy Gibbons Dec 7 '18 at 8:02
  • Your examples would already be on topic for your corporate WAN. What you are in essence asking is how to configure your network for those cases. Traffic that egresses China: do you allow it, do you handle it differently in some way, and so on. How can I optimize the use of multiple service provider links to account for issues on the Internet or how can I use routing to choose/encourage a different path based on performance. These are questions about how to configure the network under your control based on outside information. But they are about a network you control. – YLearn Dec 7 '18 at 8:10
  • OK fair enough, thanks. – Jeremy Gibbons Dec 7 '18 at 8:23
1

Questions should be on topic by their actual topic and not their subject. If someone by dumb luck happens to replace "home" with "office" in their question, then people here consider it on topic, when that is a completely irrelevant data point.

If someone asks a question about ARP proxying on their Cisco, that is no more valid than if they asked that about ARP proxying on their linux box. The same goes for a litany of protocols and functions.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .