Re: [Teas] IETF97 minutes posted--Regarding "PCE in Native IP network"

Hi, Lou:

Thanks for your updated minutes. Here I want to give some responses for the
concerned questions about "PCE in Native IP network", which are initiated
from different experts. Wish it can clarify some confusion points for this
draft and put forward it some steps further.

Question 1(from Danielle Ceccarelli): "We already have a solution for
Traffic-Engineering in IP networks -- it is called MPLS."  
[Aijun Wang]: Traditional MPLS technology that is deployed in distributed
manner can only do bandwidth reservation via the RSVP signaling protocol,
can't meet the application QoS requirement in real time traffic network. The
deployment of RSVP protocol is complex and it also brings large burden on
the network devices. This is the main reason that the SR(Segment Routing)
technology is emerged and popular in recent days.
But as I mentioned during the presentation, SR now can only be deployed in
MPLS and IPv6 network, and there is no similar solution for Native IP
network. The draft "PCE in native IP network" is just to fulfill this aim,
that is to say, to find and deploy one end-to-end path in underlying network
upon the QoS requirement of application.

Question 2(from Jeff Tantsura): " Would like to see better comparison with
FlowSpec and BGP based solutions before we proceed"
[Aijun Wang]: BGP flowspec should deploy specific policy for every
application prefix in every on-path router, but the solution described in
"PCE in native IP network" treats edge routers and other on-path routers
differently: only the edge routers need to keep the policy for every prefix,
the other on-path routers should only keep the policy for specific route to
related edge routers, not the specific application prefix. This can relive
the burden of on-path routers and has more flexibility and expandability
during deployment.

Question 3:(About the relationship with PCECC use-case draft)(from Lou and
Dhru)
[Aijun Wang]: We have described this in the abstract of the draft "PCE in
Native IP network"
(https://datatracker.ietf.org/doc/draft-wang-teas-pce-native-ip/), as the
following: 
   "This document defines the scenario and solution for traffic
   engineering within Native IP network, using Dual/Multi-BGP session
   strategy and PCE-based central control architecture. The proposed
   central mode control solution conforms to the concept that defined
   in draft [I-D.draft-ietf-teas-pce-control-function], and together
   with draft [I-D.draft-zhao-teas-pcecc-use-cases], the solution
   portfolio for traffic engineering in MPLS and Native IP network is
   almost completed."
I also prefer to separate the two drafts in two tracks, one is for PCECC for
MPLS network, the other for PCECC for Native IP network. Because after the
use case, we should propose the related solution and extension proposal for
PCEP. The solution and extension for these two categories use cases seems to
have little similar characteristics. The author of these two drafts are
overlapping, so we will cooperate with each other to forward these drafts.

Do the above explanation make senses for the concerned questions? We are
also eager to hear more value suggestions and comments for this scenario and
solution. 

Best Regards.

Aijun Wang
China Telecom Beijing Research Institute
Network R&D and Operation Support Department

-----Original Message-----
From: teas-bounces@ietf.org [mailto:teas-bounces@ietf.org] On Behalf Of Lou
Berger
Sent: Friday, December 9, 2016 11:57 PM
To: TEAS WG
Cc: teas-chairs@ietf.org
Subject: [Teas] IETF97 minutes posted

All,

Thanks to our note takers, we have posted updated minutes.
Please review and comment:

Latest rev is in etherpad:
http://etherpad.tools.ietf.org:9000/p/notes-ietf-97-teas

*if* you make changes, please discuss them on the list as only discussed
changes will be upload to be part of the final meeting record.

Thank you,
Lou and Pavan

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas