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 [77], 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
Julien
Meuric:
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
Julien
Meuric:
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]
JP
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
JP
Vasseur:
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
GMPLS TE
Presenter: Daniel King
JP
Vasseur:
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?
JP
Vasseur:
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]
JP
Vasseur:
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]
JP
Vasseur:
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
JP
Vasseur:
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
TE-LSPs
Presenter: Quintin Zhao
- Quintin Zhao replaced Zafar Ali as the presenter.
JP
Vasseur:
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]
Wenhu
Lu:
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
Julien
Meuric:
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
JP
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.