Seventieth IETF, Vancouver, December 2007 Tuesday, December 4, 2007 0900-1130 Morning Session I RTG ccamp Common Control and Measurement Plane WG CCAMP Working Group Minutes, Session 1 of 2 ============================================ Chairs: Adrian Farrel Deborah Brungard Note takers: Dimitri Papadimitriou, Martin Vigoureux ================================================ 0. Administrivia (chairs, 5, 5/150) Asked for comments on the agenda. No comments. =========================================================== ================================================ 1. WG status, RFCs, drafts, milestones, charter (chairs, 10, 15/150) 4 new RFCs. 4 in Editors Queue, 5 in AD/IESG review. Charter has been updated. For the GELS work, milestones on web page not updated yet. Loa: Apologize for not sending the updated MPLS and GMPLS security framework draft to ccamp list. Comments should go to the MPLS list. ================================================ ================================================ 2. RSVP Proxy use of GMPLS messages (Francois 10, 25/150) Soon ready for last call. Comments should be posted to the tsvwg list. Lou: Downstream notify sent to an upstream node? Francois: Correct. The sender would have to be ready to receive a downstream notify message (resulting from a Resv error not a Path error, sent upstream). Lou: do you state it clearly? do you mention backward compatibility issues? Francois: No but could be a good thing to add. Lou: Indeed. Igor: what happens if Notify is lost? Francois: expect sender to be able to lose the different notifications. We do not discuss this particularly. Should we discuss? Igor: patherr more reliable (hop-by-hop). Notify may get lost (IP datagram directly sent to sender). Prefer patherr as it may also be used to remove the state. Francois: Indeed pros and cons using Notify/PathErr. PathErr is default mandatory approach. Dimitri: do you plan to discuss Notification Ack for reliability? Francois: No I do not plan to. Dimitri: do you mandate not using Ack? Francois: Believe no specific need to re-discuss all points in this document? Dimitri: Notify message sent only for CAC rejection or also other errors? Francois: Here same guiding principles apply. So one says it wants notification, it will get notification. ================================================ ================================================ 3. Issues and developments for distribution of TE information from outside ASs a. Introduction and Scope (Adrian 10, 35/150) Adrian: we will have only clarification questions during the drafts presentations, discussion at the end of the presentations. b. Requirements for GMPLS Inter-Domain Routing (Tomohiro 10, 45/150) Dimitri: What do you mean by statistical configuration? Tomohiro: Sorry, typo read instead static configuration. Dimitri: What partitions do you consider? Multiple or single SCs? Tomohiro: We suppose here we have one SC only. Dimitri: Need to be clear about horizontal and vertical partitioning? Adrian: Good point. We did not think about that. Igor: As in the case of hierarchical routing, separate routing process for TE vs. IP routing. IP routing separated from inter-AS TE using separate processes by having visibility of full areas and advertised views of the contained areas. Kireeti: Not a good idea to separate both due to the structure enforced by the IGP areas -> TE areas not the other way around. Doing the other way around would result in scalability issues since TE routing instance requires IP routing. Dimitri: Need to rescope discussion. The situation here is different from ASON hierarchical routing. Here, IP routing domain partitioning not other kind of partitioning. Adrian: IGP areas and ASs only. So other subdivisions are not in scope. The domain here is an AS not a "TE domain". c. Inter-AS TE Links (Mach 10, 55/150) No clarification question. Adrian: ISIS document status will be on hold- until agreement is reached on how to progress on this topic. d. Requirements for end-to-end RSVP-TE over a BGP/MPLS IP-VPN (Kenji 5, 60/150 No clarification question. Adrian: This is a L3VPN document but it also shows scenarios and examples of interest for CCAMP. e. Advertising CE-PE TE Links in BGP (JP 10, 70/150) JP: Mention the use of PCE for this purpose. Here, we try to achieve CE-PE TE information so that PCE can compute the path in one shot (not per segment). François: Do these procedures work in both cases? Aggregation or 1:1 mapping? JP: 1:1 mapping only. f. BGP Traffic Engineering Attribute (Yakov, Don, Hamid 10, 80/150) Igor: Any specific concern wrt BGP? Yakov: No. I have no concerns wrt BGP. But BGP in contrast to OSPF/ISIS, has no notion of multiple instances so your question is irrelevant in the context of BGP. Don O'Connor: L1VPN (PE) devices do not run BGP. Yakov: Time will tell. JP: - Question to Adrian on the need for CE-PE TE. - Only disagreement remaining is the need to compute a path between CE-CE. - Why not having an empty field/container in which we will put TE information. - Addressing Yakov: Suppose your document is the base. How do you handle the need for new attributes? Yakov: two options here. Either adopt as generic BGP-TE or focus on L1VPN discovery for CE-PE link only. JP: Would you change / adapt format to carry all IGP information? Yakov: When there is WG consensus. JP: Then, we are in agreement. We made progress, no? Yakov: No, we did not make progress. JP: If you agree to extend the proposed format to carry IGP TLVs. I am fine. Yakov: If there is consensus, I am fine too. Dimitri: What about Inter-AS links? Yakov: The problem is limited to the CE-PE links only, in the present context. Adrian: You said the document would be also useful for multi-AS L1VPN. So, would you be ready to scope the document to CE-PE links only. My understanding is no? Yakov: Please see presented slides. Dimitri: How does Adrians discussion slides and related concerns fit then in with the present discussion? Adrian: How do we handle the VPN problem? Dimitri: The flooding problems and concerns, the slides presented do not discuss, because we are making a specific decision for L1VPN. Adrian: Some guidance needed on what should/could be done would be useful. Yakov: If someone wants to propose some text, I am fine. Kireeti: Going back to attribute. Why not take the whole opaque LSA, take all the fields? If we extend OSPF-TE will you automatically replicate all the information? Yakov: It depends on the application. But as said to JP, it is OK for including top-level TLV information. Adrian: Would it be applicable to L3VPN? Yakov: Slides are clear about this point. Adrian: I have an action to find a proper home for this document. Yakov: You had to do this since last summer. Adrian: But you made good progress by writing that bullet on that slide so I can now do my work. Yakov: By when? Adrian: No specific date. Yakov: I think ADs have to look at this. Kireeti: Pointing to the Adrian's slides. Why AS only and not Area? Adrian: Write / propose text. Kireeti: May be different proposal for different domains. Adrian:? JP: Thanks for the slides to show how scary this could be. Adrian: We need some scoping typically if info comes from BGP and describe what to do with it. We can't let people break their network because this also impacts others. Some text is needed on usage and practice. This is usual scoping. Jean-Louis: On the proposal slide, concerning Area/AS TE flooding, I would advise restrict TE link flooding to single area. Adrian: This is why we need to understand what is dangerous and what is not. Dimitri: The point of being dangerous or not is not engineering sound. What is the dynamic of distributing internally the externally learnt information? Is intermediate aggregation on ABR permitted (that would result in making use of per-area flooding)? Would like to see further analysis when discussing flooding of external TE information such as to prevent any scaling and convergence/stability issue. Dave: Adrian can you list steps planned? Adrian: - Step 1: sit down, get my head together, and see what are the steps, will cover: application & guidelines - Step 2: freeing up process for drafts to get moving Dave: - Ok, those steps are separable. - On application & guidelines, we have experience in that, can follow similar steps as in past. - On drafts progress: need home for Yakov's draft. If discussions needed on process, please contact your ADs. g. Discussion (10, 90/150) (Refer to above) ================================================ ================================================ 4. Ethernet a. Reminder of our targets and approach (Deborah 5, 95/150) b. Service Provider Requirements for Ethernet control with GMPLS (Wataru 10, 105/150) Nurit: hybrid operation with bridge network / GMPLS? Wataru: yes, but there are different requirements for service providers. Nurit: requirements should be Ethernet wide -- not .1Qay only. Adrian: you are spot on. c. GMPLS Ethernet Label Switching Architecture and Framework (Don 10, 115/150) d. GMPLS control of Ethernet PBB-TE (Don 10, 125/150) (on c+d) Don: - Ask to make the framework + architecture document as WG I-D? - Ask to make PBB-TE document as WG I-D? - Ask for comments. Ali Sajassi: - There are nits in the document (in part. I-BEB vs. B-BEB components not as presented in this document) - Would like advantages of GMPLS to be reinserted in requirements doc., not as per this new version. Don: these advantages were considered in the DT. Ali: Ok but this discussion should be included. Loa: Said you want support of multiple Ethernet LSPs between two endpoints? Ali: Yes Lou: Why separation between framework and architecture document? Don:? (No time for additional discussion) e. MEF Ethernet Traffic Parameters (Dimitri 5, 130/150) Dimitri: Document status from informational to standards track. Change title from MEF to Ethernet traffic parameters. Don: In DT thought of using MEF traffic parameters. Dimitri: Ok, the title move fits. Also better to provide an answer more centered on our architecture needs than application specific needs. f. GMPLS For MEF and G.8011 Ethernet Services (Lou 10, 140/150) Lou: This version has identified and resolved open issues. Solicit feedback from MEF/OIF: Do we need a liaison? Adrian: Will clarify. Dimitri: - About document split. We should not divide our efforts by having as many documents/specifications per liaisons/requests (MEF, OIF, etc.). - Should keep network and service protocol architecture independent. - Have a protocol/architecture sound way to move forward. Such approach is also inline with RFC 3945 and parallel protocol work (RFC3471, etc.). Otherwise we are hurting ourselves. (No time to ask other questions) g. GMPLS Asymmetric Bandwidth Bidirectional LSPs (Lou 10, 150/150) (No time for discussion) ************************************************ ************************************************ Thursday, December 6, 2007 1300-1500 Afternoon Session I RTG ccamp Common Control and Measurement Plane WG CCAMP Working Group Agenda Session II Note taker: Dan King ===================================== ================================================ 5. Administrivia (chairs, 5, 5/120) ================================================ ================================================ 6. ITU-T and OIF progress report (Lyndon, 10, 15/120) Comments: Lou: It would be good to hear if there is any disconnect on ethernet services. Specifically on what we are working on and UNI. Lyndon: There is no disconnect at this time. Lou: Please give us advance notice. Lyndon: Will do, intention is to align with CCAMP work. ================================================ ================================================ 7. ARP For GMPLS controlled PSC Ethernet Interfaces (Zafar 5, 20/120) No questions or comments. ================================================ ================================================ 8. GMPLS OAM a. OAM Requirements for GMPLS Networks (Tomohiro 5, 25/120) Adrian: There is no way that we are not going to liaise with the appropriate OAM and data plane authorities. We still need to get a grip on requirements. We probably need another revision. My question is which bits of the ITU that we should be liaising with? Eve V: Indeed its a good idea to share it. In reviewing G.7718, it would be useful to liaise with q14. Some of the requirements are already there. There are some protocol neutral requirements, start with SG15. Don oConnor: MIB work is Study Group 4, it has network management responsibility. Eve V: I think that more specific control plane work is supported by the TMF work, they have gone into a detailed solutions space. Don: Anything to do with data plane management is Study Group 15, their next meeting is in Feb. Tomohiro: I am participating at the TMF. b. Ping and Traceroute for GMPLS LSPs in Non-Packet Switched Networks (Zafar 10, 35/120) Don: IETF cannot be producing data plane solutions for some vendors’ non standard optical data plane / cross connect without OAM. We are not in a position to produce OAM solutions. Take it to the ITU. Zafar: The scope of this is where no OAM exists. Don: If Cisco does not want to support G.709 than tough. We should not be developing propriety OAM solutions for a specific vendor. Take it to the ITU. Zafar: Well this is the same as LMP. Don: Take it study group 15. Zafar: Are we liaising this? Adrian: We are not liaising with the ITU on this. Don: Take it to the ITU Igor: If you do not use LMP, is this only for PSC network? Zafar: Only for PSC. Igor: What other technologies is this relevant for? Zafar: This is PSC. Igor: Can we use this anywhere else? Zafar: Can not find the fault for GMPLS LSP, LSP Ping is not sufficient. Igor: I am trying to understand how useful this is. This not useful for Ethernet. I do not see any other PSC layer that will benefit. Igor: I do not see how you can detect a failure. Adrian: Igor, please restate your question on the list and Zafar can answer on list. Eve V.: I am trying to understand the problem statement. Is this a photonic cross-connect not supporting a standard OAM? Zafar: No OAM solution is supported. Eve V.: Is this targeted for non-standard OAM optical solutions? Which data plane technologies? Zafar: This is pre-OTN. Eve V.: I think you need to be more specific. ?: You are tracing through the control plane? Why not just send a unicast packet? Zafar: You are right, you can just send it directly to the node. It would change the mandate. We are discussing what the right thing to do is. Lou: Interesting to hear why its not supported. Adrian: Lets move on. c. GMPLS RSVP-TE Ethernet OAM Extensions (Attila 10, 45/120) Adrian: What we have seen on the mailing list is fairly good support. ?: If we can generalize then that’s good. Igor: I think its a useful draft. I see a couple of issues; one apparent miss is there is no way to signal the source MAC address to the egress. The egress must be prepared to get OAM messages. Attila: We assume that this information can be derived. We are considering some additional requirements to meet this objective. Igor: This looks like end-to-end signaling. Generally we do not like hop-by-hop, it creates extra state on transit nodes. Another issue is if something is broken in the middle, and there is no end-to-end signal, it could cause problems. Suggest you consider this. Deborah: Suggest continuing WG discussions on the mailing list. ================================================ ================================================ 9. VCAT/LCAS (Greg 10, 55/120) No discussion. ================================================ ================================================ 10. Wavelength Switching a. Framework (Greg 10, 65/120) Adrian: Who thinks that the WSON is relevant to us? Not a unanimous show of hands, but still a good show of hands. We will go to list to see if this is the right draft for the framework. b. Lambda labels (Tomohiro 5, 70/120) Igor: What is the advantage of this format? What if I were to just specify frequency? Tomohiro: G.694.1 defines. Igor: What if my wavelength does not fit frequency? Adrian: If you are not using standard grids, then you are not going to interoperate. Igor: If I use both, different grids (say experimental)? Adrian: Nothing prevents you. Igor: What is the advantage? Greg: Understanding the channel spacing. We have label sets not label ranges, to be able to specify the grid allows you to specify label range. Since they have global significance, it lets you specify common industry standard frequency specifications. There are questions about systems that can handle two grid spacing’s; this can handle by this. Igor: There are issues with advertisements. You specify grid with bits, I do not see difference. ?: If you have some equipment that can support 50 / 100 grids, is there an expectation that all devices support all grids? Tomohiro: No. Only what it can support. ?: what are the implications of specifying a label range. Adrian: Are you asking control plane questions? You can represent 50/100 lambdas as the same. Lou: 694 label format. This is the way it is. ?: Looks like the base requirement is interoperability at control plane. Do operators transparently interconnect optical vendors? Tomohiro: This is for multi-vendor environments. Sometimes we use OEO for different vendors. Greg: Additional Interop uses, potential innovation comes from using this for PCE type applications. c. Signaling Extensions for Wavelength Switched Optical Networks (Greg 10, 80/120) Lou: Is this a replacement for communicating traffic parameters in the session? Greg: I am still counting on getting the bit rate. Lou: it belongs in the T-Spec. Greg: You got it. Lou: this is an optimization? Greg: I want one more flavor of label set. Lou: Otani set, your not happy with it because of the bytes on the wire? What is the real optimization? (in order to understand the benefit) This should be discussed. Greg: We can discuss this on the list. Lou: we have had lots of cases where path selection could be next hop or other. We never specified before what algorithms we should be using. Why do we need a mode change? Greg:(?) Lou: Is this technology really different from packet etc for path computation. Greg: If it does not fit, we can take this out. Lou: we have not historically standardized algorithms. Like CSPF. Greg: PCE has knobs we can tweak. Lou: its not clear to me we need this. Adrian: you need to be careful to get back to deployment requirements. Greg: some things are general, some are future based. d. GMPLS Signaling Extensions for Optical Impairment Aware Lightpath Setup (Giovanni 10, 90/120) Don: these parameters are in the signaling protocol. How are they used? They could be included on the node. Don: The nodes measure the parameters. They encapsulate them - for what purpose? Giovanni: You can see if the LSP fails due to say optical power. Don: Need to have practical implementation document. This needs to go Study Group 15 question 6. They have been studying this for years. Need motivation document and send this to ITU, and formalize on the optical side. Should this be carried in signaling or routing? Adrian: this should point to ITU standards. e. Bidirectional Symmetrical Lightpath Signaling (Sugang 10, 100/120) f. Routing Wavelength Switched Optical Networks (Greg 5, 105/120) g. Evaluation of Possible IGP Extensions for WSON (Dan 5, 110/120) ================================================ ================================================ 11. Performance Metrics (Weiqiang Sun 10, 120/120) ================================================ (No time)