< draft-ietf-spring-sr-yang-20.txt   draft-ietf-spring-sr-yang-21.txt >
SPRING Working Group S. Litkowski SPRING Working Group S. Litkowski
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track Y. Qu Intended status: Standards Track Y. Qu
Expires: February 18, 2021 Futurewei Expires: February 26, 2021 Futurewei
A. Lindem A. Lindem
Cisco Systems Cisco Systems
P. Sarkar P. Sarkar
Individual Individual
J. Tantsura J. Tantsura
Apstra Apstra
August 17, 2020 August 25, 2020
YANG Data Model for Segment Routing YANG Data Model for Segment Routing
draft-ietf-spring-sr-yang-20 draft-ietf-spring-sr-yang-21
Abstract Abstract
This document defines a YANG data model for segment routing This document defines a YANG data model for segment routing
configuration and operation, which is to be augmented by different configuration and operation, which is to be augmented by different
segment routing data planes. The document also defines a YANG model segment routing data planes. The document also defines a YANG model
that is intended to be used on network elements to configure or that is intended to be used on network elements to configure or
operate segment routing MPLS data plane, as well as some generic operate segment routing MPLS data plane, as well as some generic
containers to be reused by IGP protocol modules to support segment containers to be reused by IGP protocol modules to support segment
routing. routing.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2021. This Internet-Draft will expire on February 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
2.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3
3. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 3. Design of the Data Model . . . . . . . . . . . . . . . . . . 3
4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IGP Control plane configuration . . . . . . . . . . . . . . . 6 5. IGP Control plane configuration . . . . . . . . . . . . . . . 6
5.1. IGP interface configuration . . . . . . . . . . . . . . . 7 5.1. IGP interface configuration . . . . . . . . . . . . . . . 7
5.1.1. Adjacency SID properties . . . . . . . . . . . . . . 7 5.1.1. Adjacency SID properties . . . . . . . . . . . . . . 7
5.1.1.1. Bundling . . . . . . . . . . . . . . . . . . . . 7 5.1.1.1. Bundling . . . . . . . . . . . . . . . . . . . . 7
5.1.1.2. Protection . . . . . . . . . . . . . . . . . . . 8 5.1.1.2. Protection . . . . . . . . . . . . . . . . . . . 8
6. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. State Data . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 8
8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Configuration example . . . . . . . . . . . . . . . 31 Appendix A. Configuration example . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This document defines a YANG data model [RFC7950] for segment routing This document defines a YANG data model [RFC7950] for segment routing
[RFC8402] configuration and operation. The document also defines a [RFC8402] configuration and operation. The document also defines a
YANG model that is intended to be used on network elements to YANG model that is intended to be used on network elements to
configure or operate segment routing MPLS data plane [RFC8660] This configure or operate segment routing MPLS data plane [RFC8660]. This
document does not define the IGP extensions to support segment document does not define the IGP extensions to support segment
routing but defines generic groupings that SHOULD be reused by IGP routing but defines generic groupings that SHOULD be reused by IGP
extension modules. The reason of this design choice is to not extension modules. The reason of this design choice is to not
require implementations to support all IGP extensions. For example, require implementations to support all IGP extensions. For example,
an implementation may support IS-IS extension but not OSPF. an implementation may support IS-IS extension but not OSPF.
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) [RFC8342]. Datastore Architecture (NMDA) [RFC8342].
2. Terminology and Notation 2. Terminology and Notation
skipping to change at page 8, line 19 skipping to change at page 8, line 19
protection. If the "single" option is used, a single Adj-SID will be protection. If the "single" option is used, a single Adj-SID will be
advertised for the interface. If the interface is protected, the advertised for the interface. If the interface is protected, the
B-Flag for the Adj-SID advertisement will be set. If the "dual" B-Flag for the Adj-SID advertisement will be set. If the "dual"
option is used and if the interface is protected, two Adj-SIDs will option is used and if the interface is protected, two Adj-SIDs will
be advertised for the interface adjacencies. One Adj-SID will always be advertised for the interface adjacencies. One Adj-SID will always
have the B-Flag set and the other will have the B-Flag clear. This have the B-Flag set and the other will have the B-Flag clear. This
option is intended to be used in the case of traffic engineering option is intended to be used in the case of traffic engineering
where a path must use either protected segments or non-protected where a path must use either protected segments or non-protected
segments. segments.
6. States 6. State Data
The operational states contains information reflecting the usage of The operational states contains information reflecting the usage of
allocated SRGB labels. allocated SRGB labels.
It also includes a list of all global SIDs, their associated It also includes a list of all global SIDs, their associated
bindings, and other information such as the source protocol and bindings, and other information such as the source protocol and
algorithm. algorithm.
7. Notifications 7. Notifications
The model defines the following notifications for segment-routing. The model defines the following notifications for segment-routing.
o segment-routing-global-srgb-collision: Rasied when a control plane o segment-routing-global-srgb-collision: Raised when a control plane
advertised SRGB blocks have conflicts. advertised SRGB blocks have conflicts.
o segment-routing-global-sid-collision: Raised when a control plane o segment-routing-global-sid-collision: Raised when a control plane
advertised index is already associated with another target (in advertised index is already associated with another target (in
this version, the only defined targets are IPv4 and IPv6 this version, the only defined targets are IPv4 and IPv6
prefixes). prefixes).
o segment-routing-index-out-of-range: Raised when a control plane o segment-routing-index-out-of-range: Raised when a control plane
advertised index fall outside the range of SRGBs configured for advertised index fall outside the range of SRGBs configured for
the network device. the network device.
8. YANG Module 8. YANG Modules
There are three modules included in this document:
o ietf-segment-routing.yang: This module defines a generic framework
for Segment Routing, and it is to be augmented by models for
different SR data planes.
o ietf-segment-routing-common.yang: This module defines a collection
of generic types and groupings for SR as defined in [RFC8402].
o ietf-segment-routing-mpls.yang: This module defines the
configuration and operation states for Segment Routing MPLS data
plane.
The following RFCs and drafts are not referenced in the document text The following RFCs and drafts are not referenced in the document text
but are referenced in the ietf-segment-rouuting-common.yang and/or but are referenced in the ietf-segment-routing-common.yang and/or
ietf-segment-routing.yang module: [RFC6991], [RFC8294], [RFC8476], ietf-segment-routing.yang module: [RFC6991], [RFC8294], [RFC8476],
[RFC8491], [RFC8665], and [RFC8667]. [RFC8491], [RFC8665], and [RFC8667].
<CODE BEGINS> file "ietf-segment-routing@2020-08-17.yang" <CODE BEGINS> file "ietf-segment-routing@2020-08-17.yang"
module ietf-segment-routing { module ietf-segment-routing {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing"; namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing";
prefix sr; prefix sr;
import ietf-routing { import ietf-routing {
skipping to change at page 31, line 34 skipping to change at page 31, line 44
Extensions for Segment Routing", RFC 8667, Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019, DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>. <https://www.rfc-editor.org/info/rfc8667>.
12.2. Informative References 12.2. Informative References
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
Appendix A. Configuration example Appendix A. Configuration example
Note: '\' line wrapping per [RFC8792].
The following is an XML example using the SR MPLS YANG modules. The following is an XML example using the SR MPLS YANG modules.
<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"> <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<segment-routing <segment-routing
xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing"> xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing">
<sr-mpls <sr-mpls
xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls"> xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls">
<msd> <msd>
<node-msd>5</node-msd> <node-msd>5</node-msd>
</msd> </msd>
<bindings> <bindings>
<mapping-server> <mapping-server>
<policy> <policy>
<name>mapping 1</name> <name>mapping 1</name>
<entries> <entries>
<mapping-entry> <mapping-entry>
<prefix>198.51.100.0/24</prefix> <prefix>198.51.100.0/24</prefix>
<algorithm xmlns:sr-cmn= <algorithm xmlns:sr-cmn="urn:ietf:params:xml:ns:yang\
"urn:ietf:params:xml:ns:yang: :ietf-segment-routing-common">\
ietf-segment-routing-common"> sr-cmn:prefix-sid-algorithm-shortest-path\
sr-cmn:prefix-sid-algorithm-shortest-path</algorithm> </algorithm>
<start-sid>200</start-sid> <start-sid>200</start-sid>
<range>100</range> <range>100</range>
</mapping-entry> </mapping-entry>
</entries> </entries>
</policy> </policy>
</mapping-server> </mapping-server>
<connected-prefix-sid-map> <connected-prefix-sid-map>
<connected-prefix-sid> <connected-prefix-sid>
<prefix>192.0.2.0/24</prefix> <prefix>192.0.2.0/24</prefix>
<algorithm xmlns:sr-cmn= <algorithm xmlns:sr-cmn="urn:ietf:params:xml:ns:yang:\
"urn:ietf:params:xml:ns:yang:ietf-segment-routing-common"> ietf-segment-routing-common">\
sr-cmn:prefix-sid-algorithm-strict-spf</algorithm> sr-cmn:prefix-sid-algorithm-strict-spf</algorithm>
<start-sid>100</start-sid> <start-sid>100</start-sid>
<range>1</range> <range>1</range>
<last-hop-behavior>php</last-hop-behavior> <last-hop-behavior>php</last-hop-behavior>
</connected-prefix-sid> </connected-prefix-sid>
</connected-prefix-sid-map> </connected-prefix-sid-map>
</bindings> </bindings>
<global-srgb> <global-srgb>
<srgb> <srgb>
<lower-bound>45000</lower-bound> <lower-bound>45000</lower-bound>
<upper-bound>55000</upper-bound> <upper-bound>55000</upper-bound>
</srgb> </srgb>
</global-srgb> </global-srgb>
</sr-mpls> </sr-mpls>
</segment-routing> </segment-routing>
</routing> </routing>
The following is the same example using JSON format.
{
"ietf-routing:routing": {
"ietf-segment-routing:segment-routing": {
"ietf-segment-routing-mpls:sr-mpls": {
"msd": {
"node-msd": 5
},
"bindings": {
"mapping-server": {
"policy": [
{
"name": "mapping 1",
"entries": {
"mapping-entry": [
{
"prefix": "198.51.100.0/24",
"algorithm": "ietf-segment-routing-common:\
prefix-sid-algorithm-shortest-path",
"start-sid": 200,
"range": 100
}
]
}
}
]
},
"connected-prefix-sid-map": {
"connected-prefix-sid": [
{
"prefix": "192.0.2.0/24",
"algorithm": "ietf-segment-routing-common:\
prefix-sid-algorithm-strict-spf",
"start-sid": 100,
"range": 1,
"last-hop-behavior": "php"
}
]
}
},
"global-srgb": {
"srgb": [
{
"lower-bound": 45000,
"upper-bound": 55000
}
]
}
}
}
}
}
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski
Cisco Systems Cisco Systems
Email: slitkows.ietf@gmail.com Email: slitkows.ietf@gmail.com
Yingzhen Qu Yingzhen Qu
Futurewei Futurewei
 End of changes. 15 change blocks. 
60 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/