A YANG Data Model for MPLS Static LSPs

Introduction This document describes a YANG data model for configuring and managing the Multiprotocol Label Switching (MPLS) Static LSPs. The model allows the configuration of LER and LSR devices with the necessary MPLS cross-connects or bindings to realize an end-to-end LSP service. A static LSP is established by manually specifying incoming and outgoing MPLS label(s) and necessary forwarding information on each of the traversed LER and LSR devices (ingress, transit, or egress nodes) of the forwarding path. For example, on an ingress LER device, the model is used to associate a specific Forwarding Equivalence Class (FEC) of packets-- e.g. matching a specific IP prefix in a Virtual Routing or Forwarding (VRF) instance-- to an MPLS outgoing label imposition, next-hop(s) and respective outgoing interface(s) to forward the packet. On an LSR device, the model is used to create a binding that swaps the incoming label with an outgoing label and forwards the packet on one or multiple egress path(s). On an egress LER, it is used to create a binding that decapsulates the incoming MPLS label and performs forwarding based on the inner MPLS label (if present) or IP forwarding in the packet. The MPLS Static LSP YANG model is contained in the module "ietf-mpls-static" and covers the basic features for the configuration and management of unidirectional MPLS Static LSP(s), The module "ietf-mpls-static" augments the MPLS Base YANG model defined in module "ietf-mpls" in .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The terminology for describing YANG data models is found in .

Acronyms and Abbreviations

MPLS: Multiprotocol Label Switching

LSP: Label Switched Path

LSR: Label Switching Router

LER: Label Edge Router

FEC: Forwarding Equivalence Class

NHLFE: Next Hop Label Forwarding Entry

ILM: Incoming Label Map

MPLS Static LSP Model

Model Organization The base MPLS Static LSP model covers the core features with the minimal set of configuration parameters needed to manage and operate MPLS Static LSPs.

Model Tree Diagram The MPLS Static tree diagram as per is shown in .

Model Overview This document describes a YANG data model for the configuration and management of MPLS Static LSP(s) contained in a the YANG module 'ietf-mpls-static'. The 'ietf-mpls-static' module contains the following high-level types and groupings: static-lsp-ref:

A YANG reference type for a static LSP that can be used by data models to reference a configured static LSP.

in-segment:

A YANG grouping that describes parameters of an incoming class of FEC associated with a specific LSP as described in the MPLS architecture document . The model allows the following types of traffic to be mapped onto the static LSP on an ingress LER:

out-segment:

A YANG grouping that describes parameters for the forwarding path(s) and their associated attributes for an LSP. The model allows for the following cases:

Model YANG Module(s) Configuring LSPs through an LSR/LER involves the following steps: Enabling MPLS on MPLS capable interfaces. Configuring in-segments and out-segments on LER(s) and LSR(s) traversed by the LSP. Setting up the cross-connect per LSP to associate segments and/or to indicate connection origination and termination. Optionally specifying label stack actions. Optionally specifying segment traffic parameters. The objects covered by this model are derived from the Incoming Label Map (ILM) and Next Hop Label Forwarding Entry (NHLFE) as specified in the MPLS architecture document . The ietf-mpls-static module imports the followinig modules: ietf-inet-types defined in ietf-routing defined in ietf-routing-types defined in ietf-interfaces defined in ietf-mpls defined in The ietf-mpls-static module is shown below:

file "ietf-mpls-static@2024-03-01.yang" module ietf-mpls-static { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-static"; prefix "mpls-static"; import ietf-mpls { prefix "mpls"; reference "RFC8960: MPLS Base YANG Data Model"; } import ietf-routing { prefix "rt"; reference "RFC8349: A YANG Data Model for Routing Management"; } import ietf-routing-types { prefix "rt-types"; reference "RFC8294: Common YANG Data Types for the Routing Area"; } import ietf-inet-types { prefix inet; reference "RFC6991: Common YANG Data Types"; } import ietf-interfaces { prefix "if"; reference "RFC7223: A YANG Data Model for Interface Management"; } organization "IETF MPLS Working Group"; contact "WG Web: WG List: Editor: Tarek Saad Editor: Rakesh Gandhi Editor: Xufeng Liu Editor: Vishnu Pavan Beeram Editor: Igor Bryskin "; description "This YANG module augments the 'ietf-routing' module with basic configuration and operational state data for MPLS static The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision "2024-03-01" { description "Latest revision of MPLS Static LSP YANG module"; reference "RFC XXXX: A YANG Data Model for MPLS Static LSPs"; } typedef static-lsp-ref { type leafref { path "/rt:routing/mpls:mpls/mpls-static:static-lsps/" + "mpls-static:static-lsp/mpls-static:name"; } description "This type is used by data models that need to reference configured static LSP."; } grouping in-segment { description "In-segment grouping"; container in-segment { description "MPLS incoming segment"; container fec { description "Forwarding Equivalence Class grouping"; choice type { description "FEC type choices"; case ip-prefix { leaf ip-prefix { type inet:ip-prefix; description "An IP prefix"; } } case mpls-label { leaf incoming-label { type rt-types:mpls-label; description "label value on the incoming packet"; } } } leaf incoming-interface { type if:interface-ref; description "Optional incoming interface if FEC is restricted to traffic incoming on a specific interface"; } } } } grouping out-segment { description "Out-segment grouping"; container out-segment { description "MPLS outgoing segment"; choice out-segment { description "The MPLS out-segment type choice"; case nhlfe-single { container nhlfe-single { description "Container for single NHLFE entry"; uses mpls:nhlfe-single-contents; leaf outgoing-interface { type if:interface-ref; description "The outgoing interface"; } } } case nhlfe-multiple { container nhlfe-multiple { description "Container for multiple NHLFE entries"; list nhlfe { key index; description "MPLS NHLFE entry"; uses mpls:nhlfe-multiple-contents; leaf outgoing-interface { type if:interface-ref; description "The outgoing interface"; } } } } } } } augment "/rt:routing/mpls:mpls" { description "Augmentations for MPLS Static LSPs"; container static-lsps { description "Statically configured LSPs, without dynamic signaling"; list static-lsp { key name; description "list of defined static LSPs"; leaf name { type string; description "name to identify the LSP"; } leaf operation { type mpls:mpls-operations-type; description "The MPLS operation to be executed on the incoming packet"; } uses in-segment; uses out-segment; } } } }

]]>


IANA Considerations

This document registers the following URIs in the IETF XML registry
.
Following the format in , the following registration is
requested to be made.



This document registers two YANG modules in the YANG Module Names
registry .




Security Considerations

The YANG modules specified in this document define schemas for data
that is designed to be accessed via network management protocols such
as NETCONF  or RESTCONF .  The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) .  The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
{!RFC8446}}.

The NETCONF access control model  provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.

All nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default) may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) to these
data nodes without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their
sensitivity/vulnerability:

o /ietf-routing:routing/ietf-mpls:mpls:/ietf-mpls:static-lsps: This entire
subtree is related to security.

An administrator needs to restrict write access to all configurable
objects within this data model.


Contributors