[Pce] Draft minutes from PCE WG meeting

[Jonathan Hardwick <[e-mail]>]

Thanks to everyone who contributed to the PCE WG minute taking in yesterday's meeting.  The draft minutes are below.  Please could you review them and, if you have any corrections to make, edit the online copy in Etherpad at the following link?
http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-pce?useMonospaceFont=true

Cheers
Jon

========

PCE Working Group Meeting
IETF 95 (Buenos Aires)
===============================================================================

Working Group Chairs:
     Julien Meuric ([e-mail])
     JP Vasseur ([e-mail])
     Jonathan Hardwick ([e-mail])

Working Group Secretary:
     Daniel King ([e-mail])

Responsible AD:
     Deborah Brungard ([e-mail])

Time:
     April 6, 2016, 1400-1600 (2:00pm-4:00pm)

Location:
     Atlantico B, Hilton Buenos Aires, Argentina

Note Taker:
     Dhruv Dhody ([e-mail])

Jabber:
     Daniel King

-------------------------------------------------------------------------------

1. Introduction
---------------

1.1. Administrivia, Agenda Bashing (chairs, 5 min)

Jon reminds WG to use the mailing list! Please use it!

No Agenda Changes

1.2. WG Status (chairs, 15 min)

Dhruv: Domain-sequence draft pending IRO-Update (under IESG review)
Dan: Thanks to Dhruv for 2 months late review for inter-area-as applicability draft. But. What a great review. Thank you very much.This draft will be updated right after this IETF.
Dhruv; the last draft (draft-ietf-pce-stateful-pce-inter-doman-lsp) seems not be adopted by the WG.
Xian: Re: H-PCE Extensions. I-D is stable we were waiting on further implementations. We have one new implementation that we would like to document. We will also update the security section. Our plan is update and submit soon.
Fatai: The inter-layer draft is expired for a long time. See if more people can review the draft. The GMPLS pcep extensions depends on this draft,so it is better to move forward this draft.
Jon: Please revive the document (update the number) and send an email to the list and say it's alive.

2. Work in Progress
-------------------

2.1 P2MP stateful PCE
https://datatracker.ietf.org/doc/draft-palle-pce-stateful-pce-p2mp/
https://datatracker.ietf.org/doc/draft-palle-pce-stateful-pce-initiated-p2mp-lsp/
Dhruv Dhody, 10 min

Jon:  question for confirmation, can this be applied to stateless PCE?
Dhruv: it's only applicable to stateful PCE, as it is used only in the report message;
Jon: why not merge these two draft into one;
Dhruv: no objection on that, listen to WG. (The reasoning being not all implementation do "PCE-initiation")

Poll by Jon: Who read the document - About 12
Poll by Jon: Who thinks this is a good place to start? - About the same.

2.2 PCEP Extensions for Service Function Chaining
draft-wu-pce-traffic-steering-sfc
https://datatracker.ietf.org/doc/draft-wu-pce-traffic-steering-sfc/
Qin Wu, 5 min

Cyril: Can you do this with stateless PCE?
Qin Wu: Currently we consider stateful PCE.
Cyril: Does not seem big step to also consider stateless
Qin: Try to use initiate message currently, explore more on stateless architecture
Anh Le: Do you have an architecture for this?
Qin: Yes, in the draft it is explained well.
Anh Le: Does the path computation happen at clasifier? In DC case there is unlimited bandwidth assumed.
Qin: The focus is currently in TE case.
Anh Le: For SFC used in data centers, it only needs source and destination information without TE. We should document requirements first before we go for the solution. <partially captured, need to update after listen to recordings>
Qin: currently the draft focus only on TE based solution on SFC. There may be other senarios that has not been covered yet.
Jon: Regarding adoption, SFC WG needs to request PCEP as a control plane architecture.
Qin: Work with control plane authors and discuss more offline.

2.3 PCE as a Central Controller (PCECC) Procedures and Protocol Extensions
draft-zhao-pce-pcep-extension-for-pce-controller
https://datatracker.ietf.org/doc/draft-zhao-pce-pcep-extension-for-pce-controller/
Chao Zhou/Quintin Zhao, 10 min

Sergio: In the document you discredit the distributed signaling approach which is implemented  and deployed
Dhruv (co-author): We will update the draft.

3. New Work Not Previously Discussed
------------------------------------

3.1 PCEP Extensions for MPLS-TE LSP Path Protection with stateful PCE
draft-ananthakrishnan-pce-stateful-path-protection-01
https://datatracker.ietf.org/doc/draft-ananthakrishnan-pce-stateful-path-protection/
Hariharan Ananthakrishnan, 10 min

Sergio: Read, no problem with text, draft only mention MPLS, is there any problem with GMPLS?
Hariharan Ananthakrishnan: Not specific to MPLS, there is no problem.
Huaimo: do you have special extension to compute the backup path? we should consider the primary path, and compute the backup path based on that.
Hariharan Ananthakrishnan: that's how the association works, i don't think any extension needed. Policy on how to compute a backup path is out of the scope of this draft.
Jon: What do you think is missing?
Huaimo: we need to consider primary path during backup path computation, we have an applicability draft for backup path computation by PCE in various scenarios.
Hari: The aim of this draft is only to do association, how is the backup path computation is done (node, link disjoint) is out of scope.
Huaimo: The FRR backup path computation needs different parameter, there was a draft proposed for the FRR backup computation previously.
Jeff T: Progress quickly, will shepherd
Cyril: Another draft exit for FRR. This draft focus on e2e protection.

(2:51:38 PM) ravi: @Huaimo - this draft will not cover algorithms for backup path computation..

3.2 PCEP Extension for Flow Specification
draft-li-pce-pcep-flowspec-00
https://datatracker.ietf.org/doc/draft-li-pce-pcep-flowspec/
Shunwan Zhuang, 10 min

Cyril: It is useful draft to have to know how traffic map (to know which traffic flows on which lsp.)
Shunwan Zhuang: Thank You!

3.3 PCEP Extensions for Tunnel Segment
draft-li-pce-tunnel-segment-01
https://datatracker.ietf.org/doc/draft-li-pce-tunnel-segment/
Xia Chen, 10 min

Dr. Barka: (remote) - What is the SR Segment?
Adrian: Read the architecture document in SPRING.
Jeff T: There is a label binding draft which covers exactly what you require, so why you need a different draft?
Xia Chen: The TLV used there is only for LSP, not tunnel, we aim to bind this to tunnel segment which may include both primary and backup LSP, we want to represent them as a single tunnel.
Jeff T: Same value can be assigned to the two.
Xia: We also have a need for IP Tunnel.
Jeff T: no difference IMO.
Jon (no hat): I agree with Jeff. It is a local decisioin to switch to backup, as long as there is association relationship.
Xia: If the primary LSP is switched to the secondary LSP, the tunnel need not to be changed, right? If you use LSP, then you need to advertise.
Jon: SID doesnt need to change between primary and backup
Xia: Discuss Offline.

3.4 PCEP Extensions for Bidirectional Forwarding Detection
draft-li-pce-bfd-00
https://datatracker.ietf.org/doc/draft-li-pce-bfd/
Xia Chen, 10 min

Jon: This is intresting, first draft to uses PCEP to control OAM, can it made more generic.
Xia Chen: This is only for BFD, not for generic OAM. This is useful not only for MPLS-TE, but also SR.
John: Sounds an interesting idea, will be great to make it generic. There is an assumption that this is useful if reverse path cannot be deduced from the forward path. Useful regardless.
Adrian: When the WG accepts LSP Initiation, the flood gate is opened. We have to either re-open the architectural discussion, or understand that PCE has become [a apart of] an NMS. If that is the case, we must expect to be able to push both control and behaviour information. Flowspec is for saying what the LSP is for. This work is for controlling the LSP.
Jon: What i was saying is that this seems more generic and whether we want it or just on BFD?
Jeff: need to clarify that bi-directional is not much; BFD is related to silicon, so enabling BFD via PCEP is a good idea, but passing configuration parameters maybe not.


3.5 Hierarchical Stateful PCE
draft-dhodylee-pce-stateful-hpce-00
https://datatracker.ietf.org/doc/draft-dhodylee-pce-stateful-hpce/
Dhruv Dhody, 10 mins

Rajan Rao (jabber): what happens when a partial set of child PCEs delegate but not all? what would be E2E LSP state, who owns?
Dhruv Dhody: Please can we have this conversation on the list
Jeff T: Good work. Each vendor deciding to expose LSP on his whim might be an issue. Scalability issue needs to be clarified.
Dhruv Dhody: We should add more clarification. Only inter-domain LSPs need to be exposed. Need to work out how much info is needed for these LSPs, just lsp state might be reported and use existing mechanims like pathkey. to hide information.

3.6 Establishing Relationships Between Sets of LSPs and Virtual Networks
draft-leedhody-pce-vn-association-00
https://datatracker.ietf.org/doc/draft-leedhody-pce-vn-association/
Young Lee, 10 mins

Jon: is this applicable to ACTN work?
Young: Yes.
Jon: PCEP will become one of the ACTN solutions? have you considered about other solutions?
Young Lee: Yes, PCEP is one way to implement some ACTN functionality. It depends on the operator, and see how they would like map their network into ACTN.
Daniele: There is not full plan map for ACTN. There may be other solutions, always welcomed for discussion. What could be useful is to prepare an applicability statement to list out set of RFC and drafts that might be applicable with suitable gap analysis.
Young: for other applicability considerations, they may not belong to PCE WG, should be TEAS.
Jon: great to know where PCEP can help to ACTN, also the group.

3.7 PCE Hierarchical SDNs
draft-chen-pce-h-sdns-00
https://datatracker.ietf.org/doc/draft-chen-pce-h-sdns/
Huaimo Chen, 10 min

<no questions>

3.8 PCEP Procedures for Hierarchical LSPs
draft-margaria-pce-pcep-hlsp-extension-00
https://datatracker.ietf.org/doc/draft-margaria-pce-pcep-hlsp-extension/
Cyril Margaria, 5 min

Haomian: Can you add some more procedures, to know who are the PCC and PCE and how they interact with each other for H-LSP, some sort of architecture/use case will be helpful.
Cyril: Some text exist, will be added more details in future version.

---meeting adjourned---