Subject: [spring] New draft for networking request for comments and look for interested people, thank you.

From: tanxuefei 00203118 <[email-masked]>
Date: Wed, 22 Jun 2016 09:45:09 +0000

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

-----Original Message-----
From: tanxuefei 00203118 
Sent: Wednesday, June 22, 2016 3:06 PM
To: [email-masked]' <[email-masked]>
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-masked] [mailto:[email-masked]] 
发送时间: 2016年6月22日 14:39
收件人: tanxuefei 00203118 <[email-masked]>; tanxuefei 00203118 <[email-masked]>
主题: 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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 22 Jun 2016 11:59:50 +0200

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-masked]>
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.
> The posted document at
> https://datatracker.ietf.org/doc/draft-tan-rtgwg-proactive-routing-network-arch/
> propose a new networking mechanism to:
> 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.
> 主题: New Version Notification for
> draft-tan-rtgwg-proactive-routing-network-arch-00.txt
>
>
> 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:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Tanxuefei (NGIP)" <[email-masked]>
Date: Thu, 23 Jun 2016 07:40:57 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, June 22, 2016 6:00 PM
To: tanxuefei 00203118 <[email-masked]>
Cc: [email-masked] ([email-masked]) <[email-masked]>
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>

-----Original Message-----
From: tanxuefei 00203118
Sent: Wednesday, June 22, 2016 3:06 PM
To: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>
Subject: New draft for networking request for comments and look for interested people, thank you.

Dear All,

Thanks,
Tan Xuefei
tanxuefei at Huawei.com

-----邮件原件-----
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2016年6月22日 14:39
收件人: tanxuefei 00203118 <[email-masked]<mailto:[email-masked]>>; tanxuefei 00203118 <[email-masked]<mailto:[email-masked]>>
主题: New Version Notification for draft-tan-rtgwg-proactive-routing-network-arch-00.txt

Abstract:

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring