2.7.1 Common Control and Measurement Plane (ccamp)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


Kireeti Kompella <kireeti@juniper.net>
Vijay Gill <vijay@umbc.edu>

General Area Director(s):

Fred Baker <chair@ietf.org>

General Area Advisor:

Fred Baker <chair@ietf.org>

Technical Advisor(s):

Rob Coltun <rcoltun@redback.com>
Randy Bush <randy@psg.com>

Mailing Lists:

General Discussion:ccamp@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe ccamp
Archive: ftp://ops.ietf.org/pub/lists/

Description of Working Group:

Note: this WG is one of a set of WGs that comprise the 'sub-IP' pseudo-area that the IESG recently created. All of the sub-IP WGs are temporarily being housed in the General Area until the IESG decides on a final management structure for managing these groups. The Area Directors for the following areas acting as a group will be the Area Advisors: INT, OPS, RTG and TSV. The name(s) listed above under "Technical Advisor(s)" are the the responsible Area Directors for the working group.

Organizational Overview
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.

Goals and Milestones:

Feb 01


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.

Mar 01


Build appropriate design teams

Apr 01


Submit Initial framework and requirement documents

May 01


Submit WG document defining path setup portions of common control plane protocol

May 01


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

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

CCAMP minutes.

Notes for CCAMP:

Started off with a few comments: Kireeti mentioned that CCAMP needs design teams for requirements . Also more SP input would be welcomed. There would also be CCAMP interaction with TEWG.

Sub-IP area intro (Scott)

Need to consolidate sub-IP stuff into one area (currently temporary - aimed at 1-2 years and hopefully less.)

CCAMP is one WG - also a bunch of others. Commonality is that none of these fit well into existing areas. "Dark underbelly of IP, not bright light above."

Will keep ADs as tech advisers to WG. Fairly hands off. Mentioned that there are 300 or so IDs that need to be filtered in this area.
Need help from a lot of people to filter through this to figure out what the IETF in general and this area esp. needs to deal with.

Will be re-evaluated post IETF in London (IETF 51).

Using 2 octets for b/w values (Qingming Ma)

Thing to note: Formula is a * 2 ^ b - handles values up to 8,000,000,000 TB/s. (Really means (a*2)^b of course).

Saves about 50% of size of TLVs. Also reduces h/w requirements (no float.)

Recommendation - replace 4-byte FP in current drafts OR define new B/W sub-TLVs that use 2 octets.

Was put to the Room. The general commentary appeared to be that this was not worth pursuing. [Notes are a bit vague here, commentary welcome]

Tunneltrace (Ron Bonica)

Curtis - Need to support ICMP work done earlier, and accept that in reality we're going to have to transition at some point. Lack of ACL used to be considered a "feature" in the NSFNet days (allowed customers to tell clueless operators what they were doing wrong.) So it should be a requirement that at least at the macro level this is still true.

Kireeti - AS level should suffice?

Curtis - want ICMP to be informational now, and historic later.

Scott Bradner - IESG has discussed this a lot. Asked a design team to come up with generic problem statement and come up with generic solution. Right time to talk about it is once that report has been discussed.

Crankback Routing Extensions (Atsushi Iwata)

initial March 2000 (00.txt) CR-LDP extension for crankback
second Jul 2000 (01.txt) additional descriptions for CR-LDP (accepted as MPLS-WG draft)
third Dec 2000 (this draft) RSVP-TE in, and improves descriptions.

Propose that whole draft is accepted as a CCAMP WG doc (draft-ietf-ccamp-crankback-00.txt) for crankback routing for MPLS signalling.


Rob Coltun - applicability? Can see it being used for abstraction (e.g. ABR). For single area why not crankback and retry without this draft?

Atsushi - crankback should be general to both single and multi-area cases. Should not preclude single area. Feedback mechanism could be used instead, but we definitely need crankback for multi-area.

Rob - want requirements for multi-area/hierarchy sussed before this is accepted.

Curtis - would only have strict route in local area, and loose route beyond that. If hierarchical tunnels should be able to recover.

Kireeti - but you could have picked the wrong ABR.

Curtis - if you don't use admin colours you're OK - can't pick wrong ABR.

Unknown - several multi area methods have beenh proposed. All ask for crankback.

Kireeti - will wait until all requirements come out and then come back to this draft.

