Internet DRAFT - draft-pdutta-mpls-tldp-hello-reduce

draft-pdutta-mpls-tldp-hello-reduce






Network Working Group                                           P. Dutta
Internet-Draft                                            Alcatel-Lucent
Intended status: Standards Track                                G. Heron
Expires: March 5, 2013                                     Cisco Systems
                                                               T. Nadeau
                                                        Juniper Networks
                                                      September 01, 2012


                      Targeted LDP Hello Reduction
                 draft-pdutta-mpls-tldp-hello-reduce-04

Abstract

   Targeted LDP (t-LDP) Hellos are used for establishing adjacencies
   with non-directly connected peers.  After an LDP session is
   established to a Targeted Peer, there are deployment scenerios where
   it is not necessary to send Targeted LDP Hellos at the configured
   intervals.  This document proposes a mechanism to turn off or reduce
   the rate of exchange of Targeted LDP Hellos after LDP session is
   established to a peer.

Requirements Language

   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 RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on March 5, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the



Dutta, et al.             Expires March 5, 2013                 [Page 1]

Internet-Draft            T-LDP Hello Reduction           September 2012


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Targeted LDP Hello Reduction Procedure  . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Operational Considerations  . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

























Dutta, et al.             Expires March 5, 2013                 [Page 2]

Internet-Draft            T-LDP Hello Reduction           September 2012


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.  There are
   certain deployment scenerios where 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.  Moreover additional mechanisms such as
   centralized BFD [RFC5880] may be used to track liveliness of ldp
   sessions.

   When an LSR maintains a large number of LDP sessions (thousands) to
   Targeted peers, it is an additional burden to send and receive
   Targeted Hellos for all peers at periodic intervals.  In MPLS
   deployments at access or mobility backhaul or in Seamless MPLS
   [I-D.ietf-mpls-seamless-mpls] , there can be very large volume of LDP
   sessions (e.g 10,000) with targeted LDP adjacencies to each base
   station (or last mile in a MPLS domain).

   Another problem with targeted hello adjacency arises is Denial Of
   Service (DoS) attacks.  It is possible that existing hello
   adjacencies can get lost due to DoS attack on LDP Hello receiver by
   spurious hello packets.  Unlike TCP sessions it is not always
   possible to provide per peer protection for UDP based hellos.
   Implementations can use methods to protect existing adjacencies while



Dutta, et al.             Expires March 5, 2013                 [Page 3]

Internet-Draft            T-LDP Hello Reduction           September 2012


   throttling spurious adjacencies but such methods may not be available
   in low cost MPLS devices deployed in access.  So it is important to
   avoid dependency on Targeted LDP hellos on t-LDP adjacency
   maintenance as far as possible.  Reduction of Hellos provide
   probabilistically better resilience on maintenance of hello
   adjacencies during sporadic hello attacks.

   This document proposes an OPTIONAL mechanism to turn off Targeted LDP
   Hellos after a LDP session is established to a targeted peer, without
   changes in the procedures defined in [RFC5036].  The solutions
   described in this document may not be applicable in scenerios where
   Session Keepalives or BFD may not act as substitute for Targeted LDP
   Hellos.  Refer to section 6 for operational considerations while
   deploying the solution described in this document.


2.  Terminology

   This document uses the terminology defined in [RFC3031] and
   [RFC5036].


3.  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.

   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



Dutta, et al.             Expires March 5, 2013                 [Page 4]

