Draft PCE Working Minutes - IETF-67 - San Diego Thanks to Alia and Adrian for the notes. 1) Agenda/admin (Chairs - 5mn) 2) Working Group progress (Chairs - 10mn) * Three new RFCs published: RFC4655, RFC4657 and RFC 4674 * Close to LC: - draft-ietf-pce-pcecp-interarea-reqs-03.txt (JL: only minor editorial updates, lots of comments from Adrian, plan v04 next week then ready for last call) - draft-ietf-pce-brpc-01.txt (few remaining items including manageability section). - draft-ietf-pce-disco-proto-igp-02.txt has been split: draft-ietf-pce-disco-proto-isis and draft-ietf-pce-disco-proto-ospf * JP: PCEP is now fairly stable. No intent to go to LC before implementations/interop reports. Idea is to work on additional work in separate drafts if necessary. Looking for someone to work on the PCEP MIB. (see slides for more details) 3) Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) - draft-ietf-pce-interas-pcecp-reqs-01.txt (Raymond - 5mn) Raymond: lot of changes have gone into the draft. Received a lot of comments, did some clarifications to make much clearer, updated refs and reposted as 01. Probably do one more revision if there are comments on the list and then the draft will be ready for last call. 4) Update on Inter-Layer Traffic Engineering (Eiji Oki - 5mn) [25] - drat-ietf-pce-inter-layer-frwk-01.txt - draft-ietf-pce-inter-layer-req-02.txt Dimitri: There were 2 requirements of 7. One of the requirements was a communication between the PCE and the VNT Manager. How are you going to model that communication in the requirements? Eiji: In the framework draft, focus on the PCE ... After the VNT manager is completed, we will focus on the communication between them. Dimitri: If you look at the diagram the interface number 2 is not covered by the PCEP protocol - hence how the chain of exchanges could be provided? Jean-Louis: In this draft, we just identify the interface where the VNT is a client of the PCE manger. Dimitri: understood - but the discussion slides say VNT outside the scope of requirements document hence where is this interface going to be addressed? And how? 5) Update on Path Computation Element (PCE) Communication Protocol (PCEP) draft-ietf-pce-pcep-03.txt (JP - 5mn) JP: The PCEP protocol base is now fairly stable. There a very few requirements listed in RFC4657 hat are not yet addressed. Protocol Recovery requirement is pretty vague. Jean-Louis (JL): It would be good to minimize the computation extensions but it's a pretty vague requirements. JP: is it acceptable to just forget about a request after a failure or do we need to resynchronize the states with the client? It's pretty important because it adds a lot to the protocol if you want to resync. Dimitri: My interpretation is that such need should be based on the operational requirements. In particular, what is the cost/gain ratio to ensure session permanence in case of transport connection failure? JP: will send an email to the list about this. Adrian: If everything said to do it, would you plan to include this in the PCEP draft? JP: Yes, I think it should be in the main draft. I will take the action item to send an email to the list. JP: We need someone to work on the MIB. Now is a good time to look at the draft & the sooner the better to get comments. Adrian: I've spoken with IANA about creating registry. They don't want to do that until the first protocol goes through. We'll set up a temporary webpage with assignments so we don't have collisions. 6) A set of monitoring tools for Path Computation Element based Architecture draft-vasseur-pce-monitoring-01.txt (JP - 10mn) JP: We've already had a few comments on the list. Once we have the architecture fleshed out, we can add more objects. Dimitri: Question concerning diagnostic or management. You want to have diagnostic with messages to follow rather than real-time or near-real time monitoring the statistics. JP: The objective here is to offer both a diagnostic and a performance monitoring tool. Dimitri: It's similar to diagnostic message per RFC 2735. It's more diagnostic than monitoring. What are you implying by monitoring the path computation? JP: You can use it for troubleshooting and for diagnostics. If you have a problem where computation times are too long, you can use the tool to identify the bottleneck in the path computation chain. Dimitri: You can monitor and send messages periodically to check liveness of the path between PCEs (towards the destination) but this should be used for diagnostic purposes not monitoring. Obtaining such monitoring information is going to increase load and decrease the true performance without providing usable information (hence, the cure would be worst than the disease) JP: Even for performance monitoring this could be implemented w/o risking to overload the PCE. Peng He - how long you monitor? JP: frequency depends. Look at 2nd example. You send a request and you can also choose to gather some statistics. Peng: response time may be too long to give meaningful information JP: this may be useful information. You may want to know whether the delay is due to a PCE in another domain, or the local domain, or... Once you have the info, you can figure out what is going on. Peng: purpose is to determine if path is right? JP: no, trying to find out behavior of computation (e.g. why delay) Andrew Dolganow: In 2nd case, gathering data that management can be doing at each of the nodes. What we're looking here is the local performance being added to messages. I have some serious reservations about this. Jean-Louis: I don't really agree with the previous speakers. Example 1 can be used for diagnostics or monitoring. One can monitor a service. If you check that there is a failure, you can get back the reject request & can be used as a monitoring process. Dimitri: By doing this, you care about monitoring first. If there's congestion, then the priority is sending information back? What do you want to monitor from the service? Do you want to hear it from one node or go to end-to-end? Andrew Dolganow: When you measure servicability at one point of time, it doesn't guarantee anything about next time. All you are doing is adding a message to monitor and it gives you no guarantee that the service will be available. From my perspective, easiest way is to just send the message. JP: Ok. Let's take the discussion to the list. I disagree, but we will continue on the ML. Igor: Suppose I wanted to signal with RSVP; should I send an IP ping? JP: Good analogy. What do you do when you can't reach a destination in the network? You do you use ping or traceroute. Here, you could use an equivalent "PCE-ping" and discover/check the path computation chain + optionally gather performance data. Andrew Dolganow: It's important but what it is doing as part of the signalling protocol. It's OAM. JP: Right it is. Let's cut discussion here and go to list. Dimitri: Without operational feedback on PCEP usability seems rather premature. What are the requirements? JP: If you want to deploy inter-area TE, don't you think you need some simple trouble-shooting mechanisms? Dimitri: Here, you've jumped to the solution without describing the expectations. Requirements can be incorporated within the same draft no need have a separate document Raymond: A lot of these requirements are already specified in the various requirements draft. If we need this, there are already a lot of those. I don't think it's worth doing a requirements draft on a lot of those. 7) Requirements for Manageability Sections in PCE Working Group Drafts draft-farrel-pce-manageability-requirements-00.txt (Adrian - 10mn) Lou Berger: I think this is an interesting experiment, in the context of a process experiment. I think you should recognize that it is still an experiment. I think that pushing it through as an RFC before we've even tried it once is a bit fast. I'd suggest we work on it and even Last Call it, but wait until we have some implementations of this before pushing it. Adrian: We already have some RFCs referring to this. Lou: Before the working group has even reviewed or Last Called it. Again, I think we're in the experimental stage; I think a MUST is too strong and a SHOULD be good. Adrian: I thought about this and the next line says that the section may be empty. In the cases where it isn't needed, documenting the reason would be good. Lou: As long as the "reason" can be "manageability considerations aren't considered in this document". We did this when security considerations were being introduced. Adrian: It depends on why. Simply saying "they're not addressed" means there's no point to this. Saying "the editors don't know what they are" would be fine. Lou: I guess I'm just not willing to accept it yet. JP: Any comments on this? ????: How do we manage the framework which is an existing RFC? Adrian: I can speak for the architecture. The requirements in this draft came from writing that section in the architecture, including the Ops AD reviewed the section as it went through the IESG. ????: We may have new RFCs before this draft comes through. Adrian: This isn't retroactive. ????: We may have a lot of work that may make it impossible to advance. Adrian: I'd agree & counter it that we're coming up with protocols and if we don't at least make some attempt to understand it, we could be damaging things. Dimitri: The impact of the interaction may be harder to document than the protocol itself. Adrian: yes and... Dimitri: If it is so difficult to be documented, we may start to argue the existence and the time to generate the document. Adrian: If we are doing something where the manageability of something in an environment is so complex, then we need to know that we are doing that. Are we going to impose some requirements on the network operations. JP: If I may, I think that Adrian's point is that each time we add a protocol extension, we need to understand the manageability of such protocol Dimitri: How are we going to use the info in the RFC??? Lou: I think some of what Dimitri is saying is why this is still in the experimental. We don't know if the subsections are the right list. Is this too detailed? Do we need to have a MIB defined at the same time as the protocols. I'd like to see us go through it with a protocol doc, not just an architecture. If the 3 sentences in PCEP is enough, ok, but we don't have that. Also, for some docs, we may want to address manageability across the board rather than in each doc. I'm not saying we should run away from manageability, it's important, but this is a lot to jump into. Ross: In my role as Routing AD, I'm looking forward to the big rush of PCE docs before this. Taking off my hat, I think this is a good idea but I'm not sure that the 6 sections are the right idea. Maybe it should be a SHOULD and not a MUST. I'm not sure. Loa: If you're not absolutely sure about those sections, how are you going to become sure? Lou: I'm waiting to see how the editors of the major docs in this WG do and how it goes. Seeing it for PCEP would be good. Lou: If the major working group docs are participating, then if they show that they're successful and that it's good, that's enough. Loa: I'm hearing that you're not sure about this. The way to get sure is to start experimenting. To do that, we need the document. Lou: As I said earlier, there's no reason we can't get input on it today and even last call it, but wait until we have experience. Ross: If we get a lot of experience with it and we find that, say, 5 of the sections are good & a 6th doesn't, do we update the RFC. Loa: Am I hearing Ross: As a Routing AD, I'll do what the WG wants to do. As an ordinary guy, this might mean don't submit for 6 months until have some experience or use it as guidelines. Lou; It seems that the number of "yes we're doing it" editors is giving a good critical mass. 8) Definitions of Managed Objects for Path Computation Element Discovery Protocol (PCEDP) (Emile Stefan - 10mn) [60] draft-stephan-pce-disc-mib-00.txt draft-stephan-pce-tc-mib-00.txt Adrian: I think it would be fine to limit to just these two, but as we do extensions we need to decide if we want them as extensions tables or in the tables. You may want to look at the monitoring information available from the signalling (??) Adrian: If all of the info is available, then you're done. If some of it is only through signalling... JP: Ask WG to provide some feedback on this draft. It may be worth sending email to the list about specific items so you can start a discussion. 9) Preserving Topology Confidentiality in Inter-Domain Path Computation and Signaling - draft-bradford-pce-path-key-01.txt (Adrian Farrel - 5mn) What I'd like to hear is some discussion from the list - in particular from anybody who thinks we shouldn't be taking this on. JP: Does a straw-poll of who has read the list? (A few hands) Jean-Louis: It would be good to ... Is it (case A) or (case B)? Adrian: Yes, the latter. JP: We should go back to the requirements and explain why. 10) Locate ASBR in PCE draft-zhang-pce-locate-asbr-00.txt - (Mach Chen - 10mn) [75] ?: What about other routers, not PCE? Mach: It may be other routers. ?: Have you considered the route reflector for iBGP? There is a backward compatibility. What's the impact on others? On route reflector peers? JP: That's a key question. Would you be willing to post on the mailing list and start a discussion? 11) Path Computation Element Communication Protocol (PCECP) Requirements for Support of Global Concurrent Optimization - draft-lee-pce-global-concurrent-optimization-00.txt (Young Lee - 10mn) [85] Jerry Ash: It seems to me that all the requirements are already covered and we don't really need another requirements draft. It seems what you're looking for is enhancements to PCEP. Global architecture is already in the architecture. JP: Could you take a look at the RFC and see what's missing? Young: Right, the global optimization isn't specified in detail. Jean-Louis: I agree with Jerry. There is some overlap with the generic requirements RFC. You should align with the terminology also. JP: Take to the list & discuss what is missing from the requirements and look at what is already in PCEP. 12) BGP Protocol extensions for PCE Discovery across Autonomous systems draft-vijay-somen-pce-disco-proto-bgp-02.txt - (Prasanna Kumar - 10mn) Not presented/discussed. 13) Path Computation Policy Information Model (PCPIM) draft-bryskin-pce-pcpim-00.txt - (Igor/Lou - 10mn) JP: No time for questions - please bring to list. 14) PCC-PCE Communication Requirements for VPNs draft- yasukawa-pce-vpn-req-01.txt - (Seisho - 5mn) [110] 15) PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) draft-yasukawa-pce-p2mp-req-01.txt - (Seisho - 5mn) [115] Adrian gave a brief overview of these drafts - Discussion on the list welcome - No time for questions. 16) Dynamic Placement of Pseudowires using a Path Computation Element draft-martini-pwe3-ms-pw-pce-00.txt (Luca Martini - 5mn) [120] JL: Do you plan to address the inter-AS case? In this case, do you think you could reuse the BRPC path computation procedures. Luca: I think so. The main difference is that we are using a layer 2 addressing scheme that is unique across all domains. The other question and that I'd still like input from people, in this example, this network will be very dumb and won't even talk to the PCE; it's not meant to be the only one. JP: If you're interested in this, please go to the PWE3 working group. Adrian and I will be discussing it with the PWE3 chairs.