draft-ietf-ospf-yang-22.txt   draft-ietf-ospf-yang-23.txt 
Internet D. Yeung Internet D. Yeung
Internet-Draft Arrcus Internet-Draft Arrcus
Intended status: Standards Track Y. Qu Intended status: Standards Track Y. Qu
Expires: December 24, 2019 Huawei Expires: January 2, 2020 Huawei
J. Zhang J. Zhang
Juniper Networks Juniper Networks
I. Chen I. Chen
The MITRE Corporation The MITRE Corporation
A. Lindem A. Lindem
Cisco Systems Cisco Systems
June 22, 2019 July 1, 2019
YANG Data Model for OSPF Protocol YANG Data Model for OSPF Protocol
draft-ietf-ospf-yang-22 draft-ietf-ospf-yang-23
Abstract Abstract
This document defines a YANG data model that can be used to configure This document defines a YANG data model that can be used to configure
and manage OSPF. The model is based on YANG 1.1 as defined in RFC and manage OSPF. The model is based on YANG 1.1 as defined in RFC
7950 and conforms to the Network Management Datastore Architecture 7950 and conforms to the Network Management Datastore Architecture
(NDMA) as described in RFC 8342. (NDMA) as described in RFC 8342.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 December 24, 2019. This Internet-Draft will expire on January 2, 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
(http://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
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 25 skipping to change at page 2, line 25
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
2. Design of Data Model . . . . . . . . . . . . . . . . . . . . 3 2. Design of Data Model . . . . . . . . . . . . . . . . . . . . 3
2.1. OSPF Operational State . . . . . . . . . . . . . . . . . 3 2.1. OSPF Operational State . . . . . . . . . . . . . . . . . 3
2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. OSPFv2 and OSPFv3 . . . . . . . . . . . . . . . . . . . . 5 2.3. OSPFv2 and OSPFv3 . . . . . . . . . . . . . . . . . . . . 5
2.4. Optional Features . . . . . . . . . . . . . . . . . . . . 5 2.4. Optional Features . . . . . . . . . . . . . . . . . . . . 5
2.5. OSPF Router Configuration/Operational State . . . . . . . 7 2.5. OSPF Router Configuration/Operational State . . . . . . . 7
2.6. OSPF Area Configuration/Operational State . . . . . . . . 10 2.6. OSPF Area Configuration/Operational State . . . . . . . . 10
2.7. OSPF Interface Configuration/Operational State . . . . . 16 2.7. OSPF Interface Configuration/Operational State . . . . . 16
2.8. OSPF notification . . . . . . . . . . . . . . . . . . . . 19 2.8. OSPF notification . . . . . . . . . . . . . . . . . . . . 19
2.9. OSPF RPC Operations . . . . . . . . . . . . . . . . . . . 22 2.9. OSPF RPC Operations . . . . . . . . . . . . . . . . . . . 23
3. OSPF YANG Module . . . . . . . . . . . . . . . . . . . . . . 23 3. OSPF YANG Module . . . . . . . . . . . . . . . . . . . . . . 23
4. Security Considerations . . . . . . . . . . . . . . . . . . . 115 4. Security Considerations . . . . . . . . . . . . . . . . . . . 116
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 116 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 116 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 117
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.1. Normative References . . . . . . . . . . . . . . . . . . 117 7.1. Normative References . . . . . . . . . . . . . . . . . . 118
7.2. Informative References . . . . . . . . . . . . . . . . . 122 7.2. Informative References . . . . . . . . . . . . . . . . . 123
Appendix A. Contributors' Addresses . . . . . . . . . . . . . . 124 Appendix A. Contributors' Addresses . . . . . . . . . . . . . . 125
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125
1. Overview 1. Overview
YANG [RFC6020][RFC7950] is a data definition language used to define YANG [RFC6020][RFC7950] is a data definition language used to define
the contents of a conceptual data store that allows networked devices the contents of a conceptual data store that allows networked devices
to be managed using NETCONF [RFC6241]. YANG is proving relevant to be managed using NETCONF [RFC6241]. YANG is proving relevant
beyond its initial confines, as bindings to other interfaces (e.g., beyond its initial confines, as bindings to other interfaces (e.g.,
ReST) and encodings other than XML (e.g., JSON) are being defined. ReST) and encodings other than XML (e.g., JSON) are being defined.
Furthermore, YANG data models can be used as the basis for Furthermore, YANG data models can be used as the basis for
implementation of other interfaces, such as CLI and programmatic implementation of other interfaces, such as CLI and programmatic
skipping to change at page 5, line 51 skipping to change at page 5, line 51
MTU mismatch checking. MTU mismatch checking.
6. lls: Support OSPF link-local signaling (LLS) [RFC5613]. 6. lls: Support OSPF link-local signaling (LLS) [RFC5613].
7. prefix-suppression: Support OSPF prefix advertisement 7. prefix-suppression: Support OSPF prefix advertisement
suppression [RFC6860]. suppression [RFC6860].
8. ttl-security: Support OSPF Time to Live (TTL) security check 8. ttl-security: Support OSPF Time to Live (TTL) security check
support [RFC5082]. support [RFC5082].
9. nsr: Support OSPF Non-Stop Routing (NSR). 9. nsr: Support OSPF Non-Stop Routing (NSR). The OSPF NSR feature
allows a router with redundant control-plane capability (e.g.,
dual Route-Processor (RP) cards) to maintain its state and
adjacencies during planned and unplanned control-plane
processing restarts. It differs from graceful-restart or Non-
Stop Forwarding (NSF) in that no protocol signaling or
assistance from adjacent OSPF neighbors is required to recover
control-plane state.
10. graceful-restart: Support Graceful OSPF Restart [RFC3623], 10. graceful-restart: Support Graceful OSPF Restart [RFC3623],
[RFC5187]. [RFC5187].
11. auto-cost: Support OSPF interface cost calculation according to 11. auto-cost: Support OSPF interface cost calculation according to
reference bandwidth [RFC2328]. reference bandwidth [RFC2328].
12. max-ecmp: Support configuration of the maximum number of Equal- 12. max-ecmp: Support configuration of the maximum number of Equal-
Cost Multi-Path (ECMP) paths. Cost Multi-Path (ECMP) paths.
skipping to change at page 7, line 31 skipping to change at page 7, line 36
the instance statistics, IETF SPF delay statistics, AS-Scoped Link the instance statistics, IETF SPF delay statistics, AS-Scoped Link
State Database, local RIB, SPF Log, and the LSA log. State Database, local RIB, SPF Log, and the LSA log.
module: ietf-ospf module: ietf-ospf
augment /rt:routing/rt:control-plane-protocols/ augment /rt:routing/rt:control-plane-protocols/
rt:control-plane-protocol: rt:control-plane-protocol:
+--rw ospf +--rw ospf
. .
. .
+--rw af iana-rt-types:address-family +--rw af iana-rt-types:address-family
+--rw enable? boolean {admin-control}? +--rw enable? boolean
+--rw explicit-router-id? rt-types:router-id +--rw explicit-router-id? rt-types:router-id
| {explicit-router-id}? | {explicit-router-id}?
+--rw preference +--rw preference
| +--rw (scope)? | +--rw (scope)?
| +--:(single-value) | +--:(single-value)
| | +--rw all? uint8 | | +--rw all? uint8
| +--:(multi-values) | +--:(multi-values)
| +--rw (granularity)? | +--rw (granularity)?
| | +--:(detail) | | +--:(detail)
| | | +--rw intra-area? uint8 | | | +--rw intra-area? uint8
skipping to change at page 13, line 4 skipping to change at page 13, line 9
| | +--rw router-id rt-types:router-id | | +--rw router-id rt-types:router-id
| | +--rw hello-interval? uint16 | | +--rw hello-interval? uint16
| | +--rw dead-interval? uint32 | | +--rw dead-interval? uint32
| | +--rw retransmit-interval? uint16 | | +--rw retransmit-interval? uint16
| | +--rw transmit-delay? uint16 | | +--rw transmit-delay? uint16
| | +--rw lls? boolean {lls}? | | +--rw lls? boolean {lls}?
| | +--rw ttl-security {ttl-security}? | | +--rw ttl-security {ttl-security}?
| | | +--rw enable? boolean | | | +--rw enable? boolean
| | | +--rw hops? uint8 | | | +--rw hops? uint8
| | +--rw enable? boolean | | +--rw enable? boolean
| | | {admin-control}?
| | +--rw authentication | | +--rw authentication
| | | +--rw (auth-type-selection)? | | | +--rw (auth-type-selection)?
| | | +--:(ospfv2-auth) | | | +--:(ospfv2-auth)
| | | | +--rw ospfv2-auth-trailer-rfc? | | | | +--rw ospfv2-auth-trailer-rfc?
| | | | | ospfv2-auth-trailer-rfc-version | | | | | ospfv2-auth-trailer-rfc-version
| | | | | {ospfv2-authentication-trailer}? | | | | | {ospfv2-authentication-trailer}?
| | | | +--rw (ospfv2-auth-specification)? | | | | +--rw (ospfv2-auth-specification)?
| | | | +--:(auth-key-chain) {key-chain}? | | | | +--:(auth-key-chain) {key-chain}?
| | | | | +--rw ospfv2-key-chain? | | | | | +--rw ospfv2-key-chain?
| | | | | key-chain:key-chain-ref | | | | | key-chain:key-chain-ref
skipping to change at page 14, line 39 skipping to change at page 14, line 43
| | +--rw remote-id inet:ip-address | | +--rw remote-id inet:ip-address
| | +--rw hello-interval? uint16 | | +--rw hello-interval? uint16
| | +--rw dead-interval? uint32 | | +--rw dead-interval? uint32
| | +--rw retransmit-interval? uint16 | | +--rw retransmit-interval? uint16
| | +--rw transmit-delay? uint16 | | +--rw transmit-delay? uint16
| | +--rw lls? boolean {lls}? | | +--rw lls? boolean {lls}?
| | +--rw ttl-security {ttl-security}? | | +--rw ttl-security {ttl-security}?
| | | +--rw enable? boolean | | | +--rw enable? boolean
| | | +--rw hops? uint8 | | | +--rw hops? uint8
| | +--rw enable? boolean | | +--rw enable? boolean
| | | {admin-control}?
| | +--rw authentication | | +--rw authentication
| | | +--rw (auth-type-selection)? | | | +--rw (auth-type-selection)?
| | | +--:(ospfv2-auth) | | | +--:(ospfv2-auth)
| | | | +--rw ospfv2-auth-trailer-rfc? | | | | +--rw ospfv2-auth-trailer-rfc?
| | | | | ospfv2-auth-trailer-rfc-version | | | | | ospfv2-auth-trailer-rfc-version
| | | | | {ospfv2-authentication-trailer}? | | | | | {ospfv2-authentication-trailer}?
| | | | +--rw (ospfv2-auth-specification)? | | | | +--rw (ospfv2-auth-specification)?
| | | | +--:(auth-key-chain) {key-chain}? | | | | +--:(auth-key-chain) {key-chain}?
| | | | | +--rw ospfv2-key-chain? | | | | | +--rw ospfv2-key-chain?
| | | | | key-chain:key-chain-ref | | | | | key-chain:key-chain-ref
skipping to change at page 17, line 27 skipping to change at page 17, line 30
| | +--rw enable? boolean | | +--rw enable? boolean
| +--rw hello-interval? uint16 | +--rw hello-interval? uint16
| +--rw dead-interval? uint32 | +--rw dead-interval? uint32
| +--rw retransmit-interval? uint16 | +--rw retransmit-interval? uint16
| +--rw transmit-delay? uint16 | +--rw transmit-delay? uint16
| +--rw lls? boolean {lls}? | +--rw lls? boolean {lls}?
| +--rw ttl-security {ttl-security}? | +--rw ttl-security {ttl-security}?
| | +--rw enable? boolean | | +--rw enable? boolean
| | +--rw hops? uint8 | | +--rw hops? uint8
| +--rw enable? boolean | +--rw enable? boolean
| {admin-control}?
| +--rw authentication | +--rw authentication
| | +--rw (auth-type-selection)? | | +--rw (auth-type-selection)?
| | +--:(ospfv2-auth) | | +--:(ospfv2-auth)
| | | +--rw ospfv2-auth-trailer-rfc? | | | +--rw ospfv2-auth-trailer-rfc?
| | | | ospfv2-auth-trailer-rfc-version | | | | ospfv2-auth-trailer-rfc-version
| | | | {ospfv2-authentication-trailer}? | | | | {ospfv2-authentication-trailer}?
| | | +--rw (ospfv2-auth-specification)? | | | +--rw (ospfv2-auth-specification)?
| | | +--:(auth-key-chain) {key-chain}? | | | +--:(auth-key-chain) {key-chain}?
| | | | +--rw ospfv2-key-chain? | | | | +--rw ospfv2-key-chain?
| | | | key-chain:key-chain-ref | | | | key-chain:key-chain-ref
skipping to change at page 23, line 28 skipping to change at page 23, line 35
-> /rt:routing/control-plane-protocols/ -> /rt:routing/control-plane-protocols/
control-plane-protocol/name control-plane-protocol/name
3. OSPF YANG Module 3. OSPF YANG Module
The following RFCs and drafts are not referenced in the document text The following RFCs and drafts are not referenced in the document text
but are referenced in the ietf-ospf.yang module: [RFC0905], but are referenced in the ietf-ospf.yang module: [RFC0905],
[RFC4576], [RFC4973], [RFC5250], [RFC5309], [RFC5642], [RFC5881], [RFC4576], [RFC4973], [RFC5250], [RFC5309], [RFC5642], [RFC5881],
[RFC6991], [RFC7770], [RFC8294], and [RFC8476]. [RFC6991], [RFC7770], [RFC8294], and [RFC8476].
<CODE BEGINS> file "ietf-ospf@2019-06-22.yang" <CODE BEGINS> file "ietf-ospf@2019-07-01.yang"
module ietf-ospf { module ietf-ospf {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ospf"; namespace "urn:ietf:params:xml:ns:yang:ietf-ospf";
prefix ospf; prefix ospf;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
reference "RFC 6991 - Common YANG Data Types"; reference "RFC 6991 - Common YANG Data Types";
} }
skipping to change at page 24, line 45 skipping to change at page 25, line 4
contact contact
"WG Web: <http://datatracker.ietf.org/group/lsr/> "WG Web: <http://datatracker.ietf.org/group/lsr/>
WG List: <mailto:lsr@ietf.org> WG List: <mailto:lsr@ietf.org>
Editor: Derek Yeung Editor: Derek Yeung
<mailto:derek@arrcus.com> <mailto:derek@arrcus.com>
Author: Acee Lindem Author: Acee Lindem
<mailto:acee@cisco.com> <mailto:acee@cisco.com>
Author: Yingzhen Qu Author: Yingzhen Qu
<mailto:yingzhen.qu@huawei.com> <mailto:yingzhen.qu@huawei.com>
Author: Jeffrey Zhang Author: Jeffrey Zhang
<mailto:zzhang@juniper.net> <mailto:zzhang@juniper.net>
Author: Ing-Wher Chen Author: Ing-Wher Chen
<mailto:ingwherchen@mitre.org>"; <mailto:ingwherchen@mitre.org>";
description description
"This YANG module defines the generic configuration and "This YANG module defines the generic configuration and
operational state for the OSPF protocol common to all operational state for the OSPF protocol common to all
vendor implementations. It is intended that the module vendor implementations. It is intended that the module
will be extended by vendors to define vendor-specific will be extended by vendors to define vendor-specific
OSPF configuration parameters and policies, OSPF configuration parameters and policies,
for example, route maps or route policies. for example, route maps or route policies.
This YANG model conforms to the Network Management This YANG model conforms to the Network Management
Datastore Architecture (NDMA) as described in RFC 8242. Datastore Architecture (NDMA) as described in RFC 8242.
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2018 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
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; This version of this YANG module is part of RFC XXXX
see the RFC itself for full legal notices."; (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
revision 2019-06-22 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices.";
revision 2019-07-01 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for OSPF."; "RFC XXXX: A YANG Data Model for OSPF.";
} }
feature multi-topology { feature multi-topology {
description description
"Support Multiple-Topology Routing (MTR)."; "Support Multiple-Topology Routing (MTR).";
reference "RFC 4915 - Multi-Topology Routing"; reference "RFC 4915 - Multi-Topology Routing";
skipping to change at page 26, line 41 skipping to change at page 27, line 9
feature ttl-security { feature ttl-security {
description description
"OSPF Time to Live (TTL) security check support."; "OSPF Time to Live (TTL) security check support.";
reference "RFC 5082 - The Generalized TTL Security reference "RFC 5082 - The Generalized TTL Security
Mechanism (GTSM)"; Mechanism (GTSM)";
} }
feature nsr { feature nsr {
description description
"Non-Stop-Routing (NSR) support."; "Non-Stop-Routing (NSR) support. The OSPF NSR feature
allows a router with redundant control-plane capability
(e.g., dual Route-Processor (RP) cards) to maintain its
state and adjacencies during planned and unplanned
OSPF instance restarts. It differs from graceful-restart
or Non-Stop Forwarding (NSF) in that no protocol signaling
or assistance from adjacent OSPF neighbors is required to
recover control-plane state.";
} }
feature graceful-restart { feature graceful-restart {
description description
"Graceful OSPF Restart as defined in RFC 3623 and "Graceful OSPF Restart as defined in RFC 3623 and
RFC 5187."; RFC 5187.";
reference "RFC 3623 - Graceful OSPF Restart reference "RFC 3623 - Graceful OSPF Restart
RFC 5187 - OSPFv3 Graceful Restart"; RFC 5187 - OSPFv3 Graceful Restart";
} }
skipping to change at page 36, line 26 skipping to change at page 36, line 49
enum point-to-point { enum point-to-point {
value "4"; value "4";
description description
"Interface point-to-point state."; "Interface point-to-point state.";
} }
enum dr { enum dr {
value "5"; value "5";
description description
"Interface Designated Router (DR) state."; "Interface Designated Router (DR) state.";
} }
enum backup { enum bdr {
value "6"; value "6";
description description
"Interface Backup Designated Router (BDR) state."; "Interface Backup Designated Router (BDR) state.";
} }
enum dr-other { enum dr-other {
value "7"; value "7";
description description
"Interface Other Designated Router state."; "Interface Other Designated Router state.";
} }
} }
description description
"OSPF interface state type."; "OSPF interface state type.";
} }
skipping to change at page 64, line 17 skipping to change at page 64, line 40
} }
container body { container body {
description description
"Decoded OSPF LSA body data."; "Decoded OSPF LSA body data.";
uses ospfv3-lsa-body; uses ospfv3-lsa-body;
} }
} }
grouping lsa-common { grouping lsa-common {
description description
"Common fields for OSPF LSA representation."; "Common fields for OSPF LSA representation.";
leaf decoded-completed { leaf decode-completed {
type boolean; type boolean;
description description
"The OSPF LSA body is fully decoded."; "The OSPF LSA body was successfully decoded other than
unknown TLVs. Unknown LSAs types and OSPFv2 unknown
opaque LSA types are not decoded. Additionally,
malformed LSAs are generally not accepted and are
not be in the Link State Database.";
} }
leaf raw-data { leaf raw-data {
type yang:hex-string; type yang:hex-string;
description description
"The complete LSA in network byte "The complete LSA in network byte
order hexadecimal as received or originated."; order hexadecimal as received or originated.";
} }
} }
grouping lsa { grouping lsa {
skipping to change at page 68, line 39 skipping to change at page 69, line 19
if-feature lfa; if-feature lfa;
description description
"This container may be augmented with "This container may be augmented with
global parameters for Loop-Free Alternatives (LFA). global parameters for Loop-Free Alternatives (LFA).
Container creation has no effect on LFA activation."; Container creation has no effect on LFA activation.";
} }
} }
} }
grouping instance-fast-reroute-state { grouping instance-fast-reroute-state {
description "IPFRR state data grouping"; description "IP-FRR state data grouping";
container protected-routes { container protected-routes {
if-feature fast-reroute; if-feature fast-reroute;
config false; config false;
description "Instance protection statistics"; description "Instance protection statistics";
list address-family-stats { list address-family-stats {
key "address-family prefix alternate"; key "address-family prefix alternate";
description description
"Per Address Family protected prefix information"; "Per Address Family protected prefix information";
skipping to change at page 74, line 19 skipping to change at page 74, line 48
metric."; metric.";
} }
} }
grouping interface-common-config { grouping interface-common-config {
description description
"Common configuration for all types of interfaces, "Common configuration for all types of interfaces,
including virtual links and sham links."; including virtual links and sham links.";
leaf hello-interval { leaf hello-interval {
type rt-types:timer-value-seconds16; type uint16;
units seconds;
description description
"Interval between hello packets (seconds). It must "Interval between hello packets (seconds). It must
be the same for all routers on the same network. be the same for all routers on the same network.
Different networks, implementations, and deployments Different networks, implementations, and deployments
will use different hello-intervals. A sample value will use different hello-intervals. A sample value
for a LAN network would be 10 seconds."; for a LAN network would be 10 seconds.";
} }
leaf dead-interval { leaf dead-interval {
type rt-types:timer-value-seconds32; type uint16;
units seconds;
must "../dead-interval > ../hello-interval" { must "../dead-interval > ../hello-interval" {
error-message "The dead interval must be " error-message "The dead interval must be "
+ "larger than the hello interval"; + "larger than the hello interval";
description description
"The value MUST be greater than 'hello-interval'."; "The value MUST be greater than 'hello-interval'.";
} }
description description
"Interval after which a neighbor is declared down "Interval after which a neighbor is declared down
(seconds) if hello packets are not received. It is (seconds) if hello packets are not received. It is
typically 3 or 4 times the hello-interval. A typical typically 3 or 4 times the hello-interval. A typical
skipping to change at page 75, line 9 skipping to change at page 75, line 40
units seconds; units seconds;
description description
"Interval between retransmitting unacknowledged Link "Interval between retransmitting unacknowledged Link
State Advertisements (LSAs) (seconds). This should State Advertisements (LSAs) (seconds). This should
be well over the round-trip transmit delay for be well over the round-trip transmit delay for
any two routers on the network. A sample value any two routers on the network. A sample value
would be 5 seconds."; would be 5 seconds.";
} }
leaf transmit-delay { leaf transmit-delay {
type rt-types:timer-value-seconds16; type uint16;
units seconds;
description description
"Estimated time needed to transmit Link State Update "Estimated time needed to transmit Link State Update
(LSU) packets on the interface (seconds). LSAs have (LSU) packets on the interface (seconds). LSAs have
their age incremented by this amount on advertised their age incremented by this amount on advertised
on the interface. A sample value would be 1 second."; on the interface. A sample value would be 1 second.";
} }
leaf lls { leaf lls {
if-feature lls; if-feature lls;
type boolean; type boolean;
skipping to change at page 76, line 40 skipping to change at page 77, line 24
leaf ospfv2-key-id { leaf ospfv2-key-id {
type uint32; type uint32;
description description
"Key Identifier"; "Key Identifier";
} }
leaf ospfv2-key { leaf ospfv2-key {
type string; type string;
description description
"OSPFv2 authentication key. The "OSPFv2 authentication key. The
length of the key may be dependent on the length of the key may be dependent on the
cryptographic algorithm. In cases where it is cryptographic algorithm.";
not, a key length of at least 32 octets should
be supported to allow for interoperability
with strong keys.";
} }
leaf ospfv2-crypto-algorithm { leaf ospfv2-crypto-algorithm {
type identityref { type identityref {
base key-chain:crypto-algorithm; base key-chain:crypto-algorithm;
} }
description description
"Cryptographic algorithm associated with key."; "Cryptographic algorithm associated with key.";
} }
} }
} }
} }
case ospfv3-auth-ipsec { case ospfv3-auth-ipsec {
when "derived-from-or-self(../../../../../../rt:type, " when "derived-from-or-self(../../../../../../rt:type, "
+ "'ospf:ospfv3')" { + "'ospf:ospfv3')" {
description "Applied to OSPFv3 only."; description "Applied to OSPFv3 only.";
} }
if-feature ospfv3-authentication-ipsec; if-feature ospfv3-authentication-ipsec;
leaf sa { leaf sa {
skipping to change at page 77, line 46 skipping to change at page 78, line 27
} }
case auth-key-explicit { case auth-key-explicit {
leaf ospfv3-sa-id { leaf ospfv3-sa-id {
type uint16; type uint16;
description description
"Security Association (SA) Identifier"; "Security Association (SA) Identifier";
} }
leaf ospfv3-key { leaf ospfv3-key {
type string; type string;
description description
"OSPFv2 authentication key. The "OSPFv3 authentication key. The
length of the key may be dependent on the length of the key may be dependent on the
cryptographic algorithm. In cases where it is cryptographic algorithm.";
not, a key length of at least 32 octets should
be supported to allow for interoperability
with strong keys.";
} }
leaf ospfv3-crypto-algorithm { leaf ospfv3-crypto-algorithm {
type identityref { type identityref {
base key-chain:crypto-algorithm; base key-chain:crypto-algorithm;
} }
description description
"Cryptographic algorithm associated with key."; "Cryptographic algorithm associated with key.";
} }
} }
} }
skipping to change at page 80, line 24 skipping to change at page 80, line 49
type uint16 { type uint16 {
range "1..65535"; range "1..65535";
} }
description description
"Neighbor cost. Different implementations have different "Neighbor cost. Different implementations have different
default costs with some defaulting to a cost inversely default costs with some defaulting to a cost inversely
proportional to the interface speed. Others will proportional to the interface speed. Others will
default to 1 equating the cost to a hop count." ; default to 1 equating the cost to a hop count." ;
} }
leaf poll-interval { leaf poll-interval {
type rt-types:timer-value-seconds16; type uint16;
units seconds;
description description
"Neighbor poll interval (seconds) for sending OSPF "Neighbor poll interval (seconds) for sending OSPF
hello packets to discover the neighbor on NBMA hello packets to discover the neighbor on NBMA
networks. This interval dictates the granularity for networks. This interval dictates the granularity for
discovery of new neighbors. A sample would be 2 minutes discovery of new neighbors. A sample would be 2 minutes
for a legacy Packet Data Network (PDN) X.25 network."; for a legacy Packet Data Network (PDN) X.25 network.";
} }
leaf priority { leaf priority {
type uint8 { type uint8;
range "1..255";
}
description "Neighbor priority for DR election."; description "Neighbor priority for DR election.";
} }
} }
} }
leaf node-flag { leaf node-flag {
if-feature node-flag; if-feature node-flag;
type boolean; type boolean;
default false; default false;
description description
skipping to change at page 82, line 17 skipping to change at page 82, line 41
description description
"OSPF neighbor state."; "OSPF neighbor state.";
} }
leaf cost { leaf cost {
type uint32; type uint32;
config false; config false;
description "Cost to reach neighbor for Point-to-Multipoint description "Cost to reach neighbor for Point-to-Multipoint
and Hybrid networks"; and Hybrid networks";
} }
leaf dead-timer { leaf dead-timer {
type rt-types:timer-value-seconds32; type rt-types:timer-value-seconds16;
config false; config false;
description "This timer tracks the remaining time before description "This timer tracks the remaining time before
the neighbor is declared dead."; the neighbor is declared dead.";
} }
container statistics { container statistics {
config false; config false;
description "Per-neighbor statistics"; description "Per-neighbor statistics";
uses neighbor-stat; uses neighbor-stat;
} }
} }
skipping to change at page 89, line 22 skipping to change at page 89, line 43
leaf route-tag { leaf route-tag {
type uint32; type uint32;
description "Route tag for this route."; description "Route tag for this route.";
} }
} }
} }
} }
grouping ietf-spf-delay { grouping ietf-spf-delay {
leaf initial-delay { leaf initial-delay {
type rt-types:timer-value-milliseconds; type uint32;
units milliseconds;
description description
"Delay used while in QUIET state (milliseconds)."; "Delay used while in QUIET state (milliseconds).";
} }
leaf short-delay { leaf short-delay {
type rt-types:timer-value-milliseconds; type uint32;
units milliseconds;
description description
"Delay used while in SHORT_WAIT state (milliseconds)."; "Delay used while in SHORT_WAIT state (milliseconds).";
} }
leaf long-delay { leaf long-delay {
type rt-types:timer-value-milliseconds; type uint32;
units milliseconds;
description description
"Delay used while in LONG_WAIT state (milliseconds)."; "Delay used while in LONG_WAIT state (milliseconds).";
} }
leaf hold-down { leaf hold-down {
type rt-types:timer-value-milliseconds; type uint32;
units milliseconds;
description description
"Timer used to consider an IGP stability period "Timer used to consider an IGP stability period
(milliseconds)."; (milliseconds).";
} }
leaf time-to-learn { leaf time-to-learn {
type rt-types:timer-value-milliseconds; type uint32;
units milliseconds;
description description
"Duration used to learn all the IGP events "Duration used to learn all the IGP events
related to a single component failure (milliseconds)."; related to a single component failure (milliseconds).";
} }
leaf current-state { leaf current-state {
type enumeration { type enumeration {
enum "quiet" { enum "quiet" {
description "QUIET state"; description "QUIET state";
} }
enum "short-wait" { enum "short-wait" {
description "SHORT_WAIT state"; description "SHORT_WAIT state";
} }
enum "long-wait" { enum "long-wait" {
description "LONG_WAIT state"; description "LONG_WAIT state";
} }
} }
config false; config false;
description description
skipping to change at page 90, line 18 skipping to change at page 90, line 43
} }
enum "long-wait" { enum "long-wait" {
description "LONG_WAIT state"; description "LONG_WAIT state";
} }
} }
config false; config false;
description description
"Current SPF back-off algorithm state."; "Current SPF back-off algorithm state.";
} }
leaf remaining-time-to-learn { leaf remaining-time-to-learn {
type rt-types:timer-value-seconds16; type rt-types:timer-value-milliseconds;
config false; config false;
description description
"Remaining time until time-to-learn timer fires."; "Remaining time until time-to-learn timer fires.";
} }
leaf remaining-hold-down { leaf remaining-hold-down {
type rt-types:timer-value-seconds16; type rt-types:timer-value-milliseconds;
config false; config false;
description description
"Remaining time until hold-down timer fires."; "Remaining time until hold-down timer fires.";
} }
leaf last-event-received { leaf last-event-received {
type yang:timestamp; type yang:timestamp;
config false; config false;
description description
"Time of last SPF triggering event."; "Time of last SPF triggering event.";
} }
skipping to change at page 91, line 42 skipping to change at page 92, line 21
leaf explicit-router-id { leaf explicit-router-id {
if-feature explicit-router-id; if-feature explicit-router-id;
type rt-types:router-id; type rt-types:router-id;
description description
"Defined in RFC 2328. A 32-bit number "Defined in RFC 2328. A 32-bit number
that uniquely identifies the router."; that uniquely identifies the router.";
} }
container preference { container preference {
description "Route preference config state."; description
"Route preference configuration In many
implementations, preference is referred to as
administrative distance.";
reference
"RFC 8349 - A YANG Data Model for Routing Management
(NMDA Version)";
choice scope { choice scope {
description description
"Options for expressing preference "Options for expressing preference
as single or multiple values."; as single or multiple values.";
case single-value { case single-value {
leaf all { leaf all {
type uint8; type uint8;
description description
"Preference for intra-area, inter-area, and "Preference for intra-area, inter-area, and
external routes."; external routes.";
skipping to change at page 95, line 12 skipping to change at page 95, line 45
choice trigger { choice trigger {
description description
"Specific triggers which will enable stub "Specific triggers which will enable stub
router state."; router state.";
container always { container always {
presence presence
"Enables unconditional stub router support"; "Enables unconditional stub router support";
description description
"Unconditional stub router state (advertise "Unconditional stub router state (advertise
transit links with max metric"; transit links with MaxLinkMetric";
reference "RFC 6987 - OSPF Stub Router
Advertisement";
} }
} }
} }
container mpls { container mpls {
description description
"OSPF MPLS config state."; "OSPF MPLS config state.";
container te-rid { container te-rid {
if-feature te-rid; if-feature te-rid;
description description
"Stable OSPF Router IP Address used for Traffic "Stable OSPF Router IP Address used for Traffic
Engineering (TE)"; Engineering (TE)";
leaf ipv4-router-id { leaf ipv4-router-id {
type inet:ipv4-address; type inet:ipv4-address;
skipping to change at page 112, line 47 skipping to change at page 113, line 33
uses notification-instance-hdr; uses notification-instance-hdr;
uses notification-interface; uses notification-interface;
uses notification-neighbor; uses notification-neighbor;
leaf status { leaf status {
type restart-helper-status-type; type restart-helper-status-type;
description "Restart helper status."; description "Restart helper status.";
} }
leaf age { leaf age {
type rt-types:timer-value-seconds32; type rt-types:timer-value-seconds16;
description description
"Remaining time in current OSPF graceful restart "Remaining time in current OSPF graceful restart
interval when the router is acting as a restart interval when the router is acting as a restart
helper for the neighbor."; helper for the neighbor.";
} }
leaf exit-reason { leaf exit-reason {
type restart-exit-reason-type; type restart-exit-reason-type;
description description
"Restart helper exit reason."; "Restart helper exit reason.";
} }
description description
"This notification is sent when a neighbor restart "This notification is sent when a neighbor restart
helper status change is detected."; helper status change is detected.";
skipping to change at page 115, line 46 skipping to change at page 116, line 32
operations and content. operations and content.
There are a number of data nodes defined in ietf-ospf.yang module There are a number of data nodes defined in ietf-ospf.yang module
that are writable/creatable/deletable (i.e., config true, which is that are writable/creatable/deletable (i.e., config true, which is
the default). These data nodes may be considered sensitive or the default). These data nodes may be considered sensitive or
vulnerable in some network environments. Write operations (e.g., vulnerable in some network environments. Write operations (e.g.,
edit-config) to these data nodes without proper protection can have a edit-config) to these data nodes without proper protection can have a
negative effect on network operations. For OSPF, the ability to negative effect on network operations. For OSPF, the ability to
modify OSPF configuration will allow the entire OSPF domain to be modify OSPF configuration will allow the entire OSPF domain to be
compromised including peering with unauthorized routers to misroute compromised including peering with unauthorized routers to misroute
traffic or mount a massive Denial-of-Service (DoS) attack. The traffic or mount a massive Denial-of-Service (DoS) attack.
security considerations of OSPFv2 [RFC2328] and [RFC5340] apply to
the ietf-ospf.yang module as well.
Some of the readable data nodes in the ietf-ospf.yang module may be Some of the readable data nodes in the ietf-ospf.yang module may be
considered sensitive or vulnerable in some network environments. It considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config, is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. The exposure of the Link State or notification) to these data nodes. The exposure of the Link State
Database (LSDB) will expose the detailed topology of the network. Database (LSDB) will expose the detailed topology of the network.
This may be undesirable since both due to the fact that exposure may This may be undesirable since both due to the fact that exposure may
facilitate other attacks. Additionally, network operators may facilitate other attacks. Additionally, network operators may
consider their topologies to be sensitive confidential data. consider their topologies to be sensitive confidential data.
For OSPF authentication, configuration is supported via the For OSPF authentication, configuration is supported via the
specification of key-chains [RFC8177] or the direct specification of specification of key-chains [RFC8177] or the direct specification of
key and authentication algorithm. Hence, authentication key and authentication algorithm. Hence, authentication
configuration using the "auth-table-trailer" case in the configuration using the "auth-table-trailer" case in the
"authentication" container inherits the security considerations of "authentication" container inherits the security considerations of
[RFC8177]. This includes the considerations with respect to the [RFC8177]. This includes the considerations with respect to the
local storage and handling of authentication keys. local storage and handling of authentication keys.
Additionally, local specificationn of OSPF authentication keys and
the associated authentication algorithm is supported for legacy
implementations that do not support key-chains [RFC8177] for legacy
implementations that do not support key-chains. It is RECOMMENDED
that implementations migrate to key-chains due the seamless support
of key and algorithm rollover, as well as, the encryption of key
using the Advanced Encryption Standard (AES) Key Wrap Padding
Algorithm [RFC5649].
Some of the RPC operations in this YANG module may be considered Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. The OSPF YANG important to control access to these operations. The OSPF YANG
module support the "clear-neighbor" and "clear-database" RPCs. If module support the "clear-neighbor" and "clear-database" RPCs. If
access to either of these is compromised, they can result in access to either of these is compromised, they can result in
temporary network outages be employed to mount DoS attacks. temporary network outages be employed to mount DoS attacks.
5. IANA Considerations 5. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. This document registers a URI in the IETF XML registry [RFC3688].
skipping to change at page 117, line 26 skipping to change at page 118, line 18
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-bfd-yang] [I-D.ietf-bfd-yang]
Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and
G. Mirsky, "YANG Data Model for Bidirectional Forwarding G. Mirsky, "YANG Data Model for Bidirectional Forwarding
Detection (BFD)", draft-ietf-bfd-yang-17 (work in Detection (BFD)", draft-ietf-bfd-yang-17 (work in
progress), August 2018. progress), August 2018.
[RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765,
DOI 10.17487/RFC1765, March 1995,
<https://www.rfc-editor.org/info/rfc1765>.
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits",
RFC 1793, DOI 10.17487/RFC1793, April 1995, RFC 1793, DOI 10.17487/RFC1793, April 1995,
<https://www.rfc-editor.org/info/rfc1793>. <https://www.rfc-editor.org/info/rfc1793>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, <https://www.rfc- DOI 10.17487/RFC2328, April 1998,
editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, DOI 10.17487/RFC3101, January 2003, RFC 3101, DOI 10.17487/RFC3101, January 2003,
<https://www.rfc-editor.org/info/rfc3101>. <https://www.rfc-editor.org/info/rfc3101>.
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
Restart", RFC 3623, DOI 10.17487/RFC3623, November 2003, Restart", RFC 3623, DOI 10.17487/RFC3623, November 2003,
<https://www.rfc-editor.org/info/rfc3623>. <https://www.rfc-editor.org/info/rfc3623>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, <https://www.rfc- DOI 10.17487/RFC3630, September 2003,
editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004,
editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>. <https://www.rfc-editor.org/info/rfc4552>.
[RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a
Link State Advertisement (LSA) Options Bit to Prevent Link State Advertisement (LSA) Options Bit to Prevent
Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", Looping in BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 4576, DOI 10.17487/RFC4576, June 2006, RFC 4576, DOI 10.17487/RFC4576, June 2006,
<https://www.rfc-editor.org/info/rfc4576>. <https://www.rfc-editor.org/info/rfc4576>.
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
June 2006, <https://www.rfc-editor.org/info/rfc4577>. June 2006, <https://www.rfc-editor.org/info/rfc4577>.
[RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed.,
Coltun, R., and F. Baker, "OSPF Version 2 Management
Information Base", RFC 4750, DOI 10.17487/RFC4750,
December 2006, <https://www.rfc-editor.org/info/rfc4750>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007, RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>. <https://www.rfc-editor.org/info/rfc4915>.
[RFC4973] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental
Extension to OSPF for Traffic Engineering", RFC 4973,
DOI 10.17487/RFC4973, July 2007,
<https://www.rfc-editor.org/info/rfc4973>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>. <https://www.rfc-editor.org/info/rfc5082>.
[RFC5185] Mirtorabi, S., Psenak, P., Lindem, A., Ed., and A. Oswal, [RFC5185] Mirtorabi, S., Psenak, P., Lindem, A., Ed., and A. Oswal,
"OSPF Multi-Area Adjacency", RFC 5185, "OSPF Multi-Area Adjacency", RFC 5185,
DOI 10.17487/RFC5185, May 2008, <https://www.rfc- DOI 10.17487/RFC5185, May 2008,
editor.org/info/rfc5185>. <https://www.rfc-editor.org/info/rfc5185>.
[RFC5187] Pillay-Esnault, P. and A. Lindem, "OSPFv3 Graceful [RFC5187] Pillay-Esnault, P. and A. Lindem, "OSPFv3 Graceful
Restart", RFC 5187, DOI 10.17487/RFC5187, June 2008, Restart", RFC 5187, DOI 10.17487/RFC5187, June 2008,
<https://www.rfc-editor.org/info/rfc5187>. <https://www.rfc-editor.org/info/rfc5187>.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <https://www.rfc-editor.org/info/rfc5250>. July 2008, <https://www.rfc-editor.org/info/rfc5250>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, <https://www.rfc- DOI 10.17487/RFC5286, September 2008,
editor.org/info/rfc5286>. <https://www.rfc-editor.org/info/rfc5286>.
[RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation
over LAN in Link State Routing Protocols", RFC 5309,
DOI 10.17487/RFC5309, October 2008,
<https://www.rfc-editor.org/info/rfc5309>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3", "Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008, RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>. <https://www.rfc-editor.org/info/rfc5329>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613, Yeung, "OSPF Link-Local Signaling", RFC 5613,
DOI 10.17487/RFC5613, August 2009, <https://www.rfc- DOI 10.17487/RFC5613, August 2009,
editor.org/info/rfc5613>. <https://www.rfc-editor.org/info/rfc5613>.
[RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, [RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson,
"Dynamic Hostname Exchange Mechanism for OSPF", RFC 5642, "Dynamic Hostname Exchange Mechanism for OSPF", RFC 5642,
DOI 10.17487/RFC5642, August 2009, <https://www.rfc- DOI 10.17487/RFC5642, August 2009,
editor.org/info/rfc5642>. <https://www.rfc-editor.org/info/rfc5642>.
[RFC5643] Joyal, D., Ed. and V. Manral, Ed., "Management Information
Base for OSPFv3", RFC 5643, DOI 10.17487/RFC5643, August
2009, <https://www.rfc-editor.org/info/rfc5643>.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, DOI 10.17487/RFC5709, October Authentication", RFC 5709, DOI 10.17487/RFC5709, October
2009, <https://www.rfc-editor.org/info/rfc5709>. 2009, <https://www.rfc-editor.org/info/rfc5709>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>.
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
R. Aggarwal, "Support of Address Families in OSPFv3", R. Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, DOI 10.17487/RFC5838, April 2010, RFC 5838, DOI 10.17487/RFC5838, April 2010,
<https://www.rfc-editor.org/info/rfc5838>. <https://www.rfc-editor.org/info/rfc5838>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010, <https://www.rfc-
editor.org/info/rfc5881>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, <https://www.rfc- DOI 10.17487/RFC6020, October 2010,
editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[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>.
[RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and
M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge
(PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565,
June 2012, <https://www.rfc-editor.org/info/rfc6565>. June 2012, <https://www.rfc-editor.org/info/rfc6565>.
[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast
and Point-to-Multipoint Interface Type", RFC 6845, and Point-to-Multipoint Interface Type", RFC 6845,
DOI 10.17487/RFC6845, January 2013, <https://www.rfc- DOI 10.17487/RFC6845, January 2013,
editor.org/info/rfc6845>. <https://www.rfc-editor.org/info/rfc6845>.
[RFC6860] Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only [RFC6860] Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only
Networks in OSPF", RFC 6860, DOI 10.17487/RFC6860, January Networks in OSPF", RFC 6860, DOI 10.17487/RFC6860, January
2013, <https://www.rfc-editor.org/info/rfc6860>. 2013, <https://www.rfc-editor.org/info/rfc6860>.
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 6987,
DOI 10.17487/RFC6987, September 2013,
<https://www.rfc-editor.org/info/rfc6987>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166, Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014, <https://www.rfc- DOI 10.17487/RFC7166, March 2014,
editor.org/info/rfc7166>. <https://www.rfc-editor.org/info/rfc7166>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key "Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<https://www.rfc-editor.org/info/rfc7474>. <https://www.rfc-editor.org/info/rfc7474>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015, RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>. <https://www.rfc-editor.org/info/rfc7490>.
skipping to change at page 121, line 38 skipping to change at page 122, line 33
[RFC8042] Zhang, Z., Wang, L., and A. Lindem, "OSPF Two-Part [RFC8042] Zhang, Z., Wang, L., and A. Lindem, "OSPF Two-Part
Metric", RFC 8042, DOI 10.17487/RFC8042, December 2016, Metric", RFC 8042, DOI 10.17487/RFC8042, December 2016,
<https://www.rfc-editor.org/info/rfc8042>. <https://www.rfc-editor.org/info/rfc8042>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
Zhang, "YANG Data Model for Key Chains", RFC 8177, Zhang, "YANG Data Model for Key Chains", RFC 8177,
DOI 10.17487/RFC8177, June 2017, <https://www.rfc- DOI 10.17487/RFC8177, June 2017,
editor.org/info/rfc8177>. <https://www.rfc-editor.org/info/rfc8177>.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294, "Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017, <https://www.rfc- DOI 10.17487/RFC8294, December 2017,
editor.org/info/rfc8294>. <https://www.rfc-editor.org/info/rfc8294>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, <https://www.rfc- DOI 10.17487/RFC8341, March 2018,
editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>. <https://www.rfc-editor.org/info/rfc8343>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349, Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018, <https://www.rfc- DOI 10.17487/RFC8349, March 2018,
editor.org/info/rfc8349>. <https://www.rfc-editor.org/info/rfc8349>.
[RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., [RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A.,
Francois, P., and C. Bowers, "Shortest Path First (SPF) Francois, P., and C. Bowers, "Shortest Path First (SPF)
Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, Back-Off Delay Algorithm for Link-State IGPs", RFC 8405,
DOI 10.17487/RFC8405, June 2018, <https://www.rfc- DOI 10.17487/RFC8405, June 2018,
editor.org/info/rfc8405>. <https://www.rfc-editor.org/info/rfc8405>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,
"Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476,
DOI 10.17487/RFC8476, December 2018, <https://www.rfc- DOI 10.17487/RFC8476, December 2018,
editor.org/info/rfc8476>. <https://www.rfc-editor.org/info/rfc8476>.
7.2. Informative References 7.2. Informative References
[RFC0905] "ISO Transport Protocol specification ISO DP 8073", [RFC0905] "ISO Transport Protocol specification ISO DP 8073",
RFC 905, DOI 10.17487/RFC0905, April 1984, RFC 905, DOI 10.17487/RFC0905, April 1984,
<https://www.rfc-editor.org/info/rfc905>. <https://www.rfc-editor.org/info/rfc905>.
[RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765, [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed.,
DOI 10.17487/RFC1765, March 1995, <https://www.rfc- Coltun, R., and F. Baker, "OSPF Version 2 Management
editor.org/info/rfc1765>. Information Base", RFC 4750, DOI 10.17487/RFC4750,
December 2006, <https://www.rfc-editor.org/info/rfc4750>.
[RFC4973] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental
Extension to OSPF for Traffic Engineering", RFC 4973,
DOI 10.17487/RFC4973, July 2007, <https://www.rfc-
editor.org/info/rfc4973>.
[RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation
over LAN in Link State Routing Protocols", RFC 5309,
DOI 10.17487/RFC5309, October 2008, <https://www.rfc-
editor.org/info/rfc5309>.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, DOI 10.17487/RFC5443, March Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
2009, <https://www.rfc-editor.org/info/rfc5443>. 2009, <https://www.rfc-editor.org/info/rfc5443>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", [RFC5643] Joyal, D., Ed. and V. Manral, Ed., "Management Information
RFC 5714, DOI 10.17487/RFC5714, January 2010, Base for OSPFv3", RFC 5643, DOI 10.17487/RFC5643, August
<https://www.rfc-editor.org/info/rfc5714>. 2009, <https://www.rfc-editor.org/info/rfc5643>.
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
McPherson, "OSPF Stub Router Advertisement", RFC 6987, (AES) Key Wrap with Padding Algorithm", RFC 5649,
DOI 10.17487/RFC6987, September 2013, <https://www.rfc- DOI 10.17487/RFC5649, September 2009,
editor.org/info/rfc6987>. <https://www.rfc-editor.org/info/rfc5649>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>.
Appendix A. Contributors' Addresses Appendix A. Contributors' Addresses
Dean Bogdanovic Dean Bogdanovic
Volta Networks, Inc. Volta Networks, Inc.
EMail: dean@voltanet.io EMail: dean@voltanet.io
Kiran Koushik Agrahara Sreenivasa Kiran Koushik Agrahara Sreenivasa
Verizon Verizon
 End of changes. 78 change blocks. 
152 lines changed or deleted 196 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/