idnits 2.17.1 draft-ietf-mpls-crldp-unnum-09.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 == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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: 'ISIS-GMPLS' is mentioned on line 79, but not defined == Missing Reference: 'OSPF-GMPLS' is mentioned on line 79, but not defined == Missing Reference: 'CD-LDP' is mentioned on line 218, but not defined == Missing Reference: 'IANA' is mentioned on line 222, but not defined == Unused Reference: 'GMPLS-SIG' is defined on line 251, but no explicit reference was found in the text -- No information found for draft-ietf-generalized-mpls-signalling - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-SIG' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-06 ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-02 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-03 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-11 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-07 == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-07 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-03 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kireeti Kompella 3 Internet Draft Juniper Networks 4 Expiration Date: April 2003 Yakov Rekhter 5 Juniper Networks 6 Alan Kullberg 7 NetPlane Systems 9 Signalling Unnumbered Links in CR-LDP 11 draft-ietf-mpls-crldp-unnum-09.txt 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 2. Abstract 36 Current signalling used by Multi-Protocol Label Switching Traffic 37 Engineering (MPLS TE) doesn't provide support for unnumbered links. 38 This document defines procedures and extensions to Constraint-Routing 39 Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling 40 protocols, that are needed in order to support unnumbered links. 42 3. Specification of Requirements 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 4. Overview 50 Supporting MPLS TE over unnumbered links (i.e., links that do not 51 have IP addresses) involves two components: (a) the ability to carry 52 (TE) information about unnumbered links in IGP TE extensions (ISIS or 53 OSPF), and (b) the ability to specify unnumbered links in MPLS TE 54 signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The 55 focus of this document is on the latter. 57 Current signalling used by MPLS TE doesn't provide support for 58 unnumbered links because the current signalling doesn't provide a way 59 to indicate an unnumbered link in its Explicit Route Objects. This 60 document proposes simple procedures and extensions that allow CR-LDP 61 signalling [CR-LDP] to be used with unnumbered links. 63 5. Link Identifiers 65 An unnumbered link has to be a point-to-point link. An LSR at each 66 end of an unnumbered link assigns an identifier to that link. This 67 identifier is a non-zero 32-bit number that is unique within the 68 scope of the LSR that assigns it. The IS-IS and/or OSPF and RSVP 69 modules on an LSR must agree on the identifiers. 71 There is no a priori relationship between the identifiers assigned to 72 a link by the LSRs at each end of that link. 74 LSRs at the two end points of an unnumbered link exchange with each 75 other the identifiers they assign to the link. Exchanging the 76 identifiers may be accomplished by configuration, by means of a 77 protocol such as LMP ([LMP]), by means of RSVP/CR-LDP (especially in 78 the case where a link is a Forwarding Adjacency, see below), or by 79 means of IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]). 81 Consider an (unnumbered) link between LSRs A and B. LSR A chooses an 82 idenfitier for that link. So is LSR B. From A's perspective we refer 83 to the identifier that A assigned to the link as the "link local 84 identifier" (or just "local identifier"), and to the identifier that 85 B assigned to the link as the "link remote identifier" (or just 86 "remote identifier"). Likewise, from B's perspective the identifier 87 that B assigned to the link is the local identifier, and the 88 identifier that A assigned to the link is the remote identifier. 90 In the context of this document the term "Router ID" refers to the 91 "Router Address" as defined in [OSPF-TE], or "Traffic Engineering 92 Router ID" as defined in [ISIS-TE]. 94 This section is equally applicable to the case of unnumbered 95 component links (see [LINK-BUNDLE]). 97 6. Unnumbered Forwarding Adjacencies 99 If an LSR that originates an LSP advertises this LSP as an unnumbered 100 Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR 101 uses the Forwarding Adjacency formed by this LSP as an unnumbered 102 component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST 103 allocate an identifier to that Forwarding Adjacency (just like for 104 any other unnumbered link). Moreover, the REQUEST message used for 105 establishing the LSP that forms the Forwarding Adjacency MUST contain 106 an LSP_TUNNEL_INTERFACE_ID TLV (described below), with the LSR's 107 Router ID set to the head end's Router ID, and the Interface ID set 108 to the identifier that the LSR allocated to the Forwarding Adjacency. 110 If the REQUEST message contains the LSP_TUNNEL_INTERFACE_ID TLV, then 111 the tail-end LSR MUST allocate an identifier to that Forwarding 112 Adjacency (just like for any other unnumbered link). Furthermore, 113 the MAPPING message for the LSP MUST contain an 114 LSP_TUNNEL_INTERFACE_ID TLV, with the LSR's Router ID set to the 115 tail-end's Router ID, and the Interface ID set to the identifier 116 allocated by the tail-end LSR. 118 For the purpose of processing the Explicit Route TLV and the 119 Interface ID TLV, an unnumbered Forwarding Adjacency is treated as an 120 unnumbered (TE) link or an unnumbered component link as follows. The 121 LSR that originates the Adjacency sets the link local identifier for 122 that link to the value that the LSR allocates to that Forwarding 123 Adjacency, and the link remote identifier to the value carried in the 124 Interface ID field of the Reverse Interface ID TLV (for the 125 definition of Reverse Interface ID TLV see below). The LSR that is a 126 tail-end of that Forwarding Adjacency sets the link local identifier 127 for that link to the value that the LSR allocates to that Forwarding 128 Adjacency, and the link remote identifier to the value carried in the 129 Interface ID field of the Forward Interface ID TLV (for the 130 definition of Forward Interface ID see below). 132 6.1. LSP_TUNNEL_INTERFACE_ID TLV 134 The LSP_TUNNEL_INTERFACE ID TLV has Type to be determined by IETF 135 consensus and length 8. The format is given below. 137 Figure 1: LSP_TUNNEL_INTERFACE_ID TLV 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |0|0| Type | Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | LSR's Router ID | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Interface ID (32 bits) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 This TLV can optionally appear in either a REQUEST message or a 150 MAPPING message. In the former case, we call it the "Forward 151 Interface ID" for that LSP; in the latter case, we call it the 152 "Reverse Interface ID" for the LSP. 154 7. Signalling Unnumbered Links in Explicit Route TLV 156 A new Type of ER-Hop TLV of the Explicit Route TLV is used to specify 157 unnumbered links. This Type is called Unnumbered Interface ID, and 158 has the following format: 160 Figure 2: Unnumbered Interface ID 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 |0|0| Type = 0x0805 | Length = 12 | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |L| Reserved | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Router ID | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Interface ID (32 bits) | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 The Type is 0x0805 (Unnumbered Interface ID) and the Length is 12. 175 The L bit is set to indicate a loose hop, and cleared to indicate a 176 strict hop. 178 The Interface ID is the identifier assigned to the link by the LSR 179 specified by the router ID. 181 7.1. Processing the IF_ID TLV 183 When an LSR receives a REQUEST message containing the IF_ID TLV (see 184 [GMPLS-CRLDP]) with the IF_INDEX TLV, the LSR processes this TLV as 185 follows. The LSR must have information about the identifiers assigned 186 by its neighbors to the unnumbered links between the neighbors and 187 the LSR. The LSR uses this information to find a link with tuple 188 matching the tuple carried in the IF_INDEX TLV. If the matching tuple is 190 found, the match identifies the link for which the LSR has to perform 191 label allocation. 193 Otherwise, the LSR SHOULD return an error. 195 7.2. Processing the Unnumbered Interface ID ER-Hop TLV 197 The Unnumbered Interface ID ER-Hop is defined to be a part of a 198 particular abstract node if that node has the Router ID that is equal 199 to the Router ID field in the Unnumbered Interface ID ER-Hop, and if 200 the node has an (unnumbered) link or an (unnumbered) Forwarding 201 Adjacency whose local identifier (from that node's point of view) is 202 equal to the value carried in the Interface ID field of the 203 Unnumbered Interface ID ER-Hop. 205 With this in mind, the Explicit Route TLV processing in the presence 206 of the Unnumbered Interface ID ER-Hop follows the rules specified in 207 section 4.8.1 of [CR-LDP]. 209 As part of the Explicit Route TLV processing, or to be more precise, 210 as part of the next hop selection, if the outgoing link is 211 unnumbered, the REQUEST message that the node sends to the next hop 212 MUST include the IF_ID TLV, with the IP address field of that TLV set 213 to the Router ID of the node, and the Interface ID field of that TLV 214 set to the identifier assigned to the link by the node. 216 8. IANA Considerations 218 RFC3036 [LDP] defines the LDP TLV name space. RFC3212 [CD-LDP] 219 further subdivides the range of RFC 3036 from that TLV space for TLVs 220 associated with the CR-LDP in the range 0x0800 - 0x08FF. 222 Following the policies outlined in [IANA], TLV types in this range 223 are allocated through an IETF Consensus action. 225 This document makes the following assignments: 227 TLV Type 228 -------------------------------------- ---------- 229 UNNUMBERED_INTERFACE_ID 0x0805 230 LSP_TUNNEL_INTERFACE_ID 0x08?? 232 9. Security Considerations 234 This document extends CR-LDP and raises no new security issues. CR- 235 LDP inherits the same security mechanism described in Section 4.0 of 236 [LDP] to protect against the introduction of spoofed TCP segments 237 into LDP session connection streams. 239 10. Acknowledgments 241 Thanks to Rahul Aggarwal for his comments on the text. Thanks too to 242 Bora Akyol, Vach Kompella, and George Swallow. 244 11. References 246 11.1. Normative references 248 [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using 249 LDP", RFC3212, December 2001 251 [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling 252 Functional Description", draft-ietf-generalized-mpls- 253 signalling-08.txt 255 [GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- 256 LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-06.txt 258 [LDP] Andersson, Loa, et al., "LDP Specification" RFC3036, January 259 2001 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, March 1997. 264 11.2. Non-normative references 266 [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 267 Bundling in MPLS Traffic Engineering", draft-kompella-mpls- 268 bundle-05.txt (work in progress) 270 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS 271 TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress) 273 [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", 274 draft-ietf-ccamp-lmp-03.txt (work in progress) 276 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 277 Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls- 278 extensions-11.txt (work in progress) 280 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 281 Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- 282 gmpls-extensions-07.txt (work in progress) 284 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 285 Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-07.txt 286 (work in progress) 288 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 289 Engineering", draft-ietf-isis-traffic-03.txt (work in progress) 291 12. Author Information 292 Kireeti Kompella 293 Juniper Networks, Inc. 294 1194 N. Mathilda Ave. 295 Sunnyvale, CA 94089 296 e-mail: kireeti@juniper.net 298 Yakov Rekhter 299 Juniper Networks, Inc. 300 1194 N. Mathilda Ave. 301 Sunnyvale, CA 94089 302 e-mail: yakov@juniper.net 304 Alan Kullberg 305 NetPlane Systems, Inc. 306 Westwood Executive Center 307 200 Lowder Brook Drive 308 Westwood, MA 02090 309 e-mail: akullber@netplane.com