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 <tanxue...@huawei.com> 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 > tanxue...@huawei.com > > -----Original Message----- > From: tanxuefei 00203118 > Sent: Wednesday, June 22, 2016 3:06 PM > To: 'rt...@ietf.org' <rt...@ietf.org> > 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 > > -----邮件原件----- > 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > 发送时间: 2016年6月22日 14:39 > 收件人: tanxuefei 00203118 <tanxue...@huawei.com>; tanxuefei 00203118 < > tanxue...@huawei.com> > 主题: 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. > > The IETF Secretariat > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
