idnits 2.17.1 draft-ietf-mpls-crldp-unnum-05.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 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 181: '...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 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 (~~), 11 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: September 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-05.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 = 0x0805 | Length = 12 | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 |L| Reserved | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Router ID | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Interface ID (32 bits) | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 The Type is 0x0805 (Unnumbered Interface ID) and the Length is 12. 163 The L bit is set to indicate a loose hop, and cleared to indicate a 164 strict hop. 166 The Interface ID is the identifier assigned to the link by the LSR 167 specified by the router ID. 169 6.1. Processing the IF_ID TLV 171 When an LSR receives a REQUEST message containing the IF_ID TLV (see 172 [GMPLS-CRLDP]) with the IF_INDEX TLV, the LSR processes this TLV as 173 follows. The LSR must have information about the identifiers assigned 174 by its neighbors to the unnumbered links between the neighbors and 175 the LSR. The LSR uses this information to find a link with tuple 176 matching the tuple carried in the IF_INDEX TLV. If the matching tuple is 178 found, the match identifies the link for which the LSR has to perform 179 label allocation. 181 Otherwise, the LSR SHOULD return an error. 183 6.2. Processing the ERO object 185 The Unnumbered Interface ID subobject is defined to be a part of a 186 particular abstract node if that node has the Router ID that is equal 187 to the Router ID field in the subobject, and if the node has an 188 (unnumbered) link or an (unnumbered) Forwarding Adjacency whose local 189 identifier (from that node's point of view) is equal to the value 190 carried in the Interface ID field of the subobject. 192 With this in mind, the ERO processing in the presence of the 193 Unnumbered Interface ID subobject follows the rules specified in 194 section 4.8.1 of [CR-LDP]. 196 As part of the ERO processing, or to be more precise, as part of the 197 next hop selection, if the outgoing link is unnumbered, the REQUEST 198 message that the node sends to the next hop MUST include the IF_ID 199 TLV, with the IP address field of that TLV set to the Router ID of 200 the node, and the Interface ID field of that TLV set to the 201 identifier assigned to the link by the node. 203 7. Security Considerations 205 This document raises no new security concerns for CR-LDP. 207 8. Acknowledgments 209 Thanks to Rahul Aggarwal for his comments on the text. Thanks too to 210 Bora Akyol and Vach Kompella. 212 9. References 214 [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 215 Bundling in MPLS Traffic Engineering", draft-kompella-mpls- 216 bundle-05.txt (work in progress) 218 [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using 219 LDP", draft-ietf-mpls-cr-ldp-04.txt (work in progress) 221 [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling 222 Functional Description", draft-ietf-generalized-mpls- 223 signalling-05.txt 225 [GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- 226 LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-04.txt 228 [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic 229 Engineering", draft-ietf-isis-traffic-02.txt (work in progress) 231 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS 232 TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress) 234 [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to 235 OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress) 237 10. Author Information 238 Kireeti Kompella 239 Juniper Networks, Inc. 240 1194 N. Mathilda Ave. 241 Sunnyvale, CA 94089 242 e-mail: kireeti@juniper.net 244 Yakov Rekhter 245 Juniper Networks, Inc. 246 1194 N. Mathilda Ave. 247 Sunnyvale, CA 94089 248 e-mail: yakov@juniper.net 250 Alan Kullberg 251 NetPlane Systems, Inc. 252 Westwood Executive Center 253 200 Lowder Brook Drive 254 Westwood, MA 02090 255 e-mail: akullber@netplane.com