IETF 77 PCE Working Group Meeting
Thursday, March 25th, 2010, 13:00 PM
1. WG Status
Presenter: PCE Chairs
- Milestones: Applicability statement for inter-area MPLS and GMPLS Traffic Engineering. First draft submitted by Dan [Daniel King].
- Milestones: PCE P2MP communication requirements in RFC Editors Queue.
- PCE P2MP PCEP protocol extensions have finished last call.
JP Vasseur: We would like to know who has implemented this solution.
(one hand raised)
Julien Meuric: If you are planning to implement you can also email co-chairs as well.
- PCEP MIBs are on today's agenda.
- PCE recharter. More discussion needed, please email co-chairs or list!
- The use of SVEC list for Synchronized dependent path computations.
JP Vasseur: Does our AD have a comment?
Adrian Farrel: This was on IESG agenda before this IETF , we had a heavy load so we moved this item to early April.
- Inter-layer Requirements and Extensions
Tomonori Takeda: A brief update, the inter-layer requirements is ready. The chairs can decide how to proceed. The extensions work will need more time to work on the protocols.
- VPN Requirements: We have a draft on the agenda today that addresses some of the requirements.
- Vendor Constraints Document
Adrian Farrel: As AD, I do not want to push this work. I am still there as an
author. If anyone wants to continue this please come in a pick this up. Greg [Bernstein]
is currently an administrate editor.
Young Lee: I will present a draft that has vendor constraints [WSON]; maybe I will take editorial control of this document.
Julien Meuric: Good.
- Manageability Document
Adrian Farrel: I wrote this as chair of PCE as an experiment to improve manageability of PCEP. It was good housekeeping. Then RFC5706 came along to provide a new reference. The options the chairs recently expressed on the list are:
1. Keep it alive
2. Kill it, move to 5706
3. Put in RFC repository for historic reference, move to 5706
JP Vasseur: I think that draft helped dramatically, as a matter of fact
other WGs [roll] have used this draft. It would be good to see it become a
historic RFC. So, do we kill it?
(No support in room)
Or publish as historic RFC, poll on list?
(Quite a few in support)
OK we will take this to the list.
2.1. Textual Conventions and PCE Discovery
Presenter: Daniel King
JP Vasseur: When are you hoping to complete the document?
Daniel King: Before Maastricht [IETF 78], based on the lack of the MIB expertise available for this work. I think it's good to have an early MIB Dr review.
JP Vasseur: Great, agree.
2.2. PCEP MIB
Presenter: Kiran Koushik
JP Vasseur: One of the items mentioned is
stateful PCE. We need feedback from implementers as it may be heavy.
Kiran Koushik: No feedback yet. We will try again. If it's too heavy we may want to put it in a different document.
Daniel King: Do we want to include P2MP in this MIB?
Kiran Koushik: It's already a complicated MIB, people are often put off with implementing complicated MIBs. I suggest we have a different draft for P2MP.
Daniel King: Great, I agree, I just wanted to raise the issue.
JP Vasseur: Yes.
Julien Meuric: Also agree, we want to complete the PCEP MIB for reference and cover P2MP and other areas later.
3.1. PCEP Extension for RWA
Presenter: Young Lee
Julien Meuric: A new requirement [Wavelength Policy Constraint] from the operators is a good idea.
3.2. PCEP Extension for WSON Signal Compatibility Constraints
Presenter: Young Lee
Regarding the list of modulations and FECs using PCEP. Do you expect someone to
receive a single path for a proposed modulation during the PCEP response? We do
not have the full information to make that choice. Actually we would have
expected the PCE to make the choice. Can you elaborate on the use cases?
Oscar Gonzalez De Dios: During the request we would like to do specify the specific modulation type. So I agree that it should be specified in the request and not let the PCE select the modulation type.
Julien Meuric: From an operator perspective do you really expect the operator to decide on the modulation type before path computations request?
Oscar Gonzalez De Dios: Yes.
Julien Meuric: What's the point of automatic computation?
Oscar Gonzalez De Dios: Maybe you have a choice of modulation types available. Perhaps with a specific modulation type you cannot compute the path without having regeneration. By allowing the request of a modulation type you can narrow selection down, or decide on a specific modulation type.
Julien Meuric: There is an OSPF extension in CCAMP so that the PCE is aware of the modulation formats supported by the network. The PCE can then decide based on the requirements.
Young Lee: This requirement has been requested from two operators. This is not a specific product feature.
Pierre Peloso: I do understand the point of specifying the modulation because you do not want advertise specific transponders. Do you really need a list of modulation types?
Igor Bryskin: I think I understand the requirements and support it. Consider there is a source and destination with overlapping modulations. Computing the entire path would require regeneration which we may not want to support. We could then constrain the modulation type. It’s a corner case, but it's legitimate.
- WG Adoption Request
Considering the signaling RSVP extension is not a [CCAMP] WG document. We do
not want to constrain the RSVP extensions based on our PCEP work. We had good
discussions today let's continue these discussions and follow the CCAMP work as
well. Let's also continue comments on list.
Young Lee: I agree with you. Attilla [Attica] has some additional requirements as well.
- General Comment
JP Vasseur: We have had an avalanche of new drafts with minimal discussion on the mailing list. Please use the mailing list for discussions and not Facebook J
3.3. Extensions to PCEP for TE-LSPs in GMPLS Networks
Presenter: Fatai Zhang
- New Object: QoS [Slide 6]
Vasseur: Mentioning this is a QoS object
is misleading. You should change it.
Fatai Zhang: Ok.
- Next Steps
Julien Meuric: I like the first bullet [We would like to talk to the co-authors of draft-margaria-pce-gmpls-pcep-extensions-00] this makes our job easier. Let's now move to second document [draft-margaria-pce-gmpls-pcep-extensions-00] and make comments for both documents at the end of the presentation. In general this work is very interesting.
3.4. PCEP Extensions for GMPLS
Presenter: Oscar Gonzalez De Dios
Traffic Parameters [slide 5] why a new object?
Oscar Gonzalez De Dios: There are some bits available, but we prefer a new object and format it with the additional information. We can now use the object type the traffic type, for example G709, SDH, etc.
JP Vasseur: Do not hesitate to involve the WG to perform the merge. It’s a good way to isolate the choices, and then poll the WG for decisions.
Oscar Gonzalez De Dios: Will do this via email and comments.
Young Lee: I agree. We will work with you guys.
4.1. PCE Applicability to Inter-Area and -AS MPLS and
Presenter: Daniel King
Were you able to discuss the work with Emmanuel Dotaro? He was very interested
in this work.
Daniel King: Will do.
Pierre Peloso: I will help with co-ordination.
- The Work [slide 3]: is there anything missing in the current PCE solutions tool kit?
Good idea but you need to be careful and consider the metrics you are using to
decide what's sufficient and not sufficient.
Daniel King: Yes, the work started with a rather wide list.
JP Vasseur: How many service providers in the room?
(A few hands)
JP Vasseur: We need feedback for Dan [King], especially if you already have PCE deployed in your network.
Daniel King: Great to have actual deployment and consider future deployments as well.
- General comments
JP Vasseur: Some good sections. It's also good to see what the PCE should not be used for.
4.2. PCEP Extension for Enhanced Errors and Notifications
Presenter: Pierre Peloso
- Notification Use-Case [Slide 4]
A dangerous comment. Mentioning that this situation [use case] will happen
means we [PCE WG] are doing a bad job.
Pierre Peloso: We are addressing potential issues, including problems that may arise from scenarios that Dan [Daniel King] mentioned in his earlier presentation [PCE Applicability to Inter-Area and -AS MPLS and GMPLS TE].
- PCEP Behavior [slide 6]
JP Vasseur: The first time I read this draft I was a little confused by the motivation. You are doing this for very good reasons, but it may not be just for different vendors.
- PCEP Behavior [slide 7]
Do you foresee any change in the error system (second bullet). Julien Meuric
[chair hat off]: The idea is not change any procedures; it proposes
messages that will help troubleshoot behavior. We do not want to modify
previous or future behavior.
JP Vasseur: When I read the document it reads useful. The question "what to do when I receive this" could be explained in the document with examples.
Pierre Peloso: Do we specify how to handle messages?
JP Vasseur: An example, the reason PCE monitoring took so long to complete is we had a similar problem. We had an overload bit, the IESG asked "what do you do if I receive this bit set?" That's why I am saying we do not change the signaling but we may change the behavior. It would be useful to explain this instead of a narrow point.
Julien Meuric: Yes.
- Next Steps
Who read this draft?
(At least Pierre Peloso and the remaining authors)
JP Vasseur: Ok, let’s try to get more feedback and interest in the list.
4.3. PCE for Shortest Constrained P2MP Inter-Domain
Presenter: Quintin Zhao
- Quintin Zhao replaced Zafar Ali as the presenter.
There are still multiple solutions in the document: why?
Quintin Zhao: Depending on the size of the networks, there may be better choice of the overall solution. For scalability then core tree is better. When you build the core tree, you are using the extended BRPC procedure of the draft.
JP Vasseur: I recommend that we take two mechanisms and have an objective to merge them into just one. Use the list to discuss the requirements and proposed mechanisms and decide how to move forward. Fast-reroute is a good example of having multiple mechanisms and not trying to merge into a single solution. However, if it turns out those two mechanisms are necessary for different deployment scenarios, that might be fine. It must be very clear when you use one mechanism versus the other and how they can be combined. Is that clear?
Quintin Zhao: Yes. That makes sense. We can provide text that might detail when each mechanism should be used.
JP Vasseur: That’s fine but make sure the WG agrees.
- P2MP-BRPC using Incremental In-progress Tree Example [slide 5]
If you merge these two paths until the paths have multiple constraints, some
paths cannot pass thru certain nodes. See B17 to B27. If you have one path you
may just have enough BW, if you merge two paths to the same link you may not
have enough BW.
Quintin Zhao: So some links may have BW that supports single paths but when you merge paths you may not have enough BW?
Wenhu Lu: You need to consider the bottle neck. It could be anywhere along the path.
JP Vasseur: By trying to make the solution incremental you may not find the solution. It may not be able to have a new leaf, when you recompute. Even if you could recompute, it may be less optimal.
Wenhu Lu: My point is if you let CSPF compute the path itself it may merge the paths anyway.
JP Vasseur: Actually that's why I mentioned that incremental may not be optimal. Secondly if you add a new leaf, it may be less optimal.
Quintin Zhao: This is a good point, we should discuss this more offline.
5.1. Explicit Control of Region Boundary in Inter-layer Architecture
Presenter: Xihua Fu
I have seen mails to CCAMP on this and I have not seen any responses. It's not
a common assumption regarding this use case. You need to bring more material to
convince people about the problem. Usually the router has this information.
Xihua Fu: The PCE can determine the region boundaries.
Julien Meuric: Does it really address the actual problem, if there is a problem. The issue needs to be better defined and how often we face it. No point to extend for a single case. Considering the lack of feedback [including CCAMP] you need to elaborate a bit more.
Xihua Fu: We wanted to put this work into PCE first and then start work in CCAMP.
Julien Meuric: We also do not want PCEP to put constraints on RSVP signaling. If the signaling is not worked on or ready we do not want to work on extensions in PCE WG. This is similar to our comments to Young [Lee] earlier (regarding PCEP Extension for WSON Signal Compatibility Constraints).
Xihua Fu: For clarification, we do not want to solve the problem. We want to make the inter-layer interaction more convenient.
JP Vasseur: We need to be careful regarding the architecture. The PCE is there to compute paths; it could be used for other means. You can always extend the protocol but it has to be specific. This work is a little bit of a stretch.
5.2. PCE Extensions for a BGP/MPLS IP-VPN
Presenter: Chikara Sasaki
Vasseur: Did you present the RSVP
extensions required in CCAMP already? To setup multiple tunnels between PEs to
different CEs requires changes to RSVP signaling.
Chikara Sasaki: No [not at IETF 77].
Daniel King: With my l3vpn secretary hat on. A proposal was presented at this IETF that discusses the extensions needed that would to identify the VPNs that are to be connected. This work was originally presented in ccamp [IETF 76].
JP Vasseur: Do you agree that unless you can setup the tunnel there is no point in sending the request to a PCE? What about fast-reroute, did you consider the impact of CE to CE protection? Have you thought about this yet?
Chikara Sasaki: No, not yet.
JP Vasseur: I will write this down and send it to you.