diff --git a/npep/npep-127.md b/npep/npep-127.md
new file mode 100644
index 00000000..7ce99444
--- /dev/null
+++ b/npep/npep-127.md
@@ -0,0 +1,88 @@
+# NPEP-127: Add southbound traffic support in (B)ANP API
+
+* Issue: [#127](https://github.com/kubernetes-sigs/network-policy-api/issues/127)
+* Status: Provisional
+
+## TLDR
+
+This NPEP proposes adding support for cluster ingress (southbound) traffic control in the `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` API objects.
+
+## Goals
+
+* Implement ingress traffic control from external destinations (outside the cluster)
+
+## Non-Goals
+
+(What is out of scope for this proposal.)
+
+## Introduction
+
+Currently, (B)ANP only allows to specify [peers](https://github.com/kubernetes-sigs/network-policy-api/blob/46be90096f23934f56342bc408b94a1aa79a159c/apis/v1alpha1/shared_types.go#L98-L103) 
+based on pod and namespace selector, that will only apply to non-hostNetwork cluster pods. This enhancement aims to
+add more types of incoming connections that may be specified. A similar effort exists for the [egress](https://github.com/kubernetes-sigs/network-policy-api/issues/126)
+direction.
+
+By default, cluster workloads are not accessible from outside the cluster, but there are many ways to expose these workloads
+(either with k8s APIs like [Ingress API](https://kubernetes.io/docs/concepts/services-networking/ingress/) or
+[Gateway API](https://gateway-api.sigs.k8s.io/), or with downstream implementations,
+like [openshift Route](https://docs.openshift.com/container-platform/4.13/rest_api/network_apis/route-route-openshift-io-v1.html)).
+Some of the APIs may provide functionality to filter incoming connections, but Network Policy API is different, because
+it is applied to the cluster workloads, and should provide the required level of security regardless of how/if a cluster workload
+is exposed to the outer world.
+
+### Use cases
+ - zero trust policy: As a cluster administrator I want to set up default deny all ingress policy as a BANP.
+
+    Example: when implementing a zero trust policy I want to make sure no ingress connection (unless explicitly allowed) will
+get to the cluster workloads. This should apply not only to the connections coming from the other cluster workloads, but to
+all incoming connections.
+
+ - block well-known ports: As a cluster administrator I want to block all ingress traffic on specific ports.
+
+   Example: when defining a cluster security policy, we decided that some well-known services like ftp, telnet, SNMP, etc.
+should not be allowed for cluster workloads. To implement this policy I want to explicitly deny all ingress connections
+for TCP ports 21, 23, 161, etc.
+
+ - compromised node protection: As a cluster administrator I want to make sure a compromised node can't send traffic to the 
+cluster workloads scheduled on the other nodes.
+
+    Example: my cluster has a set of nodes with very sensitive workloads, I want to make sure that if a worker node A is
+compromised, it will not be able to affect other worker nodes. To do so, I want to create a cluster-wide policy to
+deny ingress connections from some of the cluster nodes. I may also need to explicitly allow access from the control plane nodes.
+
+ - inter-cluster communication: As a cluster manager for multiple clusters I want to make sure ingress connections
+are only allowed from a pre-defined set of related clusters, which are identified by their network CIDR.
+
+    Example: I have a cluster (management cluster) that creates other clusters on request (hosted clusters).
+Management cluster assigns a subnet for hosted cluster workloads. I want to make sure that hosted cluster workloads
+have limited access to the management cluster workloads by selecting management cluster workloads I want to protect
+and a set of allowed subnets for the corresponding hosted clusters.
+
+- external services: As a cluster manager I want to make sure ingress connections from a pre-defined set of external endpoints
+can't be denied by the namespace owners.
+
+    Example: I have an external service to collect telemetry and metrics from multiple clusters, and I want to make sure
+namespaced Network Policies won't drop incoming connections from this service.
+
+## API
+
+(... details, can point to PR with changes)
+
+## Conformance Details
+
+(This section describes the names to be used for the feature or
+features in conformance tests and profiles.
+
+These should be `CamelCase` names that specify the feature as
+precisely as possible, and are particularly important for
+Extended features, since they may be surfaced to users.)
+
+## Alternatives
+
+(List other design alternatives and why we did not go in that
+direction)
+
+## References
+
+(Add any additional document links. Again, we should try to avoid
+too much content not in version control to avoid broken links)