idnits 2.17.1 draft-ietf-mpls-crldp-unnum-01.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 78: '... Forwarding Adjacency in IS-IS or OSPF [LSP-HIER], the LSR MUST...' RFC 2119 keyword, line 80: '...sage for the LSP MUST contain an INTER...' RFC 2119 keyword, line 88: '...the tail-end LSR MUST allocate an inte...' RFC 2119 keyword, line 90: '... the LSP MUST contain an INTERFACE I...' RFC 2119 keyword, line 143: '...e receiving node MUST return an error ...' (4 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) == Missing Reference: 'BUNDLE' is mentioned on line 189, but not defined == 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 (~~), 6 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: August 2001 Yakov Rekhter 4 Juniper Networks 5 Alan Kullberg 6 NetPlane Systems 8 Signalling Unnumbered Links in CR-LDP 10 draft-ietf-mpls-crldp-unnum-01.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 signalling [CR-LDP] 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 32-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; we call this the link's "incoming 72 interface identifier from A's point of view". There is no a priori 73 relationship between the two interface identifiers. 75 5. Unnumbered Forwarding Adjacencies 77 If an LSR that originates an LSP advertises this LSP as an unnumbered 78 Forwarding Adjacency in IS-IS or OSPF [LSP-HIER], the LSR MUST 79 allocate an interface ID to that Forwarding Adjacency. Moreover, the 80 REQUEST message for the LSP MUST contain an INTERFACE ID object 81 (described below), with the LSR's Router ID set to the head end's 82 router ID, and the Interface ID set to the LSP's interface ID. If 83 the LSP is part of a bundled link (see [BUNDLE]), the Interface ID is 84 set to the component interface ID of the LSP. 86 If the LSP is bidirectional, and the tail-end LSR (of the forward 87 LSP) advertises the reverse LSP as an unnumbered Forwarding 88 Adjacency, the tail-end LSR MUST allocate an interface ID to the 89 reverse Forwarding Adjacency. Furthermore, the MAPPING message for 90 the LSP MUST contain an INTERFACE ID object, with the LSR's Router ID 91 set to the tail end's router ID, and the Interface ID set to the 92 reverse LSP's interface ID. If the LSP is part of a bundled link 93 (see [BUNDLE]), the Component Interface ID is set to the component 94 interface ID of the LSP; otherwise, it is set to zero. 96 5.1. INTERFACE ID Object 98 The INTERFACE ID object has Type to be determined by IETF consensus 99 and length 8. The format is given below. 101 Figure 1: Interface ID TLV 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 |0|0| Type | Length | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | LSR's Router ID | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Interface ID (32 bits) | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 This object can optionally appear in either a REQUEST message or a 114 MAPPING message. In the former case, we call it the "Forward 115 Interface ID" for that LSP; in the latter case, we call it the 116 "Reverse Interface ID" for the LSP. 118 6. Signalling Unnumbered Links in EROs 120 A new subobject of the Explicit Route Object (ERO) is used to specify 121 unnumbered links. This subobject has the following format: 123 Figure 2: Unnumbered Interface ID Subobject 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 |0|0| Type | Length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Router ID | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Interface ID (32 bits) | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 This subobject is strict. The Type is 0x0805 (Unnumbered Interface 136 ID) and the Length is 8. 138 6.1. Interpreting the Unnumbered Interface ID Subobject 140 The Router ID (say X) is the router ID of the LSR P at the upstream 141 end of the unnumbered link. The Interface ID (say I) is the outgoing 142 interface identifier with respect to the LSR specified by the router 143 ID. If not, the receiving node MUST return an error message. 145 6.2. Validating the Unnumbered Interface ID Subobject 147 First of all, the receiving node R must validate that it received the 148 Request message correctly. If the first subobject in the ERO is an 149 Unnumbered Interface subobject, the check is done as follows. R 150 looks up in its Traffic Engineering database the node P corresponding 151 to the router ID X in the ERO subobject. It then checks that there 152 is a link from P to R that carries the same Interface ID as the one 153 in the ERO subobject (I). If this is not the case, R has received 154 the message in error and SHOULD return a "Bad Initial ER-Hop" error. 156 For other types of ERO subobjects, the rules in [CR-LDP] apply. 158 6.3. Determining the Link Identified by the ERO 160 Determining the link for which label allocation must be done depends 161 on whether a Component Interface Identifier object [BUNDLE] is 162 present in the Request message or not. If so, set ID to the 163 Component Interface ID; otherwise, set ID to I (the Interface ID in 164 the ERO subobject). X is (as above) the router ID in the Unnumbered 165 ERO subobject. 167 First, R checks whether the tuple matches the tuple of any of the LSPs for which the 169 node is a tail-end. If a match is found, the match identifies the 170 Forwarding Adjacency for which the node has to perform label 171 allocation. 173 Otherwise, the node MUST check whether the tuple matches the 174 tuple of any of the 175 bidirectional LSPs for which the node is the head-end. If a match is 176 found, the match identifies the Forwarding Adjacency for which the 177 node has to perform label allocation, namely, the reverse Forwarding 178 Adjacency for the LSP identified by the match. 180 Otherwise, R must have information about Interface IDs and Component 181 Interface IDs assigned by its neighbors for the unnumbered links 182 between R and its neighbors (i.e., incoming interface identifiers 183 from R's point of view). 185 If the Request message does not contain a Component Interface 186 Identifier object, R determines the link by looking up in the 187 Traffic Engineering database. If the Request message contains a 188 Component Interface Identifier object, R determines the link as 189 described in [BUNDLE]. 191 Otherwise, it is assumed that the node has to perform label 192 allocation for the link over which the Request message was received. 194 6.4. Selecting the Next Hop 196 Once the link has been determined, the initial subobject is removed, 197 and the next hop should be computed. The next hop for an Unnumbered 198 Interface ID subobject is determined as follows. The Interface ID 199 MUST refer to an outgoing interface identifier that this node 200 allocated; if not, the node SHOULD return a "Bad Strict Node" error. 201 The next hop is the node at the other end of the link that the 202 Interface ID refers to. If this node is R itself, the subobject is 203 removed, and the process repeated. If the next node is not R, say N, 204 this is the next hop to which a Request message must be sent. 206 Furthermore, when sending a Request message to N, the ERO to be used 207 is the remaining ERO (i.e., starting with the subobject that refers 208 to a node different from the receiving node); the PHOP object is R's 209 router ID. 211 7. Security Considerations 213 This document raises no new security concerns for CR-LDP. 215 8. Acknowledgments 217 Thanks to Rahul Aggarwal for his comments on the text. Thanks too to 218 Bora Akyol and Vach Kompella. 220 9. References 222 [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using 223 LDP", draft-ietf-mpls-cr-ldp-04.txt (work in progress) 225 [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic 226 Engineering", draft-ietf-isis-traffic-02.txt (work in progress) 228 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS 229 TE", draft-ietf-mpls-lsp-hierarchy-01.txt (work in progress) 231 [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to 232 OSPF", draft-katz-yeung-ospf-traffic-02.txt (work in progress) 234 10. Author Information 235 Kireeti Kompella 236 Juniper Networks, Inc. 237 1194 N. Mathilda Ave. 238 Sunnyvale, CA 94089 239 e-mail: kireeti@juniper.net 241 Yakov Rekhter 242 Juniper Networks, Inc. 243 1194 N. Mathilda Ave. 244 Sunnyvale, CA 94089 245 e-mail: yakov@juniper.net 247 Alan Kullberg 248 NetPlane Systems, Inc. 249 888 Washington St. 250 Dedham, MA 02026 251 e-mail: akullber@netplane.com