[mpls] I-D Action: draft-ietf-mpls-ri-rsvp-frr-02.txt

internet-drafts@ietf.org Fri, 11 August 2017 12:24 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Cc: mpls@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150245427228.24449.2563771409981720310@ietfa.amsl.com>
Date: Fri, 11 Aug 2017 05:24:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/jgdKAOkxHfBfTho6kXSg5BKnuEc>
Subject: [mpls] I-D Action: draft-ietf-mpls-ri-rsvp-frr-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching WG of the IETF.

        Title           : Refresh Interval Independent FRR Facility Protection
        Authors         : Chandra Ramachandran
                          Ina Minei
                          Dante Pacella
                          Tarek Saad
	Filename        : draft-ietf-mpls-ri-rsvp-frr-02.txt
	Pages           : 24
	Date            : 2017-08-11

Abstract:
    RSVP-TE relies on periodic refresh of RSVP messages to synchronize
    and maintain the LSP related states along the reserved path. In the
    absence of refresh messages, the LSP related states are
    automatically deleted. Reliance on periodic refreshes and refresh
    timeouts are problematic from the scalability point of view. The
    number of RSVP-TE LSPs that a router needs to maintain has been
    growing in service provider networks and the implementations should
    be capable of handling increase in LSP scale.

    RFC 2961 specifies mechanisms to eliminate the reliance on periodic
    refresh and refresh timeout of RSVP messages, and enables a router
    to increase the message refresh interval to values much longer than
    the default 30 seconds defined in RFC 2205. However, the protocol
    extensions defined in RFC 4090 for supporting fast reroute (FRR)
    using bypass tunnels implicitly rely on short refresh timeouts to
    cleanup stale states.

    In order to eliminate the reliance on refresh timeouts, the routers
    should unambiguously determine when a particular LSP state should be
    deleted. Coupling LSP state with the corresponding RSVP-TE signaling
    adjacencies as recommended in RSVP-TE Scaling Recommendations
    (draft-ietf-teas-rsvp-te-scaling-rec) will apply in scenarios other
    than RFC 4090 FRR using bypass tunnels. In scenarios involving RFC
    4090 FRR using bypass tunnels, additional explicit tear down
    messages are necessary. Refresh-interval Independent RSVP FRR (RI-
    RSVP-FRR) extensions specified in this document consists of
    procedures to enable LSP state cleanup that are essential in
    scenarios not covered by procedures defined in RSVP-TE Scaling
    Recommendations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mpls-ri-rsvp-frr-02
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-ri-rsvp-frr-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ri-rsvp-frr-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

[mpls] I-D Action: draft-ietf-mpls-ri-rsvp-frr-02… internet-drafts