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

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 8 Feb 2017 06:06:13 -0500

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

---

From: Khasanov Boris <[email-masked]>
Date: Wed, 8 Feb 2017 13:13:14 +0000

Hi all,
yes/support as co-author.

SY,
Boris

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Wednesday, February 08, 2017 2:06 PM
To: [email-masked]
Cc: TEAS WG Chairs
Subject: [Teas] WG adoption poll - draft-zhao-teas-pcecc-use-cases

All,

Thanks,
Pavan and Lou

---

From: "Chao Zhou (czhou)" <[email-masked]>
Date: Wed, 8 Feb 2017 13:56:43 +0000

yes/support. As co-author, I believe this document shows some real world cases.

Thanks,
-Chao

On Feb 8, 2017, at 7:06 PM, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>> wrote:

All,

Thanks,
Pavan and Lou
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Рачицкий Артём Дмитриевич <[email-masked]>
Date: Wed, 08 Feb 2017 18:25:48 +0300

Yes/support as co-author.
>
> *From:*Teas [mailto:[email-masked]] *On Behalf Of *Vishnu Pavan 
> Beeram
> *Sent:* Wednesday, February 08, 2017 2:06 PM
> *To:* [email-masked]
> *Cc:* TEAS WG Chairs
> *Subject:* [Teas] WG adoption poll - draft-zhao-teas-pcecc-use-cases
>
> All,
>

-- 
BR,
Artsiom Rachytski
Mobile TeleSystems JLLC
Belarus, Minsk

---

From: Leeyoung <[email-masked]>
Date: Wed, 8 Feb 2017 20:34:41 +0000

Yes/support.

Thanks,
Young

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Wednesday, February 08, 2017 5:06 AM
To: [email-masked]
Cc: TEAS WG Chairs <[email-masked]>
Subject: [Teas] WG adoption poll - draft-zhao-teas-pcecc-use-cases

All,

Thanks,
Pavan and Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 9 Feb 2017 15:09:44 -0000

Hi Pavan,
 
Yes, I think we should have a document that builds on draft-ietf-teas-pce-central-control by expounding some use cases so that people can understand what they might want to build and what protocol work might be needed. We need to be careful to understand whether we are aiming for:
- a complete list of all possible use cases
- some of the major *potential* use cases
- a few wide-ranging examples
- those use cases that people are really keen to build and deploy.
Maybe it would be good to make that decision as part of adoption, and to flag it in the Abstract and Introduction as the purpose of the document.
 
A couple of points on this revision of the document...
 
Maybe the chairs will want to sort out the front page author list before adoption to save having the (painful) debate later.
 
Why is this document positioned as Experimental? In view of draft-ietf-teas-pce-central-control it would seem that we have moved beyond an experiment.
 
But, saying that, I am quite surprised to see no reference made to draft-ietf-teas-pce-central-control. In fact, that document makes nearly all of Section 1 redundant. 
 
Section 3 is a surprise and, I think belongs in the PCE WG. But (maybe more to the point) this looks like a rather random set of protocol requirements driven by some of use cases, but in no way generic. For example, requirement 6 doesn't seem to be applicable to the use case in Section 10. My suggestion would be to completely remove Section 3, and not worry about it. Protocol requirements will follow obviously from the use cases as/when the PCE WG looks at any necessary protocol extensions.  (This especially in view of Section 14.)
 
Compared with the other use cases, Section 4 seems very terse and does not really explain the use case.
 
I make no comment on which use cases I think are viable and which not. I suspect developers and (more important) operators need to discuss that.
 
Thanks,
Adrian

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 08 February 2017 11:06
To: [email-masked]
Cc: TEAS WG Chairs
Subject: [Teas] WG adoption poll - draft-zhao-teas-pcecc-use-cases
 
All,

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

Thanks,
Pavan and Lou

---

From: Anton Gulida <[email-masked]>
Date: Wed, 8 Feb 2017 13:32:27 +0000

Hi all,

Regards,
Anton

Anton Gulida
Manager of Unit
SN Operation / IT Infrastructure Operations Services Unit

+375 (25) 909 05 82
life.com.by<http://www.life.com.by/>

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Wednesday, February 08, 2017 2:06 PM
To: [email-masked]<mailto:[email-masked]>
Cc: TEAS WG Chairs
Subject: [Teas] WG adoption poll - draft-zhao-teas-pcecc-use-cases

All,

Thanks,
Pavan and Lou

[bip]

BiP – new popular messenger! Free with life:)
Download life.com.by/bip<http://life.com.by/bip>

