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

[Khasanov Boris <[e-mail]>]

Hi Aijun,
Thank you for the valuable feedback. We will address it in new version of the draft.
Comments are inline (>>).

SY,
Boris

From: Teas [mailto:[e-mail]] On Behalf Of Aijun Wang
Sent: Friday, February 10, 2017 7:14 AM
To: 'Vishnu Pavan Beeram'; [e-mail]
Cc: 'TEAS WG Chairs'
Subject: [Teas] 答复: WG adoption poll - draft-zhao-teas-pcecc-use-cases

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.
>>  It is really hard to predict possible co-existing combinations for PCECC and other technologies in the future. For every  use case there might  be different solutions as in your example with combined mode. We cannot define that any particular solution is better or is  a best  for using in given situation , this is the choice of particular customer to use one or another or their combination. Thus we are focusing on finding solutions by means of PCECC, surely there can be other solutions by means of  SR, BIER, NETCONF, etc.

Following are the comments for each use cases:

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

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?
>> I guess that there is some misunderstanding here.  PCECC SR case has the same forwarding plane  as the IGP extension based SR except that the labeled related SID information is programmed through PCE instead of IGP.  This is explained in more detail in the PCECC protocol extension draft.

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.

>> Thank you for suggestion we will think and address it in new version of the draft.

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.

>> Good idea.  We will think about how to use the PCECC for allocation of  the Bit Index as extension to current use case.   We would like to give customer a choice  to create multicast forwarding state via PCECC  or to use another technology.

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?
>> Agree that BGP will still be used in the near future, we just wanted to show that service labels could be also provisioned from PCECC on edge PEs in particular cases, additionally to BGP. We will change the description to more general one.

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.
>> Agree.

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”
            >> We will re-group it under TE LSP hierarchy.

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?
                 >> It is based on P2MP use case but adds additional details, we will re-group it under Multicast LSPs hierarchy.

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

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. ☺
            >>Agree, will do that.



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.

>>We will mention this as well as add reference links.

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]> [mailto:[e-mail]] 代表 Vishnu Pavan Beeram
发送时间: 2017年2月8日 19:06
收件人: [e-mail]<mailto:[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/

The poll ends February 22.

Thanks,
Pavan and Lou