idnits 2.17.1 draft-shen-mpls-ldp-nnhop-label-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 321. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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) -- Looks like a reference, but probably isn't: 'R3' on line 85 ** Obsolete normative reference: RFC 3036 (ref. '1') (Obsoleted by RFC 5036) -- Possible downref: Normative reference to a draft: ref. '3' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Naiming Shen 2 Internet Draft Enke Chen 3 Cisco Systems 4 Expiration Date: November 2005 Albert Tian 5 Redback Networks 7 Discovering LDP Next-Nexthop Labels 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or 16 she becomes aware will be disclosed, in accordance with Section 6 17 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This document specifies extensions to LDP in support of next-nexthop 39 label discovery. The next-nexthop label information can be used to 40 fast re-route LDP LSP traffic into an explicitly routed tunnel 41 for nexthop node protection in the case of a link or node failure. 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC-2119 [5]. 49 1. Introduction 51 As currently specified in [1], the LDP protocol only needs to know 52 label mapping for the adjacent peers and there is no way for an LSR 53 to learn the adjacent peer's downstream label mapping. This document 54 proposes an LDP extension that allows an LSR to discover the 55 next-nexthop label mapping from its downstream peers. 57 One application for learning the next-nexthop label mapping is 58 for fast re-route. Similar to the facility based node-protection 59 of LSP Fast ReRoute [2], the NFRR (Nexthop Fast ReRoute) [3] scheme 60 allows an LSR to perform Fast ReRoute on any type of traffic, 61 including LDP LSP traffic. When the Nexthop Fast ReRoute is used 62 for node-protection of LDP LSP traffic, the next-nexthop labels are 63 needed to tunnel the data traffic into the next-nexthop LSR in the 64 case of a link or node failure. 66 A new Status TLV code is specified for an LSR to indicate its 67 interest in receiving the next-nexthop label mapping information. 68 A new Next-Nexthop Label TLV is specified to pass the downstream 69 label mapping to the upstream LSR in the Label Mapping Message. 71 The extension specified in this document assumes the next-nexthop 72 nodes use platform-wide label space for LDP. It is outside the 73 scope of this document when the next-nexthop nodes use 74 per-interface label space. 76 2. LDP Next-Nexthop Label Mapping Scheme 78 2.1 Example 80 Confiser LSRs interconnected with LDP as the following: 82 +----------+ 83 | lsp2 | (link-protection) 84 | V 85 | ||=>c[R3] 86 | || 87 [R1]====>[R2]a=|| X 88 | || / 89 | ||===>b[R4]====>[R5] 90 | (x2) (x1) ^ 91 | | 92 | (z1) (z2) | 93 +-------[R6]-----------+ 94 lsp1 (node-protection) 96 Figure 1: NFRR node-protection for LDP data traffic 98 R2 is the PLR (Point of Local Repair) node, the lsp1 is the 99 NFRR [3] LSP for the purpose of protecting node R4 over R2's 100 interface "a". The lsp2 is the NFRR LSP for link protection in 101 the case of interface "a" or "c" is down. We will only be 102 concerned with node-protection using lsp1 in this document. 104 R5 advertises FEC X to R4 with label x1. R4 advertises the same 105 FECs with label x2 to upstream peer R2. The RSVP signaled lsp1 106 uses label z1 from R2 to R6 and z2 from R6 to R5, and z2 can 107 also be an implicit null. 109 When R2 detects either the interface "a" is down, or the nexthop 110 "b" is unreachable, or LSR R4 is down, the forwarding engine on 111 R2 will re-direct the LDP data traffic into the NFRR tunnel lsp1. 112 This can be quickly done by pushing the label x1 onto the label 113 stack and send the packet through the lsp1 for LDP data traffic 114 going to FEC X. As long as the platform-wide label space is 115 used on LSR R5, the R5 does not even know the difference. In 116 this case, the next-nexthop label x1 is used by PLR node R2 117 for fast re-route with node-protection. For this scheme to work, 118 LSR R4 needs to advertise the next-nexthop label x1 to the 119 upstream LSR R2 in addition to their own label mapping of x2 for 120 the same FEC. 122 2.2 Next-Nexthop Label Request 124 Take the same example as in section 2.1, a user can statically 125 configure on LSR R4 that it needs to include downstream labels 126 to all or some of the upstream peers while it advertises the 127 label mappings. A better way is for LSR R2 to make a request 128 to its peer R4 that it is interested in receiving the next-nexthop 129 label mapping information, since R2 has already been configured 130 to perform node-protection for LSR R4. 132 When the LDP peer between R2 and R4 is up, and there is at least 133 one NFRR lsp configured on R2 to perform node-protection of R4, 134 R2 can optionally send a Notification Message with the Next-Nexthop 135 Label Request bit set in the Status TLV. When the last NFRR LSP 136 protecting node R4 is removed, R2 can optionally send the 137 Notification Message to R4 with the Next-Nexthop Label Withdraw bit 138 set in the Status TLV. 140 2.3 Next-Nexthop Label Advertisement 142 When an LSR advertises the FEC-label bindings to its peer, if it 143 has received the Next-Nexthop Label Request from that peer or the 144 LSR is configured with this capability, it SHOULD include the 145 next-nexthop label mapping information when applicable in the 146 Label Mapping Message. 148 An optional Next-Nexthop Label TLV is defined to be used in the 149 Label Mapping Message. The Next-Nexthop Label contains a list 150 of (label, downstream router-id) tuples. More than one tuple 151 can be used when there is an ECMP case to different downstream 152 nodes for the same FECs. It is an implementation and local 153 configuration issue whether to announce only one or multiple 154 tuples in the ECMP case. 156 If some FECs are not advertised with next-nexthop labels, then 157 no node-protection can be performed on those FECs. But they 158 can still be fast re-routed with NFRR link-protection scheme [3]. 159 If there is a NFRR LSP built from R2 to R4, then the LDP data 160 traffic will be re-routed directly onto R4 itself. The 161 node-protection is not meant for all the situations. Usually 162 node-protection is used in the backbone portion of the network, 163 and link-protection is used close to the edge of the network. 165 2.4 Next-Nexthop Label Update 167 If an LSR advertises the Next-Nexthop Label TLV in the Label 168 Mapping Messages, and when the next-nexthop label information 169 changes, it MUST re-send the Label Mapping Message with updated 170 next-nexthop label information. The LSR SHOULD implement a means 171 to dampen the re-advertisement to avoid potentially excessive 172 updating due to link flapping. 174 2.5 Comparing with Targeted LDP Session Approach 176 The discovering Next-Nexthop LDP label scheme described in this 177 document relies on the downstream LDP nodes to relay the label 178 mapping of Next-Nexthop LDP nodes. This approach has a number of 179 advantages in comparing with directly setting up targeted LDP 180 sessions to the Next-Nexthop LDP nodes. 182 When using the downstream LDP nodes relaying label mapping message, 183 not only there is less configuration involved, but also the 184 network will have less LDP sessions to be established. 186 In the case of two and more Next-Nexthop LDP nodes advertising the 187 same route to their immediate upstream nodes, the selection of 188 the nexthops follows the underlying routing. This is not the 189 case in the targeted LDP session in general. When the PLR receives 190 from two Next-Nexthop LDP nodes on the label binding of the same 191 route directly, there is no way for it to tell which one should 192 be preferred or both of them need to be used for loadsharing. The 193 targeted LDP session approach might couple the IGP topology 194 information in the route selection process, but it would make the 195 solution more complex especially in the case of nexthop LDP node 196 being an area border router. 198 3. Next-Nexthop Label Packet Encoding 200 3.1 Next-Nexthop Label Bits in Status TLV 202 The Next-Nexthop Label Request/Withdraw information is sent in the 203 Notification Message. Two bits (to be allocated by IANA) are 204 defined in this document, one for Request and one for Withdraw. 205 Unlike most of the bits already defined in the Status TLV, 206 the Next-Nexthop Label Bits are used by an LSR to dynamically 207 announce a capability to its peers. 209 The E bit and F bit MUST be set to zero if Next-Nexthop Label 210 Request or Withdraw is the only status code set. The Next-Nexthop 211 Label Bits SHOULD only be used in Notification Message, otherwise 212 it MUST be quietly ignored upon receipt. 214 3.2 Next-Nexthop Label TLV in Label Mapping Message 216 The Next-Nexthop Label TLV can be optionally carried in the Optional 217 Parameters field of a Label Mapping Message. The TLV consists a 218 list of (label, router-id) pairs with the following format: 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |0|0| Next-Nexthop Label (IANA) | Length (4 + N * 8 bytes) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | NNhop-Label 1 | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | NNhop Router-ID 1 | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 // // 230 // // 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | NNhop-Label N | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | NNhop Router-ID N | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 NNhop-Label 238 Next-Nexthop Label. This is a 20-bit label value as specified 239 in [4] represented as a 20-bit number in a 4 octet field. 241 NNhop Router-ID 242 Next-Nexthop router-ID which advertised that next-nexthop label. 243 This is a 4 octet number. 245 4. Security Considerations 247 This mechanism does not introduce any new security issue in LDP. 249 5. IANA Considerations 251 Two new bits in Status TLV and a new LDP TLV Type is defined in 252 section 3. This LDP extension requires that IANA allocate those 253 numbers. 255 6. Acknowledgments 257 TBD. 259 7. References 261 [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. 262 Thomas, "LDP Specification", RFC 3036, January 2001. 264 [2] Pan, P., Gan, D., Swallow, G., Vasseur, J.Ph., Copper, D., 265 Atlas, A., Jork, M., "Fast Reroute Technique in RSVP-TE", 266 Internet draft, draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt, 267 work in progress. 269 [3] Shen, N., Pan, P., "Nexthop Fast ReRoute for IP and MPLS", 270 Internet draft, draft-shen-nhop-fastreroute-01.txt, work in 271 progress. 273 [4] Rosen, E., Tappan, D., Federkow, G., Rekhter, Y., Farinacci, D., 274 Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, 275 January 2001. 277 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 278 Levels", BCP 14, RFC 2119, March 1997. 280 8. Authors' Addresses 282 Naiming Shen 283 Cisco Systems 284 170 W. Tasman Drive 285 San Jose, CA, 95134 USA 286 e-mail: naiming@cisco.com 287 Enke Chen 288 Cisco Systems 289 170 W. Tasman Drive 290 San Jose, CA, 95134 USA 291 e-mail: enke@cisco.com 293 Albert Tian 294 Redback Networks, Inc. 295 300 Holger Way 296 San Jose, CA 95134 297 e-mail: tian@redback.com 299 Intellectual Property 301 The IETF takes no position regarding the validity or scope of any 302 Intellectual Property Rights or other rights that might be claimed 303 to pertain to the implementation or use of the technology described 304 in this document or the extent to which any license under such 305 rights might or might not be available; nor does it represent that 306 it has made any independent effort to identify any such rights. 307 Information on the procedures with respect to rights in RFC 308 documents can be found in BCP 78 and BCP 79. 310 Copies of IPR disclosures made to the IETF Secretariat and any 311 assurances of licenses to be made available, or the result of an 312 attempt made to obtain a general license or permission for the use 313 of such proprietary rights by implementers or users of this 314 specification can be obtained from the IETF on-line IPR repository 315 at http://www.ietf.org/ipr. 317 The IETF invites any interested party to bring to its attention any 318 copyrights, patents or patent applications, or other proprietary 319 rights that may cover technology that may be required to implement 320 this standard. Please address the information to the IETF at 321 ietf-ipr@ietf.org. 323 Full Copyright Notice 325 Copyright (C) The Internet Society (2005). This document is subject 326 to the rights, licenses and restrictions contained in BCP 78, and 327 except as set forth therein, the authors retain all their rights. 329 This document and the information contained herein are provided on 330 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 331 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 332 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 333 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 334 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 335 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 336 PARTICULAR PURPOSE. 338 Acknowledgment 340 Funding for the RFC Editor function is currently provided by the 341 Internet Society.