| rfc8532v1.txt | rfc8532.txt | |||
|---|---|---|---|---|
| skipping to change at page 3, line 10 ¶ | skipping to change at page 3, line 10 ¶ | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 53 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 53 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 55 | 9.2. Informative References . . . . . . . . . . . . . . . . . 55 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 | |||
| 1. Introduction | 1. Introduction | |||
| Operations, Administration, and Maintenance (OAM) are important | Operations, Administration, and Maintenance (OAM) are important | |||
| networking functions that allow operators to: | networking functions that allow operators to: | |||
| 1. monitor network communications (i.e., reachability verification, | 1. monitor network communications (i.e., reachability verification | |||
| continuity check) | and Continuity Check) | |||
| 2. troubleshoot failures (i.e., fault verification and localization) | 2. troubleshoot failures (i.e., fault verification and localization) | |||
| 3. monitor service-level agreements and performance (i.e., | 3. monitor service-level agreements and performance (i.e., | |||
| performance management) | performance management) | |||
| An overview of OAM tools is presented at [RFC7276]. | An overview of OAM tools is presented in [RFC7276]. | |||
| Ping and Traceroute (see [RFC792] and [RFC4443]) are respectively | Ping and Traceroute (see [RFC792] and [RFC4443]) are respectively | |||
| well-known fault verification and isolation tools for IP networks. | well-known fault verification and isolation tools for IP networks. | |||
| Over the years, different technologies have developed similar | Over the years, different technologies have developed similar | |||
| toolsets for equivalent purposes. | toolsets for equivalent purposes. | |||
| The different sets of OAM tools may support both connection-oriented | The different sets of OAM tools may support both connection-oriented | |||
| or connectionless technologies. In connection-oriented technologies, | or connectionless technologies. In connection-oriented technologies, | |||
| a connection is established prior to the transmission of data. After | a connection is established prior to the transmission of data. After | |||
| the connection is established, no additional control information such | the connection is established, no additional control information such | |||
| as signaling or operations and maintenance information is required to | as signaling or operations and maintenance information is required to | |||
| transmit the actual user data. In connectionless technologies, data | transmit the actual user data. In connectionless technologies, data | |||
| is typically sent between communicating end points without prior | is typically sent between communicating end points without prior | |||
| arrangement, but control information is required to identify the | arrangement, but control information is required to identify the | |||
| destination (e.g., [G.800] and [RFC7276]). The YANG data model for | destination (e.g., [G.800] and [RFC7276]). The YANG data model for | |||
| OAM protocols using connection-oriented communications is specified | OAM protocols using connection-oriented communications is specified | |||
| in [RFC8531]. | in [RFC8531]. | |||
| This document defines a base YANG data model for OAM protocols that | This document defines a base YANG data model for OAM protocols that | |||
| use connectionless communications. The data model is defined using | use connectionless communications. The data model is defined using | |||
| the YANG data modeling language [RFC7950]. This generic YANG model | the YANG data modeling language [RFC7950]. This generic YANG data | |||
| for connectionless OAM includes only configuration and state data. | model for connectionless OAM includes only configuration and state | |||
| It can be used in conjunction with the data retrieval method model | data. It can be used in conjunction with the data retrieval method | |||
| described in [RFC8533], which focuses on the data retrieval | model described in [RFC8533], which focuses on the data retrieval | |||
| procedures such as RPC, or it can be used independently of this data | procedures such as RPC, or it can be used independently of this data | |||
| retrieval method model. | retrieval method model. | |||
| 2. Conventions Used in This Document | 2. Conventions Used in This Document | |||
| The following terms are defined in [RFC6241] and are used in this | The following terms are defined in [RFC6241] and are used in this | |||
| specification: | specification: | |||
| o client | o client | |||
| o configuration data | o configuration data | |||
| skipping to change at page 6, line 43 ¶ | skipping to change at page 6, line 43 ¶ | |||
| o TP-attribute identifying a TP associated with an application-layer | o TP-attribute identifying a TP associated with an application-layer | |||
| function | function | |||
| o Router-id to represent the device or node, which is commonly used | o Router-id to represent the device or node, which is commonly used | |||
| to identify nodes in routing and other control-plane protocols | to identify nodes in routing and other control-plane protocols | |||
| [RFC8294]. | [RFC8294]. | |||
| To define a forwarding treatment of a test packet, the 'tp-address' | To define a forwarding treatment of a test packet, the 'tp-address' | |||
| grouping needs to be associated with additional parameters, e.g., | grouping needs to be associated with additional parameters, e.g., | |||
| DSCP for IP or Traffic Class [RFC5462] for MPLS. In the generic | DSCP for IP or Traffic Class [RFC5462] for MPLS. In the generic | |||
| connectionless OAM YANG model, these parameters are not explicitly | connectionless OAM YANG data model, these parameters are not | |||
| configured. The model user can add corresponding parameters | explicitly configured. The model user can add corresponding | |||
| according to their requirements. | parameters according to their requirements. | |||
| 3.2. Tools | 3.2. Tools | |||
| The different OAM tools may be used in one of two basic types of | The different OAM tools may be used in one of two basic types of | |||
| activation: proactive and on-demand. Proactive OAM refers to OAM | activation: proactive and on-demand. Proactive OAM refers to OAM | |||
| actions that are carried out continuously to permit proactive | actions that are carried out continuously to permit proactive | |||
| reporting of faults. The proactive OAM method requires persistent | reporting of faults. The proactive OAM method requires persistent | |||
| configuration. On-demand OAM refers to OAM actions that are | configuration. On-demand OAM refers to OAM actions that are | |||
| initiated via manual intervention for a limited time to carry out | initiated via manual intervention for a limited time to carry out | |||
| specific diagnostics. The on-demand OAM method requires only | specific diagnostics. The on-demand OAM method requires only | |||
| skipping to change at page 9, line 23 ¶ | skipping to change at page 9, line 23 ¶ | |||
| data to be retrieved on a 'per-hop' basis via a list of 'path-trace- | data to be retrieved on a 'per-hop' basis via a list of 'path-trace- | |||
| info-list' items which includes information such as 'timestamp' | info-list' items which includes information such as 'timestamp' | |||
| grouping, 'ingress-intf-name', 'egress-intf-name', and 'app-meta- | grouping, 'ingress-intf-name', 'egress-intf-name', and 'app-meta- | |||
| data'. The path discovery data model is made generic enough to allow | data'. The path discovery data model is made generic enough to allow | |||
| different methods of data retrieval. None of the fields are made | different methods of data retrieval. None of the fields are made | |||
| mandatory for that reason. Note that a set of retrieval methods are | mandatory for that reason. Note that a set of retrieval methods are | |||
| defined in [RFC8533]. | defined in [RFC8533]. | |||
| 3.7. Continuity Check Data | 3.7. Continuity Check Data | |||
| This is a generic grouping for the continuity check data model that | This is a generic grouping for the Continuity Check data model that | |||
| can be retrieved by any data retrieval methods including RPC | can be retrieved by any data retrieval methods including RPC | |||
| operations. Continuity check data output from methods, includes | operations. Continuity Check data output from methods, includes | |||
| 'src-test-point' container, 'dst-test-point' container, | 'src-test-point' container, 'dst-test-point' container, | |||
| 'sequence-number' leaf, 'hop-cnt' leaf, and session statistics of | 'sequence-number' leaf, 'hop-cnt' leaf, and session statistics of | |||
| various kinds. The continuity check data model is made generic | various kinds. The Continuity Check data model is made generic | |||
| enough to allow different methods of data retrieval. None of the | enough to allow different methods of data retrieval. None of the | |||
| fields are made mandatory for that reason. Noted that a set of | fields are made mandatory for that reason. Noted that a set of | |||
| retrieval methods are defined in [RFC8533]. | retrieval methods are defined in [RFC8533]. | |||
| 3.8. OAM data hierarchy | 3.8. OAM data hierarchy | |||
| The complete data hierarchy related to the OAM YANG model is | The complete data hierarchy related to the OAM YANG data model is | |||
| presented below. | presented below. | |||
| module: ietf-connectionless-oam | module: ietf-connectionless-oam | |||
| +--ro cc-session-statistics-data {continuity-check}? | +--ro cc-session-statistics-data {continuity-check}? | |||
| +--ro cc-session-statistics* [type] | +--ro cc-session-statistics* [type] | |||
| +--ro type identityref | +--ro type identityref | |||
| +--ro cc-ipv4-sessions-statistics | +--ro cc-ipv4-sessions-statistics | |||
| | +--ro cc-session-statistics | | +--ro cc-session-statistics | |||
| | +--ro session-count? uint32 | | +--ro session-count? uint32 | |||
| | +--ro session-up-count? uint32 | | +--ro session-up-count? uint32 | |||
| skipping to change at page 15, line 4 ¶ | skipping to change at page 15, line 4 ¶ | |||
| identity ntp64 { | identity ntp64 { | |||
| base timestamp-type; | base timestamp-type; | |||
| description | description | |||
| "Identity for 64-bit NTP timestamp."; | "Identity for 64-bit NTP timestamp."; | |||
| } | } | |||
| identity icmp { | identity icmp { | |||
| base timestamp-type; | base timestamp-type; | |||
| description | description | |||
| "Identity for 32-bit ICMP timestamp."; | "Identity for 32-bit ICMP timestamp."; | |||
| } | } | |||
| identity ptp80 { | ||||
| base timestamp-type; | ||||
| description | ||||
| "Identity for 80-bit PTP timestamp."; | ||||
| } | ||||
| } | } | |||
| <CODE ENDS> | <CODE ENDS> | |||
| 5. Connectionless OAM YANG Module | 5. Connectionless OAM YANG Module | |||
| This module imports the Core YANG Derived Types definition ("ietf- | This module imports the Core YANG Derived Types definition ("ietf- | |||
| yang-types" module) and Internet-Specific Derived Types definitions | yang-types" module) and Internet-Specific Derived Types definitions | |||
| ("ietf-inet-types" module) from [RFC6991], the "ietf-routing-types" | ("ietf-inet-types" module) from [RFC6991], the "ietf-routing-types" | |||
| module from [RFC8294], the "ietf-interfaces" module from [RFC8343], | module from [RFC8294], the "ietf-interfaces" module from [RFC8343], | |||
| skipping to change at page 16, line 4 ¶ | skipping to change at page 16, line 9 ¶ | |||
| } | } | |||
| import ietf-routing-types { | import ietf-routing-types { | |||
| prefix rt; | prefix rt; | |||
| } | } | |||
| import ietf-lime-time-types { | import ietf-lime-time-types { | |||
| prefix lime; | prefix lime; | |||
| } | } | |||
| organization | organization | |||
| "IETF LIME Working Group"; | "IETF LIME Working Group"; | |||
| contact | contact | |||
| "Deepak Kumar <dekumar@cisco.com> | "WG Web: <https://datatracker.ietf.org/wg/lime> | |||
| WG List: <mailto:lmap@ietf.org> | ||||
| Deepak Kumar <dekumar@cisco.com> | ||||
| Qin Wu <bill.wu@huawei.com> | Qin Wu <bill.wu@huawei.com> | |||
| Srihari Raghavan <srihari@cisco.com> | Srihari Raghavan <srihari@cisco.com> | |||
| Michael Wang <wangzitao@huawei.com> | Michael Wang <wangzitao@huawei.com> | |||
| Reshad Rahman <rrahman@cisco.com>"; | Reshad Rahman <rrahman@cisco.com>"; | |||
| description | description | |||
| "This YANG module defines the generic configuration, | "This YANG module defines the generic configuration, | |||
| data model, and statistics for OAM protocols using | data model, and statistics for OAM protocols using | |||
| connectionless communications, described in a | connectionless communications, described in a | |||
| protocol independent manner. It is assumed that each | protocol independent manner. It is assumed that each | |||
| protocol maps corresponding abstracts to its native | protocol maps corresponding abstracts to its native | |||
| format. Each protocol may extend the YANG model defined | format. Each protocol may extend the YANG data model defined | |||
| here to include protocol specific extensions. | here to include protocol specific extensions. | |||
| Copyright (c) 2019 IETF Trust and the persons identified as | Copyright (c) 2019 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 | without modification, is permitted pursuant to, and subject | |||
| to the license terms contained in, the Simplified BSD License | to the license terms contained in, the Simplified BSD License | |||
| set forth in Section 4.c of the IETF Trust's Legal Provisions | set forth in Section 4.c of the IETF Trust's Legal Provisions | |||
| Relating to IETF Documents | Relating to IETF Documents | |||
| skipping to change at page 16, line 47 ¶ | skipping to change at page 17, line 7 ¶ | |||
| Operations, Administration, and Maintenance (OAM) Protocols | Operations, Administration, and Maintenance (OAM) Protocols | |||
| That Use Connectionless Communications"; | That Use Connectionless Communications"; | |||
| } | } | |||
| feature connectionless { | feature connectionless { | |||
| description | description | |||
| "This feature indicates that the OAM solution is connectionless."; | "This feature indicates that the OAM solution is connectionless."; | |||
| } | } | |||
| feature continuity-check { | feature continuity-check { | |||
| description | description | |||
| "This feature indicates that the server supports | "This feature indicates that the server supports | |||
| executing a continuity check OAM command and | executing a Continuity Check OAM command and | |||
| returning a response. Servers that do not advertise | returning a response. Servers that do not advertise | |||
| this feature will not support executing | this feature will not support executing | |||
| continuity check commands or the RPC operation model for | Continuity Check commands or the RPC operation model for | |||
| continuity check commands."; | Continuity Check commands."; | |||
| } | } | |||
| feature path-discovery { | feature path-discovery { | |||
| description | description | |||
| "This feature indicates that the server supports | "This feature indicates that the server supports | |||
| executing a path discovery OAM command and | executing a path discovery OAM command and | |||
| returning a response. Servers that do not advertise | returning a response. Servers that do not advertise | |||
| this feature will not support executing | this feature will not support executing | |||
| path discovery commands or the RPC operation model for | path discovery commands or the RPC operation model for | |||
| path discovery commands."; | path discovery commands."; | |||
| } | } | |||
| skipping to change at page 23, line 7 ¶ | skipping to change at page 23, line 16 ¶ | |||
| grouping session-delay-statistics { | grouping session-delay-statistics { | |||
| description | description | |||
| "Grouping for delay statistics per session."; | "Grouping for delay statistics per session."; | |||
| container session-delay-statistics { | container session-delay-statistics { | |||
| description | description | |||
| "Session delay summarized information. By default, a | "Session delay summarized information. By default, a | |||
| one-way measurement protocol (e.g., OWAMP) is used | one-way measurement protocol (e.g., OWAMP) is used | |||
| to measure delay. When a two-way measurement protocol | to measure delay. When a two-way measurement protocol | |||
| (e.g., TWAMP) is used instead, it can be indicated | (e.g., TWAMP) is used instead, it can be indicated | |||
| using the protocol-id defined in RPC operation of | using the protocol-id defined in RPC operation of | |||
| draft-ietf-lime-yang-connectionless-oam-methods, i.e., | retrieval methods for connectionless OAM (RFC 8533), | |||
| set protocol-id as OWAMP. Note that only one measurement | i.e., set protocol-id as OWAMP. Note that only one | |||
| protocol for delay is specified for interoperability reasons."; | measurement protocol for delay is specified for | |||
| interoperability reasons."; | ||||
| leaf time-unit-value { | leaf time-unit-value { | |||
| type identityref { | type identityref { | |||
| base lime:time-unit-type; | base lime:time-unit-type; | |||
| } | } | |||
| default lime:milliseconds; | default lime:milliseconds; | |||
| description | description | |||
| "Time units, where the options are s, ms, ns, etc."; | "Time units, where the options are s, ms, ns, etc."; | |||
| } | } | |||
| leaf min-delay-value { | leaf min-delay-value { | |||
| type uint32; | type uint32; | |||
| skipping to change at page 23, line 46 ¶ | skipping to change at page 24, line 7 ¶ | |||
| description | description | |||
| "Grouping for per session jitter statistics."; | "Grouping for per session jitter statistics."; | |||
| container session-jitter-statistics { | container session-jitter-statistics { | |||
| description | description | |||
| "Summarized information about session jitter. By default, | "Summarized information about session jitter. By default, | |||
| jitter is measured using IP Packet Delay Variation | jitter is measured using IP Packet Delay Variation | |||
| (IPDV) as defined in RFC 3393. When the other measurement | (IPDV) as defined in RFC 3393. When the other measurement | |||
| method is used instead (e.g., Packet Delay Variation used | method is used instead (e.g., Packet Delay Variation used | |||
| in ITU-T Recommendation Y.1540, it can be indicated using | in ITU-T Recommendation Y.1540, it can be indicated using | |||
| protocol-id-meta-data defined in RPC operation of | protocol-id-meta-data defined in RPC operation of | |||
| draft-ietf-lime-yang-connectionless-oam-methods. Note that | retrieval methods for connectionless OAM (RFC 8533). | |||
| only one measurement method for jitter is specified | Note that only one measurement method for jitter is | |||
| for interoperability reasons."; | specified for interoperability reasons."; | |||
| leaf unit-value { | leaf unit-value { | |||
| type identityref { | type identityref { | |||
| base lime:time-unit-type; | base lime:time-unit-type; | |||
| } | } | |||
| default lime:milliseconds; | default lime:milliseconds; | |||
| description | description | |||
| "Time units, where the options are s, ms, ns, etc."; | "Time units, where the options are s, ms, ns, etc."; | |||
| } | } | |||
| leaf min-jitter-value { | leaf min-jitter-value { | |||
| type uint32; | type uint32; | |||
| description | description | |||
| "Minimum jitter value observed."; | "Minimum jitter value observed."; | |||
| } | } | |||
| skipping to change at page 33, line 27 ¶ | skipping to change at page 33, line 36 ¶ | |||
| } | } | |||
| grouping tp-tools { | grouping tp-tools { | |||
| description | description | |||
| "Test point OAM toolset."; | "Test point OAM toolset."; | |||
| container tp-tools { | container tp-tools { | |||
| leaf continuity-check { | leaf continuity-check { | |||
| type boolean; | type boolean; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "A flag indicating whether or not the | "A flag indicating whether or not the | |||
| continuity check function is supported."; | Continuity Check function is supported."; | |||
| reference | reference | |||
| "RFC 792: INTERNET CONTROL MESSAGE PROTOCOL | "RFC 792: INTERNET CONTROL MESSAGE PROTOCOL | |||
| RFC 4443: Internet Control Message Protocol (ICMPv6) | RFC 4443: Internet Control Message Protocol (ICMPv6) | |||
| for the Internet Protocol Version 6 (IPv6) Specification | for the Internet Protocol Version 6 (IPv6) Specification | |||
| RFC 5880: Bidirectional Forwarding Detection | RFC 5880: Bidirectional Forwarding Detection | |||
| RFC 5881: BFD for IPv4 and IPv6 | RFC 5881: BFD for IPv4 and IPv6 | |||
| RFC 5883: BFD for Multihop Paths | RFC 5883: BFD for Multihop Paths | |||
| RFC 5884: BFD for MPLS Label Switched Paths | RFC 5884: BFD for MPLS Label Switched Paths | |||
| RFC 5885: BFD for PW VCCV | RFC 5885: BFD for PW VCCV | |||
| RFC 6450: Multicast Ping Protocol | RFC 6450: Multicast Ping Protocol | |||
| skipping to change at page 37, line 9 ¶ | skipping to change at page 37, line 18 ¶ | |||
| description | description | |||
| "List of test point locations."; | "List of test point locations."; | |||
| } | } | |||
| description | description | |||
| "Serves as top-level container | "Serves as top-level container | |||
| for test point location list."; | for test point location list."; | |||
| } | } | |||
| description | description | |||
| "Container for AS number location types."; | "Container for AS number location types."; | |||
| } | } | |||
| container group-router-id-location-type { | container group-router-id-location-type { | |||
| when "derived-from-or-self(../tp-location-type,"+ | when "derived-from-or-self(../tp-location-type,"+ | |||
| "'cl-oam:router-id-address-type')" { | "'cl-oam:router-id-address-type')" { | |||
| description | description | |||
| "When test point location type is equal to system-info."; | "When test point location type is equal to system-info."; | |||
| } | } | |||
| container test-point-system-info-location-list { | container test-point-system-info-location-list { | |||
| list test-point-locations { | list test-point-locations { | |||
| key "router-id-location"; | key "router-id-location"; | |||
| leaf router-id-location { | leaf router-id-location { | |||
| type rt:router-id; | type rt:router-id; | |||
| description | description | |||
| "System ID."; | "System ID."; | |||
| } | } | |||
| leaf ni { | leaf ni { | |||
| type routing-instance-ref; | type routing-instance-ref; | |||
| skipping to change at page 38, line 10 ¶ | skipping to change at page 38, line 19 ¶ | |||
| grouping timestamp { | grouping timestamp { | |||
| description | description | |||
| "Grouping for timestamp."; | "Grouping for timestamp."; | |||
| leaf timestamp-type { | leaf timestamp-type { | |||
| type identityref { | type identityref { | |||
| base lime:timestamp-type; | base lime:timestamp-type; | |||
| } | } | |||
| description | description | |||
| "Type of timestamp, such as Truncated PTP or NTP."; | "Type of timestamp, such as Truncated PTP or NTP."; | |||
| } | } | |||
| container timestamp-64bit { | container timestamp-64bit { | |||
| when | when | |||
| "derived-from-or-self(../timestamp-type, 'cl-oam:truncated-ptp')"+ | "derived-from-or-self(../timestamp-type, 'lime:truncated-ptp')" | |||
| "or derived-from-or-self(../timestamp-type,'cl-oam:ntp64')" { | + "or derived-from-or-self(../timestamp-type, 'lime:ntp64')" { | |||
| description | description | |||
| "Only applies when PTP truncated or 64-bit NTP timestamp."; | "Only applies when PTP truncated or 64-bit NTP timestamp."; | |||
| } | } | |||
| leaf timestamp-sec { | leaf timestamp-sec { | |||
| type uint32; | type uint32; | |||
| description | description | |||
| "Absolute timestamp in seconds as per IEEE 1588v2 | "Absolute timestamp in seconds as per IEEE 1588v2 | |||
| or seconds part in 64-bit NTP timestamp."; | or seconds part in 64-bit NTP timestamp."; | |||
| } | } | |||
| leaf timestamp-nanosec { | leaf timestamp-nanosec { | |||
| type uint32; | type uint32; | |||
| description | description | |||
| "Fractional part in nanoseconds as per IEEE 1588v2 | "Fractional part in nanoseconds as per IEEE 1588v2 | |||
| or fractional part in 64-bit NTP timestamp."; | or fractional part in 64-bit NTP timestamp."; | |||
| } | } | |||
| description | description | |||
| "Container for 64-bit timestamp. In Network Time Protocol | "Container for 64-bit timestamp. The Network Time Protocol | |||
| (NTP) 64-bit timestamp format is defined in RFC 5905. The | (NTP) 64-bit timestamp format is defined in RFC 5905. The | |||
| PTP truncated timestamp format is defined in IEEE 1588v1."; | PTP truncated timestamp format is defined in IEEE 1588v1."; | |||
| reference | reference | |||
| "RFC 5905: Network Time Protocol Version 4: Protocol and | "RFC 5905: Network Time Protocol Version 4: Protocol and | |||
| Algorithms Specification | Algorithms Specification | |||
| IEEE 1588v1: IEEE Standard for a Precision Clock | IEEE 1588v1: IEEE Standard for a Precision Clock | |||
| Synchronization Protocol for Networked Measurement and | Synchronization Protocol for Networked Measurement and | |||
| Control Systems Version 1"; | Control Systems Version 1"; | |||
| } | } | |||
| container timestamp-80bit { | container timestamp-80bit { | |||
| when "derived-from-or-self(../timestamp-type, 'cl-oam:ptp80')"{ | when "derived-from-or-self(../timestamp-type, 'lime:ptp80')"{ | |||
| description | description | |||
| "Only applies when 80-bit PTP timestamp."; | "Only applies when 80-bit PTP timestamp."; | |||
| } | } | |||
| if-feature ptp-long-format; | if-feature ptp-long-format; | |||
| leaf timestamp-sec { | leaf timestamp-sec { | |||
| type uint64 { | type uint64 { | |||
| range "0..281474976710655"; | range "0..281474976710655"; | |||
| } | } | |||
| description | description | |||
| "48-bit timestamp in seconds as per IEEE 1588v2."; | "48-bit timestamp in seconds as per IEEE 1588v2."; | |||
| } | } | |||
| leaf timestamp-nanosec { | leaf timestamp-nanosec { | |||
| type uint32; | type uint32; | |||
| description | description | |||
| "Fractional part in nanoseconds as per IEEE 1588v2."; | "Fractional part in nanoseconds as per IEEE 1588v2."; | |||
| } | } | |||
| description | description | |||
| "Container for 80-bit timestamp."; | "Container for 80-bit timestamp."; | |||
| } | } | |||
| container ntp-timestamp-32bit { | container ntp-timestamp-32bit { | |||
| when "derived-from-or-self(../timestamp-type, 'cl-oam:truncated-ntp')"{ | when "derived-from-or-self(../timestamp-type, 'lime:truncated-ntp')"{ | |||
| description | description | |||
| "Only applies when 32-bit NTP short-format timestamp."; | "Only applies when 32-bit NTP short-format timestamp."; | |||
| } | } | |||
| if-feature ntp-short-format; | if-feature ntp-short-format; | |||
| leaf timestamp-sec { | leaf timestamp-sec { | |||
| type uint16; | type uint16; | |||
| description | description | |||
| "Timestamp in seconds as per short-format NTP."; | "Timestamp in seconds as per short-format NTP."; | |||
| } | } | |||
| leaf timestamp-nanosec { | leaf timestamp-nanosec { | |||
| type uint16; | type uint16; | |||
| description | description | |||
| "Truncated fractional part in 16-bit NTP timestamp."; | "Truncated fractional part in 16-bit NTP timestamp."; | |||
| } | } | |||
| description | description | |||
| "Container for 32-bit timestamp. See Section 4.2.2 of | "Container for 32-bit timestamp RFC5905."; | |||
| draft-ietf-ntp-packet-timestamps for NTP 32-bit timestamp | reference | |||
| format."; | "RFC 5905: Network Time Protocol Version 4: Protocol and | |||
| Algorithms Specification."; | ||||
| } | } | |||
| container icmp-timestamp-32bit { | container icmp-timestamp-32bit { | |||
| when "derived-from-or-self(../timestamp-type, 'cl-oam:icmp-ntp')"{ | when "derived-from-or-self(../timestamp-type, 'lime:icmp')"{ | |||
| description | description | |||
| "Only applies when Truncated PTP or 64-bit NTP Timestamp."; | "Only applies when ICMP timestamp."; | |||
| } | } | |||
| if-feature icmp-timestamp; | if-feature icmp-timestamp; | |||
| leaf timestamp-millisec { | leaf timestamp-millisec { | |||
| type uint32; | type uint32; | |||
| description | description | |||
| "Timestamp in milliseconds for ICMP timestamp."; | "Timestamp in milliseconds for ICMP timestamp."; | |||
| } | } | |||
| description | description | |||
| "Container for 32-bit timestamp. See RFC 792 for ICMP | "Container for 32-bit timestamp. See RFC 792 for ICMP | |||
| timestamp format."; | timestamp format."; | |||
| } | } | |||
| } | } | |||
| grouping path-discovery-data { | grouping path-discovery-data { | |||
| description | description | |||
| skipping to change at page 41, line 43 ¶ | skipping to change at page 42, line 4 ¶ | |||
| leaf transit-delay { | leaf transit-delay { | |||
| type uint32; | type uint32; | |||
| description | description | |||
| "Time in nanoseconds that the packet spent transiting a | "Time in nanoseconds that the packet spent transiting a | |||
| node."; | node."; | |||
| } | } | |||
| leaf app-meta-data { | leaf app-meta-data { | |||
| type uint64; | type uint64; | |||
| description | description | |||
| "Application-specific data added by node."; | "Application-specific data added by node."; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| grouping continuity-check-data { | grouping continuity-check-data { | |||
| description | description | |||
| "Continuity check data output from nodes."; | "Continuity Check data output from nodes."; | |||
| container src-test-point { | container src-test-point { | |||
| description | description | |||
| "Source test point."; | "Source test point."; | |||
| uses tp-address-ni; | uses tp-address-ni; | |||
| leaf egress-intf-name { | leaf egress-intf-name { | |||
| type if:interface-ref; | type if:interface-ref; | |||
| description | description | |||
| "Egress interface name."; | "Egress interface name."; | |||
| } | } | |||
| } | } | |||
| skipping to change at page 46, line 39 ¶ | skipping to change at page 46, line 45 ¶ | |||
| } | } | |||
| Similar augmentations can be defined to support other BFD | Similar augmentations can be defined to support other BFD | |||
| technologies such as BFD over LAG, etc. | technologies such as BFD over LAG, etc. | |||
| 6.1.2. Schema Mount | 6.1.2. Schema Mount | |||
| An alternative method is using the schema mount mechanism [RFC8528] | An alternative method is using the schema mount mechanism [RFC8528] | |||
| in the "ietf-connectionless-oam" module. Within the "test-point- | in the "ietf-connectionless-oam" module. Within the "test-point- | |||
| locations" list, a "root" attribute is defined to provide a mount | locations" list, a "root" attribute is defined to provide a mount | |||
| point for models mounted per "test-point-locations". Therefore, the | point for models that will be added onto per "test-point-locations". | |||
| "ietf-connectionless-oam" module can provide a place in the node | Therefore, the "ietf-connectionless-oam" module can provide a place | |||
| hierarchy where other OAM YANG data models can be attached, without | in the node hierarchy where other OAM YANG data models can be | |||
| any special extension in the "ietf-connectionless-oam" YANG data | attached, without any special extension in the "ietf-connectionless- | |||
| module [RFC8528]. Note that the limitation of the schema mount | oam" YANG data module [RFC8528]. Note that the limitation of the | |||
| method is that it's not allowed to specify certain modules that are | schema mount method is that it's not allowed to specify certain | |||
| required to be mounted under a mount point. | modules that are required to be mounted under a mount point. | |||
| The snippet below depicts the definition of the "root" attribute. | The snippet below depicts the definition of the "root" attribute. | |||
| anydata root { | anydata root { | |||
| yangmnt:mount-point root; | yangmnt:mount-point root; | |||
| description | description | |||
| "Root for models that are supported per test point"; | "Root for models that are supported per test point"; | |||
| } | } | |||
| The following section shows how the "ietf-connectionless-oam" module | The following section shows how the "ietf-connectionless-oam" module | |||
| skipping to change at page 53, line 23 ¶ | skipping to change at page 53, line 23 ¶ | |||
| URI: urn:ietf:params:xml:ns:yang:ietf-lime-time-types | URI: urn:ietf:params:xml:ns:yang:ietf-lime-time-types | |||
| Registrant Contact: The IESG. | Registrant Contact: The IESG. | |||
| XML: N/A; the requested URI is an XML namespace. | XML: N/A; the requested URI is an XML namespace. | |||
| URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam | URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam | |||
| Registrant Contact: The IESG. | Registrant Contact: The IESG. | |||
| XML: N/A; the requested URI is an XML namespace. | XML: N/A; the requested URI is an XML namespace. | |||
| This document registers two YANG modules in the "YANG Module Names" | This document registers two YANG modules in the "YANG Module Names" | |||
| registry [RFC7950]. | registry [RFC6020]. | |||
| Name: ietf-lime-time-types | Name: ietf-lime-time-types | |||
| Namespace: urn:ietf:params:xml:ns:yang:ietf-lime-time-types | Namespace: urn:ietf:params:xml:ns:yang:ietf-lime-time-types | |||
| Prefix: lime | Prefix: lime | |||
| Reference: RFC 8532 | Reference: RFC 8532 | |||
| Name: ietf-connectionless-oam | Name: ietf-connectionless-oam | |||
| Namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam | Namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam | |||
| Prefix: cl-oam | Prefix: cl-oam | |||
| Reference: RFC 8532 | Reference: RFC 8532 | |||
| skipping to change at page 54, line 30 ¶ | skipping to change at page 54, line 30 ¶ | |||
| [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
| (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | |||
| <https://www.rfc-editor.org/info/rfc5880>. | <https://www.rfc-editor.org/info/rfc5880>. | |||
| [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, | [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, | |||
| "Network Time Protocol Version 4: Protocol and Algorithms | "Network Time Protocol Version 4: Protocol and Algorithms | |||
| Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, | Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, | |||
| <https://www.rfc-editor.org/info/rfc5905>. | <https://www.rfc-editor.org/info/rfc5905>. | |||
| [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", | ||||
| RFC 6021, DOI 10.17487/RFC6021, October 2010, | ||||
| <https://www.rfc-editor.org/info/rfc6021>. | ||||
| [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | |||
| and A. Bierman, Ed., "Network Configuration Protocol | and A. Bierman, Ed., "Network Configuration Protocol | |||
| (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | |||
| <https://www.rfc-editor.org/info/rfc6241>. | <https://www.rfc-editor.org/info/rfc6241>. | |||
| [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | |||
| Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | |||
| <https://www.rfc-editor.org/info/rfc6242>. | <https://www.rfc-editor.org/info/rfc6242>. | |||
| [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", | [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", | |||
| skipping to change at page 56, line 23 ¶ | skipping to change at page 56, line 23 ¶ | |||
| [IEEE.1588v2] | [IEEE.1588v2] | |||
| "IEEE Standard for a Precision Clock Synchronization | "IEEE Standard for a Precision Clock Synchronization | |||
| Protocol for Networked Measurement and Control Systems | Protocol for Networked Measurement and Control Systems | |||
| Version 2", IEEE Std 1588, 2008. | Version 2", IEEE Std 1588, 2008. | |||
| [LSP-PING-YANG] | [LSP-PING-YANG] | |||
| Zheng, L., Zheng, G., Mirsky, G., Rahman, R., and F. | Zheng, L., Zheng, G., Mirsky, G., Rahman, R., and F. | |||
| Iqbal, "YANG Data Model for LSP-Ping", Work in Progress, | Iqbal, "YANG Data Model for LSP-Ping", Work in Progress, | |||
| draft-zheng-mpls-lsp-ping-yang-cfg-10, January 2019. | draft-zheng-mpls-lsp-ping-yang-cfg-10, January 2019. | |||
| [PACKET-TS] | ||||
| Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for | ||||
| Defining Packet Timestamps", Work in Progress, draft-ietf- | ||||
| ntp-packet-timestamps-05, December 2018. | ||||
| [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching | [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching | |||
| (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic | (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic | |||
| Class" Field", RFC 5462, DOI 10.17487/RFC5462, February | Class" Field", RFC 5462, DOI 10.17487/RFC5462, February | |||
| 2009, <https://www.rfc-editor.org/info/rfc5462>. | 2009, <https://www.rfc-editor.org/info/rfc5462>. | |||
| [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | ||||
| the Network Configuration Protocol (NETCONF)", RFC 6020, | ||||
| DOI 10.17487/RFC6020, October 2010, | ||||
| <https://www.rfc-editor.org/info/rfc6020>. | ||||
| [RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual | [RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual | |||
| Private Network (L2VPN) Operations, Administration, and | Private Network (L2VPN) Operations, Administration, and | |||
| Maintenance (OAM) Requirements and Framework", RFC 6136, | Maintenance (OAM) Requirements and Framework", RFC 6136, | |||
| DOI 10.17487/RFC6136, March 2011, | DOI 10.17487/RFC6136, March 2011, | |||
| <https://www.rfc-editor.org/info/rfc6136>. | <https://www.rfc-editor.org/info/rfc6136>. | |||
| [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. | [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. | |||
| Weingarten, "An Overview of Operations, Administration, | Weingarten, "An Overview of Operations, Administration, | |||
| and Maintenance (OAM) Tools", RFC 7276, | and Maintenance (OAM) Tools", RFC 7276, | |||
| DOI 10.17487/RFC7276, June 2014, | DOI 10.17487/RFC7276, June 2014, | |||
| End of changes. 35 change blocks. | ||||
| 79 lines changed or deleted | 81 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||