idnits 2.17.1 draft-ietf-mpls-crldp-unnum-02.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 an Authors' Addresses Section. ** 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 81: '... component link of a bundled link (see [BUNDLE]), the LSR MUST...' RFC 2119 keyword, line 85: '... MUST contain an LSP_TUNNEL_INTERFAC...' RFC 2119 keyword, line 92: '...the tail-end LSR MUST allocate an inte...' RFC 2119 keyword, line 94: '... for the LSP MUST contain an LSP_TUN...' RFC 2119 keyword, line 151: '... message, MUST contain the same Rout...' (7 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: 'LINK-BUNDLE' is mentioned on line 184, but not defined -- Possible downref: Normative reference to a draft: ref. '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: 8 errors (**), 0 flaws (~~), 8 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: March 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-02.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. Interface Identifiers 58 Since unnumbered links are not identified by an IP address, then for 59 the purpose of MPLS TE they need some other identifier. We assume 60 that each unnumbered link on a Label Switched Router (LSR) is given a 61 unique 32-bit identifier. The scope of this identifier is the LSR to 62 which the link belongs; moreover, the IS-IS and/or OSPF and CR-LDP 63 modules on an LSR must agree on interface identifiers. 65 Note that links are directed, i.e., a link l is from some LSR A to 66 some other LSR B. LSR A chooses the interface identifier for link l. 67 To be completely clear, we call this the "outgoing interface 68 identifier from LSR A's point of view". If there is a reverse link 69 from LSR B to LSR A (for example, a point-to-point SONET interface 70 connecting LSRs A and B would be represented as two links, one from A 71 to B, and another from B to A), B chooses the outgoing interface 72 identifier for the reverse link; we call this the link's "incoming 73 interface identifier from A's point of view". There is no a priori 74 relationship between the two interface identifiers. 76 5. Unnumbered Forwarding Adjacencies 78 If an LSR that originates an LSP advertises this LSP as an unnumbered 79 Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR 80 uses the Forwarding Adjacency formed by this LSP as an unnumbered 81 component link of a bundled link (see [BUNDLE]), the LSR MUST 82 allocate an interface identifier to that Forwarding Adjacency (just 83 like for any other unnumbered link). Moreover, the Request message 84 used for establishing the LSP that forms the Forwarding Adjacency 85 MUST contain an LSP_TUNNEL_INTERFACE_ID object (described below), 86 with the LSR's Router ID set to the head end's Router ID, and the 87 Interface ID set to the interface identifier that the LSR allocated 88 to the Forwarding Adjacency. 90 If the LSP is bidirectional, and the tail-end LSR (of the forward 91 LSP) advertises the reverse LSP as an unnumbered Forwarding 92 Adjacency, the tail-end LSR MUST allocate an interface identifier to 93 the reverse Forwarding Adjacency. Furthermore, the MAPPING message 94 for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the 95 LSR's Router ID set to the tail end's router ID, and the Interface ID 96 set to the interface identifier allocated by the tail-end LSR. 98 5.1. LSP_TUNNEL_INTERFACE_ID Object 100 The LSP_TUNNEL_INTERFACE ID object has Type to be determined by IETF 101 consensus and length 8. The format is given below. 103 Figure 1: Interface ID TLV 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 |0|0| Type | Length | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | LSR's Router ID | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Interface ID (32 bits) | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 This object can optionally appear in either a REQUEST message or a 116 MAPPING message. In the former case, we call it the "Forward 117 Interface ID" for that LSP; in the latter case, we call it the 118 "Reverse Interface ID" for the LSP. 120 6. Signalling Unnumbered Links in EROs 122 A new subobject of the Explicit Route Object (ERO) is used to specify 123 unnumbered links. This subobject has the following format: 125 Figure 2: Unnumbered Interface ID Subobject 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 |0|0| Type | Length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Router ID | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Interface ID (32 bits) | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 This subobject is strict. The Type is 0x0805 (Unnumbered Interface 138 ID) and the Length is 8. 140 The Interface ID is the outgoing interface identifier with respect to 141 the LSR specified by the router ID. 143 6.1. Processing the Unnumbered Interface ID Subobject 145 First of all, the receiving LSR must validate that it received the 146 Request message correctly. If the first subobject in the ERO is an 147 Unnumbered Interface subobject, the check is done as follows (for 148 other types of ERO subobjects, the rules in [CR-LDP] apply). 150 The IF_ID TLV ([GMPLS-SIG], [GMPLS-CRLDP]), if present in the 151 message, MUST contain the same Router ID (IP Address) as the Router 152 ID carried in the Unnumbered Interface ID subobject. If not, the 153 receiving LSR MUST return a "Bad Initial ER-Hop" error. If IF_ID TLV 154 is present, and it carries the IF_INDEX TLV, the receiving LSR SHOULD 155 check that the value carried in this TLV is the same as carried in 156 the Interface ID field of the Unnumbered Interface ID subobject. If 157 the value is different, the receiving LSR MUST return a "Bad Initial 158 ER-Hop" error. 160 If the above checks are passes, the LSR checks whether the tuple 161 from the Unnumbered Interface subobject 162 matches the tuple of any of the 163 LSPs for which the LSR is a tail-end. If a match is found, the match 164 identifies the Forwarding Adjacency for which the LSR has to perform 165 label allocation. 167 Otherwise, the LSR MUST check whether the tuple from the Unnumbered Interface subobject matches the tuple of any of the bidirectional LSPs for which 170 the LSR is the head-end. If a match is found, the match identifies 171 the Forwarding Adjacency for which the LSR has to perform label 172 allocation, namely, the reverse Forwarding Adjacency for the LSP 173 identified by the match. 175 Otherwise, the LSR must have information about the identifiers 176 assigned by its neighbors to the unnumbered links (i.e., incoming 177 interface identifiers from LSR's point of view). The LSR uses this 178 information to find a link with tuple matching the tuple from the 180 Unnumbered Interface subobject. If the matching tuple is found, and 181 the link is not a bundled link, the match identifies the link for 182 which the LSR has to perform label allocation. If the matching tuple 183 is found, and the link is a bundled link, the LSR follows the 184 procedures for label allocation as described in [LINK-BUNDLE]. 186 6.2. Selecting the Next Hop 188 Once an LSR determines the link for which the LSR has to perform 189 label allocation, the LSR removes the initial subobject in the ERO, 190 and computes the next hop. The next hop for an Unnumbered Interface 191 ID subobject is determined as follows. The Interface ID MUST refer 192 to an outgoing interface identifier that this node allocated; if not, 193 the node SHOULD return a "Bad Strict Node" error. The next hop is 194 the LSR at the other end of the link that the Interface ID refers to. 195 If this is the LSR itself, the subobject is removed, and the process 196 repeated. If the next node is some other LSR, this is the next hop 197 to which a Request message must be sent. 199 When sending a Request message to the next hop, if the message 200 carries the IF_ID object, then this object MUST contain the IF_INDEX 201 TLV, with IP Address in that TLV set to the LSR's Router ID, and 202 Interface ID set to the Interface ID carried in the first subobject 203 of the ERO. 205 7. Security Considerations 207 This document raises no new security concerns for CR-LDP. 209 8. Acknowledgments 211 Thanks to Rahul Aggarwal for his comments on the text. Thanks too to 212 Bora Akyol and Vach Kompella. 214 9. References 216 [BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in 217 MPLS Traffic Engineering", draft-kompella-mpls-bundle-05.txt (work in 218 progress) 220 [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using 221 LDP", draft-ietf-mpls-cr-ldp-04.txt (work in progress) 223 [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling 224 Functional Description", draft-ietf-generalized-mpls- 225 signalling-05.txt 227 [GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- 228 LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-04.txt 230 [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic 231 Engineering", draft-ietf-isis-traffic-02.txt (work in progress) 233 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS 234 TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress) 236 [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to 237 OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress) 238 10. Author Information 240 Kireeti Kompella 241 Juniper Networks, Inc. 242 1194 N. Mathilda Ave. 243 Sunnyvale, CA 94089 244 e-mail: kireeti@juniper.net 246 Yakov Rekhter 247 Juniper Networks, Inc. 248 1194 N. Mathilda Ave. 249 Sunnyvale, CA 94089 250 e-mail: yakov@juniper.net 252 Alan Kullberg 253 NetPlane Systems, Inc. 254 Westwood Executive Center 255 200 Lowder Brook Drive 256 Westwood, MA 02090 257 e-mail: akullber@netplane.com