Closed-loop automatic link provisioning (Lily Cheng)

[notes get vague here ]

CCAMP requirements (Dave Walker)

First draft of a requirements document. Aim is to put CCAMP work into some kind of context. Goes beyond requirements into framework/architecture etc.


Curtis - this is nothing to do with CCAMP charter. Very like COPS which has been rejected for this.

Dave - but we have to have a framework.

Curtis - this isn't it.

Vijay - I tend to agree, but we need to take this to the list.

G-MPLS Architecture (Eric Mannie)
27 co-authors!

Reverse engineering of 10 existing drafts to get arch. 8 of these are WG items, some moving to WG last call. Form a coherent/consistent set of specs. Challenge is to explain them all in one doc. Co-authors are authors of those drafts.

Status: published, Got comments. Added new section on n/w management. Log of comments/resolutions. Will be adapted to revised building blocks. 01 soon after this IETF.

How to help:
Send comments in email.

Comments on building blocks directly to the authors of those. Please point out discrepancies between draft and building blocks.

Accept as CCAMP WG item
target info RFC
publish new version
Send draft to ITU-T and OIF


Scott - If sent, it needs to note that this is only temporary and the
author's opinion, not that of WG (until it is). Especially
with ITU-T, we have to be careful, as they can't reference
IETF drafts.

Curtis - this is what he expected. Not perfect but very good and
should be WG doc.

Eve - excellent reverse eng of work done. Had hoped that CCAMP formation and expression of requirements would enable us to do more with architecture than reverse architect proposed solution. Think we should also look at carrier requirements and look for discrepancies with architecture. G-ASTN is actually not intended to be different approach. Both doing ASTN - need some form of ?. G-ASTN relies on architecture input from carriers. Need open email discussion.

Curtis - requirements of carriers not being addressed?

Eve - happy to discuss on mailing list in absence of time.

Kireeti - might be premature to have requirements after drafts. Do these in the right order - code freeze, code review, requirements.

Intra-Domain GMPLS architecture (Yangguang Xu)

Accept this as WG document.


Eric Mannie - what is missing in "our" G-MPLS architecture?

Kireeti - no time for this. Eric's doc is a concrete proposal, shows how it all fits together. Personal opinion is that this draft is more of a framework. Should decide if we want a framework ID, do we want arch ID. Do these fit requirements?

Xu - can we work together? No problem with working with other authors.

Curtis - in past practice was to have 2 WGs if there were different approaches. If they are different, should we have 2 WGs? If not, then one is framework and one is architecture.

Lou Berger - Any parts that fit architecture picture should be incorporated into that.

Xu - what about reverse direction.

Vijay - Work out on mailing list. Thanks for your time...

G-MPLS signaling specs - Lou Berger

A few changes - aimed at making it easier for the future. One substantial technical change on SONET/SDH, will discuss that later. World doesn't stop as finish doc, need to accommodate new techs as they come, so one change to make it easier as it happens. One other change - moved protection flags into own object. Make it easier to change there rather than change in label request. One bug also to do with v6. Fixed.

Authors believe they are done. No more changes to make.

Big change was there was technology specific stuf in the label request. Problem would be how to assimilate future technologies - would need to change label request. Moved that into the tspec/traffic parms since were really describing connection in technology specific ways. Tspec was great for packets but not for SONET/SDH. Now fixed that. So expectation is that when new technologies arrive (e.g. G.709) will have new doc outlining new changes required to support that standard. So end up with identical label request for all technologies.

Tspec/traffic parms has technology specific stuff. First case is SONET/SDH. Some minor changes here based on feedback from SONET folks. Think is correct. Please give feedback if disagree!

Next steps - get this out in the next couple of weeks.

Proposal is to go for joint CCAMP/MPLS WG last call. Docs are believed now fully baked! Not ready for rest of IETF until we have consensus in CCAMP and MPLS. Authors believe they are ready.

? - Explanation question. Seems like new technologies will require changes. G.709 is actually ready so why not put in now?

Dimitri - we will consider G.709 within the global parameters that we have.

Kireeti - what if put in now and ready in 3 months. What if someone then says "what about something else" - we'll wait for ever. Issue what we have now and incorporate new stuff later.

Lou - agree. We have a good framework. G.709 can be easily defined within this structure. If we find in doing the G.709 document, that the structure here doesn't allow definition, then that will be an important issue.

