Minutes for PCE at IETF-95
minutes-95-pce-1

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

Working Group Chairs:
     Julien Meuric (julien.meuric@orange.com)
     JP Vasseur (jpv@cisco.com)
     Jonathan Hardwick (jonathan.hardwick@metaswitch.com)

Working Group Secretary:
     Daniel King (daniel@olddog.co.uk)

Responsible AD:
     Deborah Brungard (db3546@att.com)

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

Location:
     Atlantico B, Hilton Buenos Aires, Argentina

Note Taker:
     Dhruv Dhody (dhruv.ietf@gmail.com)

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.

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