Internet-Draft | OSPF SR YANG Data Model | February 2023 |
Qu, et al. | Expires 28 August 2023 | [Page] |
- Workgroup:
- Internet
- Internet-Draft:
- draft-ietf-ospf-sr-yang-20
- Published:
- Intended Status:
- Standards Track
- Expires:
"OSPF SR (Segment Routing) YANG Data Model">YANG Data Model for OSPF Segment Routing
Abstract
This document defines a YANG data module that can be used to configure and manage OSPF Extensions for Segment Routing.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 August 2023.¶
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
1. Overview
YANG [RFC7950] is a data definition language used to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF [RFC6241]. YANG is proving relevant beyond its initial confines, as bindings to other interfaces (e.g., ReST) and encodings other than XML (e.g., JSON) are being defined. Furthermore, YANG data models can be used as the basis for implementation of other interfaces, such as CLI and programmatic APIs.¶
This document defines a YANG data model that can be used to configure and manage OSPFv2 extensions for Segment Routing [RFC8665] and it is an augmentation to the OSPF YANG data model.¶
The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) [RFC8342].¶
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
1.2. Tree Diagrams
This document uses the graphical representation of data models defined in [RFC8340].¶
2. OSPF Segment Routing
This document defines a model for OSPF Segment Routing feature [RFC8665]. It is an augmentation of the OSPF base model.¶
The OSPF SR YANG module requires support for the base segment routing module [RFC9020], which defines the global segment routing configuration independent of any specific routing protocol configuration, and support of OSPF base model[RFC9129] which defines basic OSPF configuration and state.¶
module: ietf-ospf-sr augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf: +--rw segment-routing | +--rw enabled? boolean | +--rw bindings {mapping-server}? | +--rw advertise | | +--rw policies* -> /rt:routing/sr:segment-routing | | /sr-mpls:sr-mpls/bindings | | /mapping-server/policy/name | +--rw receive? boolean +--rw protocol-srgb {sr-mpls:protocol-srgb}? +--rw srgb* [lower-bound upper-bound] +--rw lower-bound uint32 +--rw upper-bound uint32 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:interfaces/ospf:interface: +--rw segment-routing +--rw adjacency-sid +--rw adj-sids* [value] | +--rw value-type? enumeration | +--rw value uint32 | +--rw protected? boolean | +--rw weight? uint8 +--rw advertise-adj-group-sid* [group-id] | +--rw group-id uint32 +--rw advertise-protection? enumeration augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:interfaces/ospf:interface/ospf:fast-reroute: +--rw ti-lfa {ti-lfa}? +--rw enable? boolean augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:interfaces/ospf:interface/ospf:database /ospf:link-scope-lsa-type/ospf:link-scope-lsas /ospf:link-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2 /ospf:body/ospf:opaque/ospf:extended-prefix-opaque: +--ro extended-prefix-range-tlvs +--ro extended-prefix-range-tlv* [] +--ro prefix-length? uint8 +--ro af? uint8 +--ro range-size? uint16 +--ro extended-prefix-range-flags | +--ro bits* identityref +--ro prefix? inet:ip-prefix +--ro prefix-sid-sub-tlvs | +--ro prefix-sid-sub-tlv* [] | +--ro prefix-sid-flags | | +--ro bits* identityref | +--ro mt-id? uint8 | +--ro algorithm? uint8 | +--ro sid? uint32 +--ro unknown-tlvs +--ro unknown-tlv* [] +--ro type? uint16 +--ro length? uint16 +--ro value? yang:hex-string augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:database/ospf:area-scope-lsa-type/ospf:area-scope-lsas /ospf:area-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2 /ospf:body/ospf:opaque/ospf:extended-prefix-opaque: +--ro extended-prefix-range-tlvs +--ro extended-prefix-range-tlv* [] +--ro prefix-length? uint8 +--ro af? uint8 +--ro range-size? uint16 +--ro extended-prefix-range-flags | +--ro bits* identityref +--ro prefix? inet:ip-prefix +--ro prefix-sid-sub-tlvs | +--ro prefix-sid-sub-tlv* [] | +--ro prefix-sid-flags | | +--ro bits* identityref | +--ro mt-id? uint8 | +--ro algorithm? uint8 | +--ro sid? uint32 +--ro unknown-tlvs +--ro unknown-tlv* [] +--ro type? uint16 +--ro length? uint16 +--ro value? yang:hex-string augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:database /ospf:as-scope-lsa-type/ospf:as-scope-lsas /ospf:as-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2 /ospf:body/ospf:opaque/ospf:extended-prefix-opaque: +--ro extended-prefix-range-tlvs +--ro extended-prefix-range-tlv* [] +--ro prefix-length? uint8 +--ro af? uint8 +--ro range-size? uint16 +--ro extended-prefix-range-flags | +--ro bits* identityref +--ro prefix? inet:ip-prefix +--ro prefix-sid-sub-tlvs | +--ro prefix-sid-sub-tlv* [] | +--ro prefix-sid-flags | | +--ro bits* identityref | +--ro mt-id? uint8 | +--ro algorithm? uint8 | +--ro sid? uint32 +--ro unknown-tlvs +--ro unknown-tlv* [] +--ro type? uint16 +--ro length? uint16 +--ro value? yang:hex-string augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:interfaces/ospf:interface/ospf:database /ospf:link-scope-lsa-type/ospf:link-scope-lsas /ospf:link-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2 /ospf:body/ospf:opaque/ospf:extended-prefix-opaque /ospf:extended-prefix-tlv: +--ro prefix-sid-sub-tlvs +--ro prefix-sid-sub-tlv* [] +--ro prefix-sid-flags | +--ro bits* identityref +--ro mt-id? uint8 +--ro algorithm? uint8 +--ro sid? uint32 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:database/ospf:area-scope-lsa-type/ospf:area-scope-lsas /ospf:area-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2 /ospf:body/ospf:opaque/ospf:extended-prefix-opaque /ospf:extended-prefix-tlv: +--ro prefix-sid-sub-tlvs +--ro prefix-sid-sub-tlv* [] +--ro prefix-sid-flags | +--ro bits* identityref +--ro mt-id? uint8 +--ro algorithm? uint8 +--ro sid? uint32 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:database /ospf:as-scope-lsa-type/ospf:as-scope-lsas/ospf:as-scope-lsa /ospf:version/ospf:ospfv2/ospf:ospfv2/ospf:body/ospf:opaque /ospf:extended-prefix-opaque/ospf:extended-prefix-tlv: +--ro prefix-sid-sub-tlvs +--ro prefix-sid-sub-tlv* [] +--ro prefix-sid-flags | +--ro bits* identityref +--ro mt-id? uint8 +--ro algorithm? uint8 +--ro sid? uint32 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:database/ospf:area-scope-lsa-type/ospf:area-scope-lsas /ospf:area-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2 /ospf:body/ospf:opaque/ospf:extended-link-opaque /ospf:extended-link-tlv: +--ro adj-sid-sub-tlvs | +--ro adj-sid-sub-tlv* [] | +--ro adj-sid-flags | | +--ro bits* identityref | +--ro mt-id? uint8 | +--ro weight? uint8 | +--ro sid? uint32 +--ro lan-adj-sid-sub-tlvs +--ro lan-adj-sid-sub-tlv* [] +--ro lan-adj-sid-flags | +--ro bits* identityref +--ro mt-id? uint8 +--ro weight? uint8 +--ro neighbor-router-id? yang:dotted-quad +--ro sid? uint32 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:interfaces/ospf:interface/ospf:database /ospf:link-scope-lsa-type/ospf:link-scope-lsas /ospf:link-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2 /ospf:body/ospf:opaque/ospf:ri-opaque: +--ro sr-algorithm-tlv | +--ro sr-algorithm* uint8 +--ro sid-range-tlvs | +--ro sid-range-tlv* [] | +--ro range-size? uint24 | +--ro sid-sub-tlv | +--ro sid? uint32 +--ro local-block-tlvs | +--ro local-block-tlv* [] | +--ro range-size? uint24 | +--ro sid-sub-tlv | +--ro sid? uint32 +--ro srms-preference-tlv +--ro preference? uint8 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:database/ospf:area-scope-lsa-type/ospf:area-scope-lsas /ospf:area-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2 /ospf:body/ospf:opaque/ospf:ri-opaque: +--ro sr-algorithm-tlv | +--ro sr-algorithm* uint8 +--ro sid-range-tlvs | +--ro sid-range-tlv* [] | +--ro range-size? uint24 | +--ro sid-sub-tlv | +--ro sid? uint32 +--ro local-block-tlvs | +--ro local-block-tlv* [] | +--ro range-size? uint24 | +--ro sid-sub-tlv | +--ro sid? uint32 +--ro srms-preference-tlv +--ro preference? uint8 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:database /ospf:as-scope-lsa-type/ospf:as-scope-lsas/ospf:as-scope-lsa /ospf:version/ospf:ospfv2/ospf:ospfv2/ospf:body/ospf:opaque /ospf:ri-opaque: +--ro sr-algorithm-tlv | +--ro sr-algorithm* uint8 +--ro sid-range-tlvs | +--ro sid-range-tlv* [] | +--ro range-size? uint24 | +--ro sid-sub-tlv | +--ro sid? uint32 +--ro local-block-tlvs | +--ro local-block-tlv* [] | +--ro range-size? uint24 | +--ro sid-sub-tlv | +--ro sid? uint32 +--ro srms-preference-tlv +--ro preference? uint8¶
2.1. OSPF Segment Routing YANG Module
[RFC2328], [RFC4750], [RFC5340], [RFC5643], [RFC5838], [RFC7223], [RFC8476] and [RFC8349] are referenced in the YANG model.¶
3. Security Considerations
The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
The NETCONF Configuration Access Control model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content.¶
There are a number of data nodes defined in the modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:¶
- /ospf:ospf/segment-routing/enabled - Modification to the enablement for SR could result in a Denial-of-Service (Dos) attack. If an attacker disables SR, it will cause traffic disruption.¶
- /ospf:ospf/segment-routing/bindings - Modification to the local bindings could result in a Denial-of-Service (Dos) attack.¶
- /ospf:ospf/protocol-srgb - Modification of the protocol SRGB could be used to mount a DoS attack. For example, if the protocol SRBG size is reduced to a very small value, a lot of existing segments could no longer be installed leading to a traffic disruption.¶
- /ospf:interfaces/ospf:interface/segment-routing - Modification of the Adjacency Segment Identifier (Adj-SID) could be used to mount a DoS attack. Change of an Adj-SID could be used to redirect traffic.¶
- /ospf:interfaces/ospf:interface/ospf:fast-reroute/ti-lfa - Modification of the TI-LFA enablement could lead to traffic disruption.¶
Some of the readable data nodes in the modules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes.¶
Module ietf-ospf-sr augments base OSPF module data base with various TLVs. Knowledge of these data nodes can be used to attack other routers in the OSPF domain.¶
4. Acknowledgements
The authors wish to thank Yi Yang, Alexander Clemm, Gaurav Gupta, Ladislav Lhotka, Stephane Litkowski, Greg Hankins, Manish Gupta and Alan Davey for their thorough reviews and helpful comments.¶
This document was produced using Marshall Rose's xml2rfc tool.¶
Author affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed. MITRE has approved this document for Public Release, Distribution Unlimited, with Public Release Case Number 18-3281.¶
5. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested to be made:¶
URI: urn:ietf:params:xml:ns:yang:ietf-ospf-sr Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.¶
This document registers a YANG module in the YANG Module Names registry [RFC6020].¶
name: ietf-ospf-sr namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-sr prefix: ospf-sr reference: RFC XXXX¶
6. References
6.1. Normative References
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC2328]
- Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, , <https://www.rfc-editor.org/info/rfc2328>.
- [RFC3688]
- Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
- [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, , <https://www.rfc-editor.org/info/rfc4750>.
- [RFC5340]
- Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, , <https://www.rfc-editor.org/info/rfc5340>.
- [RFC5643]
- Joyal, D., Ed. and V. Manral, Ed., "Management Information Base for OSPFv3", RFC 5643, DOI 10.17487/RFC5643, , <https://www.rfc-editor.org/info/rfc5643>.
- [RFC5838]
- Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, , <https://www.rfc-editor.org/info/rfc5838>.
- [RFC6020]
- Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, , <https://www.rfc-editor.org/info/rfc6020>.
- [RFC6241]
- Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
- [RFC6242]
- Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, , <https://www.rfc-editor.org/info/rfc6242>.
- [RFC7223]
- Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, , <https://www.rfc-editor.org/info/rfc7223>.
- [RFC7950]
- Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
- [RFC8040]
- Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
- [RFC8341]
- Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, , <https://www.rfc-editor.org/info/rfc8341>.
- [RFC8349]
- Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, , <https://www.rfc-editor.org/info/rfc8349>.
- [RFC8446]
- Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
- [RFC8476]
- Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, , <https://www.rfc-editor.org/info/rfc8476>.
- [RFC8665]
- Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, , <https://www.rfc-editor.org/info/rfc8665>.
- [RFC9020]
- Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", RFC 9020, DOI 10.17487/RFC9020, , <https://www.rfc-editor.org/info/rfc9020>.
- [RFC9129]
- Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "YANG Data Model for the OSPF Protocol", RFC 9129, DOI 10.17487/RFC9129, , <https://www.rfc-editor.org/info/rfc9129>.
6.2. Informative References
- [RFC8340]
- Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/info/rfc8340>.
- [RFC8342]
- Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, , <https://www.rfc-editor.org/info/rfc8342>.
Appendix A. Contributors' Addreses
Dean Bogdanovic Alef EMail: ivandean@gmail.com Kiran Koushik Agrahara Sreenivasa Verizon Wireless Austin, TX 78681 USA EMail: KiranKoushik.AgraharaSreenivasa@verisonwireless.com¶