A YANG Network Data Model for Service Attachment Points (SAPs)
Extracted elements (21)
A single SAP network topology can be shared across multiple service types (L3VPN, EVPN, network slice, SD-WAN, etc.) rather than requiring per-service topologies. Whether a SAP topology is dedicated to a specific service type or shared is deployment-specific; the model supports all schemes.
Comparing both 'admin-status' and 'oper-status' within 'service-status', alongside 'sap-status', enables anomaly detection: a service that is administratively up but whose SAP is down should have oper-status down; a mismatch is a trigger to investigate inconsistency between intended and observed state.
Reusing service-type identities from RFC 9181 is intentional to ease correlation between the SAP topology and the network models (L3NM RFC 9182, L2NM RFC 9291) used to provision services, enabling consistent referencing across customer-facing and resource-facing interfaces in the service orchestration stack.
SAPs differ from Termination Points (TPs) defined in RFC 8345: a link is terminated by a single TP, but an AC can be terminated by multiple SAPs. SAPs are also distinct from tunnel termination points (TTPs) and links. This distinction justifies augmenting the ietf-network model rather than reusing existing TP constructs.
The 'attachment-interface' string may reference identifiers defined in RFC 9182 Section 7.6 (l2-termination-point, bearer-reference, lag-interface-id, l3-termination-point) or RFC 9291 Section 7.6. The controller is responsible for ensuring consistent cross-model references between the SAP model and device models.
The 'ietf-sap-ntw' module augments 'ietf-network' (RFC 8345) and imports from 'ietf-network-topology' (RFC 8345), 'ietf-vpn-common' (RFC 9181), and 'ietf-yang-types' (RFC 6991). The node-level augmentation is guarded by a 'when' condition on the presence of the 'sap-network' network-type container.
The administrative 'service-status' MUST NOT be influenced by the value of the operational 'sap-status'. These two status containers are independent: sap-status reflects the SAP's physical/operational state, while service-status reflects the state of a specific provisioned service at that SAP.
Five new service-type identities extend 'vpn-common:service-type' from RFC 9181: 'virtual-network' (ACTN logical network per RFC 8453), 'enhanced-vpn' (VPN+), 'network-slice' (IETF network slice), 'sdwan' (PE-based SD-WAN), and 'basic-connectivity' (plain IP connectivity over MPLS infrastructure).
Service Attachment Points (SAPs) are abstractions of network reference points — typically the PE side of an Attachment Circuit, or the CE side for a provider-managed CE — where network services can be delivered to customers. A SAP can be bound to one or multiple ACs, and the same SAP may appear under multiple service types using the same identifier.
The 'allows-child-saps' boolean leaf indicates the attachment interface can host per-service sub-interfaces. When true, a service orchestrator knows it can instantiate sub-interfaces (child SAPs) rather than attaching directly to the parent SAP; whether a service can also attach directly to the parent SAP is service-dependent.
The 'ietf-sap-ntw' module augments '/nw:networks/nw:network/nw:network-types' with a presence container 'sap-network' (holding a 'service-type' leaf-list) and augments '/nw:networks/nw:network/nw:node' (conditioned on the sap-network presence) with a 'service' list keyed by 'service-type', each entry containing a 'sap' list keyed by 'sap-id'.
The 'interface-type' identity hierarchy defines six derived types: 'phy' (physical port), 'loopback', 'lag' (Link Aggregation Group per IEEE 802.1AX), 'irb' (Integrated Routing and Bridging, connecting IP-VRF to bridge domain), 'local-bridge' (internal bridging reference), and 'logical' (sub-interface, used only when no more specific type applies).
The 'peer-sap-id' leaf-list references remote endpoints of an Attachment Circuit — examples include CE identifiers, site identifiers (RFC 8299 Section 6.3), SDP identifiers, or peer ASBR IP addresses. Using identical identifiers on both peers eases correlation between a peer's service request and a local SAP.
The 'role' leaf uses an identityref based on 'interface-role'; two derived identities are defined: 'uni' (User-to-Network Interface) and 'nni' (Network-to-Network Interface). A SAP inherits the role of its parent interface ('parent-termination-point').
The 'sap-entry' grouping defines core SAP fields: 'sap-id' (string, node-scoped unique key), 'description' (string), 'parent-termination-point' (nt:tp-id), 'attachment-interface' (string), 'interface-type' (identityref), 'encapsulation-type' (identityref from RFC 9181), 'role' (UNI/NNI identityref), 'allows-child-saps' (boolean), and 'peer-sap-id' (leaf-list of strings).
The 'sap-status' container (config false) reports the SAP's operational state independent of any service, using the 'oper-status-timestamp' grouping from RFC 9181. The 'service-status' container holds a writable 'admin-status' sub-container and a read-only 'oper-status' sub-container, each carrying a status identityref and 'last-change' (yang:date-and-time) leaf.
This document registers the XML namespace URI 'urn:ietf:params:xml:ns:yang:ietf-sap-ntw' in the 'ns' subregistry of the IETF XML Registry (RFC 3688), with registrant contact IESG.
This document registers the YANG module 'ietf-sap-ntw' (prefix: sap; namespace: urn:ietf:params:xml:ns:yang:ietf-sap-ntw; maintained by IANA: No) in the 'YANG Module Names' subregistry within the 'YANG Parameters' registry (RFC 6020).
The readable subtree '/nw:networks/nw:network/nw:node/sap:service/sap:sap' is sensitive: unauthorized read access can disclose operational state and topology information, including 'peer-sap-id' values that may reveal customer identity or inter-AS interconnection topology.
The writable subtree '/nw:networks/nw:network/nw:node/sap:service/sap:sap' is sensitive: unauthorized write operations — for example, reassociating a SAP with a different parent termination point — can cause service disruption and network misbehavior by creating configurations inconsistent with operator intent.
The YANG module is accessed via NETCONF (mandatory-to-implement secure transport: SSH per RFC 6242) or RESTCONF (mandatory-to-implement secure transport: TLS 1.3 per RFC 8446). The Network Configuration Access Control Model (NACM, RFC 8341) provides per-user access control for operations and content.