draft-ietf-teas-yang-te-types-11.txt   draft-ietf-teas-yang-te-types-12.txt 
TEAS Working Group T. Saad TEAS Working Group T. Saad
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track R. Gandhi Intended status: Standards Track R. Gandhi
Expires: April 3, 2020 Cisco Systems Inc Expires: May 5, 2020 Cisco Systems Inc
X. Liu X. Liu
Volta Networks Volta Networks
V. Beeram V. Beeram
Juniper Networks Juniper Networks
I. Bryskin I. Bryskin
Huawei Technologies Individual
October 01, 2019 November 02, 2019
Traffic Engineering Common YANG Types Traffic Engineering Common YANG Types
draft-ietf-teas-yang-te-types-11 draft-ietf-teas-yang-te-types-12
Abstract Abstract
This document defines a collection of common data types and groupings This document defines a collection of common data types and groupings
in YANG data modeling language. These derived common types and in YANG data modeling language. These derived common types and
groupings are intended to be imported by modules that model Traffic groupings are intended to be imported by modules that model Traffic
Engineering (TE) configuration and state capabilities. Engineering (TE) configuration and state capabilities.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 3, 2020. This Internet-Draft will expire on May 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 1.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3
2. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . 3 2. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. TE Types Module Contents . . . . . . . . . . . . . . . . 4 3.1. TE Types Module Contents . . . . . . . . . . . . . . . . 4
3.2. Packet TE Types Module Contents . . . . . . . . . . . . . 8 3.2. Packet TE Types Module Contents . . . . . . . . . . . . . 8
4. TE Types YANG Module . . . . . . . . . . . . . . . . . . . . 8 4. TE Types YANG Module . . . . . . . . . . . . . . . . . . . . 8
5. Packet TE Types YANG Module . . . . . . . . . . . . . . . . . 67 5. Packet TE Types YANG Module . . . . . . . . . . . . . . . . . 67
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
7. Security Considerations . . . . . . . . . . . . . . . . . . . 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 77
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 77 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 77
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 77 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 77
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 78
10.1. Normative References . . . . . . . . . . . . . . . . . . 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 78
10.2. Informative References . . . . . . . . . . . . . . . . . 79 10.2. Informative References . . . . . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
YANG [RFC6020] and [RFC7950] is a data modeling language used to YANG [RFC6020] and [RFC7950] is a data modeling language used to
model configuration data, state data, Remote Procedure Calls, and model configuration data, state data, Remote Procedure Calls, and
notifications for network management protocols such as NETCONF notifications for network management protocols such as NETCONF
[RFC6241]. The YANG language supports a small set of built-in data [RFC6241]. The YANG language supports a small set of built-in data
types and provides mechanisms to derive other types from the built-in types and provides mechanisms to derive other types from the built-in
types. types.
skipping to change at page 9, line 11 skipping to change at page 9, line 11
o ietf-yang-types and ietf-inet-types defined in [RFC6991] o ietf-yang-types and ietf-inet-types defined in [RFC6991]
o ietf-routing-types defined in [RFC8294] o ietf-routing-types defined in [RFC8294]
In addition to the references cross-referenced in Section 3.1, this In addition to the references cross-referenced in Section 3.1, this
model also references the following RFCs in defining the types and model also references the following RFCs in defining the types and
YANG grouping of the YANG module: [RFC3272], [RFC4202], [RFC4328], YANG grouping of the YANG module: [RFC3272], [RFC4202], [RFC4328],
[RFC4657], [RFC5817], [RFC6004], [RFC6511], [RFC6205], [RFC7139], [RFC4657], [RFC5817], [RFC6004], [RFC6511], [RFC6205], [RFC7139],
[RFC7308], [RFC7551], [RFC7571], [RFC7579], [RFC4090], [RFC4561] and [RFC7308], [RFC7551], [RFC7571], [RFC7579], [RFC4090], [RFC4561] and
[RFC7951], [G709]. [RFC7951], [G709].
<CODE BEGINS> file "ietf-te-types@2019-10-01.yang" <CODE BEGINS> file "ietf-te-types@2019-11-02.yang"
module ietf-te-types { module ietf-te-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-te-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-te-types";
/* Replace with IANA when assigned */ /* Replace with IANA when assigned */
prefix "te-types"; prefix "te-types";
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference "RFC6991: Common YANG Data Types"; reference "RFC6991: Common YANG Data Types";
skipping to change at page 10, line 10 skipping to change at page 10, line 10
Editor: Vishnu Pavan Beeram Editor: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net> <mailto:vbeeram@juniper.net>
Editor: Himanshu Shah Editor: Himanshu Shah
<mailto:hshah@ciena.com> <mailto:hshah@ciena.com>
Editor: Xufeng Liu Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com> <mailto:xufeng.liu.ietf@gmail.com>
Editor: Igor Bryskin Editor: Igor Bryskin
<mailto:Igor.Bryskin@huawei.com> <mailto:i_bryskin@yahoo.com>
Editor: Young Lee Editor: Young Lee
<mailto:leeyoung@huawei.com>"; <mailto:leeyoung@huawei.com>";
description description
"This module contains a collection of generally useful TE "This module contains a collection of generally useful TE
specific YANG data type definitions. The model fully conforms specific YANG data type definitions. The model fully conforms
to the Network Management Datastore Architecture (NMDA). to the Network Management Datastore Architecture (NMDA).
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2018 IETF Trust and the persons
skipping to change at page 10, line 38 skipping to change at page 10, line 38
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this // RFC Ed.: replace XXXX with actual RFC number and remove this
// note. // note.
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and remove this note. // and remove this note.
revision "2019-10-01" { revision "2019-11-02" {
description "Latest revision of TE types"; description "Latest revision of TE types";
reference reference
"RFC XXXX: A YANG Data Model for Common Traffic Engineering "RFC XXXX: A YANG Data Model for Common Traffic Engineering
Types"; Types";
} }
/** /**
* Typedefs * Typedefs
*/ */
typedef admin-group { typedef admin-group {
type yang:hex-string { type yang:hex-string {
/* 01:02:03:04 */ /* 01:02:03:04 */
length "1..11"; length "1..11";
} }
description description
"Administrative group/Resource class/Color representation in "Administrative group/Resource class/Color representation in
hex-string type."; hex-string type.
The Most Significant Byte (MSB) is the farthest to the
left in the byte sequence.";
reference "RFC3630 and RFC5305"; reference "RFC3630 and RFC5305";
} }
typedef admin-groups { typedef admin-groups {
type union { type union {
type admin-group; type admin-group;
type extended-admin-group; type extended-admin-group;
} }
description "TE administrative group derived type"; description "TE administrative group derived type";
} }
typedef extended-admin-group { typedef extended-admin-group {
type yang:hex-string; type yang:hex-string;
description description
"Extended administrative group/Resource class/Color "Extended administrative group/Resource class/Color
representation in hex-string type"; representation in hex-string type.
The MSB is the farthest to the left in the byte sequence.";
reference "RFC7308"; reference "RFC7308";
} }
typedef path-attribute-flags { typedef path-attribute-flags {
type union { type union {
type identityref { type identityref {
base session-attributes-flags; base session-attributes-flags;
} }
type identityref { type identityref {
base lsp-attributes-flags; base lsp-attributes-flags;
skipping to change at page 13, line 31 skipping to change at page 13, line 34
+ '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+' + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+'
+ '(,(0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|' + '(,(0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|'
+ '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?[pP](\+)?(12[0-7]|' + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?[pP](\+)?(12[0-7]|'
+ '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+))*'; + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+))*';
} }
description description
"This is the generic bandwidth type that is a string containing "This is the generic bandwidth type that is a string containing
a list of numbers separated by commas, with each of these a list of numbers separated by commas, with each of these
number can be non-negative decimal, hex integer, or hex float: number can be non-negative decimal, hex integer, or hex float:
(dec | hex | float)[*(','(dec | hex | float))] (dec | hex | float)[*(','(dec | hex | float))]
For packet switching type, the string encoding follows the For packet switching type, the string encoding follows the
type bandwidth-ieee-float32 defined in RFC 8294 (e.g. 0x1p10). type bandwidth-ieee-float32 defined in RFC 8294 (e.g. 0x1p10),
where the units are in bytes per second.
For OTN switching type, a list of integers can be used, such For OTN switching type, a list of integers can be used, such
as '0,2,3,1', indicating 2 odu0's and 1 odu3. as '0,2,3,1', indicating 2 odu0's and 1 odu3.
For DWDM, a list of pairs of slot number and width can be For DWDM, a list of pairs of slot number and width can be
used, such as '0,2,3,3', indicating a frequency slot 0 with used, such as '0,2,3,3', indicating a frequency slot 0 with
slot width 2 and a frequency slot 3 with slot width 3. slot width 2 and a frequency slot 3 with slot width 3.
Canonically, the string is represented as all lowercase and in Canonically, the string is represented as all lowercase and in
hex where the prefix '0x' precedes the hex number"; hex where the prefix '0x' precedes the hex number";
reference "RFC 8294, G709"; reference "RFC 8294, G709";
} // te-bandwidth } // te-bandwidth
skipping to change at page 46, line 27 skipping to change at page 46, line 36
metrics as well as packet TE performance metrics."; metrics as well as packet TE performance metrics.";
reference reference
"RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
RFC7823: Performance-Based Path Selection for Explicitly RFC7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric Routed Label Switched Paths (LSPs) Using TE Metric
Extensions"; Extensions";
leaf one-way-residual-bandwidth { leaf one-way-residual-bandwidth {
type rt-types:bandwidth-ieee-float32; type rt-types:bandwidth-ieee-float32;
units 'bytes per second';
default '0x0p0'; default '0x0p0';
description description
"Residual bandwidth that subtracts tunnel "Residual bandwidth that subtracts tunnel
reservations from Maximum Bandwidth (or link capacity) reservations from Maximum Bandwidth (or link capacity)
[RFC3630] and provides an aggregated remainder across QoS [RFC3630] and provides an aggregated remainder across QoS
classes."; classes.";
} }
leaf one-way-residual-bandwidth-normality { leaf one-way-residual-bandwidth-normality {
type te-types:performance-metrics-normality; type te-types:performance-metrics-normality;
default 'normal'; default 'normal';
description "Residual bandwidth normality."; description "Residual bandwidth normality.";
} }
leaf one-way-available-bandwidth { leaf one-way-available-bandwidth {
type rt-types:bandwidth-ieee-float32; type rt-types:bandwidth-ieee-float32;
units 'bytes per second';
default '0x0p0'; default '0x0p0';
description description
"Available bandwidth that is defined to be residual "Available bandwidth that is defined to be residual
bandwidth minus the measured bandwidth used for the bandwidth minus the measured bandwidth used for the
actual forwarding of non-RSVP-TE LSP packets. For a actual forwarding of non-RSVP-TE LSP packets. For a
bundled link, available bandwidth is defined to be the bundled link, available bandwidth is defined to be the
sum of the component link available bandwidths."; sum of the component link available bandwidths.";
} }
leaf one-way-available-bandwidth-normality { leaf one-way-available-bandwidth-normality {
type te-types:performance-metrics-normality; type te-types:performance-metrics-normality;
default 'normal'; default 'normal';
description "Available bandwidth normality."; description "Available bandwidth normality.";
} }
leaf one-way-utilized-bandwidth { leaf one-way-utilized-bandwidth {
type rt-types:bandwidth-ieee-float32; type rt-types:bandwidth-ieee-float32;
units 'bytes per second';
default '0x0p0'; default '0x0p0';
description description
"Bandwidth utilization that represents the actual "Bandwidth utilization that represents the actual
utilization of the link (i.e. as measured in the router). utilization of the link (i.e. as measured in the router).
For a bundled link, bandwidth utilization is defined to For a bundled link, bandwidth utilization is defined to
be the sum of the component link bandwidth be the sum of the component link bandwidth
utilizations."; utilizations.";
} }
leaf one-way-utilized-bandwidth-normality { leaf one-way-utilized-bandwidth-normality {
type te-types:performance-metrics-normality; type te-types:performance-metrics-normality;
skipping to change at page 47, line 35 skipping to change at page 47, line 46
"One-way performance metrics throttle grouping."; "One-way performance metrics throttle grouping.";
leaf one-way-delay { leaf one-way-delay {
type uint32 { type uint32 {
range '0..16777215'; range '0..16777215';
} }
default 0; default 0;
description "One-way delay or latency in micro seconds."; description "One-way delay or latency in micro seconds.";
} }
leaf one-way-residual-bandwidth { leaf one-way-residual-bandwidth {
type rt-types:bandwidth-ieee-float32; type rt-types:bandwidth-ieee-float32;
units 'bytes per second';
default '0x0p0'; default '0x0p0';
description description
"Residual bandwidth that subtracts tunnel "Residual bandwidth that subtracts tunnel
reservations from Maximum Bandwidth (or link capacity) reservations from Maximum Bandwidth (or link capacity)
[RFC3630] and provides an aggregated remainder across QoS [RFC3630] and provides an aggregated remainder across QoS
classes."; classes.";
} }
leaf one-way-available-bandwidth { leaf one-way-available-bandwidth {
type rt-types:bandwidth-ieee-float32; type rt-types:bandwidth-ieee-float32;
units 'bytes per second';
default '0x0p0'; default '0x0p0';
description description
"Available bandwidth that is defined to be residual "Available bandwidth that is defined to be residual
bandwidth minus the measured bandwidth used for the bandwidth minus the measured bandwidth used for the
actual forwarding of non-RSVP-TE LSP packets. For a actual forwarding of non-RSVP-TE LSP packets. For a
bundled link, available bandwidth is defined to be the bundled link, available bandwidth is defined to be the
sum of the component link available bandwidths."; sum of the component link available bandwidths.";
} }
leaf one-way-utilized-bandwidth { leaf one-way-utilized-bandwidth {
type rt-types:bandwidth-ieee-float32; type rt-types:bandwidth-ieee-float32;
units 'bytes per second';
default '0x0p0'; default '0x0p0';
description description
"Bandwidth utilization that represents the actual "Bandwidth utilization that represents the actual
utilization of the link (i.e. as measured in the router). utilization of the link (i.e. as measured in the router).
For a bundled link, bandwidth utilization is defined to For a bundled link, bandwidth utilization is defined to
be the sum of the component link bandwidth be the sum of the component link bandwidth
utilizations."; utilizations.";
} }
} }
skipping to change at page 57, line 4 skipping to change at page 57, line 17
} }
} }
} }
leaf range-bitmap { leaf range-bitmap {
type yang:hex-string; type yang:hex-string;
description description
"When there are gaps between label-start and label-end, "When there are gaps between label-start and label-end,
this attribute is used to specify the positions this attribute is used to specify the positions
of the used labels. This is represented in big-endian as of the used labels. This is represented in big-endian as
hex-string. hex-string.
The MSB is the farthest to the left in the byte sequence.
Each bit-position in the range-bitmap hex-string maps to a Each bit-position in the range-bitmap hex-string maps to a
label in the range derived from the label-start. label in the range derived from the label-start.
For example, assuming label-start=16000 and For example, assuming label-start=16000 and
range-bitmap=0x01000001, then: range-bitmap=0x01000001, then:
- bit-position(0) is set, and the corresponding mapped label - bit-position(0) is set, and the corresponding mapped label
from the range is: 16000 + (0 * label-step) or from the range is: 16000 + (0 * label-step) or
16000 for default label-step=1. 16000 for default label-step=1.
- bit-position(24) is set, and the corresponding mapped label - bit-position(24) is set, and the corresponding mapped label
from the range is: 16000 + (24 * label-step) or from the range is: 16000 + (24 * label-step) or
skipping to change at page 67, line 36 skipping to change at page 67, line 49
<CODE ENDS> <CODE ENDS>
Figure 1: TE basic types YANG module Figure 1: TE basic types YANG module
5. Packet TE Types YANG Module 5. Packet TE Types YANG Module
The ietf-te-packet-types module imports from the following modules: The ietf-te-packet-types module imports from the following modules:
o ietf-te-types defined in this document. o ietf-te-types defined in this document.
<CODE BEGINS> file "ietf-te-packet-types@2019-10-01.yang" <CODE BEGINS> file "ietf-te-packet-types@2019-11-02.yang"
module ietf-te-packet-types { module ietf-te-packet-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-te-packet-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-te-packet-types";
/* Replace with IANA when assigned */ /* Replace with IANA when assigned */
prefix "te-packet-types"; prefix "te-packet-types";
/* Import TE generic types */ /* Import TE generic types */
import ietf-te-types { import ietf-te-types {
prefix te-types; prefix te-types;
skipping to change at page 68, line 27 skipping to change at page 68, line 40
Editor: Vishnu Pavan Beeram Editor: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net> <mailto:vbeeram@juniper.net>
Editor: Himanshu Shah Editor: Himanshu Shah
<mailto:hshah@ciena.com> <mailto:hshah@ciena.com>
Editor: Xufeng Liu Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com> <mailto:xufeng.liu.ietf@gmail.com>
Editor: Igor Bryskin Editor: Igor Bryskin
<mailto:Igor.Bryskin@huawei.com> <mailto:i_bryskin@yahoo.com>
Editor: Young Lee Editor: Young Lee
<mailto:leeyoung@huawei.com>"; <mailto:leeyoung@huawei.com>";
description description
"This module contains a collection of generally useful MPLS TE "This module contains a collection of generally useful MPLS TE
specific YANG data type definitions. The model fully conforms specific YANG data type definitions. The model fully conforms
to the Network Management Datastore Architecture (NMDA). to the Network Management Datastore Architecture (NMDA).
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2018 IETF Trust and the persons
skipping to change at page 69, line 8 skipping to change at page 69, line 20
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this // RFC Ed.: replace XXXX with actual RFC number and remove this
// note. // note.
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and remove this note. // and remove this note.
revision "2019-10-01" { revision "2019-11-02" {
description "Latest revision of TE MPLS types"; description "Latest revision of TE MPLS types";
reference reference
"RFC XXXX: A YANG Data Model for Common Traffic Engineering "RFC XXXX: A YANG Data Model for Common Traffic Engineering
Types"; Types";
} }
/** /**
* Typedefs * Typedefs
*/ */
typedef te-bandwidth-requested-type { typedef te-bandwidth-requested-type {
skipping to change at page 72, line 4 skipping to change at page 72, line 17
type uint32 { type uint32 {
range '0..16777215'; range '0..16777215';
} }
description description
"One-way maximum delay or latency in micro seconds."; "One-way maximum delay or latency in micro seconds.";
} }
leaf one-way-max-delay-normality { leaf one-way-max-delay-normality {
type te-types:performance-metrics-normality; type te-types:performance-metrics-normality;
default "normal"; default "normal";
description "One-way maximum delay or latency normality."; description "One-way maximum delay or latency normality.";
} }
leaf one-way-delay-variation { leaf one-way-delay-variation {
type uint32 { type uint32 {
range '0..16777215'; range '0..16777215';
} }
description "One-way delay variation in micro seconds."; description "One-way delay variation in micro seconds.";
reference "RFC5481, section 4.2";
} }
leaf one-way-delay-variation-normality { leaf one-way-delay-variation-normality {
type te-types:performance-metrics-normality; type te-types:performance-metrics-normality;
default "normal"; default "normal";
description "One-way delay variation normality."; description "One-way delay variation normality.";
reference "RFC7471, RFC8570, and RFC7823";
} }
leaf one-way-packet-loss { leaf one-way-packet-loss {
type decimal64 { type decimal64 {
fraction-digits 6; fraction-digits 6;
range '0 .. 50.331642'; range '0 .. 50.331642';
} }
description description
"One-way packet loss as a percentage of the total traffic "One-way packet loss as a percentage of the total traffic
sent over a configurable interval. The finest precision is sent over a configurable interval. The finest precision is
0.000003%. where the maximum 50.331642%."; 0.000003%. where the maximum 50.331642%.";
reference "RFC 7810, section-4.4"; reference "RFC 7810, section-4.4";
} }
leaf one-way-packet-loss-normality { leaf one-way-packet-loss-normality {
type te-types:performance-metrics-normality; type te-types:performance-metrics-normality;
default "normal"; default "normal";
description "Packet loss normality."; description "Packet loss normality.";
reference "RFC7471, RFC8570, and RFC7823";
} }
description description
"PM one-way packet specific augmentation to generic PM "PM one-way packet specific augmentation to generic PM
grouping"; grouping";
} }
augment performance-metrics-two-way { augment performance-metrics-two-way {
leaf two-way-min-delay { leaf two-way-min-delay {
type uint32 { type uint32 {
range '0..16777215'; range '0..16777215';
} }
default 0; default 0;
description description
"Two-way minimum delay or latency in micro seconds."; "Two-way minimum delay or latency in micro seconds.";
} }
leaf two-way-min-delay-normality { leaf two-way-min-delay-normality {
type te-types:performance-metrics-normality; type te-types:performance-metrics-normality;
default "normal"; default "normal";
description "Two-way minimum delay or latency normality."; description "Two-way minimum delay or latency normality.";
reference "RFC7471, RFC8570, and RFC7823";
} }
leaf two-way-max-delay { leaf two-way-max-delay {
type uint32 { type uint32 {
range '0..16777215'; range '0..16777215';
} }
default 0; default 0;
description description
"Two-way maximum delay or latency in micro seconds."; "Two-way maximum delay or latency in micro seconds.";
} }
leaf two-way-max-delay-normality { leaf two-way-max-delay-normality {
type te-types:performance-metrics-normality; type te-types:performance-metrics-normality;
default "normal"; default "normal";
description "Two-way maximum delay or latency normality."; description "Two-way maximum delay or latency normality.";
reference "RFC7471, RFC8570, and RFC7823";
} }
leaf two-way-delay-variation { leaf two-way-delay-variation {
type uint32 { type uint32 {
range '0..16777215'; range '0..16777215';
} }
default 0; default 0;
description "Two-way delay variation in micro seconds."; description "Two-way delay variation in micro seconds.";
reference "RFC5481, section 4.2";
} }
leaf two-way-delay-variation-normality { leaf two-way-delay-variation-normality {
type te-types:performance-metrics-normality; type te-types:performance-metrics-normality;
default "normal"; default "normal";
description "Two-way delay variation normality."; description "Two-way delay variation normality.";
reference "RFC7471, RFC8570, and RFC7823";
} }
leaf two-way-packet-loss { leaf two-way-packet-loss {
type decimal64 { type decimal64 {
fraction-digits 6; fraction-digits 6;
range '0 .. 50.331642'; range '0 .. 50.331642';
} }
default 0; default 0;
description description
"Two-way packet loss as a percentage of the total traffic "Two-way packet loss as a percentage of the total traffic
sent over a configurable interval. The finest precision is sent over a configurable interval. The finest precision is
0.000003%."; 0.000003%.";
} }
leaf two-way-packet-loss-normality { leaf two-way-packet-loss-normality {
type te-types:performance-metrics-normality; type te-types:performance-metrics-normality;
default "normal"; default "normal";
description "Two-way packet loss normality."; description "Two-way packet loss normality.";
} }
description description
"PM two-way packet specific augmentation to generic PM "PM two-way packet specific augmentation to generic PM
grouping"; grouping";
reference "RFC7471, RFC8570, and RFC7823";
} }
} }
} }
grouping one-way-performance-metrics-packet { grouping one-way-performance-metrics-packet {
description description
"One-way packet performance metrics throttle grouping."; "One-way packet performance metrics throttle grouping.";
leaf one-way-min-delay { leaf one-way-min-delay {
type uint32 { type uint32 {
range '0..16777215'; range '0..16777215';
skipping to change at page 85, line 44 skipping to change at page 86, line 28
Volta Networks Volta Networks
Email: xufeng.liu.ietf@gmail.com Email: xufeng.liu.ietf@gmail.com
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Igor Bryskin Igor Bryskin
Huawei Technologies Individual
Email: Igor.Bryskin@huawei.com Email: i_bryskin@yahoo.com
 End of changes. 35 change blocks. 
21 lines changed or deleted 41 lines changed or added

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