Internet-Draft            T-LDP Hello Reduction           September 2012


   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 MAY
   start proposing "relaxed" hold time (higher than configured) in
   Common Hello Parameters TLV in the subsequent Hello Messages.

   Each LSR increases the advertised hold time by some factor after
   sending a set of Hellos (let's say 5) advertising consistent hold
   time.  As the process of relaxing the advertised hold time continues,
   after a certain period of time an LSR reaches the maximum holdtime
   value of 0xffff.  Thus after the session is ESTABLISHED, the hello
   hold time between the LSRs gets negotiated to infinite.  Note that
   the Targeted Hello Adjacency continue to exist and only the adjacency
   hold times are now infinite.

   4.  If there are any changes in any parameters associated with a
   t-LDP Hello adjacency (e.g Configuration Sequence Number etc) then an
   updated Hello MUST be sent immediately without any changes to the
   "current" hold time (e.g inifinite) that was advertised in the last
   Hello Message.  Since hellos are not reliable, after any parameter
   change an implementation may send a set of hellos (let's say 5) at
   configured intervals (or faster) to reflect the change.  But those
   hellos would continue to advertise infinite hold time and would fall
   back to reduced transmission rate after those 5 packets are sent.

   5.  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.  This also applies when
   LDP session restarts gracefully [RFC3478] when peering LSRs are
   graceful restart capable.  Thus the reduction procedures allow an
   operator to configure very aggressive Targeted LDP Hello Holdtime to
   expedite bringing up a large number of LDP sessions in the event of
   failure but reduces the overhead of hello adjacency maintenance by
   manifold when sessions are ESTABLISHED.  It is desirable to configure
   aggressive hold times in order to tear down spurious hello
   adjacencies sooner.

   6.  When a t-LDP adjacency with a remote LSRs has negotiated to
   infinite hold time and then remote LSR decides to tear down the
   adjacency without impacting the established LDP Session then local
   LSR would not be able to detect that remote node is no longer
   accepting hellos.  It is RECOMMENDED that when a LSR that implements
   the Hello Reduction procedures send one or a set of contiguous hellos



Dutta, et al.             Expires March 5, 2013                 [Page 5]

Internet-Draft            T-LDP Hello Reduction           September 2012


   (let's say 3) advertising hold time of 1 second while bringing down
   t-LDP Hello adjacency.  This graceful closure procedure would cause
   the hello holdtimes at receiving LSR to be renegotiated to 1 second,
   which would eventually lead to tear down of the adjacency (due to
   timeout) by receiving LSR.

   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.

   Note that it is not mandatory to advertise infinite hold time after
   session is established but can be any value that is significantly
   larger than configured hello hold time.  However, it is RECOMMENDED
   to reach Infinite holdtime after session setup to derive maximum
   advantage from the procedure described above.

   The Hello Reduction procedures does not apply to Basic Discovery
   (Link LDP Hellos) as Link LDP Hellos need to be sent over an interval
   continually in order to discover and set up sessions with new peers,
   especially over a multi-access interface.


4.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


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.  Operational Considerations

   The method proposed in the document reduces significant burden on an
   LDP LSR that maintains Targeted LDP sessions to a large number (in



Dutta, et al.             Expires March 5, 2013                 [Page 6]

Internet-Draft            T-LDP Hello Reduction           September 2012


   thousands) of peers.  Further, if BFD [RFC5880] [RFC5883] is used for
   tracking connectivity to peers it is desirable to turn off Targeted
   LDP hellos after the LDP session is setup.  However there are
   scenerios where tunring off Targeted LDP Hellos may not be desirable.
   Such scenerios are as follows:

   1.  When transport address of the LDP session is different from the
   IP addresses used to exchange t-LDP Hellos then Session Keepalives
   are not substitute for reachability or liveliness of adjacency.  It
   is possible to use BFD to track the reachability of IP addresses used
   for t-LDP Hellos in which case t-LDP Hellos may be redundant.
   However if an implementation/deployment uses t-LDP hellos for
   purposes other than liveliness tracking then it is not recommended to
   turn on t-LDP hello reduction procedures.

   2.  While t-LDP Hello Reduction Procedures are deployed, it may be
   possible that t-LDP Hellos are disabled at remote LSR without
   bringing down the LDP session.  If the remote LSR does not implement
   the procedure for graceful teardown of hello adjacency as described
   in step 6 in section 3 then it is possible that local LSR may not be
   able detect that remote LSR is no longer accepting Hellos and thus
   Hello adjacency would continue to exist in local LSR.  It is also
   possible that the hello(s) sent during graceful cloure of adjacency
   may get lost (since LDP Hellos are not reliable) and thus local LSR
   may not detect the loss of adjacency with remote LSR.


7.  Acknowledgements

   The authors would like acknowledge the detailed review and the
   comments, suggestions from Markus Jork, Thomas Beckhaus, Lizhong Zin
   and Eric Rosen.


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

8.2.  Informative References

   [I-D.ietf-mpls-seamless-mpls]
              Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,



Dutta, et al.             Expires March 5, 2013                 [Page 7]

Internet-Draft            T-LDP Hello Reduction           September 2012


              M., and D. Steinberg, "Seamless MPLS Architecture",
              draft-ietf-mpls-seamless-mpls-01 (work in progress),
              March 2012.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3478]  Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful
              Restart Mechanism for Label Distribution Protocol",
              RFC 3478, February 2003.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC5883]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for Multihop Paths", RFC 5883, June 2010.


Authors' Addresses

   Pranjal Kumar Dutta
   Alcatel-Lucent
   701 E Middlefield Road
   Mountain View, CA  94043
   USA

   Email: pranjal.dutta@alcatel-lucent.com


   Giles Heron
   Cisco Systems
   9-11 New Square
   Bedfont Lakes, Feltham, Middlesex  TW14 8HA
   United Kingdom

   Email: giheron@cisco.com


   Thomas Nadeau
   Juniper Networks

   Email: tnadeau@juniper.net









Dutta, et al.             Expires March 5, 2013                 [Page 8]