[mpls] FW: New Version Notification for draft-ietf-mpls-ri-rsvp-frr-02.txt

[Chandrasekar Ramachandran <[e-mail]>]

https://datatracker.ietf.org/doc/html/draft-ietf-mpls-ri-rsvp-frr-02.html

We just posted revision 2 of the draft with editorial changes relating to the text involving references to summary FRR draft (diff given below).

https://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-ri-rsvp-frr-01&url2=draft-ietf-mpls-ri-rsvp-frr-02

Thanks,
Chandra.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, August 11, 2017 5:55 PM
To: Ina Minei <[e-mail]>; Dante Pacella <[e-mail]>; Chandrasekar Ramachandran <[e-mail]>; Tarek Saad <[e-mail]>; Chandrasekar Ramachandran <[e-mail]>
Subject: New Version Notification for draft-ietf-mpls-ri-rsvp-frr-02.txt


A new version of I-D, draft-ietf-mpls-ri-rsvp-frr-02.txt
has been successfully submitted by Chandra Ramachandran and posted to the
IETF repository.

Name:		draft-ietf-mpls-ri-rsvp-frr
Revision:	02
Title:		Refresh Interval Independent FRR Facility Protection
Document date:	2017-08-11
Group:		mpls
Pages:		24
URL:            https://www.ietf.org/internet-drafts/draft-ietf-mpls-ri-rsvp-frr-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mpls-ri-rsvp-frr-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-mpls-ri-rsvp-frr-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ri-rsvp-frr-02

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.

                                                                                  


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.

The IETF Secretariat