2.5.9 Path Computation Element (pce) Bof

Current Meeting Report

Minutes of the Path Computation Element BOF (pce) IETF-60 San Diego
#############################################################

Chairs: JP Vasseur, Adrian Farrel
ADs: Alex Zinin, Bill Fenner

*thanks to Dave Ward and Don Fedyk for their help taking notes*

1) Agenda bashing, Admin and objectives - Adrian
**********************************************************

2) Overview of PCE-based path computation - JP
*********************************************************
What is the BoF about ? What do we mean by PCE ?
PCE is an entity capable of compositing a path. Mainly we mean MPLS TE for now but could expand to other (IP paths).
If you are computing a path for a loose hop you are a PCE. PCE examples: Router, LSR, Server.
PCE is just an entity capable of doing some computation
Does not require centralized path computation. PCE can do distributed computation.
One View: Each router is a PCE for it neighbors.
Could have a PCE where global optimization is required
Could be completely stateless or stateful
PCE approach is not necessarily the only approach but one approach
PCE suits a number of problem spaces.
Highlighting that PCE can be centralized or distributed model and need both

3) Requirements for PCE-based path computation (30 minutes) Raymond (Infonet), Kenji (KDDI), Jean-Louis (France Telecom), Seisho (NTT), Jerry (ATT), Javier (Telefonica), Venkata (MCI)

Raymond Zhang, Infonet
Case customer wants a guaranteed path that is delay sensitive. Problem is there is high interconnect multi domain. Want to select paths with a high degree of control.

Kenji Kumaki, KDDI
Multi AS inter SP, Shortest end to end, Re-optimization, Multi IGP areas, Re-optimization. These are difficult problems to solve. Scalability issues with Routing and Signaling.

Jean Louis Le Roux, France Telecom
Head end is sufficient for most., Complex routing conditions for P2 MP. Multi constraint Backup Path. Inter domain path computation. Diverse path computation. Could benefit from path computation element. Dedicated tool, Centralized, Collaborative Useful for backup.

High level requirements: Reliable signaling protocol, Automatic discovery, Scalability, Balance the computational load, Distribute PCE function, High Availability, Robustness.

Question Dimitri Papadimitriou: is list detailing the PCE to PCE signaling?
JP: Yes
Dimitri: So 1st bullet is client to server signaling relationship?
JP: Yes good point load share requests but also need case where paths are dependent on one another.

Jerry Ash, AT&T
Requirements: Migrating to converged Network.
IP MPLS and all TDM to VoIP. These are the architecture plans, not committed and being implemented. PCE is part of the plan. Inter area, very large network need a solution that scales. Intra and inter AS. Need shortest path across Network
Need standards based solution

Seisho Yakukawa, NTT
Requirements: P2MP, IP-TV, Video, CPU intensive, P2MP, Inter-domain, Need wider community, PCE approach is good.

Arthi: PCE to PCE or LSR to PCE based on same protocols?
Adrian: Yet to be decided. Good Point.
Arthi :When we talk about signaling, is it query-reply or MPLS TE signaling?
JP: query-reply, no change to TE LSP signalling
Igor: Two types of signaling: are they the same ?
Adrian: This is what we are deciding. Please wait for this.
Dimitri: The issue I see is there need for synchronization. There is a need for coordination.
Adrian: Yes that is what we are discussing
?? You are going to have a discussion part a the end
JP:Yes.
Bijan Jabbari : Are you asking in the context of MPLS?
JP: Yes.
Bijan: This is related to some specific application.
JP:Yes

Venkata Josyula, MCI
Requirements: Multiple AS, Hierarchical AS and be able to build AS, Inter area PCE..
Inter AS: Need a simple solution. Not saying you can use BGP next hops.
Do need TE Policy. Like the flexibility to coexist with other approaches.
JP: Interesting question. PCE could be used for inter areas and BGP for inter AS (AS path selection). This is an Interesting point.

4) Functional requirements of a PCE-based path computation system - JP
***************************************************************************************
Functional requirements:
Multiple Models Picture:
Centralized,
Cooperative model PCE for one [or more] parts of the path.
Distributed : Each node is a fully distributed PCE (example: Backup Tunnel path comp).
Discovery of the PCE in a network:
Static Provisioning
Dynamic discovery computing resource (load sharing between multiple PCEs)
PCE may have routing adjacency with other nodes or may use some [other] protocols)

LSR-PCE Signaling: Interaction between the router and the PCE: RSVP, or new protocol. Need to specify request and reply.

