Graduating networks peer to standard channel from experimental

[tssurya]

Describe the issue:

We added support for networks peer which is a list of inline CIDRs #185

There are currently two implementations definitely who have implemented this:

1. OVN-Kubernetes
2. Calico

Other CNI implementations like Kube-OVN are waiting for this API to be in standard channel rather than experimental: kubeovn/kube-ovn#3247 (comment)

are there any concerns from the maintainers of the repo if I move this peer to standard channel?

@danwinship / @Dyanngg / @aojea / @astoycos ?

As per our docs: https://network-policy-api.sigs.k8s.io/versioning/?h=beta#experimental-standard (I can open another issue to track what we spoke about whether we want standard/experimental to mean stability OR optional but for all intents and purposes of this field there was no controversies on the optional/mandatory bits so we should try to focus on stability aspects here); it seems I need to fullfill alpha->beta chain of events: https://network-policy-api.sigs.k8s.io/versioning/?h=beta#alpha-beta

so we seems to satisfy most of the requirements here. Only missing bit is validation which I was waiting for 1.31 kube to have isCIDR validation: https://github.com/kubernetes-sigs/network-policy-api/pull/256/files#diff-e14a317f3c12a983e1037dec16d99833bd1398ab66a65a8b6476adad81d05b1cR150 so once we fix the bump to 1.31 we should be able to move networks peer.

[tssurya]

/assign @tssurya

[tssurya]

I will also tag all active community members for awareness
@npinaeva @fasaxc @nathanjsweet

[aojea]

Networks is the new IPBlocks, right?

[tssurya]

Networks is the new IPBlocks, right?

yup! https://network-policy-api.sigs.k8s.io/npeps/npep-126-egress-traffic-control/#implementing-egress-traffic-control-towards-cidrs

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale