idnits 2.17.1 draft-kompella-mpls-crldp-unnum-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 77: '... Forwarding Adjacency in IS-IS or OSPF [LSP-HIER], the LSR MUST...' RFC 2119 keyword, line 80: '... MUST be set to that interface ID, a...' RFC 2119 keyword, line 81: '...D TLV of the LSP MUST be set to the Ro...' RFC 2119 keyword, line 86: '...the tail-end LSR MUST allocate an inte...' RFC 2119 keyword, line 87: '... Furthermore, it MUST set the "Reverse...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-04 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-01 == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-02 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kireeti Kompella 2 Internet Draft Juniper Networks 3 Expiration Date: March 2001 Yakov Rekhter 4 Cisco Systems 5 Alan Kullberg 6 NetPlane Systems 8 Signalling Unnumbered Links in CR-LDP 10 draft-kompella-mpls-crldp-unnum-00.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Abstract 35 Current signalling used by MPLS TE doesn't provide support for 36 unnumbered links. This document defines procedures and extensions to 37 CR-LDP, one of the MPLS TE signalling protocols, that are needed in 38 order to support unnumbered links. 40 3. Overview 42 Supporting MPLS TE over unnumbered links (i.e., links that do not 43 have IP addresses) involves two components: (a) the ability to carry 44 (TE) information about unnumbered links in IGP TE extensions (ISIS or 45 OSPF), and (b) the ability to specify unnumbered links in MPLS TE 46 signalling. The former is covered in [ISIS-TE, OSPF-TE]. The focus 47 of this document is on the latter. 49 Current signalling used by MPLS TE doesn't provide support for 50 unnumbered links because the current signalling doesn't provide a way 51 to indicate an unnumbered link in its Explicit Route Objects. This 52 document proposes simple procedures and extensions that allow CR-LDP 53 [CR-LDP] signalling to be used with unnumbered links. 55 4. Interface Identifiers 57 Since unnumbered links are not identified by an IP address, then for 58 the purpose of MPLS TE they need some other identifier. We assume 59 that each unnumbered link on a Label Switched Router (LSR) is given a 60 unique 16-bit identifier. The scope of this identifier is the LSR to 61 which the link belongs; moreover, the IS-IS and/or OSPF and CR-LDP 62 modules on an LSR must agree on interface identifiers. 64 Note that links are directed, i.e., a link l is from some LSR A to 65 some other LSR B. LSR A chooses the interface identifier for link l. 66 To be completely clear, we call this the "outgoing interface 67 identifier from LSR A's point of view". If there is a reverse link 68 from LSR B to LSR A (for example, a point-to-point SONET interface 69 connecting LSRs A and B would be represented as two links, one from A 70 to B, and another from B to A), B chooses the outgoing interface 71 identifier for the reverse link. There is no a priori relationship 72 between the two interface identifiers. 74 5. Unnumbered Forwarding Adjacencies 76 If an LSR that originates an LSP advertises this LSP as an unnumbered 77 Forwarding Adjacency in IS-IS or OSPF [LSP-HIER], the LSR MUST 78 allocate an interface ID to that Forwarding Adjacency. Moreover, the 79 Local CR-LSP ID in the LSPID TLV of the Request Message for the LSP 80 MUST be set to that interface ID, and the Ingress LSR Router ID in 81 the LSPID TLV of the LSP MUST be set to the Router ID of the LSR that 82 originates the LSP. 84 If the LSP is bidirectional, and the tail-end LSR (of the forward 85 LSP) advertises the reverse LSP as an unnumbered Forwarding 86 Adjacency, the tail-end LSR MUST allocate an interface ID to the 87 reverse Forwarding Adjacency. Furthermore, it MUST set the "Reverse 88 Interface ID" field in the Reverse Interface ID TLV in the MAPPING 89 message to the reverse FA's interface ID. The Reverse Interface ID's 90 format is shown in Figure 1: 92 Figure 1: Reverse Interface ID TLV 94 0 1 2 3 95 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 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 |0|0| Type | Length | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | MUST be zero | Reverse Interface ID (16 bits)| 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 The Type (Reverse Interface ID) is to be determined by IETF consensus 103 and the Length is 4. 105 6. Signalling Unnumbered Links in EROs 107 A new subobject of the Explicit Route Object (ERO) is used to specify 108 unnumbered links. This subobject has the following format: 110 Figure 2: Unnumbered Interface ID Subobject 112 0 1 2 3 113 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 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 |0|0| Type | Length | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 |L| MUST be zero | Interface ID (16 bits) | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 This subobject MUST be strict (i.e., the L bit MUST be 0). The Type 121 is 0x0805 (Unnumbered Interface ID) and the Length is 4. 123 An LSR sending a Request message that includes an Unnumbered 124 Interface ID subobject as the first subobject in the ERO MUST also 125 include a PHOP TLV, specifying the Router ID of the sending LSR. 126 This TLV is depicted in Figure 3. 128 The Type (PHOP TLV) is to be determined by IETF consensus and the 129 Length is 4. 131 Figure 3: PHOP TLV 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 |0|0| Type | Length | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Sending LSR's Router ID | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 6.1. Interpreting the Unnumbered Interface ID Subobject 143 The Interface ID is the outgoing interface identifier with respect to 144 the previous node in the path (i.e., the PHOP). If the Request 145 message contains an Unnumbered Interface ID subobject as the first 146 subobject in the ERO, then the PHOP object in the message must 147 contain the router ID of the previous node. 149 6.2. Processing the Unnumbered Interface ID Subobject 151 A node that receives a Request message with an Unnumbered Interface 152 ID as the first subobject in the ERO carried by the message MUST 153 check whether the tuple matches the tuple 154 of any of the LSPs for which the 155 node is a tail-end. If a match is found, the match identifies the 156 Forwarding Adjacency for which the node has to perform label 157 allocation. 159 Otherwise, the node MUST check whether the tuple 160 matches the tuple of 161 any of the bidirectional LSPs for which the node is the head-end. If 162 a match is found, the match identifies the Forwarding Adjacency for 163 which the node has to perform label allocation, namely, the reverse 164 Forwarding Adjacency for the LSP identified by the match. 166 Otherwise, it is assumed that the node has to perform label 167 allocation for the link over which the Request message was received. 168 In this case the receiving node MAY validate that it received the 169 Request Message correctly. To do so, the node must maintain a 170 database of Traffic Engineering information distributed by IS-IS 171 and/or OSPF. 173 To validate that it received the Request message correctly, the node 174 looks up in its Traffic Engineering database for the node 175 corresponding to the router ID of the sender of the Request message. 176 It then checks that there is a link from the previous node to itself 177 that carries the same Interface ID as the one in the ERO subobject. 179 If this is not the case, the receiving node has received the message 180 in error and SHOULD return a "Bad Initial ER-Hop" error. Otherwise, 181 the receiving node removes the first subobject, and continues 182 processing the ERO. 184 6.3. Selecting the Next Hop 186 If, after processing and removing all initial subobjects in the ERO 187 that refer to itself, the receiving node finds a subobject of type 188 Unnumbered Interface ID, it determines the next hop as follows. The 189 Interface ID MUST refer to an outgoing interface identifier that this 190 node allocated; if not, the node SHOULD return a "Bad Strict Node" 191 error. The next hop is the node at the other end of the link that 192 the Interface ID refers to. 194 Furthermore, when sending a Request message to the next hop, the ERO 195 to be used is the current ERO (starting with the Unnumbered Interface 196 ID subobject). 198 7. Security Considerations 200 This document raises no new security concerns for CR-LDP. 202 8. Acknowledgments 204 Thanks to Rahul Aggarwal for his comments on the text. 206 9. References 208 [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using 209 LDP", draft-ietf-mpls-cr-ldp-04.txt (work in progress) 211 [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic 212 Engineering", draft-ietf-isis-traffic-02.txt (work in progress) 214 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS 215 TE", draft-ietf-mpls-lsp-hierarchy-01.txt (work in progress) 217 [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to 218 OSPF", draft-katz-yeung-ospf-traffic-02.txt (work in progress) 220 10. Author Information 222 Kireeti Kompella 223 Juniper Networks, Inc. 224 1194 N. Mathilda Ave. 225 Sunnyvale, CA 94089 226 e-mail: kireeti@juniper.net 228 Yakov Rekhter 229 Cisco Systems, Inc. 230 170 West Tasman Drive 231 San Jose, CA 95134 232 e-mail: yakov@cisco.com 234 Alan Kullberg 235 NetPlane Systems, Inc. 236 888 Washington St. 237 Dedham, MA 02026 238 e-mail: akullber@netplane.com