Arthi: On slide are PCE red circles. Are these the only PCEs?
JP: No of course not.
From this figure each LSR is a PCE or does it talk to other PCEs?
Adrian: If you have an Abstract node or a loose path you are using a PCE.
Arthi: This picture is not necessary the only view. It is not mandatory.
JP: It can be a server or a router itself.
Bijan: It can be [LSR]{missed it} or higher level than that?
?? It would be useful to have distinction between PCEs. Implement a LSR as a distributed machinery with PCE and share the network with the data network.
JP: We can discuss this.
?? Many, many approaches. Distributed path computation. Information is not synchronized. If you do it on several path computation elements.
Adrian: Yes that is a problem. Clearly diverse path. Clearly not produce loops.
?? Signaling protocol soft state?. RSVP-TE sounds like a funny approach. Will there be others?
Adrian: Yes 5 proposals already ...
Alex. Clarification on slides please.
Ina: Do you have model ? Does the PCE have to run routing or not? Type of discovery mechanism are a direct result of the model.
JP :Yes it is dependent.
Ping Pan: Inter domain. Great one [requirement]. What is the best algorithm? That is independent. How you communicate. COPS, RADIUS DIAMETER. Cisco scripts overnight.
JP: Not sure what you are trying to clarify.
Ping: You are limited to data path signaling.
Alex: Is it local to the box or cooperative [across boxes]?
JP: Inter domain must be standardized to some extent to compute an inter-domain shortest path and avoid loops. Intra not necessary.
Ping: Preventing loop is one thing.
Alex: Cut line hold to discussion.

JP: Policy, Security, Confidentiality.

Adrian: Not here to discuss drafts good bad or WG drafts. Just want to expose the drafts. If you have questions please go to authors not to microphone.

????: Does the LSR have to be the PCE?
JP: No, it can be another box.
????: Can PCEs be out of band?
JP: At end of meeting
????: Can we use this to find diverse paths? Can we use this for cooperative model? Are there loops formed?
JP: Yes for diverse paths, no to loops, yes to cooperative
Sue Hares: Does the PCE have to participate in routing?
JP - It can

5) Current status of drafts (20 minutes) - Several
********************************************************
Background and framework drafts 4
Requirements draft 1
PCE Discovery (see IDs in CCAMP, ISIS and OSPF WGs)
PCE signaling 3 drafts
Modified TE Flooding
Applications 2 drafts

Quick walk through the drafts - Minor clarifications and comments

JP: No time to discuss the draft in detail by the way, not the objective of this BOF.

draft-leroux-pce-backup-comp-frwk-00.txt Jean-Louis
Nurit Sprecher: What is what the assumption for failure? A single failure?
JL: Yes this is reasonable. All networks are done this way.
Nurit: For multiple failures?
JL: This is to present one model for example.

draft-oki-pce-gmpls-req-00.txt, Eiji Oki
Two kinds of requirements
PCE requirement: GMPLS and MPLS
Functionally separated from MPLS NODE
Provider can choose appropriate implementation.
Centralized and distributed.
Multi region TE in GMPLS
Interworking between MPLS and GMPLS.

Hierarchical LSP setup.
Trigger by higher level LSP setup. PCE helps GMPLS node to setup hierarchical LSP.
PCE Triggered LSP should be supported. Treat as single region network from higher level. Standard Opaque TE information. Nodal requirement
PCE two request modes: Mandatory mode, Normal request node can ask own node or PCE.

Solution drafts
******************

draft-oki-ccamp-gtep-00.txt, Eiji Oki
Generalized TE protocol GTEP.
Features:
Support trigger hierarchical LSP setup
Support TEDB synchronization
Reliable transfer of larger data based on TCP
GTEP running code

draft-vasseur-mpls-computation-rsvp-05.txt, Alia Atlas:
Extensions to RSVP-TE
Extend RSVP-TE a bit between the head end and the PCE.
Most of the stuff is there.
Request and reply message.
Some additional objects.
Drafts consider a number of different scenarios.

draft-choi-pce-e2e-centralized-restoration-srlg-00.txt, Jun Kyun
Centralized control from optical network and GMPLS 50 Ms constraint.
Logical Ring configuration based on SRLG and PCE
Compatible with ASON architecture SG-15
Simplifies and reduces management.

Bijan Jabbari: 50 msec requirement is driving control not feasible.
Jun: Where is the location of the central controller. The requirement is there.

IDs related to P2MP
LSR PCE signaling required could be part of a general PCE

IDs under construction - JP

Requirements for signaling necessary
Quick overview of inter-domain QoS ID, Mohamed Boucadair


6) Discussion points, WG formation, possible goals and milestones? Adrian, JP
*********************************************************************************************
JP: We need to discuss where can we do the work, what the scope is: MPLS or IP as well?

Adrian: Multiple components: Do we need a protocol at all ? Resolving how?
Alex: Do we have a good understanding ?

Bijan Jabbari: Note that there are requirements from research networks as well as SPs for Path Computation and routing

Alex: PCE computations?
Bijan: Yes.
????: LSR or something like that?
Bijan: In optical network very complex. Loops are a problem and problems are usually N-P complete. Complex. Requires a PCE.

JP: Let’s discuss whether we need new protocols?

Zafar Ali: There is evidence for PCE needs/desires. Yes we should be working on this in the IETF.

Mark Hanley: Is spectrum too big? New routing architecture is evident and watch how far you want to go.

Alex: Lots of requirements however, from an architecture point of view there is confusion. Are we separating out some non-forwarding pieces.

Someone from Korea: Is scope limited to MPLS TE?

JP: It includes GMPLS

Arthi: Clear that SPs require this. Server SPs already have some mechanisms. People may already have some form of this functionality. How are people are going to cooperate? Who will change? How much will existing mechanism affect what we do?

Adrian: You are saying even if this a good idea we are too late? We may be too late - Service provider can say. If we come up with a different protocol will this have impact? Do you have strong opinion?

Arthi: Yes should be done, but where? Don't know. Cannot standardize computation algorithms. Don't think so. Differentiates on PCE from [vendor to vendor]

Mohamed Boucadair, France Telecom: the PCE control plane and forwarding plane. If you have one element for this PCE it and element that manages your inter domain resources. Inter-provider not arguing for this. What we need the protocol in two different domains.

Dimitri: Does it cover co-located PCE. Should the PCE talk to elements of different vendors? What are changes expected to communicate LSR<->PCE? How far do we change RSVP? Please add requirements doc. Must have interoperability cleared up - don't get this. What about scalability problems of PCE once all TEDB are combined.

Zafar: Offline tools already present but, SP doesn't like them or not.

Dima: We know there is a need. IETF should take it on. There should be a new WG. There needs to be clarity on PCE being w/in the LSR or if the PCE should be a router to participate.

Francois LeFechaur: Clear requirements. We should do it.

Bora A: How you communicate to the router. Only Standardized. Co-located PCE on the router no different than what you do today. Comp SNMP TCL scripts and we need another algorithm. I think RSVP-TE approach may be the way to go.

Igor: I agree [with Bora]. Protocol only. Formidable task. Standardizing constraints is tough. I do believe we need to review the architecture. SNMP like protocol is a better choice.

Bjian: Need some form of centralization?
Adrian: Support centralization but not mandated
JP Yes. First slide.
Bijan: Distributed as well? Need multiple computation algorithms in the PCE. However that does not need to be standard.
Alex: We have some experience documenting algorithms. Kireeti did document an algorithm but this went [no where]. This could be done as Informational

Bijan - Is there centralization or not? There has to be both distributed and centralized.

Ina: Several people requirements and tools. Clear sign yes. Need for new working group. Should PCE be part of an LSR or and independent element?

Bora: Only thing that can be standardize is the communication, not algorithms. Ok creating another WG but, there isn't a lot of work here.

Igor: Only can standardize the communication between LSR and PCE. We need the work, the WG and the architecture. Perhaps we should have a configuration server like ATM.

Richard Rabbat: Clearly requirements, take this on. Scope don't standardize algorithm. Where. Stay in CCAMP.

JP: Note that in some cases such as collaborative path computation, you need to standardize algorithm to guarantee optimality (shortest path) and prevent looping problems.

Alia: We need signalling, we need architecture, we need resolve this, it should not be CCAMP as that WG is swamped

Hani: We should take on [new] WG

Bruce Davie: Let's not standardize the algorithms but make sure we specify it enough to make sure we don't have loops. Kireeti says that we should use BGP. It should be a WG and w/in the IETF.

Dimitri: The distributed model is difficult. Access of LSR to PCE. Next hop path resolution protocol. Important aspect should determine what are the based computation assumptions. Don't want one PCE then another PCE etc.

Ping Pan: What is a domain?
Adrian: Have some input areas computation domain and protection domains. Broad computation visibility.

Summary
************
Alex takes the mic:
Clearly there is a need
Clearly there is support for a solution
Confusion on what needs to be specified: communication, etc
Many requirements but quite diverse. Requirements good but so large.
What need to be standardized ? How this will affect the existing work ?
Tread very carefully and do architectural work so not to screw the internet
Heard strong opinion that we shouldn't standardize algorithms

Steps
********
Create mailing list - everyone will join
Need framework/arch doc(s)
Need to reduce requirements and present what will be covered
If we have something more complete by the next meting we will need another BOF.

Slides

Agenda