Link State Routing Working Group Y. Wang Internet-Draft T. Zhou Intended status: Standards Track Z. Hu Expires: May 2, 2021 Huawei October 29, 2020 IGP Extensions for Advertising Hop-by-Hop Options Header Processing Action draft-wang-lsr-hbh-process-00 Abstract This document extends Node and Link attribute TLVs to Interior Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header processing action and supported services (e.g. IOAM Trace Option and Alternate Marking) at node and link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether the Hop-by-Hop Options header and specific services can be supported in a given network. 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 May 2, 2021. Wang, et al. Expires May 2, 2021 [Page 1] Internet-Draft draft-wang-lsr-hbh-process-00 October 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Hop-by-Hop Options Header Processing Action . . . . . . . . . 4 4. Signaling Processing Action Using IS-IS . . . . . . . . . . . 5 4.1. IS-IS Node Processing-Action Sub-TLV . . . . . . . . . . 5 4.2. IS-IS Link Processing-Action Sub-TLV . . . . . . . . . . 6 5. Signaling Processing Action Using OSPF . . . . . . . . . . . 6 5.1. OSPF Node Processing-Action TLV . . . . . . . . . . . . . 7 5.2. OSPFv2 Link Processing-Action sub-TLV . . . . . . . . . . 7 5.3. OSPFv3 Link Processing-Action Sub-TLV . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction [RFC8200] specifies IPv6 extension headers, including Hop-by-Hop Options header, Destination Options header, Routing header, etc. An IPv6 packet may carry zero, one, or more extension headers that must be processed strictly in the order they appear in the packet. Except for the Hop-by-Hop Options header, other extension headers are not processed, inserted, or deleted by any transit node along a packet's delivery path, until the packet arrives at the Destination node. As specified in [RFC8200], although the Hop-by-Hop Options header is not inserted or deleted by any transit node along a packet's delivery path, it is only examined and processed by nodes along a packet's Wang, et al. Expires May 2, 2021 [Page 2] Internet-Draft draft-wang-lsr-hbh-process-00 October 2020 delivery path if they are explicitly configured to process. Besides, nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. In the results, devices of different vendors can be configured to process the Hop-by-Hop Options header in different ways. Until now, the Hop-by-Hop Options header has been widely used. In- situ Operations, Administration, and Maintenance (IOAM) data fields are encapsulated in two types of extension headers in IPv6 packets, either Hop-by-Hop Options header or Destination Options header, depending on IOAM usage [I-D.ietf-ippm-ioam-ipv6-options]. For example, IOAM-tracing options are represented as an IPv6 options in Hop-by-Hop extension header. Similarly, the Alternate Marking technique can be carried by the Hop-by-Hop Options header and the Destination Options header [I-D.ietf-6man-ipv6-alt-mark]. If nodes are not explicitly configured to process the Hop-by-Hop Option header, they should ignore them. In this case, the performance measurement does not account for all links and nodes along a path. Therefore, such advertisement can be useful for entities (e.g., the centralized controller) to determine whether a specific service can be implemented in IPv6 netowrk by encoding in the Hop-by-Hop Options header. BGP-LS defines a way to advertise topology and associated attributes and capabilities of the nodes in that topology to a centralized controller [RFC7752]. Typically, BGP-LS is configured on a small number of nodes that do not necessarily act as head-ends. In order for BGP-LS to signal the processing action of the Hop-by-Hop Options header for all the devices in the network, the processing action SHOULD be advertised by every IGP router in the network. This document defines a mechanism to signal the configured processing action of the Hop-by-Hop Options header and supported services at node and/or link granularity using IS-IS, OSPFv2 and OSPFv3. 2. Terminology Following are abbreviations used in this document: o IGP: Interior Gateway Protocols o IS-IS: Intermediate System to Intermediate System o OSPF: Open Shortest Path First o BGP-LS: Border Gateway Protocol - Link State Wang, et al. Expires May 2, 2021 [Page 3] Internet-Draft draft-wang-lsr-hbh-process-00 October 2020 o NLRI: Network Layer Reachability Information 3. Hop-by-Hop Options Header Processing Action This document defines the information of processing action formed of a tuple of a 1-octet Extension Header Options identifier and 8-bit Processing Action Flag. 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 +---------------+-------------------------------+---------------+ | Action Flag | Services Flag | Max EH Len | +---------------+-------------------------------+---------------+ Fig. 1 Processing Action Format Where: o Action Flag: A 8-bit field. The highest-order 3-bit indicates the processing action, i.e., 000 - drop packets; 001 - dispatch to control plane; 010 - forward, skip to Next Header; 011 - forward, ignoring all extension Options header; 100 - examine and process. o Max EH Len: A one octet field. The maximum length of the Extension Header in 8-octet units can be examined and processed at node or link granularity. The definition is same as the Next Header Length in [RFC8200]. o Services Flag: A 16-bit bitmap. The format is defined as follows. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-------------------------------+ |O|A| Reserved | +-------------------------------+ Fig. 2 Services Flag Format where fields are defined as the following: o O (IOAM Trace Option) is a one-bit flag. The O flag is set to 1 if the IOAM Trace Option is supported at node or link granularity. o A (Alternate Marking) is a one-bit flag. The A flag is set to 1 if the Alternate Marking method is supported at node or link granularity. o R - reserved bits for future use. These flags MUST be zeroed on transimit and ignored on receipt. Wang, et al. Expires May 2, 2021 [Page 4] Internet-Draft draft-wang-lsr-hbh-process-00 October 2020 In this document, the processing action at link granularity is defined as the supported the Hop-by-Hop Options header processing action of the interface associated with the link. When all interfaces associated with links support the same processing action, the processing action at node granularity SHOULD represent the Link processing action. Both of Node and Link processing action information are formed of a tuple of a 1-octet Extension Header Options identifier and 8-bit Processing Action Flag. When both of Node and Link processing action are advertised, the Link processing action information MUST take precedence over the Node processing action. Besides, when a Link processing action is not signaled, then the Node processing action SHOULD be considered to be the processing action for this link. 4. Signaling Processing Action Using IS-IS The IS-IS Extensions for advertising Router Information TLV named IS- IS Router CAPABILITY TLV [RFC7981], which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. 4.1. IS-IS Node Processing-Action Sub-TLV According to the format of IS-IS Router CAPABILITY TLV [RFC7981], the Node Processing-Action sub-TLV within the body of the IS-IS router CAPABILITY TLV is composed of three fields, a one-octet Type field, a one-octet Length field, and a 4-octet Value field. The following format is used: 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 | +---------------+---------------+-------------------------------+ | Node-Processing-Action | +---------------------------------------------------------------+ Fig. 3 IS-IS Node Processing-Action Sub-TLV Format Where: o Type: To be assigned by IANA o Length: A one-octet field that indicates the length of the value portion in octets. o Node-Processing-Action: A 4-octet field, which is same as defined in Section 3. Wang, et al. Expires May 2, 2021 [Page 5] Internet-Draft draft-wang-lsr-hbh-process-00 October 2020 4.2. IS-IS Link Processing-Action Sub-TLV The Link Processing-Action sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 223 to carry the Processing-Action information of the interface associated with the link. The Link Processing-Action sub- TLV is formed of three fields, a one-octet Type field, a one-octet Length field, and a 4-octet Value field. The following format is used: 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 | +---------------+---------------+-------------------------------+ | Link-Processing-Action | +---------------------------------------------------------------+ Fig. 4 IS-IS Link Processing-Action Sub-TLV Format Where: o Type: To be assigned by IANA o Length: A one-octet field that indicates the length of the value portion in octets. o Link-Processing-Action: A 4-octet field, which is same as defined in Section 3. 5. Signaling Processing Action Using OSPF Given that OSPF uses the options field in LSAs and hello packets to advertise optional router capabilities [RFC7770], this document defines a new Node Processing-Action TLV within the body of the OSPF RI Opaque LSA [RFC7770] to carry the Processing Action of the router originating the RI LSA. This document defines the Link Processing-Action sub-TLV to carry the Processing-Action information of the interface associated with the link. For OSPFv2, the link-level Processing-Action information is advertised as a sub-TLV of the OSPFv2 Extended Link TLV as defined in [RFC7684]. For OSPFv3, the link-level Processing-Action information is advertised a sub-TLV of the E-Router-LSA TLV as defined in [RFC8362]. Wang, et al. Expires May 2, 2021 [Page 6] Internet-Draft draft-wang-lsr-hbh-process-00 October 2020 5.1. OSPF Node Processing-Action TLV The Node Processing-Action TLV is composed of three fields, a 2-octet Type field, a 2-octet Length field, and a 4-octet Value field. The following format is used: 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 | +---------------------------------------------------------------+ | Node-Processing-Action | +---------------------------------------------------------------+ Fig. 5 OSPF Node Processing-Action TLV Where: o Type: To be assigned by IANA o Length: A 2-octet field that indicates the length of the value field. o Node-Processing-Action: A 4-octet field, which is as defined in Section 3. 5.2. OSPFv2 Link Processing-Action sub-TLV The Link Processing-Action sub-TLV encoded in the OSPFv2 Extended Link TLV as defined in [RFC7684], which is constructed of three fields, a 2-octet Type field, a 2-octet Length field, and a 4-octet Value field. The following format is used: 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 | +---------------------------------------------------------------+ | Link-Processing-Action | +---------------------------------------------------------------+ Fig. 6 OSPFv2 Link Processing-Action sub-TLV Where: o Type: To be assigned by IANA Wang, et al. Expires May 2, 2021 [Page 7] Internet-Draft draft-wang-lsr-hbh-process-00 October 2020 o Length: A 2-octet field that indicates the length of the value field. o Link-Processing-Action: A 4-octet field, which is as defined in Section 3. 5.3. OSPFv3 Link Processing-Action Sub-TLV The Link Processing-Action sub-TLV encoded in the OSPFv3 E-Router-LSA TLV as defined in [RFC8362], which is constructed of three fields, a 2-octet Type field, a 2-octet Length field, and a 4-octet Value field. The following format is used: 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 | +---------------------------------------------------------------+ | Link-Processing-Action | +---------------------------------------------------------------+ Fig. 7 OSPFv3 Link Processing-Action sub-TLV Where: o Type: To be assigned by IANA o Length: A 2-octet field that indicates the length of the value field. o Link-Processing-Action: A 4-octet field, which is as defined in Section 3. 6. IANA Considerations IANA is requested to allocate values for the following new TLV and sub-TLVs. +------+--------------------------------------+ | Type | Description | +------+--------------------------------------+ | TBA | IS-IS Node Processing-Action Sub-TLV | | TBA | IS-IS Link Processing-Action Sub-TLV | +------+--------------------------------------+ Wang, et al. Expires May 2, 2021 [Page 8] Internet-Draft draft-wang-lsr-hbh-process-00 October 2020 +------+---------------------------------------+ | Type | Description | +------+---------------------------------------+ | TBA | OSPF Node Processing-Action TLV | | TBA | OSPFv2 Link Processing-Action sub-TLV | | TBA | OSPFv3 Link Processing-Action sub-TLV | +------+---------------------------------------+ 7. Security Considerations This document introduces new IGP Node and Link Attribute TLVs and sub-TLVs for dvertising processing actions of the Hop-by-Hop Options header at node and/or link granularity. It does not introduce any new security risks to IS-IS, OSPFv2 and OSPFv3. 8. Acknowledgements TBD 9. References 9.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, . [RFC7684] "OSPFv2 Prefix/Link Attribute Advertisement", . [RFC7752] "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", . [RFC7770] "Extensions to OSPF for Advertising Optional Router Capabilities", . [RFC7981] "IS-IS Extensions for Advertising Router Information", . [RFC8200] "Internet Protocol, Version 6 (IPv6) Specification", . [RFC8362] "OSPFv3 Link State Advertisement (LSA) Extensibility", . Wang, et al. Expires May 2, 2021 [Page 9] Internet-Draft draft-wang-lsr-hbh-process-00 October 2020 9.2. Informative References [I-D.ietf-6man-ipv6-alt-mark] "IPv6 Application of the Alternate Marking Method", . [I-D.ietf-ippm-ioam-ipv6-options] "In-situ OAM IPv6 Options", . 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 Zhibo Hu Huawei 156 Beiqing Rd., Haidian District Beijing China Email: huzhibo@huawei.com Wang, et al. Expires May 2, 2021 [Page 10]