[Teas] 答复: WG adoption poll - draft-zhao-teas-pcecc-use-cases

["Aijun Wang" <[e-mail]>]

Hi, All and the authors of draft-zhao-teas-pcecc-use-case:

 

I support this draft as a working group document, but some clarification or modification are needed to put forward it, especially the relationship of this document with other solutions, such as SR(Segment Routing), BIER and PCE in Native IP Network. Here are my humble opinions for them, please consider whether they are suitable or not:

1.       Relation with SR/BIER: 

I think the SR and PCECC solution will be coexist in the operator network. Because their aims are the same-----to replace the complexity distributed RSVP protocol with the concept of central control. But the ISP network will not be fully/totally centrally controlled(as proposed by ONF/Openflow control mode).  The combined mode----add some centrally intelligences to the traditional distributed network will be accepted.

Then, I propose PCECC should focus on the use cases that can’t be solved easily by the traditional distributed network, by SR, by BIER and by PCE in native IP Network.  Following are the comments for each use cases:

1)       Case 4 “PCECC for Label Resource Reservations” is a good use case for PCECC

2)       Case 5 “Using PCECC for SR without the IGP Extension”. If we adopt this use case, then the forwarding path information must be stored on every on-path router, Is it expandable when comparable with the SR solution?

3)       Case 6 “Use Cases of PCECC for TE LSP” is a good use case for PCECC, but there is no bandwidth information in the corresponding example? Add this information may be better, because SR can’t accomplish this as I known.

4)       Case 7 “Use Cases of PCECC for Multicast LSPs”. I think this use case should consider the emergence of BIER solution. >From the first view, BIER can reduce the size of multicast state table on each router as caused by the RSVP-TE P2MP/mLDP protocol, but the PCECC solution can’t mitigate this problem, because PCECC should download the result multicast forwarding table on each router?  I suggest we can use the PCCECC solution to allocate the Bit Index of each router, not the forward path downloading.  BIER and PCECC all rely on the centrally calculating of the multicast path.

5)       Case 9: “Use Cases of PCECC for L3VPN and PWE3”. The example of L3VPN is not very suitable, I think the BGP protocol will not be replaced in near future and it is very common to be used for L3VPN. We can use PCECC for PWE3, but it is not the mainly purpose of PCECC because it needs only control the edge PE? 

6)       Case 10:  “Using PCECC for Traffic Classification Information”. This is same as that PWE3, we can extend the PCEP protocol to transfer the key  information and send them to the edge routers.

7)       Case 11: “Use case of PCECC for load balancing” .. Is this just to build two active LSPs on the router in path?, if so, would it be better to combine with case 6 “Use Cases of PCECC for TE LSP”

8)       Case 12: “Using reliable P2MP TE based multicast delivery for distributed computations (MapReduce-Hadoop”, is it just one use case for P2MP and the solution is same?

9)       Case 13: “PCECC and Inter-AS TE”. It will be useful to use PCECC to control/correlate edge routers in each domain.

10)   Is it better to move the section 3 “PCEP requirement” after the above use case? Then people will have some clues to know the reason for requirements of PCEP, and will read the corresponding draft. J

 

2.       Relation with PCE in Native IP:

The above use cases are all related to the central control of LSP. But in operator’s network, there is also scenario that we want do traffic engineering in Native IP network, without the using of MPLS. Such scenario can’t be solved easily via the distributed/complex MPLS-TE signaling, but can be achieved in simple manner via the assistance of PCE/Central control module, under the architecture as described in  https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central- <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/> control/ <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/> 
I think the current draft and the draft https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-01 together can give the whole solution for PCECC architecture. But the detail solution and requirements for the extension of PCEP protocol is different, then we can keep them in two different branch to put forward them.
The scenario/solution mentioned in https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-01 can’t be covered by SR, which I had claimed in the previous IETF meeting.
 

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

 

 

发件人: [e-mail] [mailto:[e-mail]] 代表 Vishnu Pavan Beeram
发送时间: 2017年2月8日 19:06
收件人: [e-mail]
抄送: TEAS WG Chairs
主题: [Teas] WG adoption poll - draft-zhao-teas-pcecc-use-cases

 

All,

This is start of a two week poll on making
draft-zhao-teas-pcecc-use-cases-02 a working group document. Please
send email to the list indicating "yes/support" or "no/do not
support". If indicating no, please state your reservations with the
document. If yes, please also feel free to provide comments you'd
like to see addressed once the document is a WG document.

Note: an IPR disclosure has been made on this document, see
https://datatracker.ietf.org/ipr/2940/  <https://datatracker.ietf.org/ipr/2940/> 

The poll ends February 22.

Thanks,
Pavan and Lou