idnits 2.17.1 draft-ietf-mpls-crldp-unnum-03.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 5 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 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 91: '... component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST...' RFC 2119 keyword, line 94: '... the Forwarding Adjacency MUST contain...' RFC 2119 keyword, line 100: '...the tail-end LSR MUST allocate an iden...' RFC 2119 keyword, line 102: '...NG message for the LSP MUST contain an...' RFC 2119 keyword, line 177: '...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: 'LMP' is mentioned on line 70, but not defined == Missing Reference: 'ISIS-GMPLS' is mentioned on line 72, but not defined == Missing Reference: 'OSPF-GMPLS' is mentioned on line 72, but not defined == Unused Reference: 'GMPLS-SIG' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'GMPLS-CRLDP' is defined on line 221, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'LINK-BUNDLE' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-04 -- 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-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-02 == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-04 Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 5 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: June 2002 Yakov Rekhter 5 Juniper Networks 6 Alan Kullberg 7 NetPlane Systems 9 Signalling Unnumbered Links in CR-LDP 11 draft-ietf-mpls-crldp-unnum-03.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 MPLS TE doesn't provide support for 37 unnumbered links. This document defines procedures and extensions to 38 CR-LDP, one of the MPLS TE signalling protocols, that are needed in 39 order to support unnumbered links. 41 3. Overview 43 Supporting MPLS TE over unnumbered links (i.e., links that do not 44 have IP addresses) involves two components: (a) the ability to carry 45 (TE) information about unnumbered links in IGP TE extensions (ISIS or 46 OSPF), and (b) the ability to specify unnumbered links in MPLS TE 47 signalling. The former is covered in [ISIS-TE, OSPF-TE]. The focus 48 of this document is on the latter. 50 Current signalling used by MPLS TE doesn't provide support for 51 unnumbered links because the current signalling doesn't provide a way 52 to indicate an unnumbered link in its Explicit Route Objects. This 53 document proposes simple procedures and extensions that allow CR-LDP 54 signalling [CR-LDP] to be used with unnumbered links. 56 4. Link Identifiers 58 An unnumbered link has to be a point-to-point link. An LSR at each 59 end of an unnumbered link assigns an identifier to that link. This 60 identifier is a non-zero 32-bit number that is unique within the 61 scope of the LSR that assigns it. The IS-IS and/or OSPF and RSVP 62 modules on an LSR must agree on the identifiers. 64 There is no a priori relationship between the identifiers assigned to 65 a link by the LSRs at each end of that link. 67 LSRs at the two end points of an unnumbered link exchange with each 68 other the identifiers they assign to the link. Exchanging the 69 identifiers may be accomplished by configuration, by means of a 70 protocol such as LMP ([LMP]), by means of RSVP/CR-LDP (especially in 71 the case where a link is a Forwarding Adjacency, see below), or by 72 means of IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]). 74 Consider an (unnumbered) link between LSRs A and B. LSR A chooses an 75 idenfitier for that link. So is LSR B. From A's perspective we refer 76 to the identifier that A assigned to the link as the "link local 77 identifier" (or just "local identifier"), and to the identifier that 78 B assigned to the link as the "link remote identifier" (or just 79 "remote identifier"). Likewise, from B's perspective the identifier 80 that B assigned to the link is the local identifier, and the 81 identifier that A assigned to the link is the remote identifier. 83 This section is equally applicable to the case of unnumbered 84 component links (see [LINK-BUNDLE]). 86 5. Unnumbered Forwarding Adjacencies 88 If an LSR that originates an LSP advertises this LSP as an unnumbered 89 Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR 90 uses the Forwarding Adjacency formed by this LSP as an unnumbered 91 component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST 92 allocate an identifier to that Forwarding Adjacency (just like for 93 any other unnumbered link). Moreover, the REQUEST message used for 94 establishing the LSP that forms the Forwarding Adjacency MUST contain 95 an LSP_TUNNEL_INTERFACE_ID TLV (described below), with the LSR's 96 Router ID set to the head end's Router ID, and the Interface ID set 97 to the identifier that the LSR allocated to the Forwarding Adjacency. 99 If the REQUEST message contains the LSP_TUNNEL_INTERFACE_ID TLV, then 100 the tail-end LSR MUST allocate an identifier to that Forwarding 101 Adjacency (just like for any other unnumbered link). Furthermore, 102 the MAPPING message for the LSP MUST contain an 103 LSP_TUNNEL_INTERFACE_ID TLV, with the LSR's Router ID set to the 104 tail-end's Router ID, and the Interface ID set to the identifier 105 allocated by the tail-end LSR. 107 For the purpose of processing the ERO and the Interface ID TLV, an 108 unnumbered Forwarding Adjacency is treated as an unnumbered (TE) link 109 or an unnumbered component link as follows. The LSR that originates 110 the Adjacency sets the link local identifier for that link to the 111 value that the LSR allocates to that Forwarding Adjacency, and the 112 link remote identifier to the value carried in the Interface ID field 113 of the Reverse Interface ID TLV (for the definition of Reverse 114 Interface ID TLV see below). The LSR that is a tail-end of that 115 Forwarding Adjacency sets the link local identifier for that link to 116 the value that the LSR allocates to that Forwarding Adjacency, and 117 the link remote identifier to the value carried in the Interface ID 118 field of the Forward Interface ID TLV (for the definition of Forward 119 Interface ID see below). 121 5.1. LSP_TUNNEL_INTERFACE_ID TLV 123 The LSP_TUNNEL_INTERFACE ID TLV has Type to be determined by IETF 124 consensus and length 8. The format is given below. 126 This TLV can optionally appear in either a REQUEST message or a 127 MAPPING message. In the former case, we call it the "Forward 128 Interface ID" for that LSP; in the latter case, we call it the 129 "Reverse Interface ID" for the LSP. 131 Figure 1: LSP_TUNNEL_INTERFACE_ID 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 | LSR's Router ID | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Interface ID (32 bits) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 6. Signalling Unnumbered Links in EROs 145 A new subobject of the Explicit Route Object (ERO) is used to specify 146 unnumbered links. This subobject has the following format: 148 Figure 2: Unnumbered Interface ID Subobject 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 |0|0| Type | Length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Router ID | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Interface ID (32 bits) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 The Type is 0x0805 (Unnumbered Interface ID) and the Length is 8. 162 The Interface ID is the identifier assigned to the link by the LSR 163 specified by the router ID. 165 6.1. Processing the IF_ID TLV 167 When an LSR receives a REQUEST message containing the IF_ID TLV with 168 the IF_INDEX TLV, the LSR processes this TLV as follows. The LSR 169 must have information about the identifiers assigned by its neighbors 170 to the unnumbered links between the neighbors and the LSR. The LSR 171 uses this information to find a link with tuple matching the tuple carried in 173 the IF_INDEX TLV. If the matching tuple is found, the match 174 identifies the link for which the LSR has to perform label 175 allocation. 177 Otherwise, the LSR SHOULD return an error. 179 6.2. Processing the ERO object 181 The Unnumbered Interface ID subobject is defined to be a part of a 182 particular abstract node if that node has the Router ID that is equal 183 to the Router ID field in the subobject, and if the node has an 184 (unnumbered) link or an (unnumbered) Forwarding Adjacency whose local 185 identifier (from that node's point of view) is equal to the value 186 carried in the Interface ID field of the subobject. 188 With this in mind, the ERO processing in the presence of the 189 Unnumbered Interface ID subobject follows the rules specified in 190 section 4.8.1 of [CR-LDP]. 192 As part of the ERO processing, or to be more precise, as part of the 193 next hop selection, if the outgoing link is unnumbered, the REQUEST 194 message that the node sends to the next hop MUST include the IF_ID 195 TLV, with the IP address field of that TLV set to the Router ID of 196 the node, and the Interface ID field of that TLV set to the 197 identifier assigned to the link by the node. 199 7. Security Considerations 201 This document raises no new security concerns for CR-LDP. 203 8. Acknowledgments 205 Thanks to Rahul Aggarwal for his comments on the text. Thanks too to 206 Bora Akyol and Vach Kompella. 208 9. References 210 [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 211 Bundling in MPLS Traffic Engineering", draft-kompella-mpls- 212 bundle-05.txt (work in progress) 214 [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using 215 LDP", draft-ietf-mpls-cr-ldp-04.txt (work in progress) 217 [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling 218 Functional Description", draft-ietf-generalized-mpls- 219 signalling-05.txt 221 [GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- 222 LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-04.txt 224 [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic 225 Engineering", draft-ietf-isis-traffic-02.txt (work in progress) 227 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS 228 TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress) 230 [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to 231 OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress) 233 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 Westwood Executive Center 250 200 Lowder Brook Drive 251 Westwood, MA 02090 252 e-mail: akullber@netplane.com