Eric - G.709 is stable. G.709 is just a TSPEC so we can do it in parallel. Adding stuff that is approved/standardized like G.709 is not a big deal. Companies are already announcing chipsets for G.709.

Lou - we should let base fns move forward, and as soon as we have specifics of G.709 (even if only 2 pages) it can be issued as a separate doc. We have structure for next technology - which may well be G.709.

? - not question of whether this is broken. Have a proposal that says what has to be added so why not do it now?

Kireeti/Lou - lets do this in their 709 presentation.

Curtis - plenty of precedence for writing something with good extension mechanism and adding stuff later.

Kireeti/Vijay - checked we have consensus for last call. Consensus of meeting will be noted to mailing list.

[There were probably about 30 folks out of 250 to put up their hands. 25 for, 5 against]

GMPLS Signaling Extensions for G.709 (Gert Grammel)

Proposal is IP-based control-plane for G709 capable networks. Why?

G709 will be interesting 10 gig, 40 gig etc. Why was G709 born? G975 is standard for submarine ULH. SDH frame + FEC. Need FEC to handle photonic transmission, and to optimize span power budget. Increased distance between regenerators =3D cost saving.

Turns out we need FEC for ULH and for VSR (allows cheaper fibers)

Sonet/SDH, and IP, GE, 10GE, ATM. Sync and Async.

New frame defined. G709 =3D "digital wrapper".

GCC =3D Gen com chan
G709 payload
Supports inbound + out of band signaling.
Future layer stack has any over G709/lambda. Need GMPLS to handle G709.

Proposal is extend G-MPLS for G709. Provide new TSPEC. Generalized label. IF/IB signalling transport via GCC (comparable to SONET DCC)

G-MPLS is the right control plane for G709!

Request WG accepts this draft as WG doc in CCAMP



Randy - My understanding of CCAMP is that "C" is "Common". Developing a unified control plane. Is this "The" Unified Control Plane?

Kireeti - GMPLS is a unified control plane, but technology specific pieces fit on top of GMPLS, this is an example. e.g. SONET, G709. We don't have a G709 or SONET WG, so can't do it there.

? - Observations. Good overview of G709. Didn't discuss all reasons for G709. Other comment - this doc defines signal types, e.g. Transparencies and OSS. Why define some of these. G709 defines a bunch of stuff. None of this was covered.

[There was much scratching of heads.]

Eric Mannie - totally incomprehensible response (lack of Microphone.)

Curtis - All the more reason why not to put G.709 into the main GMPLS signaling. - Let's wait for these to converge.

? - thinks draft-mannie is more complete. Aligning will take "2 minutes".

? - Better to have real generic format and have tech as appendix.

Kireeti - been there before. Lets not go back there!

Lightpath Route (LRO) Extensions to RSVP-TE for OCh Connection Setup
(Murali Krishnaswamy)

Scope of GMPLS Signalling (Yangang Xu)

Extensions to GMPLS signalling (Zhi Lin)

Proposal is to work together to merge/extend encoding/signal/G-PIDs, to align technology specific labels, and to resolve issues brought up in email list.

Kireeti - You should look at the most up to date drafts, they include a lot of what you mention. Need to look at current signaling spec (where stuff moved to TSPEC) to see what the gap is now.

Leen Mak - Good to have a list of circuit types. As a lot of packet folks thing there are just a few pipe types.

Kireeti - yes

Curtis - If there is any disagreement in encoding for SONET or for waveband switching then they should move SONET into separate doc (like G.709). Since you've added an extension mechanism, maybe it's best to define SONET in that manner, just like G.709.

Eric Mannie - incomprehensible reply.

Kireeti - agree with Curtis. If there is disagreement on mail list we should move out to separate document.

Lou Berger - these changes plus anything else we missed is good input to GMPLS draft to check nothing is missing. Wouldn't be surprised if in last call we find a bunch of other stuff we missed.

Kireeti - we should move G.709 to different doc. 2 groups working on G.709 should come together and THEN we can talk about making it a WG doc.

Restoration Mechanisms and Signaling in Optical Networks / Packet Optical Escalation Strategy
Dimitri (and many others)

Note from Rob Coltun that these are informational presentations at this time. Survivability is key issue for Intelligent Optical Networks. IP based control plane must cover protection and restoration mechanisms for non-packet based networks.

