idnits 2.17.1 draft-ietf-mpls-crldp-unnum-07.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 6 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 92: '... component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST...' RFC 2119 keyword, line 95: '... the Forwarding Adjacency MUST contain...' RFC 2119 keyword, line 101: '...the tail-end LSR MUST allocate an iden...' RFC 2119 keyword, line 103: '...NG message for the LSP MUST contain an...' RFC 2119 keyword, line 183: '...herwise, the LSR SHOULD return an erro...' (1 more instance...) 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 73, but not defined == Missing Reference: 'OSPF-GMPLS' is mentioned on line 73, but not defined == Missing Reference: 'CD-LDP' is mentioned on line 208, but not defined == Missing Reference: 'IANA' is mentioned on line 212, but not defined == Unused Reference: 'GMPLS-SIG' is defined on line 240, 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 Summary: 5 errors (**), 0 flaws (~~), 12 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: January 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-07.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. Overview 44 Supporting MPLS TE over unnumbered links (i.e., links that do not 45 have IP addresses) involves two components: (a) the ability to carry 46 (TE) information about unnumbered links in IGP TE extensions (ISIS or 47 OSPF), and (b) the ability to specify unnumbered links in MPLS TE 48 signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The 49 focus of this document is on the latter. 51 Current signalling used by MPLS TE doesn't provide support for 52 unnumbered links because the current signalling doesn't provide a way 53 to indicate an unnumbered link in its Explicit Route Objects. This 54 document proposes simple procedures and extensions that allow CR-LDP 55 signalling [CR-LDP] to be used with unnumbered links. 57 4. Link Identifiers 59 An unnumbered link has to be a point-to-point link. An LSR at each 60 end of an unnumbered link assigns an identifier to that link. This 61 identifier is a non-zero 32-bit number that is unique within the 62 scope of the LSR that assigns it. The IS-IS and/or OSPF and RSVP 63 modules on an LSR must agree on the identifiers. 65 There is no a priori relationship between the identifiers assigned to 66 a link by the LSRs at each end of that link. 68 LSRs at the two end points of an unnumbered link exchange with each 69 other the identifiers they assign to the link. Exchanging the 70 identifiers may be accomplished by configuration, by means of a 71 protocol such as LMP ([LMP]), by means of RSVP/CR-LDP (especially in 72 the case where a link is a Forwarding Adjacency, see below), or by 73 means of IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]). 75 Consider an (unnumbered) link between LSRs A and B. LSR A chooses an 76 idenfitier for that link. So is LSR B. From A's perspective we refer 77 to the identifier that A assigned to the link as the "link local 78 identifier" (or just "local identifier"), and to the identifier that 79 B assigned to the link as the "link remote identifier" (or just 80 "remote identifier"). Likewise, from B's perspective the identifier 81 that B assigned to the link is the local identifier, and the 82 identifier that A assigned to the link is the remote identifier. 84 This section is equally applicable to the case of unnumbered 85 component links (see [LINK-BUNDLE]). 87 5. Unnumbered Forwarding Adjacencies 89 If an LSR that originates an LSP advertises this LSP as an unnumbered 90 Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR 91 uses the Forwarding Adjacency formed by this LSP as an unnumbered 92 component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST 93 allocate an identifier to that Forwarding Adjacency (just like for 94 any other unnumbered link). Moreover, the REQUEST message used for 95 establishing the LSP that forms the Forwarding Adjacency MUST contain 96 an LSP_TUNNEL_INTERFACE_ID TLV (described below), with the LSR's 97 Router ID set to the head end's Router ID, and the Interface ID set 98 to the identifier that the LSR allocated to the Forwarding Adjacency. 100 If the REQUEST message contains the LSP_TUNNEL_INTERFACE_ID TLV, then 101 the tail-end LSR MUST allocate an identifier to that Forwarding 102 Adjacency (just like for any other unnumbered link). Furthermore, 103 the MAPPING message for the LSP MUST contain an 104 LSP_TUNNEL_INTERFACE_ID TLV, with the LSR's Router ID set to the 105 tail-end's Router ID, and the Interface ID set to the identifier 106 allocated by the tail-end LSR. 108 For the purpose of processing the ERO and the Interface ID TLV, an 109 unnumbered Forwarding Adjacency is treated as an unnumbered (TE) link 110 or an unnumbered component link as follows. The LSR that originates 111 the Adjacency sets the link local identifier for that link to the 112 value that the LSR allocates to that Forwarding Adjacency, and the 113 link remote identifier to the value carried in the Interface ID field 114 of the Reverse Interface ID TLV (for the definition of Reverse 115 Interface ID TLV see below). The LSR that is a tail-end of that 116 Forwarding Adjacency sets the link local identifier for that link to 117 the value that the LSR allocates to that Forwarding Adjacency, and 118 the link remote identifier to the value carried in the Interface ID 119 field of the Forward Interface ID TLV (for the definition of Forward 120 Interface ID see below). 122 5.1. LSP_TUNNEL_INTERFACE_ID TLV 124 The LSP_TUNNEL_INTERFACE ID TLV has Type to be determined by IETF 125 consensus and length 8. The format is given below. 127 This TLV can optionally appear in either a REQUEST message or a 128 MAPPING message. In the former case, we call it the "Forward 129 Interface ID" for that LSP; in the latter case, we call it the 130 "Reverse Interface ID" for the LSP. 132 Figure 1: LSP_TUNNEL_INTERFACE_ID TLV 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 |0|0| Type | Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | LSR's Router ID | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Interface ID (32 bits) | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 6. Signalling Unnumbered Links in EROs 146 A new Type of ER-Hop TLV of the Explicit Route Object (ERO) is used 147 to specify unnumbered links. This Type is called Unnumbered 148 Interface ID, and has the following format: 150 Figure 2: Unnumbered Interface ID 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 |0|0| Type = 0x0805 | Length = 12 | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 |L| Reserved | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Router ID | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Interface ID (32 bits) | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 The Type is 0x0805 (Unnumbered Interface ID) and the Length is 12. 165 The L bit is set to indicate a loose hop, and cleared to indicate a 166 strict hop. 168 The Interface ID is the identifier assigned to the link by the LSR 169 specified by the router ID. 171 6.1. Processing the IF_ID TLV 173 When an LSR receives a REQUEST message containing the IF_ID TLV (see 174 [GMPLS-CRLDP]) with the IF_INDEX TLV, the LSR processes this TLV as 175 follows. The LSR must have information about the identifiers assigned 176 by its neighbors to the unnumbered links between the neighbors and 177 the LSR. The LSR uses this information to find a link with tuple 178 matching the tuple carried in the IF_INDEX TLV. If the matching tuple is 180 found, the match identifies the link for which the LSR has to perform 181 label allocation. 183 Otherwise, the LSR SHOULD return an error. 185 6.2. Processing the ERO 187 The Unnumbered Interface ID ER-Hop is defined to be a part of a 188 particular abstract node if that node has the Router ID that is equal 189 to the Router ID field in the Unnumbered Interface ID ER-Hop, and if 190 the node has an (unnumbered) link or an (unnumbered) Forwarding 191 Adjacency whose local identifier (from that node's point of view) is 192 equal to the value carried in the Interface ID field of the 193 Unnumbered Interface ID ER-Hop. 195 With this in mind, the ERO processing in the presence of the 196 Unnumbered Interface ID ER-Hop follows the rules specified in section 197 4.8.1 of [CR-LDP]. 199 As part of the ERO processing, or to be more precise, as part of the 200 next hop selection, if the outgoing link is unnumbered, the REQUEST 201 message that the node sends to the next hop MUST include the IF_ID 202 TLV, with the IP address field of that TLV set to the Router ID of 203 the node, and the Interface ID field of that TLV set to the 204 identifier assigned to the link by the node. 206 7. IANA Considerations 208 RFC3036 [LDP] defines the LDP TLV name space. RFC3212 [CD-LDP] 209 further subdivides the range of RFC 3036 from that TLV space for TLVs 210 associated with the CR-LDP in the range 0x0800 - 0x08FF. 212 Following the policies outlined in [IANA], TLV types in this range 213 are allocated through an IETF Consensus action. 215 This document makes the following assignments: 217 TLV Type 218 -------------------------------------- ---------- 219 UNNUMBERED_INTERFACE_ID 0x0805 220 LSP_TUNNEL_INTERFACE_ID 0x08?? 221 8. Security Considerations 223 This document extends CR-LDP and raises no new security issues. CR- 224 LDP inherits the same security mechanism described in Section 4.0 of 225 [LDP] to protect against the introduction of spoofed TCP segments 226 into LDP session connection streams. 228 9. Acknowledgments 230 Thanks to Rahul Aggarwal for his comments on the text. Thanks too to 231 Bora Akyol, Vach Kompella, and George Swallow. 233 10. References 235 10.1. Normative references 237 [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using 238 LDP", RFC3212, December 2001 240 [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling 241 Functional Description", draft-ietf-generalized-mpls- 242 signalling-08.txt 244 [GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- 245 LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-06.txt 247 [LDP] Andersson, Loa, et al., "LDP Specification" RFC3036, January 248 2001 250 10.2. Non-normative references 252 [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 253 Bundling in MPLS Traffic Engineering", draft-kompella-mpls- 254 bundle-05.txt (work in progress) 256 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS 257 TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress) 259 [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", 260 draft-ietf-ccamp-lmp-03.txt (work in progress) 262 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 263 Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls- 264 extensions-11.txt (work in progress) 266 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 267 Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- 268 gmpls-extensions-07.txt (work in progress) 270 11. Author Information 272 Kireeti Kompella 273 Juniper Networks, Inc. 274 1194 N. Mathilda Ave. 275 Sunnyvale, CA 94089 276 e-mail: kireeti@juniper.net 278 Yakov Rekhter 279 Juniper Networks, Inc. 280 1194 N. Mathilda Ave. 281 Sunnyvale, CA 94089 282 e-mail: yakov@juniper.net 284 Alan Kullberg 285 NetPlane Systems, Inc. 286 Westwood Executive Center 287 200 Lowder Brook Drive 288 Westwood, MA 02090 289 e-mail: akullber@netplane.com