Internet DRAFT - draft-wang-lsr-ospf-ifit-node-capability
draft-wang-lsr-ospf-ifit-node-capability
Link State Routing Working Group Y. Wang
Internet-Draft T. Zhou
Intended status: Standards Track Huawei
Expires: September 10, 2020 R. Pang
China Unicom
March 09, 2020
Extensions to OSPF for Advertising In-situ Flow Information Telemetry
(IFIT) Node Capability
draft-wang-lsr-ospf-ifit-node-capability-03
Abstract
This document defines a way for an Open Shortest Path First (OSPF)
router originating the RI LSA to announce IFIT node capabilities
within the entire routing domain. A new optional TLV is extended to
the OSPF RI Opaque LSA [RFC7770] to carry the IFIT node capability
information. Such advertisements enable IFIT applications in an
operational network domain. Here, the term "OSPF" includes both
OSPFv2 and OSPFv3.
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 RFC 2119 [RFC2119].
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 September 10, 2020.
Wang, et al. Expires September 10, 2020 [Page 1]
Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-03 March 2020
Copyright Notice
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IFIT Domain . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. IFIT Node Capability Information . . . . . . . . . . . . 3
3. IFIT Node Capabilities Advertisement . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. TLVs within the body of the OSPF RI Opaque LSA . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
IFIT provides a complete framework architecture and a reflection-loop
working solution for on-path flow telemetry
[I-D.song-opsawg-ifit-framework]. At present, there are a family of
emerging on-path flow telemetry techniques, including In-situ OAM
(IOAM) [I-D.ietf-ippm-ioam-data], PBT
[I-D.song-ippm-postcard-based-telemetry], IOAM Direct Export (DEX)
[I-D.ioamteam-ippm-ioam-direct-export], Enhanced Alternate Marking
(EAM) [I-D.zhou-ippm-enhanced-alternate-marking], etc. IFIT is a
solution focusing on network domains. The "network domain" consists
of a set of network devices or entities within a single
administration. For example, a network domain can be one or more IGP
routing domains. The family of emerging on-path flow telemetry
techniques may be selectively or partially implemented in different
vendors' devices as an emerging feature for various use cases of
Wang, et al. Expires September 10, 2020 [Page 2]
Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-03 March 2020
application-aware network operations. Hence, in order to enable IFIT
applications in a network domain, IFIT node capabilities SHOULD be
advertised by every OSPF router in the IGP routing domains.
1.1. Terminology
OSPF: Open Shortest Path First
RI: Router Information
LSA: Link State Advertisement
2. Concepts
2.1. IFIT Domain
IFIT is expected to be deployed in a specific domain referred as the
IFIT domain. An IFIT domain may cross multiple network domains. One
network domain may consists of multiple IFIT domain. Within the IFIT
domain, the IFIT data fields of flow information head MAY be updated
by network nodes that the packet traverses.
2.2. IFIT Node Capability Information
Each IFIT node is configured with a node-id which uniquely identifies
a node within the associated IFIT domain. To accommodate the
different use cases or requirements of in-situ flow information
telemetry, IFIT data fields updated by network nodes fall into
different categories which are referred as different IFIT option
types, including IOAM Trace Option-Types [I-D.ietf-ippm-ioam-data],
IOAM Edge-to-Edge (E2E) Option-Type [I-D.ietf-ippm-ioam-data], IOAM
DEX Option-Type [I-D.ioamteam-ippm-ioam-direct-export] and Enhanced
Alternate Marking (EAM) Option-Type
[I-D.zhou-ippm-enhanced-alternate-marking]. So IFIT Option Types
SHOULD be carried in IFIT node capability advertisment.
3. IFIT Node Capabilities Advertisement
Given that OSPF uses the options field in LSAs and hello packets to
advertise optional router capabilities [RFC7770], this document
defnes a new IFIT Node Capability TLV within the body of the OSPF RI
Opaque LSA [RFC7770] to carry the IFIT node capabilities of the
router originating the RI LSA. The IFIT Node Capability TLV is
composed of three fields, a two-octet Type field, a two-octet Length
field, and 4-octet Value field. The Type field indicates the type of
items in the Value field. The Length field indicates the length of
the Value field in octets. The Value field indicates the IFIT Node
Wang, et al. Expires September 10, 2020 [Page 3]
Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-03 March 2020
Capability, which is a 4-octet IFIT Option Type-enabled Flag. The
TLV is padded to 4-octet alignment.
The IFIT Node-capability Sub-TLV has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Type | Length |
+---------------------------------------------------------------+
| IFIT Option Type-enabled Flag |
+---------------------------------------------------------------+
Fig. 1 IFIT Node Capability sub-TLV Format
Type: To be assigned by IANA
Length: A 8-bit field that indicates the length of the value portion
in octets and will be a multiple of 4 octets dependent on the number
of capabilities advertised.
IFIT Option Type-enabled Flag: A 4-octet field, which is defined as
following:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
|p|i|d|e|m| Reserved |
+---------------------------------------------------------------+
Where:
p-Flag: IOAM Pre-allocated Trace Option Type-enabled flag. If p bit
is set (1), the router is capable of IOAM Pre-allocated Trace
[I-D.ietf-ippm-ioam-data].
i-Flag: IOAM Incremental Trace Option Type-enabled flag. If i bit is
set (1), the router is capable of IOAM Incremental Tracing
[I-D.ietf-ippm-ioam-data].
d-Flag: IOAM DEX Option Type-enabled flag. If d bit is set (1), the
router is capable of IOAM DEX [I-D.ioamteam-ippm-ioam-direct-export].
e-Flag: IOAM E2E Option Type-enabled flag. If e bit is set (1), the
router is capable of IOAM E2E processing [I-D.ietf-ippm-ioam-data].
Wang, et al. Expires September 10, 2020 [Page 4]
Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-03 March 2020
m-Flag: Enhanced Alternative Marking enabled flag. If m bit is set
(1), then the router is capable of processing Enhanced Alternative
Marking packets [I-D.zhou-ippm-enhanced-alternate-marking].
Reserved: MUST be set to zero upon transmission and ignored upon
receipt.
An IFIT node SHALL be capable of more than one IFIT option types. So
in this case, IFIT Option Type-enabled Flag bitmap SHOULD has more
than one bit being set.
4. IANA Considerations
Note to RFC Editor: this section may be removed on publication as an
RFC.
4.1. TLVs within the body of the OSPF RI Opaque LSA
This document makes the following registrations for a TLV type of the
new IFIT Node Capability TLV proposed in Section 3 of this document
within the body of the OSPF RI Opaque LSA.
+------+----------------------+
| Type | Description |
+------+----------------------+
| TBD | IFIT Node Capability |
+------+----------------------+
5. Security Considerations
This document introduces new TLVs within the existing OSPF RI Opaque
LSA. It does not introduce any new security risks to OSPF.
6. Acknowledgements
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7770] "Extensions to OSPF for Advertising Optional Router
Capabilities", <https://www.rfc-editor.org/info/rfc7770>.
Wang, et al. Expires September 10, 2020 [Page 5]
Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-03 March 2020
7.2. Informative References
[I-D.ietf-ippm-ioam-data]
"Data Fields for In-situ OAM".
[I-D.ioamteam-ippm-ioam-direct-export]
"In-situ OAM Direct Exporting",
<https://datatracker.ietf.org/doc/draft-ioamteam-ippm-
ioam-direct-export/>.
[I-D.song-ippm-postcard-based-telemetry]
"Postcard-based On-Path Flow Data Telemetry",
<https://datatracker.ietf.org/doc/draft-song-ippm-
postcard-based-telemetry/>.
[I-D.song-opsawg-ifit-framework]
"In-situ Flow Information Telemetry Framework",
<https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-
framework/>.
[I-D.zhou-ippm-enhanced-alternate-marking]
"Enhanced Alternate Marking Method",
<https://datatracker.ietf.org/doc/draft-zhou-ippm-
enhanced-alternate-marking/>.
Authors' Addresses
Yali Wang
Huawei
156 Beiqing Rd., Haidian District
Beijing
China
Email: wangyali11@huawei.com
Tianran Zhou
Huawei
156 Beiqing Rd., Haidian District
Beijing
China
Email: zhoutianran@huawei.com
Wang, et al. Expires September 10, 2020 [Page 6]
Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-03 March 2020
Ran Pang
China Unicom
9 Shouti South Rd., Haidian District
Beijing
China
Email: pangran@chinaunicom.cn
Wang, et al. Expires September 10, 2020 [Page 7]