Description of problem:

In a networkpolicy, when a protocol is specified but the port is not, traffic is blocked to all pods in that project.

This behaviour is counter to what is specified in https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#networkpolicyport-v1-networking-k8s-io and in https://docs.google.com/document/d/1cTA_c1qahzZ9nDI-h6Vp9-9_kCB-kk1cw91K0qRjI84/edit


Version-Release number of selected component (if applicable):

3.11


Steps to Reproduce:

1. Create a test project (eg, "p1").
2. Create two pods in the project that can easily verify that traffic is flowing (eg, a simple http pods).
3. Label the pods so that it can be identified by a networkpolicy (eg, "app=p1" and "app=other").
4. Verify that no networkpolicy objects are applied to any project.
5. Verify that you can curl the pods successfully.
6. Create an ingress networkpolicy such as this (note that the label targets one pod and that the port is not specified):

{
    "apiVersion": "extensions/v1beta1",
    "kind": "NetworkPolicy",
    "metadata": {
        "name": "port-defined-only-by-protocol",
        "namespace": "p1"
    },
    "spec": {
        "ingress": [
            {
                "ports": [
                    {
                        "protocol": "TCP"
                    }
                ]
            }
        ],
        "podSelector": {
            "matchLabels": {
                "app": "p1"
            }
        },
        "policyTypes": [
            "Ingress"
        ]
    }
}


7. Try again to curl the pods - it _should_ succeed according to the docs linked above but both pods will fail to respond.
8. Edit the network policy adding a port (eg, 80 or 8080, whatever is appropriate for the image you are using).
9. Curl again. It should and will succeed.


Actual results:

No traffic ingresses to any pod in the project.


Expected results:

Not specifying the port should allow traffic of the specified protocol to flow to _any_ port. Also, not specifying a port, should not block traffic to pods that the policy is not targeting.


Additional info:

It is possible that this behaviour is by design but looking at the description of the behaviour when not specifying a port, it looks like either a bug in networkpolicy implementation or some sort of docs bug.

It is also possible that there is an issue or intended behaviour using 'matchLabels' with a 'ports' block but I cannot find mention of this.