[ presentation ]

Two approaches, the bottom up, and the top down. Bottom up. The all optical network triggers the edge/packet device. Cascading triggers since many services go over single fiber, which is a common multi-layering strategy. Their Hybrid strategy involves a coupling of the layers.

Solution Objectives. Notification aggregates multiple failures for scalability. Restoration time independent of the # LSPs. Minimize downtime and resource utilization.

Microphone passedover to Jino Hahn (sp?) for review of what has been done in actuality with regards to this.

OSC Controller in an OXC which communicates to different layers.
Example of restoration approach, see presentation.

Conclusion: need to use common mechanisms as a foundation.

Dimitri - conclusion is we need to have technology independent mechanisms and "custom" mechanisms which are technology defined.

Proposal is to split mechanisms from signaling protocol extensions.
Would like to co-operate with others.

Inference of Shared Link Risk Groups (Dimitri)

Quick comments on draft-many-inference-*
SRLGs allow failure disjointness and physical/logical hierarchies.

Important issue is definition of physical and logical hierarchies.

Physical is fibres etc.

Logical can be geography. Region/Zone/Element.

Propose a hierarchical SRLG encoding. To take geographical topology into account have region, zone ID.

Proposal: we want to open discussion on this.

Kireeti - can't progress until we have requirements (as Rob said.)

? - does that apply to SRLGs.
Kireeti - lets take this to the list.

Signaling for Fast Restoration ( Bala Rajagopalan)

What's this about?

Functional description of signaling for certain protection modes.

Makes distinction between restoration and reprovisioning.

Defines "lightweight" signaling protocol.

Why do we need restoration signaling? ?

Mechanisms needed? Pre-establishment of protect path state. Failure notification. ?

Introduces functional descriptions for restoration/re-provisioning.
Example on why signalling is needed.

Pre-establishment of protection path state, failure notifications, activation.

Perspective: SONET control channel. K1/K2 takes 375 uS, linear span restorations 60 ms, line switch 100 ms..

Why a dedicated signaling protocol?

1. Performance. Needs to be lightweight, minimal, etc. etc.
2. Customization is appropriate where it makes sense (e.g. LMP.)
3. May not have a signaling protocol for provisioning.

How to proceed?

Hopes that if we have no other job we'll read the drafts.

Question for Rob. This group doing lots of restoration work. Gated on requirements. When are we going to get them from TE?

Kireeti - appreciate the fact that Bala only took 4:18 seconds, acknowledges the dependence on TE.

Q: is TE signed up for this, there is a big dependency

(3) Jim Boyle - we understand the dependency

(3) Jim Boyle - we have done lots of work on this in TE. If it takes a while to get requirements it isn't catastrophic.

Bala - people don't seem to appreciate difference between MPLS and this.

Jim - you need to consider that if people keep disagreeing with you then they may be right!

Generalized MPLS Recovery (Jonathan Lang)

Common understanding of terminology. Difference between protection and restoration (former is fast but may need dedicated resource. Latter is slower but can use shared resource.) Path/span levels. Primary/secondary LSPs. Secondary have resources requested and reserved but not allocated so other LSPs of same pri can use the resources with caveat that if the secondary was needed by primary then they'd be bumped off.

Need mechanisms to advertise b/w for secondary LSPs. How do we do bandwidth accounting in each node to ensure resources used properly. Referenced all of this in generalized recovery draft. But this isn't published yet?

Curtis - did you look at draft-kini and is it aligned.

Jon - yes, and it has additional stuff. Part of what "we" need to work on is whether we need those requirements. Or is this something done at LSP establishment?

Curtis - essence is ability to share backup b/w. Can you do this?

Jon - yes that is the essence.

? - Other bodies have been doing work over the years. Why invent new terminology? Willing to contribute docs with terminology in to list.

Jon - we just need to agree common terminology. Seen many docs with different terminology.

? - if don't agree will have a mess.

Vijay - relying on "preemptable" services, or services that should be there (via preemption) can get interesting.

Status of LMP (Jonathan Lang)

Clarify text/terminology.
Decouple control channel/link bunndle dependence.
Address in-band control configuration.

Changes in draft enumerated in presentation.
Other changes based on comments received etc.
Modifed test messages
enhanced LinkSummary message
Added Channel Activate messages
Added LMP length field
Modified FSMs
added MD5 authentication option.

Next Step.
Remote CCId from TE link-related messages (completes the decoupling.)
Address more comments on the list.

Kireeti - thanks to Bala and Jonathan for getting us ahead of time/back on time.

LMP for WDM - Andre Fredette draft-freddette-lmp-wm-01.txt

Will describe LMP-WDM doc. Also compare to NTIP (competing proposal).

Diffs from -00 document:

1. decoupled lmp and lmp-wdm sessions. Up to the cross-connects/router to correlate this and to manage relationship between sessions.

2. Focused on opaque DWDM transport systems. More thought required before we handle all-optical stuff. But do have a framework here once IPO group send requirements.

3. Whole list of things we could advertise. Narrowed this down to get packet formats.

4. Group ID added for message suppresion - see draft!

5. Added a bunch of stuff that was proposed and are throught to be reasonable.

Requirements (LMP vs NTIP)
Need an open protocol between tx systems and OXCs (and perhaps attached devices - e.g. Routers) to exchange info about links.

Protocol characteristics:
simple as possible
motherhood and apple pie

Require following functionality (ordered from most to least agreement):

1. Adjacency Discovery and control channel maintenance.

2. Connectivity discovery (avoids manual provisioning) control over link transparency.

3. Fault management - detect defects and advertise up. NTIP proposes trace notification to monitor trace messages.

4. Link Property Advertisement. Some disagreement here on what you need.

5. Performance Information Advertisement. Link Health.

Table comparing LMP-WDM/NTIP

Big difference - LMP-WDM uses IP with LMP ACKs for transport. NTIP uses TCP. Age old argument - advantages/disadvantages of each. Both protocols attempt to accomplish the same basic objectives.

Could come to agreement on information to advertise.

LMP-WDM will incorporate good ideas from NTIP.

Big advantage with LMP-WDM is that it extends LMP. Main requirements met by LMP. Nothing extra that is not needed in LMP. Results in single protocol for basic link management.


Use of LMP for link management of all devices in GMPLS network.

Merge new items into LMP-WDM (trace monitoring/defect types)

Accept LMP-WDM as WG doc.

? - What is NTIP?

Andre - next presentation is NTIP.

? - Why not just use LMP. Isn't this just an annex?

Andre - same as with GMPLS signalling. I don't care where it goes.

(3) Jim Boyle. - all devices in GMPLS network?

Andre - yes. Wherever you have need for this info have LMP?

? - like the table. Key is fault management. Key attribute is fault monitoring. This is in NTIP.

? - IPO WG has WG item on all constraints for optical routing. Need to co-ordinate on how to pass link-layer stuff around.

Andre - yes we need to know these things. LMP can be vehicle for advertising this.

? - Something about link layer abstraction.

Kireeti - Need to know what we want to measure and communicate between systems.

Network Transport Interface Protocol (NTIP) for Photonic Cross
Connects PXC (Osama Aboul-Magd)

NTIP runs between PXC and Transport NE. (TNE).

Doesn't have knowledge of health of the line system.

Small set of messages - so simple to implement

Uses TCP for reliability - sufficient for this app and avoids reinventing the wheel.

Fast reporting of defect events - essential to ensure fast restoration and recovery of lightpaths.

Asymmetric Protocol (unlike LMP) PXC master. TNE slave. Minimises need for persistent information at TNE.

Most requests are initiated by PXC - confirms master/slave nature of protocol. Defines a series of failure types.

Big difference is simplicity relative to LMP. TNEs are pretty light on processing capacity and aren't designed for complex management - so put functionality in management system.

LSP is complex because of OXC-OXC interactions. LSP is 6 states, 18 events. Plus 9 states, 16 events for TE FSM, plus... ? states, 12 events.

NTIP is 4 states, 14 events.

TCP is sufficient for this kind of application - so chose that.
Recovery is good enough for OXC-TNE. Remember that this is one hop - so failure is rare event.

Fault localization of LMP is not needed for this PXC-TNE case. Big table comparing NTIP and LMP-WDM.

Advantages of simplicity etc. Also has priority handling of defect reporting messages. See this as important. Also ability to recover from control channel failure (not specified in LMP-WDM.)

