Subject: [Teas] draft-ravisingh-teas-rsvp-setup-retry-01.txt: feedback requested

From: Ravi Singh <[email-masked]>
Date: Fri, 3 Jul 2015 00:03:21 +0000

Hi
A new revision of this draft is now available.
The diffs since the last revision are mostly editorial.

This draft addresses an issue that has shown itself in large-scale RSVP-TE deployments.
Ingress routers can sometimes cause excessive LSP re-signaling thus exacerbating network stress.
This draft describes a best-practice to address the same.

Please provide your feedback.

Thanks
Ravi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 2, 2015 12:42 PM
To: Ravi Singh; Tarek Saad; Rob Shakir; Ravi Singh; Rob Shakir; Vishnu Pavan Beeram; Vishnu Pavan Beeram; Tarek Saad
Subject: New Version Notification for draft-ravisingh-teas-rsvp-setup-retry-01.txt

A new version of I-D, draft-ravisingh-teas-rsvp-setup-retry-01.txt
has been successfully submitted by Vishnu Pavan Beeram and posted to the IETF repository.

Name:		draft-ravisingh-teas-rsvp-setup-retry
Revision:	01
Title:		RSVP Setup Retry - BCP
Document date:	2015-07-02
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-ravisingh-teas-rsvp-setup-retry-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ravisingh-teas-rsvp-setup-retry/
Htmlized:       https://tools.ietf.org/html/draft-ravisingh-teas-rsvp-setup-retry-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ravisingh-teas-rsvp-setup-retry-01

Abstract:
    This document discusses the best current practices associated with
    the implementation of RSVP setup-retry timer.

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

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Sat, 4 Jul 2015 09:57:19 +0000

Hi Ravi,

The ill effects resulting from the bad implementation choice for the
action taken on ³setup-retry² timeouts at the ingress (in some vendors
implementations) have resulted (in my experience and under scale) in an
endless control plane signaling work cycle (of setup and tear of LSPs -
especially on transit LSRs). As well, the fact that some implementations
accept short setup-retry timeouts (combined with the bad action at
ingress) increases likelihood of such problems occurring.

I agree the proposed corrective action at the ingress on LSP setup-retry
timeout (to revalidate the last signaled path and replaying the RSVP Path
again) can address the issue above.

Regards,
Tarek

On 2015-07-02, 8:03 PM, "Teas on behalf of Ravi Singh"
<[email-masked] on behalf of [email-masked]> wrote:

>To: Ravi Singh; Tarek Saad; Rob Shakir; Ravi Singh; Rob Shakir; Vishnu
>Pavan Beeram; Vishnu Pavan Beeram; Tarek Saad
>Subject: New Version Notification for
>draft-ravisingh-teas-rsvp-setup-retry-01.txt
>
>
>URL:            
>https://www.ietf.org/internet-drafts/draft-ravisingh-teas-rsvp-setup-retry
>-01.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-ravisingh-teas-rsvp-setup-retry/
>Htmlized:       
>https://tools.ietf.org/html/draft-ravisingh-teas-rsvp-setup-retry-01
>Diff:           
>https://www.ietf.org/rfcdiff?url2=draft-ravisingh-teas-rsvp-setup-retry-01
>
>Abstract:
>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
>
>_______________________________________________
>Teas mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/teas