idnits 2.17.1 draft-li-6man-topology-id-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 142 has weird spacing: '... Option thi...' -- The document date (March 21, 2022) is 765 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8200' is defined on line 171, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft Z. Hu 4 Intended status: Standards Track J. Dong 5 Expires: September 22, 2022 Huawei Technologies 6 March 21, 2022 8 Topology Identifier in IPv6 Extension Header 9 draft-li-6man-topology-id-00 11 Abstract 13 This document proposes a new Hop-by-Hop option of IPv6 extension 14 header to carry the topology identifier, which is used to identify 15 the forwarding table instance created by the Multi Topology Routing 16 or Flexible Algorithm. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 22, 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 61 4. New IPv6 Extension Header Option for Topologies . . . . . . . 3 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 66 7.2. Informative References . . . . . . . . . . . . . . . . . 4 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 69 1. Introduction 71 This document proposes a new Hop-by-Hop option of IPv6 extension 72 header to carry the topology identifier, which is used to identify 73 the forwarding table instance created by the Multi Topology Routing 74 or Flexible Algorithm. 76 2. Terminologies 78 The following terminologies are used in this document. 80 MT: Multi Topology 82 3. Problem Statement 84 [RFC4915] defines Multi-Topology Routing in OSPF and [RFC5120] 85 defines Multi Topology Routing in ISIS. Through Multi Topology 86 Routing, there can be multiple forwarding tables in the data plane. 87 [I-D.ietf-lsr-flex-algo] can also implement the similar purpose to 88 install multiple forwarding tables for different Flexible Algorithm 89 instances. 91 In the MT IP Forwarding Considerations of [RFC5120],it is explained 92 when multiple MTs share an Interface with overlapping addresses, some 93 additional mechanism is needed to select the correct RIBs for the 94 incoming IP packets to determine the correct RIB to make a forwarding 95 decision. But there is lack of the generic approach of packet to 96 multiple MT RIB mapping over the same inbound interface. 98 4. New IPv6 Extension Header Option for Topologies 100 In order to solve the above issue, in the scenario of IPv6, the 101 topology identifier information can be carried in the packet. A new 102 Hop-by-Hop option type "Topology" is defined to carry the topology 103 related Identifier in an IPv6 packet. Its format is shown as below: 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Opt Type | Opt Data Len | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Topology ID | Reserved | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 Figure 1. Topology Option 115 where: 117 o Opt Type: Type value is TBD. 8-bit unsigned integer. Identifier of 118 the type of this Topology Option. 120 o Opt Data Len: 8-bit unsigned integer. It indicates the length of 121 the option Data field of this option, in octets. The value of Opt 122 Data Len of Topology option SHOULD be set to 4. 124 o Topology ID: 2-octet identifier which uniquely identifies the 125 topology associated with the specific forwarding table created by the 126 Multi Topology Routing or Flexible Algorithm. 128 o Reserved: 2-octet reserved field. It MUST be set as 0 and ignored 129 when received. 131 5. Security Considerations 133 TBD 135 6. IANA Considerations 137 This document requests IANA to assign a new option type from "Hop-by- 138 Hop Options" registry. 140 Value Description Reference 141 ------------------------------------------ 142 TBD Topology Option this document 144 7. References 146 7.1. Normative References 148 [I-D.ietf-lsr-flex-algo] 149 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 150 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 151 algo-18 (work in progress), October 2021. 153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 154 Requirement Levels", BCP 14, RFC 2119, 155 DOI 10.17487/RFC2119, March 1997, 156 . 158 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 159 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 160 RFC 4915, DOI 10.17487/RFC4915, June 2007, 161 . 163 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 164 Topology (MT) Routing in Intermediate System to 165 Intermediate Systems (IS-ISs)", RFC 5120, 166 DOI 10.17487/RFC5120, February 2008, 167 . 169 7.2. Informative References 171 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 172 (IPv6) Specification", STD 86, RFC 8200, 173 DOI 10.17487/RFC8200, July 2017, 174 . 176 Authors' Addresses 178 Zhenbin Li 179 Huawei Technologies 180 Beijing 100095 181 China 183 Email: lizhenbin@huawei.com 185 Zhibo Hu 186 Huawei Technologies 187 Beijing 100095 188 China 190 Email: huzhibo@huawei.com 191 Jie Dong 192 Huawei Technologies 193 Beijing 100095 194 China 196 Email: jie.dong@huawei.com