Same proposal as Andre (but other way round) - accept NTIP as WG doc.
Don't want 2 protocols. Also need to co-ordinate with T1X1/ITU.

Andre - big thing you made about events and states. But they are all in TCP. Have you counted those?

Osama - they are in O/S.

Andre - speed of TCP? What if things get stuck in TCP transmit queue.

Osama - this is very controlled environment. Not really congestion.

Andre - this is exact reason not to use TCP.

Andre - claim of simplicity is at expense of identifying un-needed complexity in LMP. Also because document hasn't been written yet.

?a - Didn't want to reinvent the wheel. But that is exactly the case if you look at LMP's functionality.

?a - LMP-WDM. All agreed that it satisfies a requirement. That's why
it was proposed. In terms of FSMs/messages you should compare with LMP-00 as that is the state this is in. Looked at messages (e.g. config) - some of this hasn't even been defined yet in the doc. So if you proceed with NTIP your number of messages/states will grow as it matures so not a fair comparison. ?a - in terms of co-ordinating with other organisations. LMP is being used in other standards bodies.

Osama - wasn't discussed in Maui.

? - suggest you read the documentation.

?b - Issue with LMP is OXC-OXC is more complex than this. Don't know if will ever implement LMP on DWDM systems.

Kireeti - Would you do NTIP on WDM devices.

?b - No. Don't really care about TCP etc. Bunch of issues, trying to talk to Jonathan etc. ahead of time. Asked for info on NTIP and didn't get in back.

?c - echoing point of importance of simplicity. Need to identify required functions. If only want one part of the functionality do I have to have whole protocol.

Kireeti - this is CCAMP so lets stay common.

Bilel - It's more important to have interoperability between WDM and line system.

?d - NTIP and LMP-WDM have similar requirements. NTIP is fault management. Carriers require protocol from line system to PXC, not PXC to PXC (as is more common case.) Key is fault management. TNE can't handle complexity, so have pragmatic need for protocol like NTIP.

George Swallow - Previous comment is a very short-sighted call.

George Swallow - I've got to do LMP anyhow. The choice for me isn't 46 vs. 14 states. It is 46 vs. 60 states.
Simplicity is to keep all in one protocol. Eve - This has happened several times before. Start with specific things. As we get experience we discover generality. As we go to next technology domain we discover what we did for specific technology wasn't generic and have to go back. Different definitions of fault management. For me it is ID + locate fault so craft can be used to fix it. What is terminated and not terminated becomes important to consider. We're calling it WDM, but is actually much wider than that. Need to make sure that what we do for discovery + defect detection that we know what we're targeting.

Andre - lots of details still to work out. Nothing to do with transport system. IMO the assertions of simplicity are assertions without basis.

Lou - 2 very separate topics / issues. 1. =3D what. 2 =3D how.
Functionality need to walk through what is there in each one and what is needed =96 come up with a "union". On transport issues. Use of TCP - while trivial to make socket call. Implications are not trivial. Yes embedded systems have TCP stacks. But how good are they? How do you deal with partial completion of messages etc. etc. Had to do a whole bunch of extensions to handle that in LDP.

Ross - also wants to stress skepticism regarding simplicity. Protocols never go away. Just end up with more and more over time. Any protocol starts simple and gathers cruft. Way to get simplicity is to use existing protocol that does most of what we want. Throw away bits of LMP you don't need. For most vendors already have TCP and LMP.

Rob Coltun - this is the last time we have 2 proposals. In future if 2 teams can't be reasonable and come up with one then neither will be accepted.

Draft-dubuc-lmp-mib-01.txt (Dubuc)

Addresses provisioning, fault management and performance monitoring.

Recommendation: WG document?
Kireeti: any objections?
none noted.
Recommend that CCAMP accept this as a WG doc.

? - AtoM MIB group is doing similar work. Where should we do the work?

George - generally keep MIBs and protocols together so MIBs are specified correctly.

Kireeti - any objection to keeping this here. No objection noted.

Summary - Kireeti

Sorry, no armwrestling.
Two-octet bandwidth values.
Tunnel trace.
Crankback - wait on hierarchy reqts.
Closed-Loop provisioning - right home? WG? IETF?
CCAMP Requirements - discuss on the list.
- do we want them, and from whom?
Architecture - Eric will integrate the two.

Scott - while it is useful to have WG input on what should be WG item. In the end it is in charter is up to WG chairs, if not then leave to IESG.

