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

From: "qinjun (G)" <[email-masked]>
Date: Thu, 5 Jan 2017 03:32:11 +0000

Dear Adrian, 

Thanks for reviewing the document and providing us your kindly advice. Please see my replies inline.

Best Regards,
Jun Qin

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, December 30, 2016 3:54 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: I-D Action: draft-qin-teas-sl-rsvp-00.txt

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.
  
[Qin] As you suggested, the name of this draft will be changed from "stateless RSVP" to "HS-RSVP" (hard-state RSVP). In the proposed mechanism, the traditional soft-state scheme in RSVP is disabled, there's no periodical refreshing of Path and Resv messages and the corresponding cleanup time interval is not needed. It actually turns RSVP from "soft-state" into "hard-state". So, HS-RSVP may be a more suitable name. 
The quote of RFC5439 will be completed in the new version of the document.

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

[Qin] In the proposed mechanism, the soft-state scheme is disabled to improve the RSVP protocol scalability. The central controller is used to solve the possibly caused problems due to the removal of the periodical refreshing. Whether or not the mechanism can increase the system complexity depends on the detailed implementation (such as using which protocol). On the other hand, maybe it is worthy to increase the system complexity a little bit if the return is effective promotion in protocol scalability.

- duplication of LSP state in the network and in the controller

[Qin] In stateful PCE (draft-ietf-pce-stateful-pce), the PCE uses the TEDB and LSPDB for path computation. And it allows the LSP to be delegated to the PCE, so the PCE or controller already have the LSP states in the network. In PCE-CC (draft-zhao-pce-pcep-extension-for-pce-controller) LSP can be calculated/ signalled/initiated and label forwarding entries are downloaded through a centralized PCE server to each network devices along the LSP path, so the PCE server will have the LSP states. In the proposed mechanism, the situation is similar.

- resolution of disagreements over state in the network and the controller

[Qin] With reliable state exchange between the controller and the network nodes, the LSP states should be kept consistent all the time. In the situation of session failure between the controller and the LSRs or unexpected breakdown of the controller or LSRs, a state synchronization process is indispensable after the recovery, as described in section 4.2. 
About the disagreements over states deletion, when the controller perceives the LSP failure, it should get the permission of deletion by the LSP initiator before sending the deletion messages to the nodes. LSP initiator is the owner of the LSP, which has the right of the LSP deletion.

- recovery or redundancy issues with the controller.

[Qin] This is a general issue for the controller based architecture, and some existing solutions may be used. Also we will analyze the recovery or redundancy issues in separate documents which specifies the protocol implementation.

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.

[Qin] As specified in the draft, the capability of deleting the LSP states needs to be negotiated at the beginning of the session between the controller and the nodes to determine whether the controller is allowed to help with the deletion. Usually the controller is owned by the operator, thus the LSP deletion by controller is still under the control of the operator and can be coordinated with the network. As explained above, the controller needs the permission of the LSP owner before it can delete the LSP states in the network.

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.

[Qin] Under the controller based architecture, in practice, a refresh interval of one day could be a scalable alternative complement that ensures that everything is kept tidy, like the unsuccessful deletion of the residual states caused by low probability controller down. 
If there's no controller helping with the deletion, when refresh interval is set as one day, that could cause problem. For example, if there exists residual states on some of the nodes along the LSP at the beginning of the day, because the refresh interval is one day, the LSP's bandwidth could not be released during all the day.

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].

[Qin] [I-D.ietf-teas-rsvp-te-scaling-rec] gives a set of implementation recommendations to help RSVP-TE deployments push the envelope on scaling, compared to that draft, our document present a kind of overall architecture, there's no detailed protocol or implementation specifications in this document (the plan was to specify protocol details in separate documents), but we are glad to find a way to fold the thoughts into a single document.

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