Last Modified: 2005-01-07
| Done | Post strawman WG goals and charter | |
| Done | Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. | |
| Done | Build appropriate design teams | |
| Done | Submit WG document defining path setup portions of common control plane protocol | |
| Done | Submit WG document defining common measurement plane protocol | |
| Done | Submit LMP MIB to IESG | |
| Dec 03 | Submit GMPLS MIBs to IESG | |
| Done | Submit protection & restoration documents to IESG | |
| Done | Submit ASON signaling requirements doc to IESG | |
| Done | Produce CCAMP WG document for generic tunnel tracing protocol | |
| Done | Produce CCAMP WG document for multi-area/AS signaling and routing | |
| Done | Submit ASON routing requirements doc to IESG | |
| Mar 04 | Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG |
| RFC | Status | Title |
|---|---|---|
| RFC3471 | PS | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description |
| RFC3472 | PS | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions |
| RFC3473 | PS | Generalized Multi-Protocol Label Switching (GMPLS)Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions |
| RFC3609 | I | Tracing Requirements for Generic Tunnels |
| RFC3945 | Standard | Generalized Multi-Protocol Label Switching Architecture |
| RFC3946 | Standard | Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control |
| RFC4003 | Standard | GMPLS Signaling Procedure For Egress Control |
|
Common Control and Measurement Plane WG (ccamp)
Tuesday, March 8, 2005 at 0900-1130 Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen Working group status - chairs - No changes to the agenda made. - Adrian reviewed status of drafts, reviewed charter milestones. We are holding off on new charter until finish last call of 8 drafts, expect 1-2 months. - Bill summarized ADs view, should wait for re-chartering until finish last call considering expectation will be very soon for last calls. * Dimitri asked about IPR assertion on re-optimization draft - Adrian said it did not give the same terms that have been seen in some recent IPR claims. The WG has to decide what to do. - Scott Bradner said we need to be very careful. Advised there may be anti-trust issues. Best to have no IETF interaction other than to ask for clarity. Scott offered to review emails on the subject. - JP said we can take that as a way to go forward and continue technical work. ASON considerations ITU liaison - Lyndon Ong presented Wesam's slides - Thanks to the IETF for liaisons and participation of Adrian and Igor at last meetings - Crankback and the comparison of LMP and ASON discovery will be incorporated in SG15 Q14's work. - There are two liaisons from ITU to CCAMP on the way. - Routing - ITU not planning any routing exts work, looking to IETF's work. - Continuing work on ASON management. - An FTP site is available for liaison statements. * Adrian asked if ITU plans to liaise G.7713 on new text for crankback before consent? - Lyndon said a meeting is upcoming and will ask for it to be considered. * Kireeti asked if there is any problem in that the crankback draft is not an RFC yet? - Adrian - RFC is desirable, not required? - Scott Bradner - it is required to have an RFC number for final balloting. The IESG can request expedited publication. * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU terminology, and may want to consider including it. - Adrian - can that be liaised to us? - Steve Trowbridge - Yes, we can do that. ASON Routing Evaluation * Adrian - The design team on routing has members from both ITU and IETF, although we did not do the correct process, so ITU reps are individuals, not ITU representatives. - Adrian will work with Steve to formalize the process. * Adrian - Would like to make the draft from the team on evaluation of routing protocols into a working group draft - we will take to the list to see if any objection. * Dimitri - asked if we can use formal liaison process to send this draft to ITU, does it need to be WG draft? And encourages comments now, before it goes to last call. - Adrian - we can liaise the draft and our intention to consider it as a WG draft Lexicography draft (Adrian) - Q14 indicates meeting went well, authors summarized comments and incorporated in this release. * Adrian asked if should be WG draft - Kireeti said we could do that, need to ask the list, also need to compare with G.8081 * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC or drafts, are there definitions? - Adrian thinks there are good terms, though in multiple RFCs/drafts. - Ben - if someone is new to the IETF, they have difficulty on where to go for definitions. - Adrian - if people want to do a draft to collect definitions of all GMPLS terms (more general than just ASON as in lexi draft), then they are welcome to do it. Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) LSP Stitching (Arthi) - Need feedback on several items. * Adrian - it would be inappropriate to move extensions to be a WG draft without first stitching draft becoming a wg draft. If no one objects, see no reason why not to be WG draft. * Dimitri - Question: the draft was to originally do signaling exts, do we need to do more on routing aspects? - Arthi - agree, however this comment would have applied to the previous merged draft. The whole point of splitting the ID was because the scope was wider and generic. In that case, it becomes necessary to include the routing aspects as well. * Dimitri - if allow stitching of end-to-end LSP with LSP segment through different switching caps, then this changes the LSP switching type along the path and thus this becomes a FA - Arthi - but end-to-end does not change. * Zafar - we need to be careful what advertising because of scalability concerns, need further consideration. - Kireeti - As Arthi said the LSP segment does not *have to* be advertised but *can be* if desired. - Arthi - You, of course, need to be careful about advertising anything as TE-links dictated by correct policies. And as far as scaling is concerned, Igor is standing right behind you and will probably say (and I agree) that LSP segments can also be bundled in which case you are no longer advertising each LSP segment as a TE-link. We are simply having the same discussion again that was on the mailing list. * Igor - thought stitching maybe more appropriate for LSP hierarchy draft, but as this already in editor's queue, will add here. * Lou - sw cap can change hop by hop just needs to match end to end of hop. - Arthi - agree, we were thinking the same. * Discussion sent to mailing list Per-domain path computation method for computing inter-domain traffic engineering (TE) LSP. (JP) Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: routing and path computation aspects. * Zafar asked clarification on ccamp-pce relationship - Kireeti - this draft discusses ASBR on the path, if not then it's PCE, suggest add this to draft to clarify that this is for when computation is done by elements on the path. - JP - ok * Adrian and Kireeti asked if this should be a WG draft? Good consensus in the room to be WG draft, will take it to the list. Automesh (JP) - Agreement to rehash work a bit to put these together. - Now 2 drafts - Not a new ID, no changes. - Deployed networks using that. - No major changes planned * Igor - asked how to reflect constraints in a node for switching? - JP - we are discussing auto mesh, not node switching. - Igor - but how do we reflect node capabilities? - JP - this draft is not about node capability discovery (for this, see draft-vasseur-ccamp-te-node-cap) - Igor - how to reflect for computation any internal constraints, could do via node caps advertisement. - JP agrees, though here just doing a discovery, doesn't think related as discovering members of mesh. - Adrian - two drafts, this is not node capability that is next one by JP, cut discussion said to take it to list. Routing extensions for discovery of TE node capabilities (JL Le Roux) * Adrian - on process, authors did a group job of splitting draft and sending to OSPF and ISIS groups, chairs will follow up with those groups. * Dimitri - should for terminology call TE router? - JL - yes. - Dimitri - should the TLV be exclusive to this function? - JL - yes. * Igor - how to distinguish node capabilities? - Adrian - do by TLVs, need to do a draft to propose, this draft gives you the TLVs, then can follow-up with other drafts to describe function want to use it for, take discussion to list. * JL asked that this be adopted as a WG document. - Adrian - Take it to the list Extensions to GMPLS RSVP graceful restart (Lou Berger) * Adrian - do editorial respin, let us know, and we will take to last call * Any implementations? - Yes - two! MRN Requirements (Kohei Shiomoto) Evaluation draft (JL Le Roux) Protocol extensions (Dimitri) * Arthi - what does virtual FA have to do with MRN, isn't it general? - Dimitri - should we have a specific doc on virtual FA for wider scope? - Arthi - did you want to scope only to MRN context? - Dimitri - no, just not sure if soln doc should be split. - Arthi - could be general - so prefer a separate doc on virtual FA. * Zafar - we need to give a priority capability for TE. - Dimitri - new TLV may be needed to describe relationships of multiple interfaces * Zafar - how relates to hierarchy draft? - Dimitri - maybe should be as applicability statement, - Kireeti - should do on mailing list * Kireeti - requests to continue work, when re-charter will consider for WG drafts. Routing considerations and CSPF for inter-as (Tomohiro Otani) * JP - very useful draft. Concerned about the advertisement of DYNAMIC summarized TE resource information across domains (static capabilities are perfectly fine). Too much of aggregation renders the solution inefficient and not enough of aggregation seriously compromises the routing scalability. Furthermore, there are other confidentiality issues to sort out in the context of inter-provider. - Otani - ok, we need more on summarizing capability. * Kireeti - thinks good and hopes to be a WG draft, though for now would request for this draft to continue work, though lets finish what ccamp has now and then when re-charter will make this as a WG doc. * Otani - how to handle inter-as cspf constraints? - Kireeti - as noted before (continue work). L2LSP (Dimitri) * Adrian asked clarification, is this "single hop"? - Dimitri - multiple hops each is a LSR, will clarify this in draft * Kireeti - ADs request a framework doc and include how it relates to other SDOs, max 10 pages - Dimitri - ok GMPLS addressing (Richard Rabbat) * Adrian - as this is first version, recommend continue discussion, re-spin draft, and then review again. * Adrian asked for feedback on the topics, not the technical content initially. * Loa - BCP is a specific type of RFC, describes what we have experience with not necessarily what should be (as in this draft) * Kireeti - warns for everyone with implementations to review the draft to ensure direction taken by this draft is right one. * Lou - should we wait for re-spin or now? - Kireeti - wait for re-spin. L1VPN (Tomonori Takeda) Framework draft Applicability draft * Alex - by next IETF will decide if it should be included in ccamp or as separate WG. Control plane saturation (JL Le Roux) * Arthi - Do you think the LSRs would really want to advertise such control plane limitations ? Secondly, what implication does this have in case of inter-domain, especially inter-provider LSPs ? * Kireeti - because of time, lets do on list. Graceful shutdown (Zafar Ali) * Kireeti - will consider for wg doc after re-charter * JP - is this part of current charter - Kireeti - doesn't matter, we just can not include anymore as WG doc until re-charter. Deployment-augmented (Zafar Ali) * Arthi - This is good work. My only concern is the use of terminology. Do you actually expect to use LSP-Hierarchy extensions (say Hop3) while signaling an MPLS LSP over that FA in the MPLS domain ? - Zafar - no just TE link GMPLS interworking (Kenji) * Dimitri - why need to adv priority of LSP? - Adrian - need to ask on list. GMPLS interworking (Kohei Shiomoto) * Adrian - WG doc will be decided after re-charter - Welcome that will merge with other draft on augmented, - Suggest also look at Kenji's interworking draft to merge. Cho - ARP signal * Kireeti - request work with Dimitri on framework draft, - When decide direction and interactions with other SDO, may decide to form a design team to work on L2, - First we need a framework. |