PCE WG Meeting Minutes - IETF-72 - August 2008 - Dublin Many Thanks to Dan King for the minutes. Administrivia (Chairs) No requested agenda changes WG Update notable points: - P2MP added to charter. - MIB added. - BRPC in RFC editor queue, we need to close of the remaining DISCUSS on PCEP, will try before end of August. - Policy Enabled Framework Draft (Lou, internally all addressed except one comment. o Dimitri: One item outstanding, objective next draft at end of August. o Adrian: We would be willing to take on task. o Draft received IESG review. One piece of work outstanding from Igor. - Inter-AS Req, done with IESG in last call (informational). AD decided last call is appropriate. - XRO Draft, two DISCUSS. One fixed, second looked at next week by Dave Ward. - MIB module documents progressing (Discovery & Textual) Kirin out of time, need volunteers for PCEP MIB. - DSTE Status, authors will update and prepare for last call. - PCE Mon tool. Stable, ready for LC. Inter-layer Framework and Requirements JP: Ready for review, will try to review in Aug-Sept. JP: Not much traffic regarding the draft, please read and comment. Inter-layer PCEP extensions JP: If you any plan to implement inter-layer please let us know in order to progress the document. PCE application to GMPLS Unknown Person (ZTE): What switch types: mac in mac, pbt, et al.? TOMOHIRO OTANI: Initial motivation is TDM GREG BERSNSTEIN: Procedurally, will bring in other switching types into one document or create separate documents. TOMOHIRO OTANI: General description, limiting to TDM. ADRIAN FARREL: Supporting GMPLS is clearly within charter. Concerning number of drafts, the CCAMP model is one main document, branch out little documents for extensions to support specific technologies. P2MP PCEP Applicability Requirements JP: You may want to work on BRPC for P2MP. We have been waiting on P2MP. JP: For, vast majority. We will take this to the list. JP: Need to figure out dynamic discovery. ADRIAN FARREL: That’s true, one of the requirements expressed is the ability to know what the PCEs out there can do. We did make a commitment not to put extra data into existing OSPF LSAs. If we need more discovery work, we will need to create a new LSA then migrate discovery work. The alternative is to just discovery and use PCEP for capabilities exchange. JP: This document will evolve with solution draft. JP: Poll. Again, vast majority are for. No one opposed. Pretty clear, we will take this to the WG list. P2MP PCEP extensions JP: (Slide 9) Depending on objective function, then this (slide 9) will require further discussion (maybe additional functions). JP will send some comments to the list. JP: (Slide 17) Did you discuss the example where you add a new leaf, and you can no longer satisfy all the constraint for all leaves, thus leading to a trade-off between adding a new leaf and somehow relaxing some of the constraints or not add the leaf ? Adrian, do you also see this as an added requirement? ADRIAN FARREL: Nods. JP: (JP Poll’s room), approx 15 vote for the work. Opposed, nobody. We will take this to the list. Poll list ask for more comments. By the way happy to see that you are filling up the flags. We had a comment during reviews on why did we have so many flag fields for PCEP. Global Concurrent Optimization JP: Co-chair review, that’s me right? I’ll do this. ADRIAN FARREL: During P2MP we were discussing issues of trade-off, what happens if you want to add leaf and degrade existing leafs. This is applicable to GCO. Expressed trade-offs. SVEC List For Synchronized Dependent Computations JP: (JP polls room), a few are in favour, who is opposed? No one opposed, we will take this to the WG. Please look at this document. It is informational. Performance Evaluation of PCE for WSON GREG BERSNSTEIN: (Slide 1) Work is minus impairments and no wavelength conversation. JP: (Slide 8) Are you planning to run the simulations on larger or different topologies? The study could be topology dependent. The group in Pisa are willing to modify study and include a variety of topologies; this is one they were doing. JP: Poll mailing list and ask for topology suggestions. LOU BERGER: This is clearly interesting work, what’s the reason for this draft? GREG BERSNSTEIN: (Slide 9) PCEP extensions should not include this architectural alternative LOU BERGER: No intent to bring this document as a WG draft. IGOR BRYSKIN: Slide 4: all this vertexes are they constrained? Any lambda can go on any interface. I am questioning the relevance of this experiment to the WG. A more useful topology would be 10 to 15 interconnected rings. IGOR BRYSKIN: Also would question the relevant of this work. ADRIAN FARREL: If you think that this topology is not representative and you think it would be useful to have other topologies, please draw them and submit them to Greg. LOU BERGER: Please distribute the paper. YOUNG LEE: This work is a response to Igor’s comment at the last WG. IGOR BRYSKIN: This presentation does not answer my question. YOUNG LEE: This is motivated by having a legacy PCE and using RWA in another PCE. LOU BERGER: We are not a conference but we are standards organizations. What we should be doing is figuring out what models of PCE do we support. ADRIAN FARREL: We are at a pretty early stage of this RWA work, ultimately CCAMP will be leading, PCE will be one application... I see this work as seeding the discussion. It’s very easy to evaluate other topologies. YOUNG LEE: We do not want to preclude anything. PCEP Requirements and Extensions for WSON ADRIAN FARREL: There are a couple of synchronization issues with CCAMP. The first is this is addressing requirements coming out of CCAMP. This cannot get ahead of CCAMP. Also need to focus the scope of the RWA work, not put effort in optical impairments for some time, also based on CCAMP. IGOR BRYSKIN: When we talking about PC we assume that someone prepare TED. JP says we make no assumptions. If you consider optical environments where you need this information faster than IP environments. I am interested to know how we are building the TEDs. If someone comes up with a draft (informational) proposing a different way of created TEDs, ADRIAN FARREL: CCAMP has started work on information model (what info do you need for PC). How do you get that information from the network to the PCE. If you propose IGP, then this is CCAMP. If you propose LDAP, then we need to consider if this for LDAP WG or maybe DB schema then maybe it stays here. We may need to include this in the charter. Maybe we need an informational ID, its within the interest of the WG. IGOR BRYSKIN: How do you know if its possible to build DB in real-time YOUNG LEE: It’s possible. We can do this. Dan’s draft in CCAMP discusses this. JP: Igor, it’s always possible to build the database differently. IGOR BRYSKIN: For instance the IGP does not build it fast enough for wavelength PC. In IP you have evaluation of BW consumption is much easier. JP: Are you sure about this? IGOR BRYSKIN: If you setup IGP tunnel and tear down, you can almost immediately create it again. In optical world once you setup tunnel and teardown you cannot setup again immediately. The responsiveness is not fast enough. JP: Need to document why this cannot be done. ADRIAN FARREL: CCAMP Dan Li draft looks at evaluating the practicality of using IGP for RWA. IGOR BRYSKIN: How is this work related or gated by Otani-san to generic PCE. ADRIAN FARREL: in order to make a specific request for an RWA path you have to .. My feeling is that this might be gated by the GMPLS but it is ahead. IGOR BRYSKIN: I would be concerned that we progress this, but not ... ADRIAN FARREL: We move GMPLS that might include some technology pieces. IGOR BRYSKIN: Is there a resolution to bring it in. ADRIAN FARREL: Yes. Vendor Constraints ADRIAN FARREL: Do PCE implementer’s think this is useful? IGOR BRYSKIN: There is vendor specific constraint, IANA would register and manage. How about objects? ADRIAN FARREL: The objects and TLVs are managed by the vendor. IGOR BRYSKIN: If it’s not standardised objects? ADRIAN FARREL: this is intended to allow vendors to have their own objects or private. As a PCE vendor you could create and publish and hope others pick this up. At some point you may want to bring this into IETF as standard object. IGOR BRYSKIN: Do you think there is misinterpretation? SNIGDHO BARDALA: I want to understand scope of idea. Is the idea that we have single vendor network and it works with another vendor PCE. ADRIAN FARREL: I started with single vendor environment with PCC and PCE are same vendor, most protocol standard. You may introduce another PCE into environment. SNIGDHO BARDALA: Multiple dataplane vendors interoperating with single PCE ADRIAN FARREL: Yes, one PCE rained to understand differences. ERIC GRAY: If you allow a vendor to define, publish and standardise. Why would they do that. ADRIAN FARREL: IETF standardisation. IGOR BRYSKIN: This draft would be useful for PCE architecture. Some TLV standardised but other private. (Unknown speaker): This is a good idea as it should stop vendors putting extensions in the protocol instead. This creates open space for vendors to put in their own implementations. This improves protocol designs. ADRIAN FARREL: Keep polishing, keep alive. JP: Vendors and users welcome to comment. Applicability of PCE to VPNs JP: Good follow-up action to take to those three WGs. ADRIAN FARREL: Alright. JP: Considering the size of L3 VPNS there are consequences on size and scalability. ADRIAN FARREL: Yes I have considered this. You could operate multiple PCEs, one PCE to service all VPNs. JP: Also dependent on number of LSPs ADRIAN FARREL: Standard problem anyway. PCEP Extensions for L3VPNs JP: Are you planning to have an accompanying document in CCAMP, mapping between IPV4 & iPV6, FRR extensions as well. KENJI KUMAKI: Currently we have not. Unknown Person (ZTE): What kind of VPN KENJI KUMAKI: L3VPN Unknown Person (ZTE): What’s difference from L1 or L2 VPN. What’s the difference. KENJI KUMAKI: We establish customer VPNs over layer L3VPN. ADRIAN FARREL: I would recommend that the others try to make the work generic, and any areas that are L3VPN state it. Any signaling requirements will require the L3VPN to acknowledge that applying PCEs to L3VPNS is a good idea. Discovering PCEs in other ASes JP: Have a look at the amount of data that you would put into the IGP... KENJI KUMAKI: BGP has the advantage JP: Yes, you limit the propagation of the PCEs. Might be good to do some maths to check... JIAN: Where do you do the work to extend the BGP protocol? ADRIAN FARREL: If you wanted to extend BGP for PCE, then you would do the work here but allow the other WG to discuss.