Last Modifield: 05/20/2002
The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for ISP and SP core tunneling technologies.
CCAMP WG tasks include:
- Define signalling protocols and measurement protocols such that they support multiple physical path and tunnel technologies (e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE) using input from technology-specific working groups such as MPLS, IPO, etc.
- Define signalling and measurement protocols that are independent of each other. This allows applications other than the signalling protocol to use the measurement protocol; it also allows the signalling protocol to use knowledge obtained by means other than the measurement protocol.
- Develop and define a set of protocol-independent metrics and parameters for describing links and paths that can be carried in protocols. These will be developed in conjunction with requests and requirements from other WGs (e.g., TEWG, PPVPN, etc.) to insure overall usefulness.
- Abstract link and path properties needed for link and path protection. Define 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 and measurement protocols, either separately or in combination.
- Define how the properties of network resources gathered by the measurement protocol can be distributed in existing routing protocols, such as OSPF and IS-IS.
- Define the relationship between layer 3 routing protocols and the common signalling protocol for establishing and maintaining paths.
- Using input from the TE working group, ensure that the signalling and measurement protocols provide both the information and the control functions adequate to support the traffic provisioning and engineering operations of service providers.
In doing this work, the WG will work closely with at least the following other WGs and constituencies: TEWG, PPVPN, IPO, MPLS, IPORPR, ISIS, OSPF, and GSMP.
CCAMP Documents Joint with MPLS:
- and draft-bonica-tunneltrace-01.txt to this section.
|Done||Post strawman WG goals and charter|
|FEB 01||Begin discussion of the framework and the requirement documents for signalling and for measurement|
|FEB 01||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|
|APR 01||Submit Initial framework and requirement documents|
|Done||Submit WG document defining path setup portions of common control plane protocol|
|Done||Submit WG document defining common measurement plane protocol|
|MAY 01||Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG|
IETF 54 CCAMP Meeting Minutes Schedule rearranged due to technical difficulties..... Kireeti: Can someone come up here and sing during the break? *) 0935 - 0950 http://www.ietf.org/internet-drafts/draf t-ietf-ccamp-lmp-06.txt Lang Provided summary of updates to LMP draft. See his slides for details. Thinks we are ready for IESG last call. Summary of updates to LMP WDM draft. See slides for details. Ready for WG last call. Bonica: initiate last call on list after meeting. LMP Test Sonet SDH draft. See slides for details. After changes, we should solicit comments from list. We would like a WG last call thereafter. Get a feel from the room? Kireeti: Assuming that J0-64 format is removed, are there any comments? Bert: The base LMP document was intended for proposed standard. We got pushback from ITU people stating that we should not be working on some of this stuff, so we split it out to a separate document. Are we intending on prop standard for this stuff? Kireeti: Yes, prop. Standards stuff. Bert: Are we on our proper turf? I would like ITU people to speak up on this as well as review it. I don't want discussion during last call, want resolution now. Speaker 1: Question RE: LMP. After this meeting I intend to start a draft. After reading LMP specification, I believe it has mandatory configuration. Are there security considerations. Lang: Yes, security considerations are mandatory. Speaker 1: I would like security to be optional. Bert: Security considerations may not be optional. We can have some as optional, but some mandatory security options are required. Kireeti: It is mandatory to define security - how to run LMP in a secure mode. It is not mandatory to run LMP in a secure mode. Can you? Lang: That is correct, it can be run un-secure. Ipsec is defined for LMP. If you do not want to run IPSec, you can run it without. Speaker 2: I am concerned about J0 encoding. It doesn't seem to be consistent with ITU T.50 requirement. Printable ASCII characters in particular might be an issue. Bert: Please pose question to mailing list. Ron: That way we will have record of conversation. Lyndon Ong(Cienna): My company is editing 7714.1 ITU document. Will there be any additional alignment with this? Lang: I think the 7714.1 document is more closely related to bootstrap document, and I would lke to discuss this in next part of presentation. Lyndon: This is now taking LMP and LMP-WDM that are tech specific. Are there any non-tech specific things that cannot be applied to both. Lang: The whole document can be applied to both. Kireeti: Is there any objection in ITU from letting IETF have this document or will we dribble out requirements one by one? ITU leason: I cannot speak for all ITUT, but we need to socialize this within the ITU. There is work going on with regard to discovery in ITU 7714 that might need to be aligned. However, I will try to get discussion going on rapidly. Dmitry P: There may be issues with the way the messages are encoded. Kireeti: We are not talking about discovery; test messages. Documents were separated so that we can work issues doc-by-doc. Good to get ruling for each document. The typical issues with using J0 etc... has rules for how to use this. Make clear that that some issues are about before service starts. Speaker 5: 7714 issue: if they do the same thing, then why define two documents for this? Lang: There may be overlap between next document, but not here. Speaker 5: Need to be clear about what the overlaps are. Lang: Bootstrap document (next doc), the intro describes why the doc exists. Prev. document is defined in LMP base document. If you disagree, let me know. LMP Bootstrap document. See slides for details. This is not WG document. Would like technical comments on list. Dmitri: Could you comment on applicability of incompatibility with other documents. Lang: The point to make is the information exchanged is the same as that for the LMP protocol. There is no new information exchanged. Kireeti: We need to continue this on the list (ITU input) on how we move these documents forward. Kireeti - CCAMP 55 WG status. Kireeti: Is there any problem with sending GMPLS framework to IESG as informational. Bert: I reviewed this doc a while back, and question is that non-standard extensions are detailed here. This seems strange to publish a document that suggests a way of signaling things without a document being somewhere that details the specifics somewhere. Dmitri: We have been looking for comments RE: pointers/document to fulfill your query. I think it is unfair to continue without filling these requirements. When I sent comments on the list, I asked people to provide pointers. If people would like to continue, please send pointers ASAP. Kireeti: As a fallback, what are we going to do if no docs are received. Bert: Throw it into the garbage. Kireeti: Unless we get pointers, this goes in the can. Kireeti: One thing has been asked about is changes to the charter. We want to make changes to the charter. Please send us suggestions. Few additions: inter-area (within AS domain), Protection/restoration, optical VPN. This will be discussed partially during SUB-IP meeting, but approval of charter changes come from IESG. JPV: Question about the charter. Will signaling between computation server and client are part of the charter, or do we need to add? Kireeti: The current charter does not explicitly have this. This is part of the charter extensions we are asking for. JPV: This can be used in other areas. Kireeti: Don't go there. If it is in the charter it is, if not then no. Need to make sure this is in the charter. Ron: I will send out an update on the charter additions (proposed) to the mailing list. Ashok - Interoperability draft. Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. These are issues for RSVP. Bert: These are separate documents. Do this in RSVP. Lou: Spec. requires TSPEC. Lets talk about this offline. Kireeti: Okay. I want to talk about some implementation recommendations. How are these published? Bert: Implementation recommendations are fine to either publish as BCP or Informational. I am worried about the limited set of specifications/issues and that they are captured. Kireeti: Generic RSVP things are already specified (according to Lou). Lets talk about this offline to see where changes are required. Define what issues are, how are they specified. Do this offline. Should we add recommendations to implementation survey as an appendix? Bert: Whichever. Lou: These look like guidelines to implementations. This is usually done outside of spec. done as BCP/Info. Kireeti: Question is where to put it. Lou: Seems like this is not a BCP. Kireeti: Too early to say that these include "best" practices. Looks informational. Need to talk with Lou about remaining issues. Tom Nadeau did a presentation on the discussions regarding the GMPLS MIBs at the Sat MIB Meeting. * how Saturday meeting affects the GMPLS MIBs? * issues for CCAMP: how to represent SONET (i.e. longer) labels * proposed solution on label/index given Tom asked for feedback from the working group on this proposed solution type field + octet string goal is to support longer labels * Comment by Kireeti to rename Link Bundling MIB to TE-LINK-MIB. (No questions on presentation). Nadeau: MIB overview presentation Dora: MIB discussion. 2 issues. Tom: SNMP is just another management interface, and like any other tool, it needs to be used appropriately. Otherwise, you will have scalability and provisioning issues. Kireeti: Lets have a discussion on the list for all of these things. Bert: Discussion going on in IESG/SNMP community. Been hearing that people do not want to use SNMP for configuration. However, I will defer to the WG for guidance on this. We need discussion on this issue, in particular from operators. Kireeti: We should take this to the mailing list. Protection/Restoration Team: Kireeti: I suggest that you kick off a discussion so that people can pick on points that might be controversial. We need to do this before we make this a WG document. We need to take this into account. Dmitri: We took existing protocols and analysed them. What I have said is a consolidation. I think we are fine with the scope. We need to focus on the validation. Kireeti: We need to make sure there is a consensus on your cut off that it was reasonable. Bonica: Tunnel trace draft. See slides. Is the requirements draft ready for WG last call. Monique: How is this going to relate to LSP Ping? Ron: When you discover a tunnel, GTTP invokes LSP ping. There is one open item: if the LSP is supported by an IP/IP tunnel. LSP Ping will not tell you this. Kireeti: Are there any comments from anyone else? The requirements document is a WG document. Can we have a show of hands for support of GTTP proposed solution as WG document? We have a small consensus in favor of this. Go back to mailing list to confirm. Dmitri: Draft. Dmitri: When you increase the scope of what GMPLS may cover. We need to handle the limited complexity here. This is what we have worked on. We need to handle optical/PSTN. Kireeti: Lets not make this a WG document until discussion on the list.