Hi Robert and All, Thanks for your reply. As you pointed out, we must be careful to avoid the well-known problems, obviously, we don’t want another RSVP. Actually, I don’t think PRN is a RSVP or alike which is just a resource reservation or QOS signaling protocol. Could I try to explain PRN in another words, and I apologize for my poor expression or English confusing you, any further question are expected and welcome.
Let’s take an example for PRN, an ant travel from one place(the Requester) to other place(the Source) for requesting reinforcement ant army, he remember the return path just by smell or really dig a pipe and leading the army back to the Requester in time. The ant should observe the return path(Path Exploration) at each fork and choose the one with best return path and mark it(Proactive Routing) or make some bridges prepared(Resource Reservation), or send out a substitute on each way if he can’t make sure which one is the best. The RSVP, in my point, is the engineer team used to build the path before the ant travel for help and must left some maintainer in each bridge of the path(Refresh) which overburden the bridge(Processing Overhead). I think maybe this is the point RSVP is criticized, RSVP is too heavy and obtuse to response. Contrast to the out-band signaling of RSVP, PRN is created and maintained in-band totally, and it is application driven making it the better way to create a host to host pipe. I think maybe you worry the number of Local Pipe on each node is too many, you are right absolutely, but Int-Serv model is one of the application models of PRN. It seems OK when applied to Diff-Serv model because only one Local Pipe is allocated for all the flows with the same output interface. Even for Int-Serv, we can limit the number of the Local Pipes below the capacity of the node, and actually, Int-Serv is aimed at high-valuable and persistent session such as VR, so if a node have 1T through-put then there are only 10K Pipes for VR session(such as 100M per session). Best Regards, Tan Xuefei tanxuefei at huawei.com From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Wednesday, June 22, 2016 6:00 PM To: tanxuefei 00203118 <[email protected]> Cc: [email protected] ([email protected]) <[email protected]> Subject: Re: [spring] New draft for networking request for comments and look for interested people, thank you. Hi Tan, I have read your proposal and to me it looks an attempt to reinvent vanilla RSVP Int-Serv in 80% of your document. The remaining 20% is ability to map such signalling to SR segments at each hop which may perhaps be something SPRING could consider to look at. Not sure. However before even going that way one observation needs to be clearly spelled out ... that RSVP Int-Serv model failed due to operational difficulty to reserve anything at any real scale at micro-flow/application level which unfortunately your proposal also suffers from. Regards, R. On Wed, Jun 22, 2016 at 11:45 AM, tanxuefei 00203118 <[email protected]<mailto:[email protected]>> wrote: Dear All, Here is a document at https://datatracker.ietf.org/doc/draft-tan-rtgwg-proactive-routing-network-arch/ I posted as RTGWG draft. We think this can take as another SPRING arch to expand the SR’s domain and simplify the label/segment distribution process. I initiate a discussion here wishing for comment and interest. Thanks, Tan Xuefei [email protected]<mailto:[email protected]> -----Original Message----- From: tanxuefei 00203118 Sent: Wednesday, June 22, 2016 3:06 PM To: '[email protected]<mailto:[email protected]>' <[email protected]<mailto:[email protected]>> Subject: New draft for networking request for comments and look for interested people, thank you. Dear All, The posted document at https://datatracker.ietf.org/doc/draft-tan-rtgwg-proactive-routing-network-arch/ propose a new networking mechanism to: 1) Provide deterministic network service for users. 2) Simplify the service management, fault location and help operators for more accurate billing. 3) Solve the addressing issue for vendors. Proactive Routing Network (PRN), provides a set of E2E Pipes for the two End Systems of communication named Requester and Source. The E2E Pipe have deterministic path learned from the trace of the Request, and is QOS guaranteed by resource reservation. Addressing issue is solved by recording the labeled interfaces or Local Pipes taken along with the Request to the Source. Each Pipe is protocol oblivious, application aware, elastic and visible for users and operators. We greatly appreciate your reviews, questions, comments, and suggestions. Thanks, Tan Xuefei tanxuefei at Huawei.com -----邮件原件----- 发件人: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] 发送时间: 2016年6月22日 14:39 收件人: tanxuefei 00203118 <[email protected]<mailto:[email protected]>>; tanxuefei 00203118 <[email protected]<mailto:[email protected]>> 主题: New Version Notification for draft-tan-rtgwg-proactive-routing-network-arch-00.txt A new version of I-D, draft-tan-rtgwg-proactive-routing-network-arch-00.txt has been successfully submitted by Tan Xuefei and posted to the IETF repository. Name: draft-tan-rtgwg-proactive-routing-network-arch Revision: 00 Title: Proactive Routing Network Architecture Document date: 2016-06-22 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-tan-rtgwg-proactive-routing-network-arch-00.txt Status: https://datatracker.ietf.org/doc/draft-tan-rtgwg-proactive-routing-network-arch/ Htmlized: https://tools.ietf.org/html/draft-tan-rtgwg-proactive-routing-network-arch-00 Abstract: Proactive Routing Network (PRN), which runs on conventional network, is user and service experience oriented; and provides a set of E2E Pipes for the two End Systems of communication named Requester and Source. The E2E Pipe have deterministic path learned from the trace of the Request sent by Requester, and is QOS guaranteed by resource reservation. Addressing issue is solved by recording the labeled interfaces or Local Pipes taken along with the Request to the Source. Each Pipe is protocol oblivious, application aware, elastic and visible for users and operators. PRN is not a new network, rather, it is a service attached to the conventional network. Therefore it does not affect the operation business of the conventional networks, so it is very conducive to the deployment and smooth evolution. PRN is valuable for users who want deterministic network service, and is helpful for operators to simplify the service management and easy for fault location and billing, and is helpful for vendors to solve the addressing issue which is one of the biggest challenges of increasing device throughput at a reasonable cost. 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<http://tools.ietf.org>. The IETF Secretariat _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
