> CCAMP Agenda For IETF 89 > Version: Feb 21, 2014 > First Session > THURSDAY, March 6, 2014 > 0900-1130 Morning Session I > Room: Blenheim > Presentation Start Time Duration Information > 0 9:00 10 Title: Administrivia & WG Status > Draft: > Presenter: Chairs http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-0.pdf > 1 9:10 5 Title: WG Document Status > Draft: > Presenter: http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-1.pdf Lou Berger: with regard to draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp, fairly significant editorial change. Please review, and we hope to move to LC shortly. Update from authors of WG drafts not being presented, or sent to the list: Giovanni Martinelli: (draft-ietf-ccamp-lsp-attribute-ro-03), latest revision addresses Adrian comments, after IANA section will be filled in, and then we expect the document to be ready for LC. Daniele Ceccarelli: (draft-ietf-ccamp-rsvp-te-li-lb-02)- No changes done or planned. Just need to understand whether there is still interest to progress the draft or not. Authors still interested in proceeding. Lou Berger: [Poll] who read latest version? [none]. Who read any version? [Fair number]. Please review and send comments to the list. Authors please state when you think it's ready for WG LC. Zafar Ali: (draft-ietf-ccamp-te-metric-recording-03)- No major changes. Feedback from WG requested. No procedural or format changes. Lou Berger: Please review and send comments to the list. > 2 9:15 10 Title: Post LC WSON Document Changes > Draft: rwa-info, general-constraint-encode, rwa-wson-encode,gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling > Presenter: Young Lee http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-2.pdf Lou Berger: Signaling document changes came in this week, please review changes as it is the last document of the set needing to be finalized prior to submission to the IESG. > 3 9:25 5 Title: RSVP-TE Extensions for Collecting SRLG Information > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-srlg-collect-04 > Presenter: Oscar Gonzalez de Dios http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-3.pdf Lou Berger: [Poll] how many read last version [really good number].Please send pre-LC comments to the list. We'll poll before next meeting. > 4 9:30 10 Title: Next steps: RSVP-TE Path Diversity using Exclude Route > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-03 > Presenter: http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-4.pdf Lou Berger: Meeting offline on diversity took place this week. We'll hear later about the 3 drafts on diversity together. There was an offline author?s meeting earlier this week, based on that we expect the authors to work together to see if how many of the three documents can be aligned into a combined solution, or kept separate into independent solutions. In our discussion later, we need to focus on what problem needs to be solved rather than the specific solutions. > 5 9:40 10 Title: Framework and Requirements for GMPLS based control of Flexi-grid DWDM Networks > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-flexi-grid-fwk-01 > Presenter: Ramon Casellas http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-5.pdf Giovanni Martinelli: editorial comment: since the doc is informational, instead of moving away the requirements could you please move them to a different section (even an appendix)? Just to have a place where to keep them. There will be equipment that likely will perform much better than what ITU-T will standardize. Ramon Casellas: ok no problem. Huub Van Helvort: Since you mention media channels and network media channels and the relationship between them, Q11 is discussing this and is meeting in two weeks, maybe it could be better to send a liaison to ask to agree on definitions or give indications on when they will be defined. Lou Berger: Good idea. Very important to be aligned with data plane asking what will be the changes and when will the definitions be stable. Ramon Casellas: Changes will for sure heavily impact the draft. Lou Berger: We need to be aligned with data plane and not be ahead of it. Iftekar Hussain: Agree, but since requirements are not clear we should not be looking into solutions yet. Lou Berger: We're discussing solutions in the next presentations. Please remember that adoption as WG does not mean the ID is finished, it means we start significant working on the topic and there is room to make changes. The WG can only drive changes in a document once it is a WG document, not on individual ones. Deborah Brungard: Please provide text for the liaison, we will send it to Q6/Q11/Q12, particularly mention hitless. Please try to put together a proposal by early next week. > 6 9:50 8 Title: Generalized Labels for the Flexi-Grid in Lambda-Switch-Capable (LSC) Label Switching Routers > Draft: http://tools.ietf.org/html/draft-farrkingel-ccamp-flexigrid-lambda-label-08 > Presenter: Fatai Zhang http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-6.pdf (Combined with previous presentation) > 7 9:58 7 Title: RSVP-TE Signaling Extensions in support of Flexible Grid >Draft: http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-rsvp-te-ext-04 >Presenter: Fatai Zhang http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-7.pdf Iftekar Hussain: There are also other solutions especially on the label side. I think perhaps the single frequency slot is more stable but the definitions in the other areas are still being discussed in the ITU, hence it is too early to move on other solutions. Fatai Zhang: These drafts are the foundation of flexgrid and were stable through deep discussion. Moreover, the label defined in this draft follows the existing format (WSON), why not re-use the existing mechanisms? Iftekar Hussain: Fundamentally both drafts have the same information. I don?t think you can claim that one solution is simpler because both solutions address the same requirements. Some fields are different for the case of single frequency slot but the info carried is the same, we might work together on a solution. In addition the multi frequency slot case is still being discussed in ITU-T and it?s too early to be discussed here. Giovanni Martinelli: 1. It?s not clear to my why you want to keep the fate of these two drafts together (label and signaling)? 2. Usually there was the old habit of writing framework and info model before solutions to define the info to be carried around. There is no info model here, it could helpful to have this. Lou Berger: Are you willing to write it? We are contribution driven, if someone believes there is a whole in the document set, the right response is to author and contribute one. Adrian Farrel: Speaking as a draft author, as a WG do we develop protocols extensions for data planes defined/published/approved by other SDOs or trying to wait for potential data plane developments and hold the control plane till that? If the latter, how long do we wait? We might have to wait for years before publishing control plane. Lou Berger: I think this point was addressed in my response to Iftekar earlier in the meeting. Zafar Ali: In general it is better to have more agreement on requirements before solutions are adopted. Xihua Fu: We are talking about new requirements in ITU-T. I don't think these requirements will be stable this year. I suggest monitoring changes. Lou Berger: [poll] who thinks that both documents are a good foundation to start a work on this activity [a reasonable number] ? Who thinks BOTH are not a good foundation? [a few hands]. To me, this is a good indication of consensus to use these documents as foundation, it means a starting point that can be changed later by the WG. Igor Bryskin: I don't understand why we need to bind the two drafts together. The label format is the simplest possible, we don't need different solutions for label format. We might have different procedural options, but a single label format. I would have preferred to have them polled separately as I think the label format can be adopted as it is. Lou Berger: If there was no clear consensus in the room on progressing both, I would have polled them separately. Rajan Rao: In G.872 the relation between media channel, network media channel and OChP is not clear. We should ask for clarification via liaison. Based on clarification there might be changes to the framework document. Deborah Brungard: Please make sure all of these questions are clear in the text of the liaison. Lou Berger: Ramon is going to draft the liaison. Send him (or the list) what you think needs to be added. Oscar Gonzalez: I'd prefer to have a solution standardized ASAP, rather than covering all possible cases. If other cases take more time please address them separately and don?t delay the control plane extensions. Lou Berger: yes, we had same issue with G.709. Deborah Brungard: Make sure your companies' reps at ITU understand the questions. > 8 10:05 8 Title: GMPLS OSPF-TE Extensions in support of Flexible Grid > Draft: http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-ospf-ext-04 > Presenter: Haomian Zheng http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-8.pdf Rajan Rao: I don't think label is appropriate to carry slot width granularity. Label includes N and M, it is not clear what M is here. Fatai Zhang: Do you mean that M should be carried in OSPF? We could simply stick to the label format defined in signaling. Rajan Rao: I would like to bring attention to the other OSPF draft I submitted a couple of days ago. Lou Berger: This discussion, or part of it, belongs to the framework document as the decision should be consistent across signaling and routing. Rajan Rao: We do capture it in the framework document without going in details of what the solution should be. Haomian Zheng: We?re open to other solutions and would be happy to work offline. Ramon Casellas: when working on these preliminary solution drafts we had a strong inheritance from WSON documents where there is a 1:1 mapping between labels and wavelengths and this is no longer true. It might not be the good solution to pursue. In flexigrid the kind of information we need to disseminate is the status of nominal central frequencies and every frequency is no longer a label as there is no longer a match between label and spectrum. I support the proposal to move this decision to the framework document and then see if there is something we can reuse from WSON or need to define something new. Lou Berger: Don?t feel that you need to limit yourself to WSON mechanisms. We are GMPLS here. E.g. there is the channel set label; we can reuse it if it makes sense? In addition to WSON mechanisms, you can build on every concept and mechanisms we have in GMPLS. Ramon Casellas: I?ll take it as an action to move all these concepts to the framework. Igor Bryskin: What is the relation between and architectural document and a framework document? Where this info should be put? Lou Berger: We don't have an architecture or information document. What does not go into solutions can only go in framework. We are contribution driven, if you want to write an architecture document it is welcome. Rajan Rao: Agree with Ramon. Lou Berger: [poll] - how many think this OSPF document is a good foundation for the WG to begin activity on routing for flexi grid? [about the same number supporting as before]. How many don't? [2 hands]. Same results as before, there is agreement in the room. Will poll the list to confirm. > 9 10:13 8 Title: Link Management Protocol Extensions for Grid Property Negotiation > Draft: http://tools.ietf.org/html/draft-li-ccamp-grid-property-lmp-03 > Presenter: Guoying Zhang http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-9.pdf Lou Berger: What do you see here that is not covered in routing? Guoying Zhang: All of these parameters are covered in routing. In addition to routing, LMP does negotiations, which allows a node to detect what is possible on the link and advertise the proper capabilities. George Swallow: It is also useful to detect misconfiguration. Lou Berger: You didn't highlight the relationship with routing in the document. You go from LMP to LSP setup. You don't speak about the relationship with routing, which is really important if that?s the desired function. Lou Berger: [poll] how many think it is an important function? [notably less than previous polls, but still a reasonable number], how many have read [about the same], how many think it is a reasonable starting point for the WG [not as much as the previous two, but still a reasonable amount of support.] Will also discuss on the list. > 10 10:21 10 Title: Terminology and Models for Control of Traffic Engineered Networks with Provider-Customer Relationship >Draft: http://tools.ietf.org/html/draft-dios-ccamp-control-models-customer-provider-00 >Presenter: Oscar Gonzalez De Dios http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-10.pdf Lou Berger: the use of CE and PE is quite common in IETF, which is customer/provider edge. Igor Bryskin: very useful document, we should go on with that as fast as we can. George Swallow: I like the diagram a lot. One comment on signaling with requirements: the requirement does not need to be something special, can be general. You can come into the bar and be told there is 100 beers and you say you want a pale ale and then you are told which pale ales are there. The requirement does not have to be something special, it can simply be: I need something like this. Fatai Zhang: This document is very useful. Perhaps just classify signaling models. > 11 10:31 10 Title: Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks > Draft: http://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange-03 > Presenter: Daniele Ceccarelli http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-11.pdf Igor Bryskin: Why is this framework not architecture? Adrian Farrel: It's just a name. Igor Bryskin: Architecture is very high-level description of the things that you do, framework is narrower blueprint for architecture. In PCE WG we have PCE architecture but we don?t have PCE framework for say inter layer computation. In my opinion architecture includes definitions and then have framework for different things that you can do in a particular context. Lou Berger: Oscar's doc can be "architecture for Igor" ? Igor: Thank you Zafar Ali: After the last IETF we had consensus that we would follow the signaling based and virtual FAs based approached, now this doc is all about virtual FAs, doesn't talk about signaling. Our proposed text wasn't included. We might take such text and put it into to a different framework that will cover a signaling based approach. Any comments? Lou Berger: This is still an individual doc and we can have more influence on its content only once it's a WG doc. We can see whether these last two documents are the foundation for starting the WG work. Clearly there is some content that needs to be shifted between them (e.g. terminology). Do the authors of the document want to comment on that? Daniele Ceccarelli: As of now just routing is in the scope of the document. Lou Berger: How about terminology? Does it stay in this document, or move to the prior document. Adrian Farrel: I have strong views about the right terminology but no view about which document to put it. I?m happy to bundle all the terminology in one place. Zafar Ali: if this document is a framework document, it needs to include the contributed text. George Swallow: I'm now confused about what a framework doc is. Are we working towards one framework document or multiple? Lou Berger (as chair): I prefer just one, but that is a preference and I can't force people to do that. George Swallow: if it?s just one, it must cover signaling as well. Igor Bryskin: it is very important to have a common terminology. It can?t go into solution documents or requirement documents. It should either go into architecture of framework. Lou Berger: Summarizing: There seems to be agreement that there should be a terminology document based on the current two documents, I'd like to ask the authors to work on that document with an aim to that being document 1 (discussed at the last meeting.) Adrian Farrel: Terminology should be in a separate draft; can still fold it back in later. Keeping it separate can help moving the terminology on fast. George Swallow: Can we have a definition of framework and architecture? My understanding is inverted from Igor's. Lou Berger: that seems beyond the scope of a single WG. I find the terminology very overloaded and try to avoid the terms in general. Adrian Farrel: I don?t care about the terms. There are two discussions ongoing: bringing all the terminology together vs bringing all the models together. Lou Berger: Agreed, I don?t believe we?ve addressed the second one. > 12 10:41 8 Title: Use cases for operating networks in the overlay model context >Draft: http://tools.ietf.org/html/draft-ceccadedios-ccamp-overlay-use-cases-04 >Presenter: Daniele Ceccarelli http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-12.pdf Lou Berger: Good setup for next three talks which cover different mechanisms to support diversity. We had a failed WG LC on LSP diversity document, we have three documents on topic. We need to determine if we need 1 or more solutions. The next three presentations will cover the objectives/motivations for their described solution, rather than mechanisms. The aim is to identify which are common and how many solutions may be needed. > 4 9:30 10 Title: Next steps: RSVP-TE Path Diversity using Exclude Route >Draft: http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-03 > Presenter: George Swallow http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-4.pdf > 13 10:49 8 Title: UNI Extensions for Diversity and Latency Support >Draft: http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-04 > Presenter: Dieter Beller http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-13.pdf > 14 10:57 8 Title: Extensions to Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) to Support Route Exclusion Using Path Key Subobject >Draft: http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-01 >Presenter: Fatai Zhang http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-30.pdf http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-14.pdf Comments on slots 4-13-14 Rajan Rao: (to Fatai) how does CE determine which PE to use for signaling? Fatai Zhang: It is known Lou Berger: cutting discussion due to time constraints (20 minutes over). Please can authors coordinate and try to come up with a common solution if possible, and if they can't state clearly why what they're doing is unique. > 15 11:05 10 Title: Analysis of LMP Security According to KARP Design Guide >Draft: http://tools.ietf.org/html/draft-mahesh-karp-lmp-analysis-01 >Presenter: Mahesh Jethanandani http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-15.pdf Lou Berger: Did the draft go through last call? Reason? Mahesh Jethanandani: No. Not enough traction/feedbacks. I want to believe because there is not enough LMP expertise in KARP. Lou Berger: who is willing to review the draft for CCAMP? 4 people. Please do the review, the sooner the better. Deadline (Adrian as AD) 1 month. > 17 11:20 5 Title: Network Assigned Upstream Label >Draft: http://tools.ietf.org/html/draft-beeram-ccamp-network-assigned-upstream-label-02 >Presenter: Vishnu Pavan Beeram http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-17.pdf Lou Berger: this is an optimization of an existing mechanism. My question to the WG is: is this a use case that requires optimization? How many followed the discussion on this? [a good number] How many think we should do this? [Close to the same number] Who thinks we should avoid it? [1] This is a clear indicator that this is functionality that we should care about and continue to discuss. > Adjourn 11:30 > > Second Session > FRIDAY, March 7, 2 > 1150-1320 Afternoon Session I > Room: Sovereign > Presentation Start Time Duration Information > 0 11:50 5 Title: Administrivia > Draft: > Presenter: Chairs http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-0.pdf Chairs: Starting with 16 and 18 from last session. > 16 11:15 5 Title: Mutually Exclusive Link Group (MELG) >Draft: http://tools.ietf.org/html/draft-beeram-ccamp-melg-03 >Presenter: Igor Bryskin / Vishnu Pavan Beeram http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-16.pdf ---moved from Session 1 --- Zafar Ali: More work needs to be done on the framework before WG adoption and discussion on this needs to be deferred in order to have a stable framework. Lou Berger: It is clear we need to represent potential topology in the next/upper layer but it is not clear how. I still think we need to define the bigger picture, which is what Zafar is saying but as I said adoption to WG is just the foundation to start work not a final definition. (Some discussion on topic and polling) [Poll]: is representation of potential topology (uncommitted resources in a lower layer) in routing something we are interested in? [a reasonable number] - how many think this particular problem (covered by the document-MELG) needs to be solved? [about half the previous number]. How many have read the document? [same as first time]. Seems there is tepid interest in this specific solution. We need to first work a bit more on the framework and then we might have more interest in this document. > 18 11:25 5 Title: OSPF-TE extensions for MLNMRN based on OTN >Draft: http://tools.ietf.org/html/draft-rao-ccamp-mlnmrn-otn-ospfte-ext-03 >Presenter: Rajan Rao Presenting together with: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-h-lsp-mln-05 http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-18.pdf ---moved from Session 1 --- Lou Berger: [Poll] How many are familiar with what these drafts are talking about? [a reasonable number] To me it is about generic adaptation issues. It is a discussion that came out during the G.709 work. How many think the WG should work on this issue (generic adaptation between layers/switching types)? [very few]. Take it to the list, explain which problem you are trying to solve and see if we have interest in it. > 20 12:03 7 Title: Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation >Draft: http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-info-03 > Presenter: Giovanni Martinelli http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-20.pdf (together with) > 19 11:55 8 Title: Information Encoding for WSON with Impairments Validation >Draft: http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-encode-03 > Presenter: Giovanni Martinelli http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-19.pdf Deborah Brungard: [Poll] How many are interested in this type of work [a similar/reasonable number] Lou Berger: Please add some text to cover the question of how application codes fit (or don't fit) in to this problem. Giovanni Martinelli: Okay, perhaps in an appendix. They don?t fit here because are in the scope of the encoding document. Dieter Beller: Why you think application codes are not sufficient? Deborah Brungard: This is not the G.698.2 discussion, this is about WSON impairments. Giovanni Martinelli: We used application codes in WSON RWA just for compatibility, and that?s the definition of application code. > 21 12:10 8 Title: An SNMP MIB extension to RFC3591 to manage optical interface parameters of DWDM applications >Draft: http://tools.ietf.org/html/draft-galikunze-ccamp-g-698-2-snmp-mib-06 > Presenter: Gabriele Galimberti http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-21.pdf (together with) > 22 12:18 7 Title: Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage application code of optical interface parameters in DWDM application >Draft: http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp-06 > Presenter: Gert Grammel http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-22.pdf Huub Van Helvoort: The Q6 rapporteur did a careful review of version 06 of these drafts and still has concerns about having application codes plus additional parameters. Maybe you should clearly state that this is not what you plan to do, and remove any confusion. Gert Grammel: which parameters are you referring to? Deborah Brungard: one of these parameters was power. Gabriele Galimberti: It is what Peter Anslow suggested at the meeting in Orlando. Power and frequency are the only two parameters left. We can work offline to close the issue. Deborah Brungard: only frequency is in the text. Dieter Beller: Why does "power" need to be exchanged via LMP? Gabriele Galimberti: It is useful to know if the link is properly working comparing the power at the two ends of the link. Dieter Beller: Clarifying text in the draft is needed. Deborah Brungard: The text is a little confusing. Are you planning to make it more general to cover other cases than the G.698.2? E.g. G.694.1-flexi grid? Gabriele Galimberti: Open to add flexi grid even if it is not yet fully clear in ITU, e.g. it isn?t clear what super channel is. Gert Grammel: Since flexi grid isn?t a WG item, it wasn?t included but we?re happy to include it when it will be working group item. It means the WG is interested in working on this topic. Deborah Brungard: [Poll] how many interested [a pretty small number] and how many read? [2x]. You need to generate more interest in this topic on the mail list. How many people are willing to work on the draft? [little less than those who are interested] You need to get more people involved. > 23 12:25 8 Title: RSVP-TE Extensions for RRO Editing >Draft: http://tools.ietf.org/html/draft-hartley-ccamp-rro-editing-01 >Presenter: Matt Hartley http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-23.pdf Greg Mirsky: I?m concerned with the latency metrics. If we don't talk about methods for measuring delay we risk to compare apples with oranges, there would be no metrics but different perspectives of something. Matt Hartley: that's just an example of the kind of thing you can do with this capability. There are separate drafts for latency collection/metrics and specifics can be discussed in that context. Greg Mirsky: There's some work done and still going on in IPPM WG on a new performance measurement registry and if interested standardizing latency measurement it should be mentioned there. Zafar Ali: Comment to Greg. We refer to OSPF WG for those metric, you might want to make your comment and the OSPF WF. Lou Berger: At the last meeting there was a question on what is the use case of tracking the information being removed. What is the use case for indicating the types of subobjects removed from the RRO? Matt Hartley: Main use case is to allow network operators to control information propagated from their network. You might want to know that SRLGs have not been modified and hence are a trustable piece of data. Lou Berger: [poll] how many interested in this function? [very few] - How many think it is useful to signal that the RRO has been modified in some way? [far fewer] - How many think that the particular solution in this document is useful? [even less that first question]. Zafar Ali: Could we ask if the WG is interested in a document modified for SRLGs only? Lou Berger: I think either the current approach or an approach that has 1 or 2 bits saying the RRO has been modified are reasonable choices. Going one by one (SO by SO) is not useful. Talk a bit more on the list to see if there is interest, particularly in the context of the draft that wanted to make use of this extension. > 24 12:33 10 Title: Signaling & Routing Extension for Links with Variable Discrete Bandwidth >Draft: http://tools.ietf.org/html/draft-long-ccamp-rsvp-te-bandwidth-availability-03 >http://tools.ietf.org/html/draft-long-ccamp-ospf-availability-extension-02 >Presenter: Amy Ye http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-24.pdf Andy Malis: there is no version number in the Ethernet bandwidth profile, you'd better define a new sub-TLV. Lou Berger: I don?t recall an ability to carry TLVs, maybe a new type is needed. Question: You are addressing only microwaves, is there any other technology that this applies to (i.e. any other link that changes rate depending on quality) E.g. ADSL? Amy Ye: yes, will broaden the scope. Deborah Brungard: [poll] how many read the draft [many], how many think this is a topic to work on [many]. > 25 12:43 8 Title: Extensions to Resource Reservation Protocol For Fast Reroute of Bidirectional Co-routed Traffic Engineering LSPs >Draft: http://tools.ietf.org/html/draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03 >Presenter: Zafar Ali http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-25.pdf Greg Mirsky: Even though this is not clearly stated, this is MPLS-TP domain. There is no requirement for co-routed bidirectional LSP in MPLS-TP and applicability of FRR to MPLS-TP. I suggest to review applicability first, this is an issue that in MPLS-TE can be solved by segment protection. Lou Berger: Why not use association object rather than FRR? Zafar Ali: 1. RFC4090 widely deployed, 2. When you have facility backup you don?t need to recover LSP by LSP but all in one. Lou Berger: If you'll go the FRR direction, I think this document needs to be moved to MPLS and not even mention TP. If you go the route of MPLS-TP plus association object, CCAMP is the right place. MPLS WG chair (George) or AD (Adrian) any comment? Adrian Farrel: This document also covers corouted LSPs, is it your intent for such work be done in MPLS. Lou Berger: Yes and the implication is the MPLS WG is going to have to solve non-GMPLS, MPLS corouted. Adrian Farrel: A feature creep of GMPLS into MPLS-TE is actually an RFC discussing the dangers of feature creep leading to the lack of a core function set and interoperability may be damaged, by the way if the chairs are happy with this split of work I?m happy. Lou Berger: If the choice of the MPLS WG chairs is to not do corouted MPLS, we can do an FRR based approach in this WG but, first we need to define GMPLS FRR. Andy Malis: MPLS-TP is not only signaled LSPs, it is also provisioned bidirectional corouted LSPs. Lou Berger: Agreed, the scope of the draft is a signaled based solution. Lou Berger to Adrian Farrel (as AD): Would you prefer to see MPLS supporting corouted LSPs or GMPLS supporting FRR explicitly (missing full definition for GMPLS FRR)? Adrian: I would prefer to see what the MPLS and CCAMP chairs agree on. Lou Berger: Okay, sounds like we need a chairs discussion. > 26 12:51 7 Title: RSVP-TE Signaling For GMPLS Restoration LSP >Draft: http://tools.ietf.org/html/draft-gandhi-ccamp-gmpls-restoration-lsp-02 > Presenter: Zafar Ali http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-26.pdf Lou Berger: There is inconsistency between the document and the intended status (informational) as it changes procedures. Either you make it standard track or change the text and make it informational. [poll] how many are interested in having it informational? [good support] Lou Berger: The document needs to be made consistent before we can discuss it further. I suggest making the document informational to be consistent with the slides. George Swallow: If changes are needed for an interoperable solution then those changes need to be documented. Lou Berger: Agreed, but then the document should indicate that it is a PS. > 27 12:58 10 Title: Requirements for Very Fast Setup of GMPLS LSPs >Draft: http://tools.ietf.org/html/draft-malis-ccamp-fast-lsps-01 > Presenter: Andy Malis http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-27.pdf Lou Berger: [poll] how many have read the document [] how many think this is an interesting problem to discuss? [a good number for each] George Swallow: What is achievable for OTN is much closer to your requirements than what is achievable for optical. I was wondering if requirements apply to both. Andy Malis: They apply to both, we have possible solutions for both but before coming with solutions we want an agreement on requirements. Rajan Rao: If we have separate data plane and control plane requirements, if the traffic doesn?t come out, what does it really mean? Lou Berger: question for the list. Adrian Farrel: I like this set of requirements, I hate you say you can't solve them with existing stuff. Push requirements and then we can work on an applicability to see if existing solutions can meet them. > 28 13:08 7 Title: Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Signaling Procedure for Resource Sharing-based LSP Setup/Teardown >Draft: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-resource-sharing-proc-00 >Presenter: Haomian Zheng http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-28.pdf Pawel Brzozowski: Please consider merging with the previous draft on restoration from Zafar. Reversion could also be done with make before break fashion. Lou Berger: the draft is informational and talks about restoration and reversion. I agree with the comment, and also suggest collaborating with Zafar. Again, if existing mechanisms are sufficient keep it informational, if you need new mechanisms then it needs to be a PS. > 29 13:15 5 Title: RSVP-TE extension for additional signal types in G.709 OTN >Draft: http://tools.ietf.org/html/draft-ali-ccamp-additional-signal-type-g709v3-01 >Presenter: Zafar Ali http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-29.pdf Deborah Brungard: The signal types are not a de-facto standard, they are just in appendix not a de-facto standard. Lou Berger: Defining the values as experimental is appropriate, but we have a process challenge. To allocate them for experimental purposes you also need a companion document to change the allocation policies of the registry to allow for experimental allocations. [poll] Is there interest in this work? [a reasonable number] > Adjourn 13:20