Last Modified: 2004-02-19
The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS WG. In this context, measurement refers to the acquisition and distribution of attributes relevant to the setting up of tunnels and paths.
CCAMP WG work scope includes:
- Definition of protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling. These will be developed in conjunction with requests and requirements from other WGs (e.g. TEWG) to insure overall usefulness.
- Definition of protocol(s) and extensions to them required for link and path attribute measurement. Link Management Protocol (LMP) is included here.
- Functional specification of extensions for routing (OSPF, ISIS) and signalling (RSVP-TE) required for path establishment. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols.
- Definition of the mechanisms required to determine the route and properties of an established path (tunnel tracing).
- Definition of MIB modules relevant to the protocols and extensions specified within the WG.
CCAMP WG currently works on the following tasks:
- Define how the properties of network resources gathered by a measurement protocol can be distributed in existing routing protocols, such as OSPF and IS-IS. CCAMP defines the generic description of the properties and how they are distributed in OSPF. The specifics of distribution within IS-IS are being addressed in the ISIS WG.
- Define signaling and routing mechanisms to make possible the creation of paths that span multiple IGP areas, multiple ASes, and multiple providers, including techniques for crankback.
- Define abstract link and path properties needed for link and path protection. Specify signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signalling, routing, and measurement protocols, either separately or in combination.
- Identify which requirements for signaling and routing for ASON are not currently met by protocols defined in CCAMP; based on these, define mechanisms to address these requirements.
- Define a protocol that can determine the actual route and other properties of paths set up by CCAMP signaling protocols, as well as other types of tunnels (tunnel tracing).
In doing this work, the WG will work closely with at least the following other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also cooperate with ITU-T.
|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|
|Dec 03||Submit protection & restoration documents to IESG|
|Dec 03||Submit ASON signaling requirements doc to IESG|
|Jan 04||Produce CCAMP WG document for multi-area/AS signaling and routing|
|Jan 04||Produce CCAMP WG document for generic tunnel tracing protocol|
|Jan 04||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|
|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|
timeCommon Control and Measurement Plane WG (ccamp) THURSDAY, March 4 at 0900-1130 =============================== CHAIRS: Kireeti Kompella <email@example.com> Adrian Farrel <firstname.lastname@example.org> === Group Admin --- Chairs Admin - Nothing much to say (in English anyway) - In Korean, however, the following was said: "Jigeumbuteo CCAMP meetingeul sijakhagesumnida". Agenda bash (5 mins) - No changes Status of WG drafts and milestones Adrian's slides showed that we do have some draft congestion in the WG. - RFC editor queue - status of IANA for SONET/SDH Kireeti talked about an issue with SONET/SDH IANA assignments - need a means to get early assignments. There is WIP to accomplish this, and it is moving ahead. - future allocation of "experimental" values Liaisons --- Marco Carugi talked about work in SG-13 (SG13 liaison). He covered topics, new study areas, timescales, objectives and status. They are also looking for people interested in doing work in these areas. An L1 VPN questionnaire and framework draft were attached to the liaison. Tomonori Takeda talked about the technical issues and details of the work. Monique Morrow had a couple of clarification for Marco - When will the consent portion of the work be done in the ITU? Marco said that the different pieces of work were progressing at different speeds. Some material is already embodied in recommendations. The next SG13 meetings are in June and September. Dimitri Papadimitriou asked if the draft (l1vpn framework) provided in the liaison could include a summarization (as conclusion) on the expected GMPLS work for the CCAMP WG, this would clarify the intent of the liaison in term of expected effort for the CCAMP WG Kireeti answered. If CCAMP's rechartering this month results in the addition of L1VPNs to the charter, then a Liaison response from the IETF will include this information, plus a request for a cooperative effort, preferably along the lines of the ASON routing work, wherein the ITU-T defines the requirements and the IETF does the protocol extensions. Alex Zinin said that we will have to make a decision at some point as to whether or not we want to do this work here. Kohei Shiomoto said that the protocol for the L1VPN should be developed at the IETF as long as it uses IP protocol. There are already internet-drafts on GVPN and CCAMP is the best place to discuss it. Deborah Brungard said that there is work and some synergy and that we should continue to work on this. Monique Morrow agrees that we should work on that. Marco added some comments that were not captured in the minutes. Malcolm Betts said he also feels that we should do this. Adrian took a quick poll and it seems as if nobody is against doing this work. Kireeti reminded people to continue this discussion on the list. --- Lyndon Ong talked about work in SG-15 (3 liaisons). Liaisons were on ASON routing requirements, response to comments on Q14 for G.7713.2 and comments on the CCAMP ASON signaling requirements draft. Lyndon spent much of the time on the details of response to comments on Q14. It seems that some of the differences in architectural models revolve around "end-to-end" and "call segment" operating models. Kireeti asked for the reply by date. Lyndon did not have that. Steve Trowbridge said that the meeting starts on April 19th Dimitri had a question on the deadline. There is a deadline on G.7713 (April 2004), isn't there a similar deadline on G.7713.2 (since this is the document to which convergence is expected) ? Lyndon said that he had not gone into that. He gave a reason, but this was not captured in the minutes. Deborah said that the liaison for 7713.2 does not say any thing about convergence. Lyndon said that they are still looking for a "meeting of the minds". Deborah said that there is an issue with G.7713.2 because of compatibility. Lyndon said that yes there has been a lot of discussion of compatibility questions and requirements. Kireeti said that we should not discuss this here. Steve Trowbridge added some comments that were not captured in the minutes. Kireeti asked the WG to take this discussion to the list and try to keep that discussion on a productive basis. Adrian said that he wanted to recognize the efforts of the ITU folks in this work. === ASON Requirements and Solutions --- Dimitri Papadimitriou presented status of ASON Signaling Requirements (draft-ietf-ccamp-gmpls-ason-reqts-05.txt. The requirements were driven by last year's liaison from the ITU. The discussion slides proposed to defer to the GROW WG (cf. RIFT WG item) concerning the (external) non-IP reachability issue since much broader than just CCAMP GMPLS/ASON context After this meeting, Dimitri would like to re-spin the draft and have a two week last call. Lyndon said he want to capture the requirement on "non-IP reachability" - whether or not we will work on it here Kireeti said that we first need to understand importance of this and then we can look to the ADs for guidance on handling this. He also said that we should take some time to work out what we want to say to the ITU when we include the current draft. --- Dimitri Papadimitriou gave status ASON Signaling Solutions (draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt) status. He would like feedback on whether or not the current draft deals correctly with the session attribute object that encodes the long call_id (alternatives were also proposed) His objective at this point is to try to have a document ready for last call for the next IETF 60 meeting in San Diego Lyndon suggested that we might remove the comparison with G.7713 from the draft. Adrian asked if this meant that the interworking draft for RFC3473/4 interworking was now obsolete. Lyndon said maybe, if interworking is removed as a requirement. --- Lou Berger talked about Egress Control - draft-berger-gmpls-egress-control-01.txt - Original egress label control became explicit label control. This draft attempts to capture the original intent. He wants to know if the WG feels that this is ready to be a BCP and what the chairs think the next steps should be. Lou re-iterated that the purpose and scope of the draft is for clarification. He does not see any value in adding to this intent or combining it with other work. Adrian then took a poll and nobody objected to take this on as a WG item (more than a third were in favor). --- Lyndon Ong went over status on ASON Routing Requirements - draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt He includes in his presentation the Design Team's conclusions as to what there is agreement about what's missing from GMPLS (delta), and what are the areas on which there is no agreement about what's missing from GMPLS. Vishal Sharma asked if the three issues (slide 6) were already opened up for discussion on the list, or would they be formally opened up with the DT members initiating a discussion on these on the list? Lyndon Ong replied that a discussion had not been formally opened up yet (although people were free to discuss/comment). Kireeti asked Lyndon to more formally open this discussion on the mailing list. Vishal Sharma said that he supports this. Kireeti said he would like - after checking with the AD - that we should take this work to the IS-IS and OSPF WGs. Alex Zinin said this is a good idea. === Tunnel Trace --- Ron Bonica presented status on draft-bonica-tunproto-05.txt The solution is very similar to Trace-Route but does not require that each node in a tunnel supports TTL decrement. He gave a few examples as to how the idea in the draft will work in a few scenarios. There are a couple of outstanding issues: - trace requires a route to tunnel head end - integration with LSP ping. He would like to get the draft accepted as a WG draft. Yakov asked what SPs use today for tunnel tracing. Ron said that in some case people can use ICMP for MPLS. Yakov then asked if we could get a BCP on what people are doing. Ron asked if he should resubmit his earlier draft on this. Kireeti said that we do not want to decide that now. === Protection and Restoration --- Dimitri Papadimitriou presented status on the work of the Protection and Restoration Team - specifically: 1) draft-ietf-ccamp-gmpls-recovery-analysis-02.txt 2) draft-ietf-ccamp-gmpls-recovery-functional-01.txt 3) draft-ietf-ccamp-gmpls-recovery-terminology-03.txt 4) draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt He gave estimates on the timing for each of the above drafts (estimated completion dates). He outlined the changes to the e2e signaling ID (draft 4, above). He encouraged the WG to really read the documents and comment. Kireeti polled for consensus on the following: a) Analysis - last call? Some support, no objection b) Functional - last call? Some support, no objection c) Terminology - last call? Some support, no objection d) e2e Signaling - WG document? Some support, no object Kohei Shiomoto said that the e2e Signaling draft does not address the misconnection issues raised in the mailing list. Dimitri answered that it is addressed in 8.3 of the draft. Kohei said that the misconnection issue does not happen only in the P&R context but also in more general context and therefore should be addressed in more general context as well. Kireeti said that the question should be continued to the mailing list. People at the microphone were asked to take their questions to the list. --- Lou Berger presented an overview of work on Segment Recovery - draft-berger-ccamp-gmpls-segment-recovery-00.txt He also talked about what still needs to be done (next steps), including more usage scenarios, more explanatory text and see if the WG will adopt this work. Arthi Ayyangar asked if the association object is required even if we are only doing segment recovery (as opposed to e2e). Arthi asked why couldn't we extend the Detour Object to achieve the same result. Kireeti asked her to take to the list. Richard Rabbat asked if this draft raised the same issues as the e2e signaling draft in terms of misconnection. Kireeti replied that they did not know if there were misconnection problems. Richard asked that the discussion about misconnections be moved to the mailing list in the interest of time. Adrian polled for support of accepting this as a WG draft. There was moderate support and no objection. === Inter-Area/AS --- Arthi Ayyangar talked about the status of the merged draft on Inter-area/AS signaling - draft-vasseur-ccamp-inter-area-as-te-00.txt The draft currently represents a full merge - work is still required to strip out redundant and unneeded text. She said that the authors encourage people to come forward with their comments. She would also like to see if there is interest in this work becoming a WG document. Vishal Sharma said that the work should apply to general path computation domains and GMPLS LSPs. In response to Arthi's question on Slide "Outstanding Issues" (about whether detailed description of various path computation algorithms should be part of this document or separate document(s)), he supported the document being split into a framework document, discussing signaling, and another document(s), discussing the path computation mechanisms, since the latter do not need to be standardized. In response to Slide "Outstanding Issues: Size of the document" and for clarity, he supported the splitting of the applicability statement into an independent document. Dimitri agreed on the subject of separating the document. In addition, he questioned about the relevance of using the LSP_Attributes to signal the signaling method for the intra-area/-AS provisioning of the LSP. In particular, he proposed to not include protocol procedures within examples/scenarios that makes the document difficult to read. Arthi asked that Dimitri take his specific comments to the list. Kireeti said that he agrees that the document needs to be split - one as a signaling and another (informational) to provide examples for path computation. He also said that we need a separate applicability document. Vishal Sharma then said that he would be happy to help with these tasks. --- Vishal Sharma talked about work on Inter-area path protection draft-dachille-inter-area-path-protection-00.txt He provided a brief overview of how it works, and showed how it relates to other work in progress. He also listed the next steps. He emphasized that this is really a generic mechanism for diverse path computation, and protection is one application of it, so the authors would respin with a new name and emphasis to reflect this." Zafar Ali asked how this would work if there is a failure at the time during which the backup path is being setup. Vishal replied that the solutions to this were, so far, not discussed in the draft, but that there are several options. He then outlined some of the options. E.g. either default in such a case to a sequential computation, and use XRO to exclude the link/node where backup path setup failed, and retry the backup (and optimize both primary and secondary later using the techniques in the draft). Or, set up the primary and the backup again, using the techniques described in the draft. Vishal said they would be happy to add some discussion in the document, and welcomed feedback on the list. Zafar asked how this work relates to PCS/PCE work. Vishal replied that it could actually be made use of by the PCS/PCE approach, and could be viewed as complementary. Kireeti asked that further discussion be taken to the list. Vishal said he welcomed further feedback on the document. Dimitri asked why, knowing that the proposed approach works as expected in the intra-domain case when the number of ABRs (where computation can be executed at each stage) does not increase, this approach is so focused on optimization (since it can't be achieved if this condition is not met). Vishal clarified that the focus of the work is to propose a generic mechanism to facilitate diverse path setup by communicating alternate path info, with optimization a desired goal (for reasons explained in the document). Vishal added that given the network model (where border nodes are not assumed to have visibility in areas other than their own), the scheme was not trying to be globally optimal. Vishal explained that in such cases some selection needs to be performed at each stage. Kireeti asked that further discussion on this should be taken to the list. Also, he said that Dimitri had a good point - we need to define criteria on which any optimization is based. Kireeti concluded by saying that path protection and inter-area are both in the charter, but that this document could only be considered for a WG document after there was discussion about the document on the list. === Control Pane Resilience, Hello Protocol and Graceful Restart --- Young Hwa Kim gave a presentation on Requirements for the Resilience of Control Plane in GMPLS - draft-kim-ccamp-cpr-reqts-00.txt He described the reasons why control plane resilience is needed. Zafar asked how control plane resilience is different from anything else in IP. Steve Trowbridge said that their is also some work in this area in the ITU and he would try to get this in as a liaison as soon as possible. Kireeti said that this is an important discussion and there are a lot of things to do. Specific topics should be raised on the list when appropriate. --- Lou Berger went over Extensions to GMPLS RSVP Graceful Restart draft-aruns-ccamp-rsvp-restart-ext-00 He emphasized that egress restart is already covered in RFC3473 and this work has no effect on that functionality. He gave a brief overview and listed open issues. Next steps include merging with other restart drafts and seeing if this work can become a WG draft. Arthi Ayyangar said that the text at the beginning of the draft seems to talk only about the recovery ERO, although using the RecoveryPath one can recover many objects besides the ERO. So the text should be clarified to this effect. Lou asked if she would like to contribute text. There was a discussion on adjacent node restart. Arthi asked why adjacent node restart was an issue being addressed in RSVP-TE. She pointed out that before this becomes an issue to be solved in RSVP-TE, we would first need to check if adjacent node restart even works for IGPs. The chairs then asked for other discussion to go to the list. --- Zafar Ali talked about Extensions to GMPLS RSVP Graceful Restart draft-rahman-ccamp-rsvp-restart-extensions-00.txt Kireeti said that he appreciated the honesty of the authors in acknowledging other work. Nurit Sprecher asked about the relationship to FRR and similar issues. Adrian agreed that these were important issues and had been raised on the list in recent days. He asked the authors to make sure that they cover the points in the draft. --- Zafar then covered modifications to Hello procedures 1) draft-ali-ccamp-rsvp-node-id-based-hello-00.txt 2) draft-ali-ccamp-rsvp-hello-gr-admin-00.txt He wants to go forward with draft 1 above. Adrian polled and there was some interest and no strong objection. Kireeti said that this work cannot be informational if it has - or proposes - changes to a standard. Zafar also wants draft 2 to be a WG document. Kireeti said that we need to take this to the list, but Zafar also needs to socialize the work he is doing so that people may decide whether or not this is work we want to do. === Everything Else --- Emmanuel Dotaro gave status of Multi-region protection - draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt He briefly covered changes since previous versions. He proposes that we may need to make changes to the charter to include all of this work. In particular to include in the charter the complete set of GMPLS mechanisms for integrated control planes, and not only multi-layer recovery (as it stands today). Adrian suggested that the authors need to get more people involved in this important work and revisit this later. --- Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs draft-vasseur-ccamp-isis-te-caps-00.txt He would like to have this accepted as a WG document. Adrian asked to hold off on this until after the OSPF talk below. --- Seisho Yasukawa draft-vasseur-ccamp-ospf-te-caps-00.txt He would like to have this accepted as a WG document. Regarding both drafts, Kireeti is not sure that this work belongs in this WG. The decision is driven by the generality of its applicability. If we do take it on, their needs to be a functional specification (independent of IGP) as well. He asked that further discussion be taken to the list. --- The Following presentations were postponed as we ran out of time. Adrian made a couple of brief comments as follows: --- Zafar Ali - Explicit Resource Control and Tracking draft-zamfir-explicit-resource-control-bundle-03.txt This work concerns identification of component links in EROs and RROs. A small group is currently examining other issues concerning identification of component links in all aspects of GMPLS. A draft is expected soon. Please mail Adrian or the list, if you want to be involved in this work. --- Lou Berger - Alarm Reporting draft-berger-ccamp-gmpls-alarm-spec-01.txt This draft is stable and complete in the view of the authors. A quick poll showed some support for this being a WG document, and no opposition. This will be taken to the