rfc9702xml2.original.xml   rfc9702.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3688 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml'>
<!ENTITY RFC6020 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml'>
<!ENTITY RFC6241 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml'>
<!ENTITY RFC6242 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.xml'>
<!ENTITY RFC7950 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7950.xml'>
<!ENTITY RFC8040 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8040.xml'>
<!ENTITY RFC8340 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8340.xml'>
<!ENTITY RFC8341 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8341.xml'>
<!ENTITY RFC8342 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8342.xml'>
<!ENTITY RFC8349 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8349.xml'>
<!ENTITY RFC8446 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml'>
<!ENTITY RFC8476 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8476.xml'>
<!ENTITY RFC8491 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8491.xml'>
<!ENTITY RFC8662 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8662.xml'>
<!ENTITY RFC8960 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8960.xml'>
<!ENTITY RFC9088 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.9088.xml'>
<!ENTITY RFC9110 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.9110.xml'>
<!ENTITY RFC9352 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.9352.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-mpls-msd-yang-12" ipr="trust200902"> <!DOCTYPE rfc [
<!-- category values: std, bcp, info, exp, and historic <!ENTITY nbsp "&#160;">
ipr values: full3667, noModification3667, noDerivatives3667 <!ENTITY zwsp "&#8203;">
you can add the attributes updates="NNNN" and obsoletes="NNNN" <!ENTITY nbhy "&#8209;">
they will automatically be output with "(if approved)" --> <!ENTITY wj "&#8288;">
]>
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-mpls-msd-yang-12" number="9702" consensus="true" ipr="trust200902" obsoletes= "" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="tru e" sortRefs="true" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="MPLS MSD YANG">YANG Data Model for Maximum Segment Identifier
if the (SID) Depth (MSD) Types and MPLS MSD</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9702"/>
<title abbrev="MPLS MSD YANG">YANG Data Model for Maximum SID Depth Types and
MPLS Maximum SID Depth </title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Yingzhen Qu" initials="Y" surname="Qu"> <author fullname="Yingzhen Qu" initials="Y" surname="Qu">
<organization>Futurewei Technologies</organization> <organization>Futurewei Technologies</organization>
<address> <address>
<email>yingzhen.ietf@gmail.com</email> <email>yingzhen.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Acee Lindem" initials="A." surname="Lindem"> <author fullname="Acee Lindem" initials="A." surname="Lindem">
<organization>LabN Consulting, L.L.C.</organization> <organization>LabN Consulting, L.L.C.</organization>
<address> <address>
<email>acee.ietf@gmail.com</email> <email>acee.ietf@gmail.com</email>
skipping to change at line 91 skipping to change at line 39
<address> <address>
<email>slitkows.ietf@gmail.com</email> <email>slitkows.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jeff Tantsura" initials="J" surname="Tantsura"> <author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
<organization>Nvidia</organization> <organization>Nvidia</organization>
<address> <address>
<email>jefftant.ietf@gmail.com</email> <email>jefftant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date month="December" year="2024"/>
<date/> <area>RTG</area>
<workgroup>mpls</workgroup>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current one, it
is
necessary to specify at least a month (xml2rfc assumes day="1" if not specifi
ed for the
purpose of calculating the expiry date). With drafts it is normally sufficie
nt to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>MPLS Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<!-- Keywords will be incorporated into HTML output <keyword>example</keyword>
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>This document defines two YANG data modules. The first <t> This document defines two YANG modules. The first module is the
is the initial version of the IANA-maintained YANG module for Maximum Se initial version of the IANA-maintained YANG module for Maximum
gment Identifier (SID) Segment Identifier (SID) Depth (MSD) Types, which includes identities
Depths (MSDs) Types, which includes identities for both the MPLS and SRv for both the MPLS data plane and Segment Routing over IPv6 (SRv6)
6 data planes. The second data plane. The second module augments the IETF MPLS YANG data model to prov
augments the IETF MPLS YANG model to ide
provide support for MPLS MSDs as defined in RFC 8476 and RFC 8491. </t> support for MPLS MSDs as defined in RFCs 8476 and 8491.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Overview"> <section numbered="true" toc="default">
<t>There are two YANG modules defined in this document. Module <name>Overview</name>
iana-msd-types defines the identities for Maximum Segment Identifier (SI <t>There are two YANG modules <xref target="RFC7950"/> defined in this
D) Depth (MSD) document. Module iana-msd-types defines the identities for Maximum SID
Types as per the IANA IGP MSD-Types registry <xref target="IANA-IGP-MSD- Depth (MSD) Types as per the "IGP MSD-Types" IANA registry <xref
Types"/>, target="IANA-IGP-MSD-Types" format="default"/>, which includes MSD types
which include MSD types for both the MPLS data plane and the SRv6 data p for both the MPLS and SRv6 data planes. This document also defines
lane. This document also module ietf-mpls-msd augmenting the IETF MPLS YANG data model <xref
defines module ietf-mpls-msd augmenting the IETF MPLS target="RFC8960" format="default"/>, which augments the routing RIB data
YANG model <xref target="RFC8960"/>, which itself augments the routing RIB model <xref target="RFC8349" format="default"/> to provide operational
data model state for various MSDs <xref target="RFC8662" format="default"/> for the
<xref target="RFC8349"/>, to provide operational state for MPLS data plane. The module augments the base MPLS model with a list of
various MSDs<xref target="RFC8662"/> for the MPLS data plane. The module a various types of Node MSDs as well as various types of Link MSDs.
ugments the base MPLS
model with a list of various types of node MSDs, as well as various types
of MSDs on links.
</t> </t>
<t> <t>
The YANG modules in this document conform to the Network Management The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA) <xref target="RFC8342"/>. Datastore Architecture (NMDA) <xref target="RFC8342" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Design of the Model"> <name>Design of the Model</name>
<section title="IANA MSD Types Module"> <section numbered="true" toc="default">
<t> <name>IANA MSD Types Module</name>
IANA has created an IANA-managed registry titled "IGP MSD-Types" <t>
under the "Interior Gateway Protocol (IGP) Parameters" registry to IANA has created a registry titled "IGP MSD-Types" under the "Interior
identify MSD-Types. Module iana-msd-types is an IANA-maintained Gateway Protocol (IGP) Parameters" registry group to identify
module, which defines the identities for the MSD-Types as in the MSD-Types. Module iana-msd-types is an IANA-maintained module, which
IANA IGP MSD-Types registry. defines the identities for the MSD-Types as in the IANA "IGP
</t> MSD-Types" registry. This module references <xref target="RFC8476"/>,
<t> <xref target="RFC8491"/>, <xref target="RFC8662"/>, <xref
target="RFC8664"/>, <xref target="RFC8814"/>, <xref
target="RFC9088"/>, and <xref target="RFC9352"/>.
</t>
<t>
On top of the base identity "msd-base", identity "msd-base-mpls" On top of the base identity "msd-base", identity "msd-base-mpls"
is defined to serve as the base for MSD types for MPLS data is defined to serve as the base for MSD types for the MPLS data
plane, and identity "msd-base-srh" is defined to serve as the plane, and identity "msd-base-srh" is defined to serve as the
base for MSD types for Segment Routing Header (SRH) in IPv6 base for MSD types for the Segment Routing Header (SRH) in the IPv6
data plane. data plane.
</t> </t>
<t> <t>
This module will be maintained by IANA and updated if and when This module is maintained by IANA and will be updated if and when
there is any change to the registry. there is any change to the registry.
</t> </t>
</section> </section>
<section title="IETF MPLS MSD Module"> <section numbered="true" toc="default">
<t> <name>IETF MPLS MSD Module</name>
Module ietf-mpls-msd augments the base MPLS model <xref target="RFC8960" <t>
/>, Module ietf-mpls-msd augments the base MPLS model <xref target="RFC8960"
and it provides support of different types of MSDs in format="default"/>,
and it provides support of different types of MSDs in the
MPLS data plane. MPLS data plane.
</t> </t>
<t> <t>
As defined in <xref target="RFC8491"/>, a Link MSD is As defined in <xref target="RFC8491" format="default"/>, a Link MSD is
the number of SIDs supported by a node's link, while a Node MSD is the number of SIDs supported by a node's link, while a Node MSD is the
the smallest MSD supported by the node across all its interfaces. smallest MSD supported by the node across all its links. The module
The module defines lists defines lists of MSDs and their MSD Types for a node and its links.
of MSDs with different MSD Types for a node and links. Please Please note that these are read-only data nodes exposing a node's
note that these are read-only data as per the node's hardware hardware capability.
capability. </t>
</t> </section>
</section> </section>
</section> <section numbered="true" toc="default">
<section title="Tree for IETF MPLS MSD Types YANG Module"> <name>Tree for IETF MPLS MSD Types YANG Module</name>
<t> <t>
This document uses the graphical representation of data models This document uses the graphical representation of data models
per <xref target="RFC8340"/>. per <xref target="RFC8340" format="default"/>.
</t> </t>
<figure align="left">
<artwork align="left"> <sourcecode name="" type="yangtree">
module: ietf-mpls-msd module: ietf-mpls-msd
augment /rt:routing/mpls:mpls: augment /rt:routing/mpls:mpls:
+--ro node-msds +--ro node-msds
+--ro node-msd* [msd-type] +--ro node-msd* [msd-type]
+--ro msd-type identityref +--ro msd-type identityref
+--ro msd-value? uint8 +--ro msd-value? uint8
augment /rt:routing/mpls:mpls/mpls:interfaces/mpls:interface: augment /rt:routing/mpls:mpls/mpls:interfaces/mpls:interface:
+--ro link-msds +--ro link-msds
+--ro link-msd* [msd-type] +--ro link-msd* [msd-type]
+--ro msd-type identityref +--ro msd-type identityref
+--ro msd-value? uint8 +--ro msd-value? uint8
</sourcecode>
</artwork> </section>
</figure> <section numbered="true" toc="default">
</section> <name>YANG Modules</name>
<section title="YANG Modules"> <t>There are two YANG modules defined in this document.</t>
<t>There are two YANG modules defined in this document.</t> <section anchor="iana-msd-types" numbered="true" toc="default">
<name>IANA-Maintained Module for MSD-Types</name>
<t>This document defines the initial version of the IANA-maintained YANG
module for MSD Types that mirrors the IANA "IGP MSD-Types"
registry <xref target="IANA-IGP-MSD-Types" format="default"/>.
</t>
<section anchor="iana-msd-types" title="IANA-Maintained Module for MSD-Types <!--[rfced] We note that two RFCs in the reference clauses in the
"> iana-msd-types module do not appear in the reference section of the RFC.
May a sentence be added before the YANG module stating that it refers to
the following RFCs? For example:
<t>This document defines the initial version of the IANA-maintained YANG This module references [RFC8476], [RFC8491], [RFC8662], [RFC8664],
module for MSD Types, which mirrors the IANA IGP MSD-Types [RFC8814], [RFC9088], and [RFC9352].
registry <xref target="IANA-IGP-MSD-Types"/>.
</t> (where [RFC8664] and [RFC8814] would be added as Informative References)
<t>
<figure> Alternatively, you could let us know a different place to cite [RFC8664]
<artwork><![CDATA[ and [RFC8814] in this document.
<CODE BEGINS> file "iana-msd-types@2024-07-04.yang" -->
<sourcecode name="iana-msd-types@2024-07-04.yang" type="yang" markers="t
rue"><![CDATA[
module iana-msd-types { module iana-msd-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-msd-types"; namespace "urn:ietf:params:xml:ns:yang:iana-msd-types";
prefix iana-msd-types; prefix iana-msd-types;
organization organization
"Internet Assigned Numbers Authority (IANA)"; "Internet Assigned Numbers Authority (IANA)";
contact contact
"Internet Assigned Numbers Authority "Internet Assigned Numbers Authority
skipping to change at line 257 skipping to change at line 202
Copyright (c) 2024 IETF Trust and the persons identified as Copyright (c) 2024 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This initial version of this YANG module is part of RFC XXXX This initial version of this YANG module is part of RFC 9702
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfc9702); see the RFC itself
for full legal notices. for full legal notices.
//RFC Ed.: replace XXXX with actual RFC number and remove
this note
//RFC Ed.: replace IANA_FOO_URL and remove this note.
The latest version of this YANG module is available at The latest version of this YANG module is available at
<IANA_FOO_URL>."; https://www.iana.org/assignments/yang-parameters.";
revision 2024-07-04 { revision 2024-07-04 {
description description
"Initial Version"; "Initial Version";
reference reference
"RFC XXXX: YANG Data Model for Maximum SID Depth Types and "RFC 9702: YANG Data Model for Maximum Segment Identifier (SID)
MPLS Maximum SID Depth"; Depth Types and MPLS Maximum SID Depth";
} }
identity msd-base { identity msd-base {
description description
"Base identity for Maximum SID Depth (MSD) Type. The MSD type "Base identity for Maximum SID Depth (MSD) Type. The MSD type
definition is defined in IANA IGP MSD-Types registry."; definition is defined in the IANA 'IGP MSD-Types' registry.";
} }
identity msd-base-mpls { identity msd-base-mpls {
base msd-base; base msd-base;
description description
"Base identity of MSD types for MPLS data plane."; "Base identity of MSD types for the MPLS data plane.";
} }
identity base-mpls-imposition-msd { identity base-mpls-imposition-msd {
base msd-base-mpls; base msd-base-mpls;
description description
"Base MPLS Imposition MSD."; "Base MPLS Imposition MSD.";
reference reference
"RFC 8491: Signaling Maximum SID Depth (MSD) using IS-IS "RFC 8491: Signaling Maximum SID Depth (MSD) Using IS-IS
RFC 8476: Signaling Maximum SID Depth (MSD) using OSPF RFC 8476: Signaling Maximum SID Depth (MSD) Using OSPF
RFC 8664: Path Computation Element Communication Protocol RFC 8664: Path Computation Element Communication Protocol
(PCEP) Extensions for Segment Routing (PCEP) Extensions for Segment Routing
RFC 8814: Signaling Maximum SID Depth (MSD) Using the Border RFC 8814: Signaling Maximum SID Depth (MSD) Using the Border
Gateway Protocol - Link State"; Gateway Protocol - Link State";
} }
identity erld-msd { identity erld-msd {
base msd-base-mpls; base msd-base-mpls;
description description
"msd-erld is defined to advertise the Entropy Readable "msd-erld is defined to advertise the Entropy Readable
skipping to change at line 323 skipping to change at line 263
identity msd-base-srh { identity msd-base-srh {
base msd-base; base msd-base;
description description
"Base identity of MSD types for Segment Routing Header (SRH)."; "Base identity of MSD types for Segment Routing Header (SRH).";
} }
identity srh-max-sl { identity srh-max-sl {
base msd-base-srh; base msd-base-srh;
description description
"The Maximum Segment Left MSD type."; "The Maximum Segments Left MSD type.";
reference reference
"RFC 9352: IS-IS Extensions to Support Segment Routing "RFC 9352: IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane"; over the IPv6 Data Plane";
} }
identity srh-max-end-pop { identity srh-max-end-pop {
base msd-base-srh; base msd-base-srh;
description description
"The Maximum End Pop MSD Type."; "The Maximum End Pop MSD Type.";
reference reference
skipping to change at line 356 skipping to change at line 296
identity srh-max-end-d { identity srh-max-end-d {
base msd-base-srh; base msd-base-srh;
description description
"The Maximum End D MSD Type."; "The Maximum End D MSD Type.";
reference reference
"RFC 9352: IS-IS Extensions to Support Segment Routing "RFC 9352: IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane"; over the IPv6 Data Plane";
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork> </section>
</figure></t> <section numbered="true" toc="default">
</section> <name>MPLS MSD YANG</name>
<t>This document also defines a YANG module for MSD extensions
<section title="MPLS MSD YANG"> <xref target="RFC8476" format="default"/> <xref target="RFC8491" format="d
<t>This document also defines a YANG module for MSD extensions efault"/> to the MPLS base
<xref target="RFC8476"/><xref target="RFC8491"/> to MPLS base model as defined in <xref target="RFC8960" format="default"/>.
model as defined in <xref target="RFC8960"/>. </t>
</t> <sourcecode name="ietf-mpls-msd@2024-07-05.yang" type="yang" markers="tr
<t> ue"><![CDATA[
<figure>
<artwork><![CDATA[
<CODE BEGINS> file "ietf-mpls-msd@2024-07-05.yang"
module ietf-mpls-msd { module ietf-mpls-msd {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-msd"; namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-msd";
prefix mpls-msd; prefix mpls-msd;
import ietf-routing { import ietf-routing {
prefix rt; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing "RFC 8349: A YANG Data Model for Routing
Management (NMDA Version)"; Management (NMDA Version)";
skipping to change at line 407 skipping to change at line 342
<mailto:yingzhen.ietf@gmail.com> <mailto:yingzhen.ietf@gmail.com>
Author: Acee Lindem Author: Acee Lindem
<mailto:acee.ietf@gmail.com> <mailto:acee.ietf@gmail.com>
Author: Stephane Litkowski Author: Stephane Litkowski
<mailto:slitkows.ietf@gmail.com> <mailto:slitkows.ietf@gmail.com>
Author: Jeff Tantsura Author: Jeff Tantsura
<mailto:jefftant.ietf@gmail.com> <mailto:jefftant.ietf@gmail.com>
"; ";
description description
"The YANG module augments the base MPLS model, and it is to "This YANG module augments the base MPLS model, and it is to
provide support for different types of Maximum SID Depth (MSD). provide support for different types of Maximum SID Depth (MSD).
This YANG model conforms to the Network Management This YANG module conforms to the Network Management
Datastore Architecture (NMDA) as described in RFC 8342. Datastore Architecture (NMDA) as described in RFC 8342.
Copyright (c) 2024 IETF Trust and the persons identified as Copyright (c) 2024 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; This version of this YANG module is part of RFC 9702;
see the RFC itself for full legal notices."; see the RFC itself for full legal notices.";
revision 2024-07-05 { revision 2024-07-05 {
description description
"Initial Version"; "Initial Version";
reference reference
"RFC XXXX: YANG Data Model for Maximum SID Depth Types and "RFC 9702: YANG Data Model for Maximum Segment Identifier (SID)
MPLS Maximum SID Depth"; Depth Types and MPLS Maximum SID Depth";
} }
grouping msd-type-value { grouping msd-type-value {
description description
"Grouping for MSD type and value."; "Grouping for MSD type and value.";
leaf msd-type { leaf msd-type {
type identityref { type identityref {
base iana-msd-types:msd-base-mpls; base iana-msd-types:msd-base-mpls;
} }
description description
"MSD types. The MSD type is defined in IANA IGP "MSD types. The MSD type is defined in IANA 'IGP
MSD-Types registry."; MSD-Types' registry.";
} }
leaf msd-value { leaf msd-value {
type uint8; type uint8;
description description
"MSD value, in the range of 0-255. 0 represents the lack "MSD value, in the range of 0-255. 0 represents the lack
of ability to support a SID stack of any depth."; of ability to support a SID stack of any depth.";
} }
} }
augment "/rt:routing/mpls:mpls" { augment "/rt:routing/mpls:mpls" {
description description
"This module augments MPLS data model (RFC 8960) "This module augments MPLS data model (RFC 8960)
with node MSD."; with Node MSD.";
container node-msds { container node-msds {
config false; config false;
description description
"Maximum SID Depth (MSD) of a node."; "Maximum SID Depth (MSD) of a node.";
list node-msd { list node-msd {
key "msd-type"; key "msd-type";
uses msd-type-value; uses msd-type-value;
description description
"List of different types of node MSDs. For the same "List of different types of Node MSDs. For the same
type, the value of node MSD is the smallest among link MSD type, the value of Node MSD is the smallest among Link MSD
values."; values.";
} }
} }
} }
augment "/rt:routing/mpls:mpls/mpls:interfaces/mpls:interface" { augment "/rt:routing/mpls:mpls/mpls:interfaces/mpls:interface" {
description description
"This module augments MPLS data model (RFC 8960) "This module augments MPLS data model (RFC 8960)
with link MSD."; with Link MSD.";
container link-msds { container link-msds {
config false; config false;
description description
"Maximum SID Depth (MSD) of an interface."; "Maximum SID Depth (MSD) of an interface.";
list link-msd { list link-msd {
key "msd-type"; key "msd-type";
uses msd-type-value; uses msd-type-value;
description description
"List of different types of MSDs on the link."; "List of different types of MSDs on the link.";
} }
} }
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork> </section>
</figure> </section>
</t> <section anchor="Security" numbered="true" toc="default">
</section> <name>Security Considerations</name>
</section> <t>
<!-- DNE begins-->
<section anchor="Security" title="Security Considerations">
<t>
The YANG modules specified in this document define a schema for data The YANG modules specified in this document define a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such as
as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. NETCONF <xref target="RFC6241" format="default"/> or RESTCONF <xref
These network management protocols are required to use a secure target="RFC8040" format="default"/>.
transport layer and mutual authentication, e.g., SSH <xref target="RFC6242 The lowest NETCONF layer
"/> is the secure transport layer, and the mandatory-to-implement secure
without the "none" authentication option, Transport Layer Security (TLS) transport is Secure Shell (SSH) <xref target="RFC6242" format="default"/>. The
<xref target="RFC8446"/> with mutual X.509 authentication, and HTTPS lowest RESTCONF layer
with HTTP authentication (Section 11 of <xref target="RFC9110"/>).</t> is HTTPS, and the mandatory-to-implement secure transport is TLS
<xref target="RFC8446" format="default"/>.</t>
<t>The NETCONF Access Control Model (NACM) <xref target="RFC8341"/> provides <t>The Network Configuration Access Control Model (NACM) <xref target="RFC
the 8341" format="default"/> provides the
means to restrict access for particular NETCONF or RESTCONF users to a means to restrict access for particular NETCONF or RESTCONF users to a
pre-configured subset of all available NETCONF or RESTCONF protocol pre-configured subset of all available NETCONF or RESTCONF protocol
operations and content.</t> operations and content.</t>
<!-- DNE ends -->
<t>Some of the readable data nodes in the ietf-mpls-msd YANG module <t>Some of the readable data nodes in the ietf-mpls-msd YANG module
may be considered sensitive or vulnerable in some network environments. It may be considered sensitive or vulnerable in some network environments. It
is thus is
important to control read access (e.g., via get, get-config, or notificati thus important to control read access (e.g., via get, get-config, or notif
on) ication)
to these data nodes. These are the to these data nodes. These are the
subtrees and data nodes and their sensitivity/vulnerability: subtrees and data nodes and their sensitivity/vulnerability:
<list style="empty"> </t>
<t>/rt:routing/mpls:mpls/msd/node-msds</t> <t indent="3">/rt:routing/mpls:mpls/msd/node-msds</t>
<t>/rt:routing/mpls:mpls/msd/link-msds</t> <t indent="3">/rt:routing/mpls:mpls/msd/link-msds</t>
<t>Exposure of the node's maximum SID depth may be useful in mounting a <t indent="3">Exposure of the node's maximum SID depth may be useful i
n mounting a
Denial-of-Service (DoS) attack by sending packets to the node that Denial-of-Service (DoS) attack by sending packets to the node that
the router can't process.</t> the router can't process.</t>
</list></t> <t>
<t> The iana-msd-types YANG module defines a set of identities that mirror
The iana-msd-types YANG module defines a set of identities, which mirrors the IANA "IGP MSD-Types" registry. These identities are intended to be reu
the IANA IGP MSD-Types registry. These identities are intended to be reuse sed
d
by other YANG modules. The module by itself does not expose any data nodes by other YANG modules. The module by itself does not expose any data nodes
that are writable or readable. As such, there are no additional security that are writable or readable. As such, there are no additional security
issues related to this YANG module that need to be considered. issues related to this YANG module that need to be considered.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<section title="Registering YANG Modules"> <section numbered="true" toc="default">
<t>This document registers URIs in the IETF XML registry <name>Registering YANG Modules</name>
<xref target="RFC3688"/>. Following the format in <xref target="RFC3688"/>, <t>This document registers URIs in the IETF XML registry
the following registrations are requested to be made: as defined in <xref target="RFC3688" format="default"/>.
<figure> The following registrations have been made:
<artwork> </t>
URI: urn:ietf:params:xml:ns:yang:iana-msd-types <dl spacing="compact">
Registrant Contact: The IESG. <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:iana-msd-types</dd>
XML: N/A, the requested URI is an XML namespace. <dt>Registrant Contact:</dt><dd>The IESG.</dd>
</artwork> <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</figure> </dl>
<dl spacing="compact">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-mpls-msd</dd>
<dt>Registrant Contact:</dt><dd>The IESG.</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<figure> <t>This document registers the YANG modules in the "YANG Module Names"
<artwork> registry as defined in <xref target="RFC6020" format="default"/>.
URI: urn:ietf:params:xml:ns:yang:ietf-mpls-msd </t>
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
</artwork>
</figure>
</t>
<t>This document registers the YANG modules in the YANG Module Names
registry <xref target="RFC6020"/>.
<figure>
<figure>
<artwork>
name: iana-msd-types
Maintained by IANA? Y
namespace: urn:ietf:params:xml:ns:yang:iana-msd-types
prefix: iana-msd-types
reference: RFC XXXX
</artwork>
</figure>
<artwork> <dl spacing="compact">
name: ietf-mpls-msd <dt>Name:</dt><dd>iana-msd-types</dd>
Maintained by IANA? N <dt>Maintained by IANA?</dt><dd>Y</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-msd <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:iana-msd-types</dd>
prefix: mpls-msd <dt>Prefix:</dt><dd>iana-msd-types</dd>
reference: RFC XXXX <dt>Reference:</dt><dd>RFC 9702</dd>
</artwork> </dl>
</figure>
</t>
</section>
<section title="IANA MSD-Types Module">
<t>This document defines the initial version of the IANA-maintained
"iana-msd-types" YANG module <xref target="iana-msd-types"/>. The latest
version of the YANG module is available from the "YANG Parameters"
registry <xref target="IANA-YANG-Parameters"/>.</t>
<t> <dl spacing="compact">
IANA is requested to add this note to the "YANG Module Names" registry: <dt>Name:</dt><dd>ietf-mpls-msd</dd>
<list style="empty"> <dt>Maintained by IANA?</dt><dd>N</dd>
<t>MSD Types must not be added directly to the iana-msd-types YANG modul <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-mpls-msd</dd>
e. <dt>Prefix:</dt><dd>mpls-msd</dd>
They must first be added to <xref target="IANA-IGP-MSD-Types"/>, which <dt>Reference:</dt><dd>RFC 9702</dd>
it mirrors.</t> </dl>
</list></t>
<t> </section>
<section numbered="true" toc="default">
<name>IANA MSD-Types Module</name>
<t>This document defines the initial version of the IANA-maintained
"iana-msd-types" YANG module (<xref target="iana-msd-types" format="defaul
t"/>). The latest
version of the YANG module is available from the "YANG Parameters"
registry <xref target="IANA-YANG-Parameters" format="default"/>.</t>
<t>
IANA has added this note to the "YANG Module Names" registry:
</t>
<blockquote>
<t>New values must not be directly added to the "iana-msd-types" YANG module. Th
ey must instead be added to the "IGP MSD-Types" registry in the "Interior Gatewa
y Protocol (IGP) Parameters" registry group <xref target="IANA-IGP-MSD-Types" fo
rmat="default"/>.</t>
</blockquote>
<t>
The identities defined in the iana-msd-types YANG module are organized hie rarchically The identities defined in the iana-msd-types YANG module are organized hie rarchically
based on the data plane. In this initial version, only MPLS and SRv6 data based on the data plane. In this initial version, only MPLS and SRv6 data
planes are supported, hence "msd-base-mpls" and "msd-base-srh" are defined . planes are supported, hence "msd-base-mpls" and "msd-base-srh" are defined .
When a new data plane is added to the "IGP MSD-Types" registry, a new "ide ntity" When a new data plane is added to the "IGP MSD-Types" registry, a new "ide ntity"
statement should be added to the "iana-msd-types" YANG module. The name of the statement should be added to the "iana-msd-types" YANG module. The name of the
"identity" is the prefix "msd-base-" plus a lower-case version of the data plane name . "identity" is the prefix "msd-base-" plus a lowercase version of the data plane name.
The identity statement should have the following sub-statements defined:</ t> The identity statement should have the following sub-statements defined:</ t>
<dl newline="false" spacing="normal" indent="15"> <dl newline="false" spacing="normal">
<dt>"base":</dt> <dt>"base":</dt>
<dd>Contains 'msd-base'.</dd> <dd>Contains 'msd-base'.</dd>
<dt>"description":</dt> <dt>"description":</dt>
<dd>Replicates the description from "msd-base-mpls" and change the cor responding data plane name.</dd> <dd>Replicates the description from "msd-base-mpls" and changes the co rresponding data plane name.</dd>
<dt>"reference":</dt> <dt>"reference":</dt>
<dd>Replicates the reference from <dd>Replicates the reference from
the registry with the title of the document added.</dd> the registry with the title of the document added.</dd>
</dl> </dl>
<t>
<t>
When an MSD type is added to the "IGP MSD-Types" registry, a new "identity " When an MSD type is added to the "IGP MSD-Types" registry, a new "identity "
statement must be added to the "iana-msd-types" YANG module. Then name of statement must be added to the "iana-msd-types" YANG module. The name of t
the he
"identity" is a lower-case version of the type name provided in the name w "identity" is a lowercase version of the type name provided in the name wi
ith th
the space replaced with "-". The "identity" statement should have the the space replaced with "-". The "identity" statement should have the
following sub-statements defined:</t> following sub-statements defined:</t>
<dl newline="false" spacing="normal" indent="15"> <dl newline="false" spacing="normal">
<dt>"base":</dt> <dt>"base":</dt>
<dd>Contains the base name of the corresponding data plane.</dd> <dd>Contains the base name of the corresponding data plane.</dd>
<dt>"description":</dt> <dt>"description":</dt>
<dd>Replicates the name from the registry.</dd> <dd>Replicates the name from the registry.</dd>
<dt>"reference":</dt> <dt>"reference":</dt>
<dd>Replicates the reference from <dd>Replicates the reference from
the registry with the title of the document added.</dd> the registry with the title of the document added.</dd>
</dl> </dl>
<t>Unassigned or reserved values are not present in the module.</t>
<t>Unassigned or reserved values are not present in the module.</t> <t>When the "iana-msd-types" YANG module is updated, a new "revision"
<t>When the "iana-msd-types" YANG module is updated, a new "revision"
statement with a unique revision date must be added in front of the statement with a unique revision date must be added in front of the
existing revision statements.</t> existing revision statements.</t>
<t> <!--[rfced] We suggest naming the column "Data Plane" no hyphen, as the
IANA is requested to the add a "data-plane" column to the hyphen seems unnecessary. If you agree, we will ask IANA to update the
registry accordingly.
Current: IANA has added a "Data-Plane" column
Suggested: IANA has added a "Data Plane" column
[and other instances]
-->
<t>
IANA has added a "Data Plane" column to the
"IGP MSD-Types" registry. This will unequivocally identify the "IGP MSD-Types" registry. This will unequivocally identify the
base identity for MSD-Types. The values for the Data-Plane base identity for MSD-Types. The values for the "Data Plane"
column for existing MSD-Types are: </t> column for existing MSD-Types are: </t>
<artwork>
Value Name Data-Plane Reference <table anchor="tab-1">
0 Reserved N/A [RFC8491] <thead>
1 Base MPLS Imposition MSD MPLS [RFC8491] <tr>
2 ERLD-MSD MPLS [RFC9088] <th>Value</th>
3-40 Unassigned N/A <th>Name</th>
41 SRH Max SL SRv6 [RFC9352] <th>Data Plane</th>
42 SRH Max End Pop SRv6 [RFC9352] <th>Reference</th>
43 Unassigned N/A </tr>
44 SRH Max H.encaps SRv6 [RFC9352] </thead>
45 SRH Max End SRv6 [RFC9352] <tbody>
46-250 Unassigned N/A <tr>
251-254 Experimental Use N/A [RFC8491] <td>0</td>
255 Reserved N/A [RFC8491] <td>Reserved</td>
</artwork> <td></td>
<t> <td><xref target="RFC8491"/></td>
IANA is requested to add this note to <xref target="IANA-IGP-MSD-Types"/ </tr>
>: <tr>
<list style="empty"> <td>1</td>
<t>When this registry is modified, the YANG module "iana-msd-types" <td>Base MPLS Imposition MSD</td>
must be updated as defined in RFC XXXX.</t> <td>MPLS</td>
</list> <td><xref target="RFC8491"/></td>
</t> </tr>
</section> <tr>
</section> <td>2</td>
<section anchor="Acknowledgements" title="Acknowledgements"> <td>ERLD-MSD</td>
<t>This document was produced using Marshall Rose's xml2rfc tool.</t> <td>MPLS</td>
<t>The YANG model was developed using the suite of YANG tools written <td><xref target="RFC9088"/></td>
and maintained by numerous authors.</t> </tr>
<t>We would like to thank Jan Lindblad, Tom Petch, Dhruv Dhody, Mohamed Bo <tr>
ucadair <td>3-40</td>
and Susan Hares for their reviews and comments.</t> <td>Unassigned</td>
<td></td>
<td></td>
</tr>
<tr>
<td>41</td>
<td>SRH Max SL</td>
<td>SRv6</td>
<td><xref target="RFC9352"/></td>
</tr>
<tr>
<td>42</td>
<td>SRH Max End Pop</td>
<td>SRv6</td>
<td><xref target="RFC9352"/></td>
</tr>
<tr>
<td>43</td>
<td>Unassigned</td>
<td></td>
<td></td>
</tr>
<tr>
<td>44</td>
<td>SRH Max H.encaps</td>
<td>SRv6</td>
<td><xref target="RFC9352"/></td>
</tr>
<tr>
<td>45</td>
<td>SRH Max End</td>
<td>SRv6</td>
<td><xref target="RFC9352"/></td>
</tr>
<tr>
<td>46-250</td>
<td>Unassigned</td>
<td></td>
<td></td>
</tr>
<tr>
<td>251-254</td>
<td>Experimental Use</td>
<td></td>
<td><xref target="RFC8491"/></td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
<td></td>
<td><xref target="RFC8491"/></td>
</tr>
</tbody>
</table>
<t>
IANA has added this note to <xref target="IANA-IGP-MSD-Types" format="de
fault"/>:
</t>
<blockquote>
<t>When this registry is modified, the YANG module "iana-msd-types"
must be updated as defined in RFC 9702.</t>
</blockquote>
</section>
</section> </section>
</middle> </middle>
<back>
<!-- *****BACK MATTER ***** --> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.36
88.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
241.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
242.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
950.xml"/>
<back> <!-- [rfced] RFC 7950 is not cited anywhere in this document. Please let us
<!-- References split into informative and normative --> know where it should be cited; otherwise, this reference will be removed
from the Normative References.
<!-- There are 2 ways to insert reference entries from the citation librarie Original:
s: [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here RFC 7950, DOI 10.17487/RFC7950, August 2016,
(as shown) <https://www.rfc-editor.org/info/rfc7950>. -->
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm
l"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.
xml")
Both are cited textually in the same manner: by using xref elements. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
If you use the PI option, xml2rfc will, by default, try to find included fi 040.xml"/>
les in the same <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
directory as the including file. You can also define the XML_LIBRARY enviro 341.xml"/>
nment variable <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
with a value containing a set of directories to search. These can be eithe 342.xml"/>
r in the local <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
filing system or remote ones accessed by http (http://domain/dir/... ).--> 349.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
476.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
491.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
960.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
088.xml"/>
<!-- <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.9110.xml"/>
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
352.xml"/>
<references title="Normative References"> <reference anchor="IANA-IGP-MSD-Types" target="https://www.iana.org/assi
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC. gnments/igp-parameters">
2119.xml"?-->
&RFC3688;
&RFC6020;
&RFC6241;
&RFC6242;
&RFC7950;
&RFC8040;
&RFC8341;
&RFC8342;
&RFC8349;
&RFC8446;
&RFC8476;
&RFC8491;
&RFC8960;
&RFC9088;
&RFC9110;
&RFC9352;
<reference anchor="IANA-IGP-MSD-Types" target="https://www.iana.org/assign
ments/igp-parameters/igp-parameters.xhtml#igp-msd-types" quoteTitle="true" deriv
edAnchor="IANA-IGP-MSD-Types">
<front> <front>
<title>IGP MSD-Types</title> <title>IGP MSD-Types</title>
<author> <author>
<organization showOnFrontPage="true">IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="IANA-YANG-Parameters" target="https://www.iana.org/assi
gnments/yang-parameters" quoteTitle="true" derivedAnchor="IANA-YANG-Parameters"> <reference anchor="IANA-YANG-Parameters" target="https://www.iana.org/as
signments/yang-parameters">
<front> <front>
<title>YANG Module Names</title> <title>YANG Module Names</title>
<author> <author>
<organization showOnFrontPage="true">IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC8340;
&RFC8662;
</references>
</back> </references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
40.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
662.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
664.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
814.xml"/>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The YANG data model was developed using the suite of YANG tools written
and maintained by numerous authors.</t>
<t>We would like to thank <contact fullname="Jan Lindblad"/>, <contact
fullname="Tom Petch"/>, <contact fullname="Dhruv Dhody"/>, <contact
fullname="Mohamed Boucadair"/>, and <contact fullname="Susan Hares"/>
for their reviews and comments.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 74 change blocks. 
411 lines changed or deleted 420 lines changed or added

This html diff was produced by rfcdiff 1.48.