Subject: Re: [Teas] I-D Action: draft-qin-teas-sl-rsvp-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Dec 2016 19:54:11 -0000

Dear authors,

Thanks for this thoughtful and stimulating document.

I think you really (really, really!) need to NOT call it stateless RSVP. You are
abolishing "soft state" in favour of "hard state" as you say quite clearly in
section 2.2. This is a good discussion to have, but it is very definitely not
stateless. I think that if you don't tidy that up you will find that your
readers enter the document confused and possibly upset :-)

Section 1 references 5439 in support of the statement "when the refresh interval
is increasing, a degree of functionality is lost." 5439 does, indeed say this,
but the context is lost in your reference. The full quote from 5439 is:
|  However, it should be noted
|  that RSVP-TE's soft-state nature depends on regular refresh messages;
|  thus, a degree of functionality is lost by increasing the refresh
|  time.  This loss may be partially mitigated by the use of the RSVP-TE
|  Hello message, and can also be reduced by the use of various GMPLS
|  extensions [RFC3473], such as the use of [RFC2961] message
|  acknowledgements on all messages.
  
One of the debates around [I-D.ietf-teas-rsvp-te-scaling-rec] has been quite how
large to increase the refresh time. You are proposing to go to the limit (i.e.,
no refreshes) and this is as attractive for packet networks as it was for
non-packet networks ten years ago. But the question to consider is just how much
house-keeping is needed to clear up orphaned LSPs.

While it is clear that a central controlled or an operator can touch the network
nodes to clear up stale state, it gives rise to a number of concerns:
- increase in complexity of the system
- duplication of LSP state in the network and in the controller
- resolution of disagreements over state in the network and the controller
- recovery or redundancy issues with the controller.
But my favourite concern is whether the operator is willing to have an external
party come into the network and remove LSP state when that LSP might really be
needed. Bugs and fat fingers have to be traded against customer services.

In practice, therefore, while the use of management commands to clean up state
is a nice approach, I wonder whether you would consider a refresh interval of
one day to be a practical and scalable alternative that ensures that everything
is kept tidy.

My last question to you is whether you think we could find a way to fold your
thoughts into [I-D.ietf-teas-rsvp-te-scaling-rec].

Thanks,
Adrian

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 28 December 2016 03:56
> To: [email-masked]
> Subject: I-D Action: draft-qin-teas-sl-rsvp-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
>         Title           : Architecture for Stateless RSVP
>         Authors         : Jun Qin
>                           Dongzhi Sun
>                           Jie Dong
>                           Xiugang Wei
>                           Mach Chen
> 	Filename        : draft-qin-teas-sl-rsvp-00.txt
> 	Pages           : 9
> 	Date            : 2016-12-27
> 
> Abstract:
>    RSVP takes a "soft state" scheme to manage the reservation states in
>    routers and hosts, the soft states are created and periodically
>    refreshed by Path and Resv messages.  Soft state scheme gives a
>    simple way to maintain the state synchonization between neighbors,
>    but also introduces scalability issue.  This document provides a
>    framework that describes and discusses the architecture for stateless
>    RSVP (SL-RSVP), which disabled the soft-state scheme to improve the
>    protocol scalability and the other processes of RSVP are kept.  This
>    document does not describe specific protocols or protocol extensions
>    needed to realize this architecture.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-qin-teas-sl-rsvp/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-qin-teas-sl-rsvp-00
> 
> 
> 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/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt