Subject: [Pce] PCE BOF - Draft minutes

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Nov 2004 05:31:36 -0000

Thanks to Richard Rabbat, Jonathan Saddler and Andy Malis.
Comments to the PCE list or to me/JP privately.

Thanks,
Adrian
=====
Path Computation Element BOF (pce)
Wednesday, November 10 at 1530-1730
CHAIR: JP Vasseur ([email-masked])
       Adrian Farrel ([email-masked])

Minute takers Richard Rabbat, Jonathan Sadler and Andrew Malis

Slides and charter available on the Routing Area web site.
http://rtg.ietf.org

1) Introduction, admin, statement of objectives of this second
   BOF (5 minutes) Adrian/JP

Adrian:
In the interest of getting to the charter, slides are on the web site.
Went over the agenda. No questions were raised.
At the mic, please limit yourselves to clarifications.

JP:
Scope of the Potential PCE WG

Specify a set of mechanism for PCE-based path computation of MPLS
Traffic Engineered LSPs in the context of a specific application.

There is no intent to come up with a new Inter-domain routing protocol.
The scope is very clear and is for TE LSPs

Based on discussions with SPs, are we trying to come up with a mesh of
1000 LSPs? Answer is no. So we start by trying to find techniques to
compute limited number of TE LSPs.

We will have 2 or 3 ASes. For the same SP, 4 or 5 ASes likely.

JP:
Objectives of this BOF
- Jerry will go over proposed architecture
- Recap different perceived requirements
- Agree a proposed charter for a working group

2) Quick summary of the conclusion of the first BOF held in San Diego
   (5 minutes) JP

JP:
- Clear statements of requirements from many providers
  (Infonet, KDDI, AT&T, FT, NTT, MCI)
- To be able to compute shortest path in multiple domains
- Diverse path computation (intra and inter domain)
- Dealing with multiple (complex) constraints
- If you have to try to solve a problem with multiple constraints,
  it is NP-complete. So off-line computation is necessary.
- Asked to write an architecture I-D.
- Common theme at SD PCE BOF was need for (G)MPLS TE LSP path
  computation
- Need to develop a draft charter
- We want to narrow the scope of work

Adrian:
- Kireeti asks that MPLS be changed to say GMPLS in all instances
- Agreement that this work needs to cover MPLS-TE and GMPLS
- Asked questions on the CCAMP ML.
   - Is this an appropriate technology to solve inter-domain TE?
   - Does it look like it may solve a problem that CCAMP
     is charted to work on?
- Answers were positive, especially from SPs
- CCAMP will commit to help provide requirements to a future PCE WG
  for the inter-domain TE problem space
- Comments made on the CCAMP list were that the architecture needs
  polishing. Comments are good and were expected

3) Problem space: recap of the PCE architecture ID
draft-ash-pce-architecture-00.txt (15 minutes) Jerry Ash

Jerry Ash:
- Main architects are JP, Adrian and Jerry
- Good amount of discussion. Will summarize issues discussed on list

Terminology:

What is a path computation element (PCE)
- entity (component, application or network node) capable of computing
  a network path based on network graph & computational constraints
- e.g., PCE computes path of a TE LSP by using TED & bandwidth/other
  constraints

What is path computation client (PCC)?
- any client application requesting a path computation by the PCE

What is a domain?
- any collection of network elements within a common sphere of address
  management or path computational responsibility
- e.g., IGP areas, AS, multiple ASs within a SP network, multiple ASs
  across multiple SP networks

What is single PCE path computation?
- single PCE computes a path in a domain

Defining multiple PCE path computation:
- multiple PCEs compute a path in a domain

Defining centralized computation model:
- all paths in a domain computed by a single, centralized PCE

Defining distributed computation model:
- computation of paths in a domain shared among multiple PCEs

Assumptions that are made:
- PCE may or may not be located at head-end
  - e.g. nodes on path contribute to path computation (e.g., loose
    hops) making them PCEs
- Path computation may be made by PCE physically distinct from the
  computed path
- The path computed by PCE may be:
  - complete: full explicit path of strict hops
  - partial: mix of strict & loose hops (may be an abstract node such
    as an AS)

PCE path computation can be used in conjunction with other path
computation models
- e.g., inter-AS TE LSP may be computed using PCE in some domains but
  not others

We make no assumptions made about PCE implementation
- e.g., could be implemented on a router, LSR, dedicated network
  server, etc.

PCE function is independent of the forwarding capability of the node
on which it is implemented

The motivation for this are:
- inter-area/AS optimal path computation (node has partial visibility)
- computation of inter-area/AS diverse path (node has partial
  visibility)
- CPU-intensive path computation/global optimization
- backup path computation for bandwidth protection with backup
  capacity optimization
- multi-layer networks e.g. TDM network provides connectivity for
  client-layer (IP, MPLS, L2, etc.)
- absence of TED or use of non-TE-enabled IGP
- where the node is outside routing domain (e.g., CE to PE path
  computation)
- where the network element lacks control plan or routing capability

Jerry then presented the composite PCE architecture. It is embedded
in the router. It could also be external to be queried for a path. It
could also be a headend LSR, where you query along the way. We can
have multiple PCEs with inter-pce communication. It looks like it's
computed by one PCE.

He listed some considerations discussed in the draft:
- Synchronization
  - non-synchronized (e.g., PCE makes multiple individual path
    computations to generate set of paths)
  - synchronized (e.g., single PCE invokes computations by other
    PCEs before supplying result to PCC
- PCE discovery & load balancing
- Detecting PCE liveness
- PCC-PCE & PCE-PCE communication
- PCE TED synchronization
- Stateful vs. stateless PCEs
- We need to monitor the state of the PCE

A major issue is that of policy & confidentiality
- we must preserve confidentiality across multiple SPs
- we must ensure confidentiality & security of PCC-PCE & PCE-PCE
  messages

For security & confidentiality:
On the PCC-PCE communication
- Snooping not a significant issue but requires authentication
  - might want to encrypt
- Spoofing is a very serious issue as it would allow for traffic
  intercept
  - must offer strong authentication
  - protocol is P2P so this is relatively easy
- DoS important because of 'centralized' nature of PCE
PCE-PCE communication
- same as for PCC-PCE, but add confidentiality
Confidentiality (protection of domain topology information)
- Policy and confidentiality issues must be handled in the information
  returned by the PCE
- Could be done through the use loose routes
- PCE encrypts ERO segments
  - decrypt on entry to domain
- Replace ERO segment with cookie, keeping confidentiality.

JP:
Manageability is probably also something that should be added

Jerry:
PCE Evaluation Metrics
- optimality
- scalability
- load sharing
- multiple path computation
- reoptimization
- path computation time
- network stability
- synchronization
  - between TED & network topology/resource states
  - speed of TED synchronization
  - impact of synchronization on data flows

There's been a good amount of discussion on the list. He listed
them as shown on the slide
- PCE should advertise its capabilities (constraints that can be
  handled, etc.)
- PCE request should handle near-disjoint as well as mandatory disjoint
- TED can include info from sources other than IGP
- Evaluation metrics should include TED sync speed, and impact on data
  flows
- Architecture should elaborate on advantages of stateful PCE and
  pitfalls of stateful PCE in a distributed PCE environment

We've already spoken about TED synchronization speed & impact on
the data flows

JP:
Please give comments about 1st cut at PCE architecture

Mark Handley:
Which part of the architecture are we talking about standardizing?

Adrian:
Please wait for the charter discussion as the charter lists this

Dimitri Papadimitriou:
The name "entity" broadens the scope instead of focusing
Appears that we are standardizing an entity, not a protocol. So what
is expected to be standardize here? LSR behavior internally is not
standardized.

Adrian:
You are saying if we co-locate a PCE with an LSR there is nothing
to do

Dimitri:
Right

???? (MCI):
Please clarify what can be done through dynamic stuff and what can be
done statically

Hani ???:
Does the architecture allow for PCEs to initiate rerouting in the
network?

JP:
Stateful PCE may allow such behavior

4) Summary of existing/future drafts (5 minutes) Adrian/JP

JP:
We'll go very quickly through the drafts
- Techniques for establishing and controlling (G)MPLS LSPs in
  multi-domain networks
  - Presents PCE as a possible approach
- Procedural and operational considerations for PCE in inter-domain TE
- Use of PCE for MPLS Fast Reroute
- GMPLS considerations for PCE (multi-region, MPLS/GMPLS)
- Generalized Traffic Engineering Protocol
  - Proposal for communications between LSRs and PCE based on GTEP
- Use of ring-based SRLG for back-up path computation

Since the last IETF, we had something like 8 new drafts. This shows
interest in the area. No time to go over them. Please go to the slides
on the web site.

Let's go to the key questions.
Clear requirements have been expressed by many Service Providers
during the last BOF in San Diego, on the mailing list,
- Is there agreement on this point?
- No dissent was expressed.

Can we say that this work belongs to the IETF (under the IETF scope
of expertise)?
- Scope is limited to (G)MPLS-TE LSPs

Alex Zinin:
Are there are any comments on JPs question?

Mark Handley:
Still haven't figured out what we're doing (standardizing).
We can't answer this question.

JP:
The charter slide does provide more definition, but has not been
presented yet. So ordering of slides was probably suboptimal.
We'll go back to your point during the discussion of the charter.
Is there enough interest on this architecture?
- No answer

Adrian:
Let's move on to the charter

5) Proposed charter (15 minutes)

The charter is on the slides and separately on the web site.

JP: (Picking out key points)

The PCE Working Group is chartered to specify a Path Computation
Element (PCE) based architecture for the computation of paths for MPLS
and GMPLS Traffic Engineering LSPs.

The Working Group will determine requirements for extensions to
existing routing and signaling protocols in support of such functions
as PCE discovery and the secure and confidential signaling of inter-
domain paths. Any necessary extensions will be produced in
collaboration with the Working Groups responsible for the protocols.

The goal is what kind of protocol we should end up with. We came up
with an architecture but it is not the objective to standardize the
architecture.

Signalling extensions is for a reply/response protocol, not for
other changes.
Note that the communications protocol between PCC and PCE is not
signaling and should not be referred to as signaling.

Currently there are 6 proposals on the table for the protocol.
New protocols, and existing protocols.

Adrian:
We'll not standardize all of them. We will have just one protocol.

JP:
In some cases, it might not be completely desirable to have automatic
discovery of PCE to communicate with and otherwise, fall back to
policy or static configuration

Routing extensions are for auto discovery of PCE.

Loa Andersson:
On this slide, I can't parse the 2nd paragraph. It doesn't come to
conclusion. What do you want to cooperate with other WGs about?

JP:
It means that we may need to extend OSPF

Loa:
On the previous slide, there is a very general comment about
extending/using routing protocols. Do you include PNNI? I want to
exclude LDP.

JP:
We need to be more explicit

Adrian:
You're not going to ask us to list all the exclusions?

Loa:
No, a list of inclusions would be good enough

JP:
When we come up with new protocols, we come up with protocol-
independent metrics to evaluate the protocol.

You want to hide internal topology when you provide path computation

If you return a loose hop, when you signal the LSP, you may not
preserve path diversity

We will need extensions to RSVP

Need security

Arthi Ayyangar:
Are extensions for policy, security and confidentiality specifically
for diverse path computation?

JP:
No general requirement.

Mark Handley:
You talk about specifying techniques. We don't standardize techniques.
We do protocols.
Don't do protocols or techniques when you don't need to have interop.

JP:
In some techniques, you have 2 ABRs that are acting as PCEs, you may
need communication between PCEs and agreed techniques.
Algorithms are not specified but inputs/outputs need to be specified.

George Swallow:
You should not specify an algorithm but the outcome of the algorithm

Choi:
Some of the NEs don't have signaling / traffic engineering capabilities

Adrian:
You're describing a situation where legacy (optical) equipment does not
have a control plane, and PCE is able to choose a route in the network
on behalf of that equipment. I understand.

Kireeti Kompella:
Show the interactions and tell what is going to be standardized. You
need multiple PCEs for reliability. If I'm a PCC, I discover the PCE,
ask it for a path, get it back from it. If I run the PCE as a
distributed computation, that's something we don't need to have
standardized. Use of distributed or centralized computation should be
an implementation detail -- not a standardized item. Please draw a
picture to show what is going to be worked on.

Adrian:
Clearly, it is none of our business to specify what they do when
they implement. Distributed computation is within scope. If in
multi-AS with PCE to PCE communication, is that distributed
computation, and shouldn't it be standardized?

Kireeti:
The behavior of a PCE should be standardized, but the way that the PCE
is used to develop an end-to-end route is not necessarily something
that should be standardized.

If I take a problem and hierarchically decompose it, then we do
need to standardize this.

If I'm the one holding the database, another is doing the computation,
no need to standardize.

JP:
What we try to mention is in the PCE id

Anna C:
If we do have distributed computation do we need to standardize the
inter-PCE communication method?

Adrian:
Somewhat

Richard Rabbat:
Distributed algorithm (not hierarchical decomposition) is an
implantation decision, so it shouldn't be standardized.

Alex Zinin:
Please continue through the milestones.

Adrian:
List is where we will start rather than a complete set

JP:
1st submit a requirements draft. Kireeti, how about CCAMP?

Kireeti:
Previously other groups do the requirements and CCAMP does the work;
this is the other way around. This discusses inter-area/domain/region
work. The other part of the problem is protection. We've been working
on both of these so CCAMP will have some requirements. You also need
to take input from other WG.

JP:
How about MPLS working group for P2MP requirements?

George:
Not quite there yet for P2MP; getting the base thing done so can't
specify PCE requirements yet. Doing the unicast case is a good start.

Adrian:
Not an attempt to force other WGs to do significant work or to
deliver requirements. Rather a statement that PCE does not develop
requirements.

Dimitri:
Previous MPLS work was on signalling/routing protocols, not behaviors.
PCE work should still not be about behaviors even though computational
complexity is increasing.

Kireeti:
One of the things in the charter I read was mp2mp LSPs. This makes me
shiver.

Adrian:
That was an early version of the charter. It's gone now.

JP:
Submit requirements draft.
We need to start with requirements.

Submit draft describing the PCE arch
Try to flesh out PCE architecture I-D. Need to define more precisely
to explain what we mean by distributed computation.

Submit draft specifying communications protocol requirements between
PCC and PCe and PCEs.

Submit draft of a SINGLE communication protocol for use between a PCC
and a PCE and between PCEs.

Submit an applicability draft
Nice to have an applicability draft describing the processes and
procedures for the use of the PCE architecture, protocols and protocol
extensions.

Kireeti:
Do we need a MIB?

Adrian:
If we have a protocol, we must have a MIB. Not immediately obvious
that we need one, but that's the rules.

Kireeti:
Agree that we need management, I'm just wondering if we need a MIB.

Adrian:
Until the IESG changes the rules, we need a MIB.

Richard Rabbat:
Does this include Load balancing between PCEs?

JP:
MPLS PCE Load balancing draft has been created already, need to have
GMPLS extensions

Richard:
Doesn't this mean that PCE needs to provide information on its
Computation power, etc? Does that cause confidentiality problem?

JP:
There are ways around this...

Kireeti:
We should walk before we run, but I would like to see in the charter
the use of PCE for Optical VPNs.

Alex:
This is the 2nd BOF. We don't normally have more than 2 BOFs.
You need to take into consideration whether there is enough interest
in this work and whether we have a good idea, whether we have good
candidates for this work.

Are there any questions on the key questions?
There are two questions:
Is there a need for a WG? Who believes the WG should be chartered?
Many hands raised
Are there any people that don't believe there is a need for a WG?
No hands raised

Hmm. Not all hands raised for those two questions. Who isn't thinking?
Some hands

Ok. Seems to be consensus in the room.

I will take it to the IESG for consideration and we will work on the
proposed BOF charter

Keep discussion going on PCE mailing list.
Find the mailing list for PCE on the routing area web pages.
All discussions on PCE will happen on that list.

Thanks for coming

JP:
Thanks.

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 Nov 2004 22:23:12 -0000

Last call for comments on the minutes.

Please send any comments to me by Wednesday 24th November.

Thanks,
Adrian