< draft-litkowski-spring-sr-yang-00.txt   draft-litkowski-spring-sr-yang-01.txt >
SPRING Working Group S. Litkowski SPRING Working Group S. Litkowski
Internet-Draft Orange Business Service Internet-Draft Orange Business Service
Intended status: Standards Track A. Lindem Intended status: Standards Track Y. Qu
Expires: September 6, 2015 Cisco Systems Expires: December 25, 2015 Cisco Systems
P. Sarkar P. Sarkar
Juniper Networks Juniper Networks
I. Chen J. Tantsura
Ericsson Ericsson
March 05, 2015 June 23, 2015
YANG Data Model for Segment Routing YANG Data Model for Segment Routing
draft-litkowski-spring-sr-yang-00 draft-litkowski-spring-sr-yang-01
Abstract Abstract
This document defines a YANG data model for segment routing This document defines a YANG data model ([RFC6020]) for segment
configuration and operation. This YANG model is intended to be used routing ([I-D.ietf-spring-segment-routing]) configuration and
on network elements to configure or operate segment routing. operation. This YANG model is intended to be used on network
elements to configure or operate segment routing. This document
defines also generic containers that SHOULD be reused by IGP protocol
modules to support segment routing.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 43 skipping to change at page 1, line 46
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 6, 2015. This Internet-Draft will expire on December 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 3
2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3
3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Adjacency SID properties . . . . . . . . . . . . . . . . 5 4. IGP Control plane configuration . . . . . . . . . . . . . . . 6
3.1.1. Bundling . . . . . . . . . . . . . . . . . . . . . . 5 4.1. IGP interface configuration . . . . . . . . . . . . . . . 6
3.1.2. Protection . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Adjacency SID properties . . . . . . . . . . . . . . 6
3.2. Prefix SID properties . . . . . . . . . . . . . . . . . . 6 4.1.1.1. Bundling . . . . . . . . . . . . . . . . . . . . 6
4. Control plane configuration . . . . . . . . . . . . . . . . . 7 4.1.1.2. Protection . . . . . . . . . . . . . . . . . . . 7
5. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 7
7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Normative References . . . . . . . . . . . . . . . . . . . . 20 11. Normative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This document defines a YANG data model for segment routing This document defines a YANG data model for segment routing
configuration and operation. configuration and operation. This document does not define the IGP
extensions to support segment routing but defines generic groupings
that SHOULD be reused by IGP extension modules. The reason of this
design choice is to not require implementations to support all IGP
extensions. For example, an implementation may support IS-IS
extension but not OSPF.
1.1. Tree diagram 1.1. Tree diagram
A simplified graphical representation of the data model is presented A simplified graphical representation of the data model is presented
in Section 2. in Section 2.
The meaning of the symbols in these diagrams is as follows: The meaning of the symbols in these diagrams is as follows:
o Brackets "[" and "]" enclose list keys. o Brackets "[" and "]" enclose list keys.
skipping to change at page 3, line 19 skipping to change at page 3, line 31
denotes a "list" or "leaf-list". denotes a "list" or "leaf-list".
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":"). marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not o Ellipsis ("...") stands for contents of subtrees that are not
shown. shown.
2. Design of the Data Model 2. Design of the Data Model
This is the initial version of this module and and its relationship As the module definition is just starting, it is expected that there
to the protocol modules. It is expected that there will be changes will be changes as the module matures.
as the module matures.
module: ietf-segment-routing module: ietf-segment-routing
augment /rt:routing/rt:routing-instance: augment /rt:routing/rt:routing-instance:
+--rw segment-routing +--rw segment-routing
+--rw transport-type? identityref +--rw transport-type? identityref
+--rw bindings +--rw bindings
| +--rw mapping-server {mapping-server}? | +--rw mapping-server {mapping-server}?
| | +--rw policy* [name]
| | +--rw name string
| | +--rw ipv4
| | | +--rw mapping-entry* [prefix]
| | | +--rw prefix inet:ipv4-prefix
| | | +--rw value-type? enumeration
| | | +--rw start-sid uint32
| | | +--rw range? uint32
| | +--rw ipv6
| | +--rw mapping-entry* [prefix]
| | +--rw prefix inet:ipv6-prefix
| | +--rw value-type? enumeration
| | +--rw start-sid uint32
| | +--rw range? uint32
| +--rw connected-prefix-sid-map
| +--rw ipv4 | +--rw ipv4
| | +--rw mapping-entry* [prefix] | | +--rw ipv4-prefix-sid* [prefix]
| | +--rw prefix inet:ipv4-prefix | | +--rw prefix inet:ipv4-prefix
| | +--rw start-sid? uint32 | | +--rw value-type? enumeration
| | +--rw range? uint32 | | +--rw start-sid uint32
| | +--rw range? uint32
| | +--rw last-hop-behavior? enumeration {sid-last-hop-behavior}?
| +--rw ipv6 | +--rw ipv6
| +--rw mapping-entry* [prefix] | +--rw ipv6-prefix-sid* [prefix]
| +--rw prefix inet:ipv6-prefix | +--rw prefix inet:ipv6-prefix
| +--rw start-sid? uint32 | +--rw value-type? enumeration
| +--rw range? uint32 | +--rw start-sid uint32
| +--rw range? uint32
| +--rw last-hop-behavior? enumeration {sid-last-hop-behavior}?
+--rw srgb* [lower-bound upper-bound] +--rw srgb* [lower-bound upper-bound]
| +--rw lower-bound uint32 +--rw lower-bound uint32
| +--rw upper-bound uint32 +--rw upper-bound uint32
+--rw interfaces
+--rw interface* [name]
+--rw name if:interface-ref
+--rw adjacency-sid
| +--rw advertise-adj-group-sid* [group-id]
| | +--rw group-id uint32
| +--rw advertise-protection? enumeration
+--rw prefix-sid
+--rw ipv4
| +--rw prefix-sid* [value]
| +--rw value-type? enumeration
| +--rw value uint32
| +--rw node-flag? boolean
| +--rw last-hop-behavior? enumeration
+--rw ipv6
+--rw prefix-sid* [value]
+--rw value-type? enumeration
+--rw value uint32
+--rw node-flag? boolean
+--rw last-hop-behavior? enumeration
augment /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol/isis:isis/isis:instance:
+--rw segment-routing
+--rw enabled? boolean
+--rw bindings
+--rw advertise? boolean
+--rw receive? boolean
augment /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol/ospf:ospf/ospf:instance:
+--rw segment-routing
+--rw enabled? boolean
+--rw bindings
+--rw advertise? boolean
+--rw receive? boolean
augment /rt:routing-state/rt:routing-instance: augment /rt:routing-state/rt:routing-instance:
+--ro segment-routing +--ro segment-routing
+--ro node-capabilities
| +--ro transport-planes* [transport-plane]
| | +--ro transport-plane identityref
| +--ro segment-stack-push-limit? uint8
| +--ro readable-label-stack-depth? uint8
+--ro label-blocks* +--ro label-blocks*
| +--ro lower-bound? uint32 | +--ro lower-bound? uint32
| +--ro upper-bound? uint32 | +--ro upper-bound? uint32
| +--ro size? uint32 | +--ro size? uint32
| +--ro free? uint32 | +--ro free? uint32
| +--ro used? uint32 | +--ro used? uint32
+--ro global-sid-list +--ro global-sid-list
+--ro sid* [target sid source source-protocol binding-type] +--ro sid* [target sid source source-protocol binding-type]
+--ro target string +--ro target string
+--ro sid uint32 +--ro sid uint32
skipping to change at page 5, line 24 skipping to change at page 5, line 27
The global configuration includes : The global configuration includes :
o segment-routing transport type : The underlying transport type for o segment-routing transport type : The underlying transport type for
segment routing. The version of the model limits the transport segment routing. The version of the model limits the transport
type to an MPLS dataplane. The transport-type is only defined type to an MPLS dataplane. The transport-type is only defined
once for a particular routing-instance and is agnostic to the once for a particular routing-instance and is agnostic to the
control plane used. Only a single transport-type is supported in control plane used. Only a single transport-type is supported in
this version of the model. this version of the model.
o bindings : Defines how external information is mapped to a segment o bindings : Defines prefix to SID mappings. The operator can
ID. The current version supports a mapping-server where static control advertisement of Prefix-SID independently for IPv4 and
prefix-to-SID bindings can be defined. Configuration of bindings IPv6. Two types of mappings are available :
does not allow advertisement of those bindings. Advertisement
must be controlled by each routing-protocol instance. * Mapping-server : maps non local prefixes to a segment ID.
Configuration of bindings does not automatically allow
advertisement of those bindings. Advertisement must be
controlled by each routing-protocol instance (see Section 4).
Multiple mapping policies may be defined.
* Connected prefixes : maps connected prefixes to a segment ID.
Advertisement of the mapping will be done by IGP when enabled
for segment routing (see Section 4). The SID value can be
expressed as an index (default), or an absolute value. The
"last-hop-behavior" configuration dictates the PHP behavior:
"explicit-null", "php", or "non-php".
o SRGB (Segment Routing Global Block): Defines a list of label o SRGB (Segment Routing Global Block): Defines a list of label
blocks represented by a pair of lower-bound/upper-bound labels. blocks represented by a pair of lower-bound/upper-bound labels.
The SRGB is also agnostic to the control plane used. So all The SRGB is also agnostic to the control plane used. So all
routing-protocol instance will have to advertise the same SRGB. routing-protocol instance will have to advertise the same SRGB.
The interface configuration includes : 4. IGP Control plane configuration
o Adjacency SID properties Support of segment-routing extensions for a particular IGP control
plane is done by augmenting routing-protocol configuration with
segment-routing extensions. This augmentation SHOULD be part of
separate YANG modules in order to not create any dependency for
implementations to support all protocol extensions.
o Prefix SID properties This module defines groupings that SHOULD be used by IGP segment
routing modules.
3.1. Adjacency SID properties The "controlplane-cfg" grouping defines the generic global
configuration for the IGP.
3.1.1. Bundling The "enabled" leaf enables segment-routing extensions for the
routing-protocol instance.
The "bindings" container controls the routing-protocol instance's
advertisement of local bindings and the processing of received
bindings.
4.1. IGP interface configuration
The interface configuration is part of the "igp-interface-cfg"
grouping and includes Adjacency SID properties.
4.1.1. Adjacency SID properties
4.1.1.1. Bundling
This section is a first proposal on how to use S-bit in Adj-SID to This section is a first proposal on how to use S-bit in Adj-SID to
create bundles. Authors would like to trigger discussion based on create bundles. Authors would like to trigger discussion based on
this first proposal. this first proposal.
In case of parallel IP links between routers, an additional Adjacency In case of parallel IP links between routers, an additional Adjacency
SID may be advertised representing more than one adjacency (i.e., a SID may be advertised representing more than one adjacency (i.e., a
bundle of adjacencies). The "advertise-adj-group-sid" configuration bundle of adjacencies). The "advertise-adj-group-sid" configuration
controls whether or not an additional adjacency SID is advertised. controls whether or not an additional adjacency SID is advertised.
The "advertise-adj-group-sid" would be a list of "group-id". The The "advertise-adj-group-sid" would be a list of "group-id". The
"group-id" will permit to identify interfaces that must be bundled "group-id" will permit to identify interfaces that must be bundled
together. together.
+-------+ +------+ +-------+ +------+
| | ------- L1 ---- | | | | ------- L1 ---- | |
| R1 | ------- L2 ---- | R2 | | R1 | ------- L2 ---- | R2 |
| | ------- L3 ---- | | | | ------- L3 ---- | |
| | ------- L4 ---- | | | | ------- L4 ---- | |
+-------+ +------+ +-------+ +------+
In the figure above, R1 and R2 are interconnected by four links. A In the figure above, R1 and R2 are interconnected by four links. A
routing protocol adjacency is established on each link. Operator routing protocol adjacency is established on each link. Operator
would like to create segment-routing Adj-SID that represent some would like to create segment-routing Adj-SID that represent some
bundles of links. We can imagine two different bundles : L1/L2 and bundles of links. We can imagine two different bundles : L1/L2 and
L2/L3. To achieve this behavior, the service provider will configure L2/L3. To achieve this behavior, the service provider will configure
a "group-id" X for both interfaces L1 and L2 and a "group-id" Y for a "group-id" X for both interfaces L1 and L2 and a "group-id" Y for
both interfaces L3 and L3. This will result in R1 advertising an both interfaces L3 and L3. This will result in R1 advertising an
additional Adj-SID for each adjacency, for example a Adj-SID with S additional Adj-SID for each adjacency, for example a Adj-SID with S
flag set and value of 400 will be added to L1 and L2. A Adj-SID with flag set and value of 400 will be added to L1 and L2. A Adj-SID with
S flag set and value of 500 will be added to L3 and L4. As L1/L2 and S flag set and value of 500 will be added to L3 and L4. As L1/L2 and
L3/L4 does not share the same "group-id", a different SID value will L3/L4 does not share the same "group-id", a different SID value will
be allocated. be allocated.
3.1.2. Protection 4.1.1.2. Protection
The "advertise-protection" defines how protection for an interface is The "advertise-protection" defines how protection for an interface is
advertised. It does not control the activation or deactivation of advertised. It does not control the activation or deactivation of
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.
3.2. Prefix SID properties
An interface may have associated IP prefixes. By default, no Prefix-
SID will be advertised for any IP prefix associated with an
interface.
The operator can control the advertisement of IP prefixes by setting
"prefix-sid" in the interface configuration.
The operator can control advertisement of Prefix-SID independently
for IPv4 and IPv6. When specified, the "prefix-sid" value must be
included.
The value can be expressed as an index (default), or an absolute
value. The operator can also control if the "node-flag" is set for
the prefix. As the network device owns the prefix, the default is to
advertise the prefix with the "node-flag" set.
The "last-hop-behavior" configuration dictates the PHP behavior:
"explicit-null", "php", or "non-php".
4. Control plane configuration
Activation of segment-routing extensions for a particular control
plane is done by augmenting routing-protocol configuration with
segment-routing.
The "enabled" leaf enables segment-routing extensions for the
routing-protocol instance.
The "bindings" container controls the routing-protocol instance's
advertisement of local bindings and the processing of received
bindings.
This model supports ISIS ([I-D.ietf-isis-segment-routing-extensions])
and OSPF as controlplane ([I-D.ietf-ospf-segment-routing-extensions]
and [I-D.psenak-ospf-segment-routing-ospfv3-extension]) for segment-
routing.
5. States 5. States
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.
6. Notifications 6. Notifications
skipping to change at page 8, line 11 skipping to change at page 8, line 16
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.
7. YANG Module 7. YANG Module
<CODE BEGINS> file "ietf-segment-routing@2015-03-04.yang" <CODE BEGINS> file "ietf-segment-routing@2015-06-23.yang"
module ietf-segment-routing { module ietf-segment-routing {
namespace "urn:ietf:params:xml:ns:" namespace "urn:ietf:params:xml:ns:"
+ "yang:ietf-segment-routing"; + "yang:ietf-segment-routing";
prefix sr; prefix sr;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix "rt";
} }
import ietf-interfaces {
prefix "if";
}
import ietf-isis {
prefix "isis";
}
import ospf {
prefix "ospf";
}
organization organization
"IETF SPRING Working Group"; "IETF SPRING Working Group";
contact contact
"WG List: &lt;mailto:spring@ietf.org&gt; "WG List: &lt;mailto:spring@ietf.org&gt;
Editor: Stephane Litkowski Editor: Stephane Litkowski
&lt;mailto:stephane.litkowski@orange.com&gt; &lt;mailto:stephane.litkowski@orange.com&gt;
Acee Lindem Acee Lindem
&lt;mailto:acee@cisco.com&gt; &lt;mailto:acee@cisco.com&gt;
Yingzhen Qu
&lt;mailto:yiqu@cisco.com&gt;
Pushpasis Sarkar Pushpasis Sarkar
&lt;mailto:psarkar@juniper.net&gt; &lt;mailto:psarkar@juniper.net&gt;
Ing-Wher Chen Ing-Wher Chen
&lt;mailto:ing-wher.chen@ericsson.com&gt; &lt;mailto:ing-wher.chen@ericsson.com&gt;
Jeff Tantsura
&lt;jeff.tantsura@ericsson.com&gt;
"; ";
description description
"The YANG module defines a generic configuration model for "The YANG module defines a generic configuration model for
Segment routing common across all of the vendor Segment routing common across all of the vendor
implementations."; implementations.";
revision 2015-06-22 {
description
"
* Prefix SID config moved to
connected-prefix-sid-map in global SR cfg
rather than IGP.
";
reference "draft-litkowski-spring-sr-yang-01";
}
revision 2015-04-23 {
description "
* Node flag deprecated from prefixSID
* SR interface cfg moved to protocol
* Adding multiple binding policies for SRMS
";
reference "";
}
revision 2015-02-27 { revision 2015-02-27 {
description "Initial"; description "Initial";
reference "draft-litkowski-spring-sr-yang-00"; reference "draft-litkowski-spring-sr-yang-00";
} }
/* Identities */ /* Identities */
identity segment-routing-transport { identity segment-routing-transport {
description description
"Base identity for segment routing transport."; "Base identity for segment routing transport.";
} }
skipping to change at page 9, line 36 skipping to change at page 9, line 51
routing."; routing.";
} }
/* Features */ /* Features */
feature mapping-server { feature mapping-server {
description description
"Support of SRMS."; "Support of SRMS.";
} }
feature sid-last-hop-behavior {
description
"Configurable last hop behavior.";
}
/* Groupings */ /* Groupings */
grouping controlplane-cfg { grouping controlplane-cfg {
container segment-routing { container segment-routing {
leaf enabled { leaf enabled {
type boolean; type boolean;
default false; default false;
description description
"Enables segment-routing "Enables segment-routing
protocol extensions."; protocol extensions.";
} }
container bindings { container bindings {
leaf advertise { container advertise {
type boolean; leaf-list policies {
default true; type string;
description
"List of policies to be advertised.";
}
description description
"Authorize the advertise "Authorize the advertise
of local mappings in binding TLV."; of local mappings in binding TLV.";
} }
leaf receive { leaf receive {
type boolean; type boolean;
default true; default true;
description description
"Authorize the reception and usage "Authorize the reception and usage
of binding TLV."; of binding TLV.";
skipping to change at page 10, line 25 skipping to change at page 10, line 48
and reception."; and reception.";
} }
description description
"segment routing global config."; "segment routing global config.";
} }
description description
"Defines protocol configuration."; "Defines protocol configuration.";
} }
grouping prefix-sid-cfg { grouping sid-value-type {
list prefix-sid { leaf value-type {
key value; type enumeration {
leaf value-type { enum index {
type enumeration { description
enum index { "The value will be
description interpreted as an index.";
"The value will be }
interpreted as an index."; enum absolute {
description
"The value will become
interpreted as an absolute
value.";
}
}
default index;
description
"This leaf defines how value
must be interpreted.";
}
description
"Defines how the SID value is expressed.";
}
} grouping ipv4-sid-cfg {
enum absolute {
description leaf prefix {
"The value will become type inet:ipv4-prefix;
interpreted as an absolute
value.";
}
}
default index;
description description
"This leaf defines how value "connected prefix sid.";
must be interpreted.";
} }
leaf value { uses sid-value-type;
leaf start-sid {
type uint32; type uint32;
mandatory true; mandatory true;
description description
"Value associated with "Value associated with
prefix. The value must prefix. The value must
be interpreted in the be interpreted in the
context of value-type."; context of value-type.";
} }
leaf node-flag {
type boolean; leaf range {
default true; type uint32;
description description
"Set prefix as a node "Describes how many SIDs could be
representative prefix."; allocated.";
} }
leaf last-hop-behavior { description
type enumeration { "This grouping defines cfg of prefix SID.";
enum explicit-null {
}
grouping ipv6-sid-cfg {
leaf prefix {
type inet:ipv6-prefix;
description
"connected prefix sid.";
}
uses sid-value-type;
leaf start-sid {
type uint32;
mandatory true;
description
"Value associated with
prefix. The value must
be interpreted in the
context of value-type.";
}
leaf range {
type uint32;
description
"Describes how many SIDs could be
allocated.";
}
description
"This grouping defines cfg of prefix SID.";
}
grouping last-hop-behavior {
leaf last-hop-behavior {
if-feature sid-last-hop-behavior;
type enumeration {
enum explicit-null {
description
"Use explicit-null for the SID.";
}
enum no-php {
description
"Do no use PHP for the SID.";
}
enum php {
description description
"Use explicit-null for the SID."; "Use PHP for the SID.";
} }
enum no-php {
}
description
"Configure last hop behavior.";
}
description
"Defines last hop behavior";
}
grouping igp-interface-cfg {
container segment-routing {
container adjacency-sid {
list advertise-adj-group-sid {
key group-id;
leaf group-id {
type uint32;
description description
"Do no use PHP for the SID.";
"The value is an internal value to identify
a group-ID. Interfaces with the same
group-ID will be bundled together.
";
} }
enum php { description
description "Control advertisement of S flag.
"Use PHP for the SID."; Enable to advertise a common Adj-SID
for parallel links.";
}
leaf advertise-protection {
type enumeration {
enum "single" {
description
"A single Adj-SID is associated
with the adjacency and reflects
the protection configuration.";
}
enum "dual" {
description
"Two Adj-SIDs will be associated
with the adjacency if interface
is protected. In this case
one will be enforced with
backup flag set, the other
will be enforced to backup flag unset.
In case, protection is not configured,
a single Adj-SID will be advertised
with backup flag unset.";
}
} }
description
"If set, the Adj-SID refers to an
adjacency being protected.";
} }
description description
"Configure last hop behavior."; "Defines the adjacency SID properties.";
} }
description description
"List of prefix SID."; "container for SR interface cfg.";
} }
description description
"This grouping defines cfg of prefix SID."; "Grouping for IGP interface cfg.";
} }
/* Cfg */ /* Cfg */
augment "/rt:routing/rt:routing-instance" { augment "/rt:routing/rt:routing-instance" {
description description
"This augments routing-instance "This augments routing-instance
configuration with segment-routing."; configuration with segment-routing.";
container segment-routing { container segment-routing {
leaf transport-type { leaf transport-type {
type identityref { type identityref {
base segment-routing-transport; base segment-routing-transport;
} }
default "segment-routing-transport-mpls"; default "segment-routing-transport-mpls";
description "Dataplane to be used."; description "Dataplane to be used.";
} }
container bindings { container bindings {
container mapping-server { container mapping-server {
if-feature mapping-server; if-feature mapping-server;
container ipv4 { list policy {
list mapping-entry { key name;
key prefix; leaf name {
type string;
leaf prefix {
type inet:ipv4-prefix;
description description
"Base prefix used for mapping."; "Name of the mapping policy.";
} }
leaf start-sid { container ipv4 {
type uint32; list mapping-entry {
key prefix;
uses ipv4-sid-cfg;
description
"Mapping entries.";
}
description description
"Starting SID value to be associated "IPv4 mapping entries.";
with prefix.";
} }
leaf range { container ipv6 {
type uint32; list mapping-entry {
key prefix;
uses ipv6-sid-cfg;
description
"Mapping entries.";
}
description description
"Describes how many SIDs could be "IPv6 mapping entries.";
allocated.";
} }
description description
"Mapping entries."; "Definition of mapping policy.";
}
description
"Configuration of mapping-server
local entries.";
}
container connected-prefix-sid-map {
container ipv4 {
list ipv4-prefix-sid {
key prefix;
uses ipv4-sid-cfg;
uses last-hop-behavior;
description
"List of prefix SID
mapped to IPv4 local prefixes.";
} }
description description
"IPv4 mapping entries."; "Parameters associated with IPv4 prefix SID";
} }
container ipv6 { container ipv6 {
list mapping-entry { list ipv6-prefix-sid {
key prefix; key prefix;
uses ipv6-sid-cfg;
leaf prefix { uses last-hop-behavior;
type inet:ipv6-prefix;
description
"Base prefix used for mapping.";
}
leaf start-sid {
type uint32;
description
"Starting SID value to be associated
with prefix.";
}
leaf range {
type uint32;
description
"Describes how many SIDs could be
allocated.";
}
description description
"Mapping entries."; "List of prefix SID
mapped to IPv6 local prefixes.";
} }
description description
"IPv6 mapping entries."; "Parameters associated with IPv6 prefix SID";
} }
description description
"Configuration of mapping-server "Prefix SID configuration.";
local entries.";
} }
description description
"List of bindings."; "List of bindings.";
} }
list srgb { list srgb {
key "lower-bound upper-bound"; key "lower-bound upper-bound";
ordered-by user; ordered-by user;
leaf lower-bound { leaf lower-bound {
type uint32; type uint32;
description description
skipping to change at page 13, line 42 skipping to change at page 16, line 24
} }
leaf upper-bound { leaf upper-bound {
type uint32; type uint32;
description description
"Upper value in the block."; "Upper value in the block.";
} }
description description
"List of global blocks to be "List of global blocks to be
advertised."; advertised.";
} }
container interfaces {
list interface {
key "name";
leaf name {
type if:interface-ref;
description
"Reference to the interface within
the routing-instance.";
}
container adjacency-sid {
list advertise-adj-group-sid {
key group-id;
leaf group-id {
type uint32;
description
"The value is an internal value to identify
a group-ID. Interfaces with the same
group-ID will be bundled together.
";
}
description
"Control advertisement of S flag.
Enable to advertise a common Adj-SID
for parallel links.";
}
leaf advertise-protection {
type enumeration {
enum "single" {
description
"A single Adj-SID is associated
with the adjacency and reflects
the protection configuration.";
}
enum "dual" {
description
"Two Adj-SIDs will be associated
with the adjacency if interface
is protected. In this case
one will be enforced with
backup flag set, the other
will be enforced to backup flag unset.
In case, protection is not configured,
a single Adj-SID will be advertised
with backup flag unset.";
}
}
description
"If set, the Adj-SID refers to an
adjacency being protected.";
}
description
"Defines the adjacency SID properties.";
}
container prefix-sid {
container ipv4 {
uses prefix-sid-cfg;
description
"Parameters associated with IPv4 prefix SID";
}
container ipv6 {
uses prefix-sid-cfg;
description
"Parameters associated with IPv6 prefix SID";
}
description
"Prefix SID configuration.";
}
description
"List of interfaces.";
}
description
"Interface configuration.";
}
description description
"segment routing global config."; "segment routing global config.";
} }
} }
augment "/rt:routing/rt:routing-instance/" +
"rt:routing-protocols/rt:routing-protocol"+
"/isis:isis/isis:instance" {
when "rt:type = 'isis:isis'" {
description
"This augment ISIS routing protocol when used";
}
description
"This augments ISIS protocol configuration
with segment routing.";
uses controlplane-cfg;
}
augment "/rt:routing/rt:routing-instance/rt:routing-protocols" +
"/rt:routing-protocol/ospf:ospf/ospf:instance" {
when "rt:type = 'ospf:ospfv2' or rt:type = 'ospf:ospfv3'" {
description
"This augment ISIS routing protocol when used";
}
description
"This augments ISIS protocol configuration
with segment routing.";
uses controlplane-cfg;
}
/* Operational states */ /* Operational states */
augment "/rt:routing-state/rt:routing-instance" { augment "/rt:routing-state/rt:routing-instance" {
description description
"This augments the operational states "This augments the operational states
with segment-routing."; with segment-routing.";
container segment-routing { container segment-routing {
container node-capabilities {
list transport-planes {
key transport-plane;
leaf transport-plane {
type identityref {
base segment-routing-transport;
}
description
"Transport plane supported";
}
description
"List of supported transport planes.";
}
leaf segment-stack-push-limit {
type uint8;
description
"Describes the number of segments
that can be pushed by the node.";
}
leaf readable-label-stack-depth {
type uint8;
description
"Number of MPLS labels that
can be read in the stack.";
}
description
"Shows the SR capability of the node.";
}
list label-blocks { list label-blocks {
leaf lower-bound { leaf lower-bound {
type uint32; type uint32;
description description
"Lower bound of the label block."; "Lower bound of the label block.";
} }
leaf upper-bound { leaf upper-bound {
type uint32; type uint32;
description description
"Upper bound of the label block."; "Upper bound of the label block.";
skipping to change at page 17, line 51 skipping to change at page 19, line 4
type enumeration { type enumeration {
enum prefix-sid { enum prefix-sid {
description description
"Binding is learned from "Binding is learned from
a prefix SID."; a prefix SID.";
} }
enum binding-tlv { enum binding-tlv {
description description
"Binding is learned from "Binding is learned from
a binding TLV."; a binding TLV.";
}
}
} }
description description
"Type of binding."; "Type of binding.";
} }
description description
"Binding."; "Binding.";
} }
description description
"List of prefix and SID associations."; "List of prefix and SID associations.";
skipping to change at page 19, line 46 skipping to change at page 20, line 47
} }
<CODE ENDS> <CODE ENDS>
8. Security Considerations 8. Security Considerations
TBD. TBD.
9. Acknowledgements 9. Acknowledgements
TBD. Authors would like to thank Derek Yeung, Acee Lindem, Greg Hankins,
Hannes Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge for their
contributions.
10. IANA Considerations 10. IANA Considerations
TBD. TBD.
11. Normative References 11. Normative References
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment-
routing-extensions-03 (work in progress), October 2014.
[I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-04 (work in progress), February 2015.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., and R. Shakir, "Segment Routing Architecture", draft-ietf-
and E. Crabbe, "Segment Routing Architecture", draft-ietf- spring-segment-routing-03 (work in progress), May 2015.
spring-segment-routing-01 (work in progress), February
2015.
[I-D.psenak-ospf-segment-routing-ospfv3-extension]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-psenak-ospf-
segment-routing-ospfv3-extension-02 (work in progress),
July 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March
2012.
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski
Orange Business Service Orange Business Service
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Acee Lindem Yingzhen Qu
Cisco Systems Cisco Systems
Email: acee@cisco.com Email: yiqu@cisco.com
Pushpasis Sarkar Pushpasis Sarkar
Juniper Networks Juniper Networks
Email: psarkar@juniper.net Email: psarkar@juniper.net
Ing-Wher Chen Jeff Tantsura
Ericsson Ericsson
Email: ing-wher.chen@ericsson.com Email: jeff.tantsura@ericsson.com
 End of changes. 72 change blocks. 
363 lines changed or deleted 370 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/