MPLS Working Group Pranjal Kumar Dutta Internet Draft Alcatel-Lucent Intended status: Standards Track Expires: September 2009 Giles Heron Thomas Nadeau BT March 3, 2009 Targeted LDP Hello Reduction draft-pdutta-mpls-tldp-hello-reduce-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 3, 2009. Abstract Targeted LDP Hellos are used for establishing adjacencies with non- directly connected peers. After an LDP session is established to a targeted peer, the session Keepalives are sufficient to notify the intent of an LSR to maintain its adjacency with the peer. This document proposes a mechanism to turn off Targeted LDP Hellos after LDP session is established to a peer. Dutta, et. al. Expires September 3, 2009 [Page 1] Internet-Draft T-LDP Hello Reduction March 2009 Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Terminology....................................................3 4. Targeted LDP Hello Reduction Procedure.........................3 5. Security Considerations........................................4 6. IANA Considerations............................................4 7. Conclusion.....................................................5 8. References.....................................................5 8.1. Normative References......................................5 8.2. Informative References....................................5 9. Acknowledgments................................................5 1. Introduction LDP Hello messages are exchanged as part of the LDP discovery mechanism [RFC5036]. There are two types of LDP discovery mechanism described in [RFC5036] - Basic Discovery and Extended Discovery. To engage in LDP Basic Discovery on an interface, an LSR periodically sends LDP Link Hellos out the interface to the well-known LDP discovery port for the "all routers on this subnet" group multicast address. Receipt of an LDP Link Hello on an interface, identifies a hello adjacency with a potential LDP peer reachable at the link level on the interface. Thus an LSR may establish hello adjacency with multiple peers discovered over a single interface and must continue to transmit hellos at regular intervals even after hello adjacency is established to a peer. Extended discovery is used to support LDP sessions between non- directly connected LSRs. An LDP Targeted Hello is sent to a specific address rather than to the "all routers" group multicast address for the ongoing interface. Receipt of a LDP Targeted Hello indentifies a hello adjacency with a potential LDP peer at network level. In Extended discovery there can be only one Targeted Hello Adjacency between two peers. Note that throughout this document "peer" means the LDP LSR designated by a unique LDP Identifier. Once the LDP session is operational between two targeted LDP peers, periodic session Keepalives are used to maintain the LDP session. After the session is operational the periodic Targeted Hellos between the LSRs become redundant, as session Keepalives in turn serves the intent of each LSR to maintain its adjacency to its peer. When an LSR maintains a large number of LDP sessions (in thousands) to targeted peers, it Dutta, et. al. Expires September 3, 2009 [Page 2] Internet-Draft T-LDP Hello Reduction March 2009 is an additional burden to send and receive Targeted Hellos for all peers at periodic intervals. This document proposes an optional mechanism to turn off Targeted LDP Hellos after a LDP session is established to a targeted peer. 2. Conventions used in this document INFO (REMOVE): INCLUDE THIS SECTION OR PORTIONS THEREOF IF DESIRED In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology This document uses the terminology defined in [RFC3031] and [RFC5036]. 4. Targeted LDP Hello Reduction Procedure The Targeted LDP Hello Reduction procedure uses the existing Common Hello Parameters TLV defined in [RFC5036]. Figure 1. shows the encoding of the TLV from [RFC5036] for reference. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Common Hello Parms(0x0400)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time |T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Common Hello Parameters TLV. By definition in [RFC5036], a value of 0 means use the default, which is 45 seconds for Targeted Hellos. A value of 0xffff means infinite. Dutta, et. al. Expires September 3, 2009 [Page 3] Internet-Draft T-LDP Hello Reduction March 2009 The procedure to be followed for Targeted LDP Hello Reduction between a pair of LSRs is as follows: 1. An LSR starts transmitting periodic targeted hellos to its peer in order to establish the targeted hello adjacency. Each LSR proposes its configured hello hold time in the Common Hello Parameters TLV in its hello message to the peer. The hold time used between a pair of LSRs is the minimum of the hold times proposed in their Hellos. 2. If the Hello is acceptable by receiving LSR it establishes targeted hello adjacency with the source LSR. Establishment of Hello adjacency establishes the LDP session between peering LSRs. 3. After the LDP session is ESTABLISHED [RFC5036], each LSR SHOULD advertise hello holdtime value of 0xffff in the Common Hello Parameters TLV. Thus after the session is ESTABLISHED, the hello hold time between the LSRs gets negotiated to infinite. An LSR MAY implement a locally configurable "tolerance" - the number of Targeted LDP Hellos to be advertised with infinite hold time after the LDP session is ESTABLISHED. 4. If the LDP session between two LSRs fails leading to tearing down of adjacency, then each LSR reverts to advertising their configured hello hold time and repeats procedure 1 to 3. It is RECOMMENDED that each peering LSR implements the Targeted LDP Hello Reduction procedure; otherwise negotiated hello hold time between the LSRs does not fall back to the infinite hold time in step 3. 5. Security Considerations - Control plane aspects - LDP security (authentication) methods as described in [RFC5036] is applicable here. - Data plane aspects - This specification does not have any impact on the MPLS forwarding plane setup by LDP. 6. IANA Considerations This document does not require any IANA consideration. Dutta, et. al. Expires September 3, 2009 [Page 4] Internet-Draft T-LDP Hello Reduction March 2009 7. Conclusion The method proposed in the document reduces significant burden on an LDP LSR that maintains Targeted LDP sessions to a large number (in thousands) of peers. Further, if BFD [BFD][BFD-MHOP] is used for tracking connectivity to peers it is desirable to turn off Targeted LDP hellos after the LDP session is setup. 8. References 8.1. Normative References [RFC5036] Andersson, L., et al. "LDP Specification", RFC5036, October 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC3031] Rosen, E., et al. "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [BFD] Katz, D., et al. "Bidirectional Forwarding Detection", draft-ietf-bfd-base-09.txt, February 2009. [BFD-MHOP] Katz, D., et al. "BFD for Multihop Paths", draft-ietf-bfd-multihop-07.txt, February 2009. 9. Acknowledgments The authors would like acknowledge the comments and suggestions from Wim Henderickx, Vach Kompella, Florin Balus, Mustapha Aissaoui, Mathew Bocci and Paul Kwok. This document was prepared using 2-Word-v2.0.template.dot. Dutta, et. al. Expires September 3, 2009 [Page 5] Internet-Draft T-LDP Hello Reduction March 2009 Authors' Addresses Pranjal Kumar Dutta 701 E Middlefield Road, Mountain View, CA 94043. USA. Email: pdutta@alcatel-lucent.com Giles Heron BT Email: giles.heron@gmail.com Thomas D. Nadeau BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom EMail: tom.nadeau@bt.com Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Dutta, et. al. Expires September 3, 2009 [Page 6]