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">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front> <!DOCTYPE rfc [
<!-- The abbreviated title is used in the page header - it is only necessary <!ENTITY nbsp "&#160;">
if the <!ENTITY zwsp "&#8203;">
full title is longer than 39 characters --> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<title abbrev="MPLS MSD YANG">YANG Data Model for Maximum SID Depth Types and MPLS Maximum SID Depth </title> <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">
<!-- add 'role="editor"' below for the editors if appropriate --> <!-- [rfced] Please note that the title of the document has been updated
to expand abbreviations per Section 3.6 of RFC 7322 ("RFC Style
Guide"). Please let us know if you prefer otherwise.
<!-- Another author who claims to be an editor --> Original:
YANG Data Model for Maximum SID Depth Types and MPLS Maximum SID Depth
Current:
YANG Data Model for Maximum Segment Identifier (SID) Depth Types
and MPLS Maximum SID Depth
-->
<front>
<title abbrev="MPLS MSD YANG">YANG Data Model for Maximum Segment Identifier
(SID) Depth Types and MPLS Maximum SID Depth </title>
<seriesInfo name="RFC" value="9702"/>
<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 50
<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, <!-- [rfced] Please insert any keywords (beyond those that appear in
IETF is fine for individual submissions. the title) for use on https://www.rfc-editor.org/search. -->
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 data modules. The first is the initial
is the initial version of the IANA-maintained YANG module for Maximum Se version of the IANA-maintained YANG module for Maximum Segment
gment Identifier (SID) Identifier (SID) Depth (MSD) Types, which includes identities for both
Depths (MSDs) Types, which includes identities for both the MPLS and SRv the MPLS data plane and Segment Routing over IPv6 (SRv6) data plane. The s
6 data planes. The second econd augments the IETF MPLS YANG model to provide support for MPLS MSDs as defi
augments the IETF MPLS YANG model to ned in RFCs 8476 and
provide support for MPLS MSDs as defined in RFC 8476 and RFC 8491. </t> 8491. </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Overview"> <section numbered="true" toc="default">
<name>Overview</name>
<t>There are two YANG modules defined in this document. Module <t>There are two YANG modules defined in this document. Module
iana-msd-types defines the identities for Maximum Segment Identifier (SI iana-msd-types defines the identities for Maximum SID Depth (MSD) Types as
D) Depth (MSD) per the "IGP MSD-Types" IANA registry <xref
Types as per the IANA IGP MSD-Types registry <xref target="IANA-IGP-MSD- target="IANA-IGP-MSD-Types" format="default"/>, which includes MSD types
Types"/>, for both the MPLS and SRv6 data planes. This document also
which include MSD types for both the MPLS data plane and the SRv6 data p defines module ietf-mpls-msd augmenting the IETF MPLS YANG data model <xre
lane. This document also f
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 MSDs on links.
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 Gateway Protocol (IGP) Parameters" registry group to
identify MSD-Types. Module iana-msd-types is an IANA-maintained identify MSD-Types. Module iana-msd-types is an IANA-maintained
module, which defines the identities for the MSD-Types as in the module, which defines the identities for the MSD-Types as in the
IANA IGP MSD-Types registry. IANA "IGP MSD-Types" registry.
</t> </t>
<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 smallest MSD supported by the node across all its interfaces. the smallest MSD supported by the node across all its interfaces.
The module defines lists The module defines lists
of MSDs with different MSD Types for a node and links. Please of MSDs with different MSD Types for a node and links. Please
note that these are read-only data as per the node's hardware note that these are read-only data as per the node's 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 212
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 356 skipping to change at line 306
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 352
<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> <!--[rfced] FYI, the Security Considerations section has been updated
to match https://wiki.ietf.org/group/ops/yang-security-guidelines.
If the differences from the approved template should be reinstated,
please let us know.
<section anchor="Security" title="Security Considerations"> Specifically, this text is no longer present:
<t> ... without the "none" authentication
The YANG modules specified in this document define a schema for data option, Transport Layer Security (TLS) [RFC8446] with mutual X.509
that is designed to be accessed via network management protocols such authentication, and HTTPS with HTTP authentication (Section 11 of
as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. [RFC9110]).
These network management protocols are required to use a secure
transport layer and mutual authentication, e.g., SSH <xref target="RFC6242
"/>
without the "none" authentication option, Transport Layer Security (TLS)
<xref target="RFC8446"/> with mutual X.509 authentication, and HTTPS
with HTTP authentication (Section 11 of <xref target="RFC9110"/>).</t>
<t>The NETCONF Access Control Model (NACM) <xref target="RFC8341"/> provides The normative reference [RFC9110] has been removed, as it was not
the cited elsewhere in the document.
-->
<t>
<!-- DNE begins-->
The YANG modules specified in this document define a schema for data
that is designed to be accessed via network management protocols such as
NETCONF <xref target="RFC6241" format="default"/> or RESTCONF <xref
target="RFC8040" format="default"/>.
The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) <xref target="RFC6242" format="default"/>. The
lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
<xref target="RFC8446" format="default"/>.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="RFC
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 <!--[rfced] FYI, "N/A" has been removed from Table 1 in order
0 Reserved N/A [RFC8491] to match the IANA registry, which does not use "N/A" for empty fields.
1 Base MPLS Imposition MSD MPLS [RFC8491] -->
2 ERLD-MSD MPLS [RFC9088]
3-40 Unassigned N/A <table anchor="tab-1">
41 SRH Max SL SRv6 [RFC9352] <thead>
42 SRH Max End Pop SRv6 [RFC9352] <tr>
43 Unassigned N/A <th>Value</th>
44 SRH Max H.encaps SRv6 [RFC9352] <th>Name</th>
45 SRH Max End SRv6 [RFC9352] <th>Data-Plane</th>
46-250 Unassigned N/A <th>Reference</th>
251-254 Experimental Use N/A [RFC8491] </tr>
255 Reserved N/A [RFC8491] </thead>
</artwork> <tbody>
<t> <tr>
IANA is requested to add this note to <xref target="IANA-IGP-MSD-Types"/ <td>0</td>
>: <td>Reserved</td>
<list style="empty"> <td></td>
<t>When this registry is modified, the YANG module "iana-msd-types" <td><xref target="RFC8491"/></td>
must be updated as defined in RFC XXXX.</t> </tr>
</list> <tr>
</t> <td>1</td>
</section> <td>Base MPLS Imposition MSD</td>
</section> <td>MPLS</td>
<section anchor="Acknowledgements" title="Acknowledgements"> <td><xref target="RFC8491"/></td>
<t>This document was produced using Marshall Rose's xml2rfc tool.</t> </tr>
<t>The YANG model was developed using the suite of YANG tools written <tr>
and maintained by numerous authors.</t> <td>2</td>
<t>We would like to thank Jan Lindblad, Tom Petch, Dhruv Dhody, Mohamed Bo <td>ERLD-MSD</td>
ucadair <td>MPLS</td>
and Susan Hares for their reviews and comments.</t> <td><xref target="RFC9088"/></td>
</tr>
<tr>
<td>3-40</td>
<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>
<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"/>
</references>
</references> </references>
<references title="Informative References"> <section anchor="Acknowledgements" numbered="false" toc="default">
<!-- Here we use entities that we defined at the beginning. --> <name>Acknowledgements</name>
&RFC8340; <t>The YANG model was developed using the suite of YANG tools written
&RFC8662; and maintained by numerous authors.</t>
</references> <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>
<!-- [rfced] Terminology
</back> a) We have received guidance from Benoît Claise and the YANG Doctors that
the terms "YANG module" and "YANG data model" are preferred. Please review
the usage in this document. For example, should text be updated as follows
or otherwise?
Abstract
Original: This document defines two YANG data modules.
Perhaps: This document defines two YANG modules.
[Section 1 already uses the latter.]
Original: The second augments the IETF MPLS YANG model to provide ...
Perhaps: The second augments the IETF MPLS YANG data model to provide ...
[And the same for similar text in Section 1.]
Acknowledgements
Original: The YANG model was developed ...
Perhaps: The YANG data model was developed ...
b) FYI, we have updated the terms below to use the form on the right,
as this is how they appear in the referenced documents (e.g., RFC 8491).
node MSD vs. Node MSD
link MSD vs. Link MSD
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers. Note that our
script did not flag any words in particular, but this should still be reviewed
as a best practice.
-->
<!-- [rfced] FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
-->
</back>
</rfc> </rfc>
 End of changes. 81 change blocks. 
395 lines changed or deleted 472 lines changed or added

This html diff was produced by rfcdiff 1.48.