idnits 2.17.1 draft-pdutta-mpls-tldp-hello-reduce-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 01, 2012) is 4248 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-seamless-mpls-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Dutta 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track G. Heron 5 Expires: March 5, 2013 Cisco Systems 6 T. Nadeau 7 Juniper Networks 8 September 01, 2012 10 Targeted LDP Hello Reduction 11 draft-pdutta-mpls-tldp-hello-reduce-04 13 Abstract 15 Targeted LDP (t-LDP) Hellos are used for establishing adjacencies 16 with non-directly connected peers. After an LDP session is 17 established to a Targeted Peer, there are deployment scenerios where 18 it is not necessary to send Targeted LDP Hellos at the configured 19 intervals. This document proposes a mechanism to turn off or reduce 20 the rate of exchange of Targeted LDP Hellos after LDP session is 21 established to a peer. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 5, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Targeted LDP Hello Reduction Procedure . . . . . . . . . . . . 4 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 6. Operational Considerations . . . . . . . . . . . . . . . . . . 6 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 LDP Hello messages are exchanged as part of the LDP discovery 78 mechanism [RFC5036]. There are two types of LDP discovery mechanism 79 described in [RFC5036]- Basic Discovery and Extended Discovery. 81 To engage in LDP Basic Discovery on an interface, an LSR periodically 82 sends LDP Link Hellos out the interface to the well-known LDP 83 discovery port for the "all routers on this subnet" group multicast 84 address. Receipt of an LDP Link Hello on an interface, identifies a 85 hello adjacency with a potential LDP peer reachable at the link level 86 on the interface. Thus an LSR may establish hello adjacency with 87 multiple peers discovered over a single interface and must continue 88 to transmit hellos at regular intervals even after hello adjacency is 89 established to a peer. 91 Extended discovery is used to support LDP sessions between non- 92 directly connected LSRs. An LDP Targeted Hello is sent to a specific 93 address rather than to the "all routers" group multicast address for 94 the ongoing interface. Receipt of a LDP Targeted Hello indentifies a 95 hello adjacency with a potential LDP peer at network level. 97 In Extended discovery there can be only one Targeted Hello Adjacency 98 between two peers. Note that throughout this document "peer" means 99 the LDP LSR designated by a unique LDP Identifier. Once the LDP 100 session is operational between two targeted LDP peers, periodic 101 session Keepalives are used to maintain the LDP session. There are 102 certain deployment scenerios where after the session is operational 103 the periodic Targeted Hellos between the LSRs become redundant, as 104 session Keepalives in turn serves the intent of each LSR to maintain 105 its adjacency to its peer. Moreover additional mechanisms such as 106 centralized BFD [RFC5880] may be used to track liveliness of ldp 107 sessions. 109 When an LSR maintains a large number of LDP sessions (thousands) to 110 Targeted peers, it is an additional burden to send and receive 111 Targeted Hellos for all peers at periodic intervals. In MPLS 112 deployments at access or mobility backhaul or in Seamless MPLS 113 [I-D.ietf-mpls-seamless-mpls] , there can be very large volume of LDP 114 sessions (e.g 10,000) with targeted LDP adjacencies to each base 115 station (or last mile in a MPLS domain). 117 Another problem with targeted hello adjacency arises is Denial Of 118 Service (DoS) attacks. It is possible that existing hello 119 adjacencies can get lost due to DoS attack on LDP Hello receiver by 120 spurious hello packets. Unlike TCP sessions it is not always 121 possible to provide per peer protection for UDP based hellos. 122 Implementations can use methods to protect existing adjacencies while 123 throttling spurious adjacencies but such methods may not be available 124 in low cost MPLS devices deployed in access. So it is important to 125 avoid dependency on Targeted LDP hellos on t-LDP adjacency 126 maintenance as far as possible. Reduction of Hellos provide 127 probabilistically better resilience on maintenance of hello 128 adjacencies during sporadic hello attacks. 130 This document proposes an OPTIONAL mechanism to turn off Targeted LDP 131 Hellos after a LDP session is established to a targeted peer, without 132 changes in the procedures defined in [RFC5036]. The solutions 133 described in this document may not be applicable in scenerios where 134 Session Keepalives or BFD may not act as substitute for Targeted LDP 135 Hellos. Refer to section 6 for operational considerations while 136 deploying the solution described in this document. 138 2. Terminology 140 This document uses the terminology defined in [RFC3031] and 141 [RFC5036]. 143 3. Targeted LDP Hello Reduction Procedure 145 The Targeted LDP Hello Reduction procedure uses the existing Common 146 Hello Parameters TLV defined in [RFC5036]. Figure 1. shows the 147 encoding of the TLV from [RFC5036] for reference. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 |0|0| Common Hello Parms(0x0400)| Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Hold Time |T|R| Reserved | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Figure 1. Common Hello Parameters TLV. 159 By definition in [RFC5036], a value of 0 means use the default, which 160 is 45 seconds for Targeted Hellos. A value of 0xffff means infinite. 162 The procedure to be followed for Targeted LDP Hello Reduction between 163 a pair of LSRs is as follows: 165 1. An LSR starts transmitting periodic targeted hellos to its peer 166 in order to establish the targeted hello adjacency. Each LSR 167 proposes its configured hello hold time in the Common Hello 168 Parameters TLV in its hello message to the peer. The hold time used 169 between a pair of LSRs is the minimum of the hold times proposed in 170 their Hellos. 172 2. If the Hello is acceptable by receiving LSR, it establishes 173 targeted hello adjacency with the source LSR. Establishment of Hello 174 adjacency establishes the LDP session between peering LSRs. 176 3. After the LDP session is ESTABLISHED [RFC5036], each LSR MAY 177 start proposing "relaxed" hold time (higher than configured) in 178 Common Hello Parameters TLV in the subsequent Hello Messages. 180 Each LSR increases the advertised hold time by some factor after 181 sending a set of Hellos (let's say 5) advertising consistent hold 182 time. As the process of relaxing the advertised hold time continues, 183 after a certain period of time an LSR reaches the maximum holdtime 184 value of 0xffff. Thus after the session is ESTABLISHED, the hello 185 hold time between the LSRs gets negotiated to infinite. Note that 186 the Targeted Hello Adjacency continue to exist and only the adjacency 187 hold times are now infinite. 189 4. If there are any changes in any parameters associated with a 190 t-LDP Hello adjacency (e.g Configuration Sequence Number etc) then an 191 updated Hello MUST be sent immediately without any changes to the 192 "current" hold time (e.g inifinite) that was advertised in the last 193 Hello Message. Since hellos are not reliable, after any parameter 194 change an implementation may send a set of hellos (let's say 5) at 195 configured intervals (or faster) to reflect the change. But those 196 hellos would continue to advertise infinite hold time and would fall 197 back to reduced transmission rate after those 5 packets are sent. 199 5. If the LDP session between two LSRs fails leading to tearing down 200 of adjacency, then each LSR reverts to advertising their configured 201 hello hold time and repeats procedure 1 to 3. This also applies when 202 LDP session restarts gracefully [RFC3478] when peering LSRs are 203 graceful restart capable. Thus the reduction procedures allow an 204 operator to configure very aggressive Targeted LDP Hello Holdtime to 205 expedite bringing up a large number of LDP sessions in the event of 206 failure but reduces the overhead of hello adjacency maintenance by 207 manifold when sessions are ESTABLISHED. It is desirable to configure 208 aggressive hold times in order to tear down spurious hello 209 adjacencies sooner. 211 6. When a t-LDP adjacency with a remote LSRs has negotiated to 212 infinite hold time and then remote LSR decides to tear down the 213 adjacency without impacting the established LDP Session then local 214 LSR would not be able to detect that remote node is no longer 215 accepting hellos. It is RECOMMENDED that when a LSR that implements 216 the Hello Reduction procedures send one or a set of contiguous hellos 217 (let's say 3) advertising hold time of 1 second while bringing down 218 t-LDP Hello adjacency. This graceful closure procedure would cause 219 the hello holdtimes at receiving LSR to be renegotiated to 1 second, 220 which would eventually lead to tear down of the adjacency (due to 221 timeout) by receiving LSR. 223 It is RECOMMENDED that each peering LSR implements the Targeted LDP 224 Hello Reduction procedure; otherwise negotiated hello hold time 225 between the LSRs does not fall back to the infinite hold time in step 226 3. 228 Note that it is not mandatory to advertise infinite hold time after 229 session is established but can be any value that is significantly 230 larger than configured hello hold time. However, it is RECOMMENDED 231 to reach Infinite holdtime after session setup to derive maximum 232 advantage from the procedure described above. 234 The Hello Reduction procedures does not apply to Basic Discovery 235 (Link LDP Hellos) as Link LDP Hellos need to be sent over an interval 236 continually in order to discover and set up sessions with new peers, 237 especially over a multi-access interface. 239 4. IANA Considerations 241 This document makes no request of IANA. 243 Note to RFC Editor: this section may be removed on publication as an 244 RFC. 246 5. Security Considerations 248 - Control plane aspects 250 - LDP security (authentication) methods as described in [RFC5036] is 251 applicable here. 253 - Data plane aspects 255 - This specification does not have any impact on the MPLS forwarding 256 plane setup by LDP. 258 6. Operational Considerations 260 The method proposed in the document reduces significant burden on an 261 LDP LSR that maintains Targeted LDP sessions to a large number (in 262 thousands) of peers. Further, if BFD [RFC5880] [RFC5883] is used for 263 tracking connectivity to peers it is desirable to turn off Targeted 264 LDP hellos after the LDP session is setup. However there are 265 scenerios where tunring off Targeted LDP Hellos may not be desirable. 266 Such scenerios are as follows: 268 1. When transport address of the LDP session is different from the 269 IP addresses used to exchange t-LDP Hellos then Session Keepalives 270 are not substitute for reachability or liveliness of adjacency. It 271 is possible to use BFD to track the reachability of IP addresses used 272 for t-LDP Hellos in which case t-LDP Hellos may be redundant. 273 However if an implementation/deployment uses t-LDP hellos for 274 purposes other than liveliness tracking then it is not recommended to 275 turn on t-LDP hello reduction procedures. 277 2. While t-LDP Hello Reduction Procedures are deployed, it may be 278 possible that t-LDP Hellos are disabled at remote LSR without 279 bringing down the LDP session. If the remote LSR does not implement 280 the procedure for graceful teardown of hello adjacency as described 281 in step 6 in section 3 then it is possible that local LSR may not be 282 able detect that remote LSR is no longer accepting Hellos and thus 283 Hello adjacency would continue to exist in local LSR. It is also 284 possible that the hello(s) sent during graceful cloure of adjacency 285 may get lost (since LDP Hellos are not reliable) and thus local LSR 286 may not detect the loss of adjacency with remote LSR. 288 7. Acknowledgements 290 The authors would like acknowledge the detailed review and the 291 comments, suggestions from Markus Jork, Thomas Beckhaus, Lizhong Zin 292 and Eric Rosen. 294 8. References 296 8.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 302 Specification", RFC 5036, October 2007. 304 8.2. Informative References 306 [I-D.ietf-mpls-seamless-mpls] 307 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 308 M., and D. Steinberg, "Seamless MPLS Architecture", 309 draft-ietf-mpls-seamless-mpls-01 (work in progress), 310 March 2012. 312 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 313 Label Switching Architecture", RFC 3031, January 2001. 315 [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful 316 Restart Mechanism for Label Distribution Protocol", 317 RFC 3478, February 2003. 319 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 320 (BFD)", RFC 5880, June 2010. 322 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 323 (BFD) for Multihop Paths", RFC 5883, June 2010. 325 Authors' Addresses 327 Pranjal Kumar Dutta 328 Alcatel-Lucent 329 701 E Middlefield Road 330 Mountain View, CA 94043 331 USA 333 Email: pranjal.dutta@alcatel-lucent.com 335 Giles Heron 336 Cisco Systems 337 9-11 New Square 338 Bedfont Lakes, Feltham, Middlesex TW14 8HA 339 United Kingdom 341 Email: giheron@cisco.com 343 Thomas Nadeau 344 Juniper Networks 346 Email: tnadeau@juniper.net