Внимание!
Настоящее электронное письмо и любые прикрепленные к нему файлы обладают конфиденциальным характером и предназначены исключительно для использования лицом или организацией, которым письмо адресовано. Если вы не являетесь указанным адресатом этого сообщения, пожалуйста, обратите внимание на то, что любое распространение, перенаправление, копирование или использование информации, которая содержится в письме, строго запрещено, поэтому такое письмо должно быть немедленно уничтожено. life:) не гарантирует точности или полноты любой информации, приведенной в настоящем письме. Исходя из этого, life:) не несет никакой ответственности за информацию, которая содержится в настоящем письме, а также за ее передачу, получение, хранение или использования любым способом. Мысли, изложенные в настоящем сообщении, принадлежат исключительно отправителю и life:) может их не разделять. Настоящее электронное письмо было проверено на отсутствие всех известных компьютерных вирусов.

Attention!
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any disclosure, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. life:) makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not obligatorily reflect the opinions of life:). This e-mail has been scanned for all known computer viruses.

---

From: Quintin zhao <[email-masked]>
Date: Thu, 9 Feb 2017 16:25:30 +0000

yes/support (as a co-author).

Thanks,
-Quintin

Thanks,
Pavan and Lou

---

From: Quintin zhao <[email-masked]>
Date: Thu, 9 Feb 2017 17:04:49 +0000

Hello Adrian,

Thanks a lot for your support!

Regarding to the use cases currently documented in the drafts, they are based on the customer requirements we have collected so far. It is true at this stage of the draft, the use case list is not complete and also it is too early to decide which use case is more important than the others. We agree with you that as the draft progresses, the scope of the use cases and priorities might be clearer.

For your other comments,  they are really helpful to make the draft to be more precise and easy to read.  We will have a new revision based on your suggestions and all other comments we receive during this polling period and we will send it to you and TEAS working group the new version after the polling is closed.

See my other comments inline and thanks for your support again,

Quintin

From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, February 09, 2017 10:10 AM
To: 'Vishnu Pavan Beeram'; [email-masked]
Cc: 'TEAS WG Chairs'
Subject: Re: [Teas] WG adoption poll - draft-zhao-teas-pcecc-use-cases

Hi Pavan,

Maybe the chairs will want to sort out the front page author list before adoption to save having the (painful) debate later.
[Quintin] We will work on this to make sure that the author list rule is followed once the draft is more mature.  It seems that for the requirements/use-case draft, it has more authors from the operator side comparing to the solution draft.

Why is this document positioned as Experimental? In view of draft-ietf-teas-pce-central-control it would seem that we have moved beyond an experiment.
[Quintin]  good point!  We would like to change this to the standard track if it is possible.

But, saying that, I am quite surprised to see no reference made to draft-ietf-teas-pce-central-control. In fact, that document makes nearly all of Section 1 redundant.
[Quintin] Will do that in the next version of the draft.

Section 3 is a surprise and, I think belongs in the PCE WG. But (maybe more to the point) this looks like a rather random set of protocol requirements driven by some of use cases, but in no way generic. For example, requirement 6 doesn't seem to be applicable to the use case in Section 10. My suggestion would be to completely remove Section 3, and not worry about it. Protocol requirements will follow obviously from the use cases as/when the PCE WG looks at any necessary protocol extensions.  (This especially in view of Section 14.)
[Quintin] We can either delete it as you suggested in the next version or leave it once the  protocol extension draft is more mature.

Compared with the other use cases, Section 4 seems very terse and does not really explain the use case.
[Quintin] Will update this section to make it easy to read.

I make no comment on which use cases I think are viable and which not. I suspect developers and (more important) operators need to discuss that.
[Quintin]  We will try to have more operators and developers to present the use cases in the mailing list and future IETF meetings.

Thanks,
Adrian

All,

Thanks,
Pavan and Lou

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 10 Feb 2017 12:14:14 +0800

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.

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

All,

Thanks,
Pavan and Lou

---

From: Khasanov Boris <[email-masked]>
Date: Thu, 16 Feb 2017 08:53:42 +0000

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:[email-masked]] On Behalf Of Aijun Wang
Sent: Friday, February 10, 2017 7:14 AM
To: 'Vishnu Pavan Beeram'; [email-masked]
Cc: 'TEAS WG Chairs'
Subject: [Teas] 答复: WG adoption poll - draft-zhao-teas-pcecc-use-cases

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:

>> Thanks!

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

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

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

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

                 >> It is based on P2MP use case but adds additional details, we will re-group it under Multicast LSPs hierarchy.

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

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/>

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

Best Regards.

Aijun Wang

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

All,

Thanks,
Pavan and Lou

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sat, 25 Feb 2017 19:19:09 -0500

All,
    The WG poll is closed.

Authors,
    Please republish draft-zhao-teas-pcecc-use-cases-02 as
draft-ietf-teas-pcecc-use-cases-00 with only the date and file name changed.
Please address the issues raised during the adoption-poll in the subsequent
(-01)
revision.

Thanks,
- Pavan and Lou.