CCAMP requirements - need to discuss on list.

Architecture docs. Eric will integrate stuff that was thought to be missing from his document.

?1 - we agreed to have requirements doc and architecture doc.

Kireeti - will discuss on list.

?2 - same point.

Kireeti - 2 proposals. If want to be architecture must integrate with existing one. But now want to split into two. So integrate architecture.

?2 - up to mailing list. Refering specifically to GMPLS. Somewhat in CCAMP. Proposal is to take GMPLS docs - what is framework, what is architecture, are they adequate, to mailing list.

?3 - makes sense to have 2 docs. Need to take to mailing list to figure out what has what. George - easier to figure out whether you have consensus at meetings than on mailing list. Few people on list can make it sound like no consensus. Thinks Eric's doc is good.

George - stuff in Yangyang's document should go into arch doc. Rest of his doc might be basis of a framework.

Eve - we had agreed to look at both docs and merge in arch stuff. And that there would be a separate doc. Look at what is left and figure out if is framework or requirements (or both.)

Kireeti - should we move the specs to last call.
Kireeti - do we have consensus? - looks like we do.
Kireeti - Base signalling to WG last call, about 30 to 2.
Kireeti - LRO needed, go to list.

Kireeti - G.709 is not cooked. For those who think it is done bear in mind that although SONET was very well cooked it took a while to figure out how to integrate it. Can authors of two G.709 proposals come up with one doc? Will be WG doc.

Wait on requirements for restoration/recovery.

Wants one spec for LMP-WDM / NTIP. Get together one more time.
Either we have one, or zero. Can't have two (or three!)

Eve - G.709 is stable/approved. Wans to see reflection of discussion point that SDH/SONET and G.709 might be treated in similar manner. Not mentioned in summary. For LMP-WDM / NTIP need clear summary of what requirement we are meeting. Don't want two protocols. Look at what is needed/required.

Andre - Don't think authors have tried twice to reconcile this. LMP authors want to use LMP to avoid new protocol. NTIP authors for some reason don't want to use LMP as is LMP. Authors at impasse.

Vijay - every new protocol in the network costs us time, costs us training. Don't want to complicate network any more than it is. With WG hat, what does the room think?

Osama - comments before going to room. NTIP solves an urgent problem.

Kireeti - then you should have defined it 2 years ago.

Curtis - requirements were pretty well spelled out in LMP-WDM spec.
So can't make statement that need to come up with them.

Jonathan - significant overlap between LMP and LMP-WDM. Don't want to redo this in new protocol.

Eve - G.709 wasn't considered in the requirements.

Eve - Reminds me of the "great information model" debate. PDH had model. SONET/SDH came along. Generic info model people has based things on PDH and didn't want to change things. But actually there was stuff which wasn't generic. Pay now or pay later!

Dimitri - Please can the G.709 people join our efforts? Integrate these extensions from the Lucent doc so we get a doc which doesn't affect GMPLS and can be suggested as an item for the next meeting. Approach should take into account the need to go further. Step forward not back. Kireeti - take LMP-WDM discussion to the mailing list.

? - sense of room?

Kireeti - need to step back and check we have requirements. Let's get those and then fold it in. What are we measuring in CCAMP? What do we need from OXCs to DWDMs.

Curtis - feel from room on G.709 and is it fully baked? Feel from room on LMP-WDM vs NTIP.

Eve - before we get sense on G.709. How many people have actually read it?

Scott - don't want to get sense on LMP-WDM/NTIP. Got sense on G.709.
Very few thought it was cooked. Only a few know what it is more than a character string. There is not enough mass to vote now

--end of minutes


Tracing Requirements for Generic Tunnels
Signaling for Fast Restoration
Generalized MPLS Recovery
Link Management Protocol
Crankback Routing Extensions for MPLS Signaling
Enhanced LSP Services
Restoration Mechanisms and Signalling in Optical Networks
Inference of Shared Risk Link Groups
Extensions to GMPLS Signaling
Network Transport Interface Protocol (NTIP) for Photonic Cross Connects (PXC)
Lightpath Route (LRO) Extensions to RSVP-TE for OCh connection Setup
Link Management Protocol (LMP) for WDM Transmission Systems
Using 2 Octets for BW Values in OSPF & ISIS Extensions for TE