IETF-75 PCE Working Group Minutes
Monday, July 27,
2009, 5:40 PM
1.1.+1.2. PCE WG
Meeting IETF 75
2.1. Extensions
to PCEP for P2MP LSPs
2.2. CE-based
Computation Procedure To Compute Shortest Constrained P2MP Inter-domain TE-LSPs
3. PCE TED Creation
and Maintenance
4. The
Application of the PCE Architecture to the Determination of a Sequence of
Domains in MPLS & GMPLS
5.1. Requirements
for GMPLS Applications of PCE
5.2. PCEP
Extension for RWA
5.3. PCEP
Requirements for WSON Impairments
1. Introduction
1.1. Administrivia, Agenda Bashing (chairs, 5
min) [5/80]
- No agenda requests or changes.
1.2. WG Status (chairs, 10 min) [15/80]
Milestone
update
- No one is currently working on the Inter-Area MPLS and GMPLS Traffic
Engineering Applicability Statement. We may need to look for volunteers to take
over this work.
- MIB co-authors no longer working on PCE or MIBs. Again, we will need to look
for volunteers to take over this work.
RFC Update
- Six new RFC's since IETF 75
IESG
Processing
- Monitoring I-D is with AD to check IANA question correctly addressed.
- P2MP Applicability will need a write up.
Not on the Agenda
draft-ietf-pce-pcep-svec-list-01
Julien Meuric: Do the authors have an update?
Daniel King: The document [draft-ietf-pce-pcep-svec-list] is complete. We need
to review and submit a new version and then the authors will request WG last
call.
draft-ietf-pce-vpn-req
Julien Meuric: Does the AD have an opinion?
Adrian Farrel: I would like to keep the VPN reqs [draft-ietf-pce-vpn-req] alive while the solution
is developed.
2. P2MP
2.1. Extensions to PCEP for P2MP LSPs (Dan King, 5
min) [20/80]
draft-ietf-pce-pcep-p2mp-extensions
JP Vasseur: You mentioned you had a couple of implementations. Can you say how
many, any interop, and what percentage of functionality has been implemented?
Daniel King: We currently have two implementations. I don’t know the specific
functionality that’s been implementing. I'll find out. We are also looking at
inter op in the future.
JP Vasseur: Do we have any service providers around who are interesting in
deploying this technology? (Dave McDysan raises hand)
2.2. CE-based Computation Procedure To Compute
Shortest Constrained P2MP Inter-domain TE-LSPs (Quintin Zhao, 10 min) [30/80]
draft-zhao-pce-pcep-inter-domain-p2mp-procedures
Daniel King: Zafar Ali BRPC solution
does not compete. It is complementary.
JP Vasseur: What kind of plan do you have? Would it better to work on a single
solution or keep them separate?
Daniel King: We had hoped to meet with Zafar at the IETF. We need to come up
with a strategy for both drafts. We will take this offline and have a call with
Zafar and discuss.
JP Vasseur: I suggest that you resolve these issues and we look at this
becoming a WG at the next IETF.
Daniel King: If we formulate a plan with the other authors. Could we look at
requesting the work becoming a WG document via the list earlier than the next
IETF?
JP Vasseur: Yes, we can.
JP Vasseur: Also, are service providers interested in these inter-domain
solutions. P2MP inter-domain is very complicated.
Daniel King: We are actively soliciting feedback outside the PCE WG and IETF,
including iPOP 2009 and MPLS 2009.
JP Vasseur: Good, please provide feedback
on the list.
Daniel King: Yes, will do.
JP Vasseur: This is a complicated solution. We can provide a technical solution
but the bigger problems are administration, policy, management, operational
issues. It’s a huge amount of traffic and different from P2P inter-domain.
Daniel King: Absolutely, we do very much understand.
3. PCE TED Creation and Maintenance (Young Lee, 10
min) [40/80]
draft-lee-pce-ted-alternatives
<At the start
of the presentation>
JP Vasseur: The devil is in the detail. The architecture looks like BGP
architecture with route reflectors. If there are a lot of implications we need
to consider this.
Young Lee: This document just elaborates on a number of possible options to
consider. When the WG shows an interest we can work on realistic and scalable solutions.
JP Vasseur: Slide comment [storage demand] did you evaluate the amount of data
you would store?
Young Lee: If we use IGP we have to upgrade our control plane network work processor.
This is part of our motivation.
JP Vasseur: The storage will be the same?
Young Lee: Yes.
Young Lee: When the PCE performs the path computation, then we do not have to
flood info.
Greg Bernstein: By not keeping the TED at each node, we are not performing all
the routing and flooding.
JP Vasseur: If you don't do it you can't fall back on distributed computation. In
the packet world off-line computation is usually combined with distributed
computation.
Young Lee: We did add resiliency requirements. We are considering the
possibilities and architectures.
Wen Hu Lou: When you say reduced storage demand, does this mean partial
topology information?
Greg Bernstein: No, we mean at the nodes, not at the PCE.
Wen Hu Lou: That is what I meant. This looks like opposite to what the IGP
does. This is a tradeoff of storage and computation time. Beyond storage gain,
have you considered the loss of speed.
Greg Bernstein: When you get to GMPLS etc. we need more info that you don't use
for IP-type computations. E.g. WSON, SONET etc. is necessary for optimisation.
Hence compromise of lots of data versus where computation is done. We are not
trying to improve the stability of the network processor. This is info used for
optimization.
Young Lee: We are not interested in implementation at the moment. We want WG
support before we work on more analysis.
Wen Hu Lou: There is a critical issue with this design, the synchronization
between TEDs.
Young Lee: Yes. This is a requirement.
Igor Bryskin: You do save storage space on the node and PCS as well.
JP Vasseur: Disagree. This is an implementation issue. Do you have to store the
data twice?
Igor Bryskin: Yes on PCE you need LSAs in the DB exactly as received in order
to flood. Then you also need the same info in the TED. Another comment, it is
obviously more efficient to send data just from node to PCE rather than flood
all data in all directions.
<End of the presentation>
Young Lee: We
request that this becomes a WG document.
Greg Bernstein: This is an analysis doc. Not doing solutions. We are trying to
answer the type of questions that are coming up.
JP Vasseur: Why can't you do analysis without being WG doc? There are
implications on other WGs (esp. CCAMP). I agree with the first slide. This is
not against PCE architecture. But it does impact how the network is operated. I
suggest we meet with authors and chairs of both WGs. We will try to do this,
this week.
4. The
Application of the PCE Architecture to the Determination of a Sequence of Domains
in MPLS & GMPLS
(Dan King, 10 min) [50/80]
Dave McDysan: What is meant "no
preference for choice of interconnection". It's not clear from the draft.
Daniel King: Per-domain PC is good if you have a good idea of where the
preferred interconnection is. In BRPC you can let BRPC work out the best
interconnection points.
JP Vasseur: We discussed in the WG there is no need for dynamic discovery
between the PCE's (Child and Parent PCE).
JP Vasseur: Did you look at how this relates to the policy framework?
Daniel King: No.
Igor Bryskin: I think good work and good start BUT benefit is obviously that
you identify the chain of domains. Recommend to limit to domain path. Don't
summarise TE info.
Daniel King: We don’t summarize TE aggregation.
Adrian Farrel: There is absolutely no way my name would be on any draft that
proposed TE aggregation.
Wen Hu Lou: Step 5 is there a single point of failure at parent node. Could
this be done in a distributed way by "promoting" a child?
Daniel King: Good point. Yes, as per designated router election.
Wen Hu Lou: If we are doing this, nodes have dual role. In this case, elected
parent needs to know domain topology
Daniel King: Yes, perhaps not all
children can be promoted.
Fatai Zhang: Also I think this is a good idea. Is there is a sequence ordering
for requests from parent?
Daniel King: It might depend on applicability.
Fatai Zhang: Can speed things up by pipelining all requests.
Daniel King: Yes.
Jonathan Sadler: I am very supportive and it's consistent with G.7715 etc. Would
you support multiple generations?
Daniel King: Possibly.
Jonathan Sadler: Agreed. Also I don’t see Dave Ward in the room but this
containment architecture exists in IS-IS already.
5. GMPLS
5.1. Requirements for GMPLS Applications of PCE
(Kenichi Ogaki, 10 min) [60/80]
No comments.
5.2. PCEP Extension for RWA (Young Lee, 10 min)
[70/80]
draft-lee-pce-wson-routing-wavelength
Julien Meuric: This work is
also in the package of I-Ds to discuss with CCAMP chairs.
Young Lee: But this is specific to PCE WG (it is PCEP) you should make the
decision.
Julien Meuric: The document will stay here. We need strong
coordination with CCAMP. It doesn't change the way this draft fits the PCE
working group.
Igor Bryskin: How do you identify wavelength for inclusion in the path.
Young Lee: Available wavelength must be advertised into TED.
Igor Bryskin: Did you include tunable? Can you indicate that the NE can choose
a tunable wavelength? It needs to be able to select the device (resource) which
is not the same as the frequency label.
Igor Bryskin: There are some graceful restart scenarios that need to be
considered.
Young Lee: Please send them to the WG mailing list.
Julien Meuric: This question is also relevant to CCAMP.
5.3. PCEP
Requirements for WSON Impairments (Greg Bernstein, 10 min) [80/80]
draft-lee-pce-wson-impairments
Igor Bryskin: What does
"several paths" mean?
Greg Bernstein: There is some limit to the number of paths.
Igor Bryskin: What if all potential paths are failures? Do I
ask for another several paths?
Greg Bernstein: Hmm. Need to think about this. May be a good item to consider?
Perhaps we also need to specify the number we look to recompute.
Young Lee: This is also policy based. There is nothing in PCEP that specifies
what to do if your request fails.
JP
Vasseur: Yes that’s right. We can also use XROs for subsequent requests.
JP Vasseur:
I wanted to ask the WG what people thought of using PCEP to report the status of LSPs and to
monitor health etc.
Greg Bernstein: Reason why computation did not complete, is that too much status
info? We can trim that. It’s nice to know why a request failed.
Wen Hu Lou: If I make a mistake in
setting a constraint, how will I find out which constraint causes the failure.
In the end you end up with nothing.
JP Vasseur: We discussed relaxing
constraints on the fly some years ago. This is hard, but interesting.
Daniel King: A scenario is that you have a hard set of minimum requirements and
a set of desires is an NP hard problem.
Giovanni : One clarification, is the block another PCE?
Greg Bernstein: Yes, we are saying give me multiple potential candidates and
feed this to my RWA algorithm.
Julien Meuric: Just for
clarification, does the first PCE compute the route and request a validation of
impairments?
Greg Bernstein: The draft shows the
sequence of path computation. The RWA PCE is the coordinator.
Julien Meuric: So one implementation could be a simple list of
possible paths.
Greg Bernstein: Yes, it could be a list
of pre-computed paths.
Eric Gray: Does your model assume that requests are handled network-wide one at
a time. Or have you simulated what happens when many requests are asked at the
same time from different places?
Greg Bernstein: We are restricting
this to a specific sub-case at this time
Lou Berger: That sub-case maybe makes the work less useful (I guess we can walk
before running). Does lambda-specific info go across the RWA/IV (blue - see
slide) interface?
Greg Bernstein: That would be
useful information to go across.
Lou Berger: Particularly if must choose lambda depending on interference.