Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-scaling-rec-02.txt

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 2 Nov 2016 08:06:04 -0400

Femi, Hi!

Apologize for the delayed response (your email somehow got buried in my
vacation pile).

Thanks for the feedback. Responses inline (prefixed VPB).

Regards,
-Pavan

On Fri, Sep 23, 2016 at 11:33 AM, Olufemi Komolafe <[email-masked]>
wrote:

> Pavan,
>
>
>
> Some initial feedback on this pretty interesting draft:
>
>
>
> Arguably the time in which an RSVP node is likely to receive the greatest
> number of messages within a short period is during the recovery period in
> graceful restart, as per RFC 3473 and RFC 5063.  I think this draft should
> at least describe how the proposals would operate during graceful restart
> and any associated advantages/disadvantages.
>

[VPB] The focus here (as stated in the draft) is to enhance RSVP-TE
scalability by making a couple of subtle changes to the basic protocol
operation ( via Refresh-Refresh Independence and Per-Peer Flow Control). We
(the authors of this draft) aren't aiming to look at each individual RSVP
feature (ever defined) and update its scalability considerations. There are
(as you say) some RSVP features where the procedures involve heavy exchange
of trigger messages. Bypass-FRR is one such feature -- there are some
efforts (draft discussed in the MPLS WG) underway that address this.
RSVP-GR is another feature -- someone someday may propose some enhancements
for it as well (this current draft wouldn't be the one to do so).

>
>
> Section 2.1.3: I think you should justify your proposal here.  And, also,
> how long do you keep retransmitting the Path/Resv messages in the absence
> of an Ack?  Indefinitely?  And isn't this potentially just re-introducing
> refresh messages surreptitiously, something the draft discourages?
>

[VPB] The retransmission is done indefinitely (in the absence of an Ack) --
until a signaling adjacency failure is detected or the user (or some
head-end procedure) intervenes. The basic idea is to revert (in the absence
of an ack) to the conventional refresh-rate (short refresh interval -- 30
second interval recommended) for that piece of "RSVP state".

>
>
> (In fact, generally, I think the draft could benefit from some more/better
> justification for the key changes that are proposed in several places.)
>

>
> There are no RSVP "Tear/Err" messages ;-)  While I think I know what you
> mean, I think you should list the complete message types each time or
> explicitly define what you mean by "Tear/Err" messages the first time you
> use this term.
>

[VPB] The reader of this draft is expected to be familiar with the basic
RSVP message types (expected to be familiar with terminology from the base
RSVP RFCs).

>
>
> Section 2.1.1: "Must support retransmit of"
>
>
>
> Lastly, the following paper is an excellent analysis of the relative
> merits of soft state vs hard state protocols etc and the conclusions may be
> of interest:
>
> "A Comparison of Hard-State and Soft-State Signaling Protocols", P. Ji, Z.
> Ge, J. Kurose. D.Towsley,  ACM SIGCOMM 2003
>
> http://conferences.sigcomm.org/sigcomm/2003/papers/p251-ji.pdf
>

[VPB] Thanks for the pointer to the paper. I don't see anything in the
conclusions that would contradict what is being advocated by this draft.
Increasing the value of the refresh-interval in a soft-state protocol is
bound to provide linear improvement on transmission overhead. The draft
proposes sufficient recommendations (see recommendations for state removal)
to make sure that there is no loss of functionality incurred by increasing
the value of the refresh interval.

>
>
> Regards,
>
> Femi
>
>
>
>
>
> *From:* Teas [mailto:[email-masked]] *On Behalf Of *Vishnu Pavan
> Beeram
> *Sent:* Thursday, September 22, 2016 2:47 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-
> scaling-rec-02.txt
>
>
>
> Folks, Hi!
>
> We just submitted a new revision to keep the draft active. We intend to
> submit another version next month addressing the open issues.
>
> Regards,
>
> - Pavan (on behalf of the authors)
>
>
>
> On Wed, Sep 21, 2016 at 9:41 PM, <[email-masked]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Traffic Engineering Architecture and
> Signaling of the IETF.
>
>         Title           : Implementation Recommendations to Improve the
> Scalability of RSVP-TE Deployments
>         Authors         : Vishnu Pavan Beeram
>                           Ina Minei
>                           Rob Shakir
>                           Dante Pacella
>                           Tarek Saad
>         Filename        : draft-ietf-teas-rsvp-te-scaling-rec-02.txt
>         Pages           : 11
>         Date            : 2016-09-21
>
> Abstract:
>     The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed
>     is growing continually and the onus is on RSVP-TE implementations
>     across the board to keep up with this increasing demand.
>
>     This document makes a set of implementation recommendations to help
>     RSVP-TE deployments push the envelope on scaling and advocates the
>     use of a couple of techniques - "Refresh Interval Independent RSVP
>     (RI-RSVP)" and "Per-Peer flow-control" - for improving scaling.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dteas-2Drsvp-2Dte-2Dscaling-2Drec_&d=DQMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=JJQeumfRIljD_Xdmpw2mJTpe2LMPz89BlujcAESMjlM&m=3xPIjqMZYcB4mq0dHwH-DJB6LH9q6ph2soLETDBw8dY&s=faMavjDqfRgGvKs_hcbYP4o0CVR_1VlZ9UxvDSlmmCE&e=>
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-02
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dteas-2Drsvp-2Dte-2Dscaling-2Drec-2D02&d=DQMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=JJQeumfRIljD_Xdmpw2mJTpe2LMPz89BlujcAESMjlM&m=3xPIjqMZYcB4mq0dHwH-DJB6LH9q6ph2soLETDBw8dY&s=lHrpQYM8Omq7ZFhQL9kK1oFoznq0RyKr6v2gJGriEdo&e=>
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-scaling-rec-02
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dteas-2Drsvp-2Dte-2Dscaling-2Drec-2D02&d=DQMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=JJQeumfRIljD_Xdmpw2mJTpe2LMPz89BlujcAESMjlM&m=3xPIjqMZYcB4mq0dHwH-DJB6LH9q6ph2soLETDBw8dY&s=OdORwji2ggNGII7m3d7Ry6HCh0n8f8anJen8-3E6YBY&e=>
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DQMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=JJQeumfRIljD_Xdmpw2mJTpe2LMPz89BlujcAESMjlM&m=3xPIjqMZYcB4mq0dHwH-DJB6LH9q6ph2soLETDBw8dY&s=VyVll37aUocGzIiieDX_HAPlqFlVgDAZY_UFcFDRCFo&e=>
> .
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DQMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=JJQeumfRIljD_Xdmpw2mJTpe2LMPz89BlujcAESMjlM&m=3xPIjqMZYcB4mq0dHwH-DJB6LH9q6ph2soLETDBw8dY&s=9MWpDSdLRvjy1fXOI6ovEVkEm3I_4St8OjZ_dejs-ek&e=>
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DQMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=JJQeumfRIljD_Xdmpw2mJTpe2LMPz89BlujcAESMjlM&m=3xPIjqMZYcB4mq0dHwH-DJB6LH9q6ph2soLETDBw8dY&s=2jddIL3UUzbXXtn-Ly9lYnCmKMmto4t11WVT9FXCi60&e=>
>
>
>