idnits 2.17.1 draft-ietf-idr-rdc-config-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 142 has weird spacing: '...ollowed by an...' == Line 143 has weird spacing: '...pletely enclo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 1996) is 10041 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) -- Missing reference section? '1' on line 186 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Ramesh Govindan 3 Expires April 28, 1997 USC/ISI 4 draft-ietf-idr-rdc-config-01.txt October 28, 1996 6 Configuring IDRP Confederations 8 Status of this Memo 10 This document is an Internet Draft, and can be found as 11 draft-ietf-idr-rdc-config-00.txt in any standard internet drafts 12 repository. Internet Drafts are working documents of the Internet 13 Engineering Task Force (IETF), its Areas, and its Working Groups. 14 Note that other groups may also distribute working documents as 15 Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months. 18 Internet Drafts may be updated, replaced, or obsoleted by other 19 documents at any time. It is not appropriate to use Internet Drafts 20 as reference material, or to cite them other than as a ``working 21 draft'' or ``work in progress.'' 23 Please check the I-D abstract listing contained in each Internet Draft 24 directory to learn the current status of this or any other Internet 25 Draft. 27 Abstract 29 In the Inter-Domain Routing Protocol (IDRP), all border 30 routers (border intermediate systems (BISs) in ISO 31 terminology) of a routing domain confederation (RDC) must be 32 configured with the identity of all RDCs that overlap or 33 enclose that RDC. This draft describes some minor 34 modifications to IDRP specification that removes this 35 requirement. 37 1 The Inter-Domain Routing Protocol 39 In the Inter-Domain Routing Protocol (IDRP, [1]), border intermediate 40 systems (BISs) of routing domains (RDs) exchange route updates. A 41 route update advertises reachability to one or more address prefixes 42 (Network Layer Reachability Information, or NLRI, in ISO terminology). 43 Each IDRP route update also contains an RD_PATH attribute; the RD_PATH 44 is a list of Routing Domain Identifiers (RDIs) of RDs traversed by a 45 route update. The RD_PATH is used to detect routing loops. 47 In a large internet, a routing update's RD_PATH may contain a large 48 number of RDIs. To allow shorter RD_PATHs, two or more topologically 49 adjacent RDs may be combined into a single IDRP Routing Domain 50 Confederation (RDC). In turn, two or more topologically adjacent RDCs 51 may be combined into a single, larger, RDC. RDCs may also overlap. An 52 RD outside an RDC A sees only the A's RDI in RD_PATHs of route updates 53 from A; that is, RDIs of RDs completely enclosed by A are not visible 54 outside A. 56 2 RDC Configuration 58 Section 7.13.2 of [1] specifies that a border router (or Border 59 Intermediate System (BIS)) that participates in one or more RDCs must: 61 be aware of the RDIs of all confederations of which it is a 62 member, and it must know the partial order which prevails 63 between these confederations: that is, it must know the 64 nesting and overlap relationships between all confederations 65 to which it belongs. 67 Such configuration is undesirable because changing an RDC's boundaries 68 may require significant coordination between that RDC and all other 69 RDCs that it contains or overlaps. 71 To understand the need for such configuration, we briefly describe 72 RD_PATH formation in IDRP (the interested reader is referred to 73 Section 7.12.3 of [1] for details). When a routing update message 74 enters an RDC, the RDC's BIS inserts an ``entry'' marker in the 75 RD_PATH. Thus, the RD_PATH of a route update that has entered three 76 RDCs A, B and C looks like this: 78 ...Enter(A)....Enter(B)....Enter(C).... 80 The ellipses indicate RDIs of other RDs or RDCs traversed by the 81 route. 83 When this route exits RDC B, B's BIS removes its ``entry'' marker and 84 updates the RD_PATH according to the rules described in Section 7.12.3 85 C 86 ********* 87 B * 88 ************************* 89 * * * 90 * * * 91 ---*------------*----------*---------> 92 * Enter B * Enter C * Exit B 93 * * * 94 ************************* 95 * 96 ********* 98 Figure 1: Suppose a route's RD_PATH contains an ``entry'' marker for 99 RD B followed by an ``entry'' marker for RD C. If the route exits B 100 before exiting C, C must overlap B. 102 of [1]. These rules depend on the nesting or overlap relationship 103 between B and all RDCs whose ``entry'' markers are listed in the 104 RD_PATH. As we show below, B cannot determine these relatioships from 105 the RD_PATH alone. For this reason, [1] specifies the configuration 106 rule described above. 108 By simple examination of the RD_PATH, B's BIS can unambiguously assert 109 that RDC C overlaps RDC B. Indeed, all ``entry'' markers in the 110 RD_PATH to the ``right'' of B's ``entry'' marker correspond to RDCs 111 that overlap with B (Figure 1). 113 However, without configured information, B's BIS cannot unambiguously 114 determine whether RDC A overlaps or contains RDC B. Indeed, any 115 ``entry'' marker in the RD_PATH to the ``left'' of B's ``entry'' 116 marker may correspond to an RDC that either overlaps with, or 117 completely contains, B (Figure 2). 119 3 Solution 121 With the following modification to the RD_PATH formation rules of 122 Section 7.12.3 ([1]), the configuration rule of the previous section 123 is no longer necessary: 125 In the absence of configured information, a BIS for an RDC B 126 (say) shall assume that B is nested within RDCs whose 127 ENTRY_SEQs and ENTRY_SETs appear to the ``left'' of B's 128 ENTRY_SEQ or ENTRY_SET. 130 A B 131 ************************ *********** 132 * B * A * * 133 * ************ * ********************** 134 ----*----*----------*------*---> ---*----*---------*-----*---> 135 * * * * * * * * 136 * ************ * * *********** * 137 * * * * 138 ************************ ********************** 139 (i) (ii) 141 Figure 2: Suppose a route's RD_PATH contains an ``entry'' marker for 142 RD A followed by an ``entry'' marker for RD B. If the route exits 143 B before exiting A, (i) A may completely enclose B, or (ii) B may 144 overlap A. 146 Instead, Section 7.13.2 now requires the following configuration 147 information: 149 Each BIS must be aware of the RDCs entered by UPDATE PDUs 150 received from each of its neighbors. Each BIS must also be 151 aware of the RDCs exited by UPDATE PDUs sent from the BIS to 152 each of its neighbors. 154 That is, a BIS need know only about RDCs which it borders, not all the 155 RDCs in which it participates. Two related modifications to [1] are 156 necessary. Section 7.13.3 is now redundant; in our proposed solution, 157 confederation boundaries are configured. For the same reason, the 158 OPEN PDU (Section 6.2) need no longer carry RDC IDs. 160 This solution has one important consequence. Consider the case when A 161 overlaps with B in the RD_PATH shown in the previous section 162 (Figure 2(ii)). If B's BIS were configured with this information, 163 both A and B's RDIs would appear in the route's RD_PATH, when seen at 164 any RD outside A. With our proposed solution, only A's RDI would 165 appear in the RD_PATH, when seen at any RD outside A. This is because 166 our solution treats B as if it were nested within A. Thus, the fact 167 that the route traverses RDC B is not visible outside RDC A. This does 168 not violate loop detection. If, for policy reasons, it is desirable 169 to have B's RDI appear in the RD_PATH, B's network administrator can 170 configure nesting and overlap relationships according to the 171 configuration rule of Section 2. 173 Finally, an equally correct solution would have been to always assume 174 that A overlaps B. This solution provides no reduction, however, in 175 the length of RD_PATHs, a primary motivation for introducing RDCs. 177 Acknowledgements 179 Yakov Rekhter motivated the study of this problem and provided 180 valuable feedback on earlier versions of the draft. Cengiz 181 Alaettinoglu, Rusty Eddy, Deborah Estrin, and Kannan Varadhan also 182 influenced the contents of this draft. 184 References 186 [1] Protocol for exchange of inter-domain routeing information among 187 intermediate systems to support forwarding of iso 8473 pdus. 188 ISO/IEC 10747: Information Processing Systems 189 Telecommunications and Information Exchange between Systems, 190 October 1993.