CCAMP Meeting Agenda
      for the
Dublin July 2008 Meeting

Session I
Time: July 28 (Monday)
      1740-1950 (5:40pm-7:50pm)

Chairs: Adrian Farrel 
        Deborah Brungard 

Note takers: Dan King, Dave McWalter, Wouter Tavernier
-----------------------------------------------------

 0. Administrivia (chairs - 5 mins [5/130])
   Slides
 No comments on the agenda.

 1. WG status, RFCs, drafts, milestones, charter (chairs - 15 mins [20/130])
   Slides
 Charter update, MPLS-TP now in scope. Three new RFCs. MLN now published.
 Dimitri: The MLN extensions is almost done wanted to make sure lsp hierarchy draft
 was aligned.
 Adrian: In order to progress this work further we need an implementation, so
 we are looking for volunteers to write code.
 Adrian: On the milestones, we deleted the milestone for the RSVP-TE MIB extensions draft
 as no one was willing to work on it.
 Lou: On graceful shutdown, this relates to reroute and soft preemption, should revisit
 depending on how mpls discussion goes.

 2. Traffic Engineering Database MIB Module (Tomo Otani - 10 mins [30/130])
   Slides
   Background reading
   - draft-ietf-ccamp-gmpls-ted-mib-04.txt
 Adrian: Good progress. Any questions?
 Lou: Support for unnumbered interfaces?
 Tomo: Yes.
 Lou: Should have a mib reviewer to ensure proper support.
 Adrian: Yes, should be addressed in discussed update.
 

 3. RSVP-TE for Conversion from Permanent to Soft-Permanent LSPs (Daniele Ceccarelli - 10 mins [40/130])
   Slides
   Background reading
   - draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt
 Adrian: Useful set of slides. I was initially worried about error cases, please look at
 the overlap of path tear and resv, maybe simply use one message for all cases.

 4. LMP for Confirming Channel Status
   CANCELLED
   Background reading
   - draft-ietf-ccamp-confirm-data-channel-status-00.txt

 5. Dynamic Provisioning Performance Metrics (Guoying Zhang - 10 mins [50/130])
   Slides
   Background reading
   - draft-ietf-ccamp-lsp-dppm-02.txt
 Lou: There are two discussion points in the document, not in the slides. First was
 processing time at end nodes, second was if should test data plane. Second is important
 especially. And need to test control plane and data plane to provide total metrics.
 GZ: Last time, we had the same question, is it minor?
 Lou: This may be minor in some implementations, but if I build a GMPLS network I want to test both.
 GZ: We separately measure dataplane and control plane. The control plane test (operator)
 can be run via NMS. Operator can measure performance. 
 Lou: In order to have complete performance statistics you need both. Fine for operator
 to decide what to test. 
 GZ: You recommend then data plane is tested.
 Dimitri: How are you going to validate the document? Are you using one test case or more
 representative cases. You may require a certain number of implementations and tests to
 create. 
 GZ: Working on commercial testing platforms. 
 Igor: If you have control plane that is separated from data plane, how do you get
 measurement?
 GZ: That might be a problem. If it is completely separated, and control plane is not
 distributed, it would be difficult.
 Lou: Two different cases, one is off board, this is something that operators should
 test.
 Other case is if you are trying to evaluate vendor’s equipment or software stack. 
 Adrian: More discussion is needed. 
 GZ: Both questions related to data plane and control plane synch.
 Adrian: Approx 6 people read the draft. Should this be shown to MPLS WG? (Loa agrees).

 6. VCAT (Greg Bernstein - 10 mins [60/130])
   Slides
   Background reading
   - draft-ietf-ccamp-gmpls-vcat-lcas-05.txt
 Greg: Anything on the communication to OIF?
 Adrian: Didn't hear anything.

 7. Unified Mechanisms for GMPLS Calls (Lou Berger - 10 mins [70/130]
   Slides
 Lou: Do we need a document? 
 Adrian: For me the question is one of the big pieces of work may be held up,
 useful to have base document as reference so MLN document is not held up. 
 Lou: I do not have a view on MLN. If you say break it out, that’s cool. 
 Dimitri: I think this is useful. I agree. 
 Lou: We are not proposing anything new, this is derivative work.
 Adrian has proposed breaking out.
 Dimitri: I do not think it’s needed. 
 Adrian: if the MLN document will reach RFC before VCAT, fine. If we are sure MLN
 extensions will go through last call without issue. 
 Lou: BCP by next meeting or wait?
 Adrian: Wait until we need it.

 8. Provision of Ethernet Services (Lou Berger - 5 mins [75/130])
   Slides
   Background reading
   - draft-ietf-ccamp-gmpls-ether-svcs-01.txt
 Lou: If we are breaking out, can do these two pieces as generic?
 Adrian: Do you really see these as generic? 	
 Lou: Yes, we would have used them in a number of implementations. 
 Don: Can you give me an example of how this would work?
 Lou: What you’re asking for is in the next document.
 Don: It does not tell the SP what to carry. EVP or EPL. I see a lot of unnecessary detail. 
 Lou: There are a lot of different MEF specifics, we are supporting those. 
 Don: Send a liaison to MEF and spell out how the dialogue would work between customers and SPs. 
 Lou: We have zero semantics. 
 Don: Section 5 is too specific. 
 Lou: We are not saying this work should be spread out to UNI.
 Lou: We are doing GMPLS, Ethernet specific or generalized, across common control plane.   
 Don: I think this should be split. I am concerned that it could be technology specific. 
 Lou: Not extending anything on UNI side. 
 Enrique: Have a concern with this.
 LB: Those who are concerned with UNI should look at MEF document and see if there is
 enough or not enough. We should send a liaison.
 Adrian: We did, sent after the last IETF. 
 Lou: Is anyone able to verify if it was received?
 Enrique: Have not seen it show up at MEF. 
 Adrian: we will chase down the liaison. 
 Loa: Bit concerned if this a liaison, it should be via IESG. 	
 Adrian: I think the WG has the right to a communication (without liaison relationship). 
 Loa: Discuss later.
 Lou: We have been trying to be involved with the MEF.
 Eric: Checking past email. There was liaison on April 28th on the MEF mailing list. 
 Lou: Do we split it out?
 Adrian: Works for me.

 9. Support for the MEF UNI (Lou Berger - 5 mins [80/130])
   Slides
   Background reading
   - draft-ietf-ccamp-gmpls-mef-uni-00.txt
 Consistency update planned. No comments.

10. Ethernet Traffic Parameters (Dimitri - 10 mins [90/130])
   Slides
   Background reading
   - draft-ietf-ccamp-ethernet-traffic-parameters-05.txt
 Dimitri: Any comments on 05 versions? Do the Chairs have a preference on moving drafts
forward? Maybe RFC?
 Adrian: I am inclined to agree. MEF have to see it and agree it. 
 Dimitri: MEF should not complain.
 Adrian: quite right, my only concern is that one application is the MEF UNI
 and they say there is something you need to do etc. 
 Dimitri: Ok, thanks.

11. Control and Configuration of Ethernet OAM (Attila - 10 mins [100/130])
   Slides
   Background reading
   - draft-takacs-ccamp-rsvp-te-eth-oam-ext-02.txt
 Nurit: First I would like to say this should be generalized. Look into MPLS-TP
 requirements. 
 Dimitri: Just one point, concerning the RSVP-TE protocol specifics. Protocol arch
 issue. We can make use of RFC 4420, we did not say how to define object.
 I am asking in terms of protocol, is this the best place to put this information. 
 Lou: Two points, flexibility for future is good. Echoing Dimitri's point, if we
 decided to do it this way.
 Attila: Does not matter where we do it, if we get the information.

12. Revertive Protection Switching (Attila - 10 mins [110/130])
   Slides
   Background reading
   - draft-takacs-ccamp-revertive-ps-01.txt
 Howard: Can I ask the WG chairs on relation with MPLS-TP. 
 Adrian: It may be a little early for MPLS-TP solutions. The design team
 is working through requirements and framework. When MPLS-TP Control Plane extensions
 needed, it will be brought here.  
 Loa: If the control plane extension relates to RSVP-TE, brought here.
 LDP will stay in MPLS WG.
 Adrian: Attila, when you consider the three alternative solutions, please
 don't pick the one that puts the WRT into the reserved flags bits. We need
 to conserve flag bits for future use.

13. Collection of LSP Performance Evidence (Marco Anisetti - 10 mins [120/130])
   Slides
   Background reading
   - draft-ali-ccamp-rsvp-te-based-evidence-collection-00.txt
 Igor: Interesting work. Couple questions, 1. Evidence collection, node by node?
 Marco: Yes
 Igor: What happened if path msg lost, with previous measurement. 
 Marco: Needs to be restarted. 
 Igor: Timing?
 Marco: We need to deal with timing to avoid delayed results. 
 Igor: What happens if you start multiple collections, how to associate multiple
 measurements.
 Marco: We have an identifier.
 (?): Goal is multi-vendor interop? Evidence collection is way too broad, I have issues. 
 Marco: WSON signalling is tied into it, for none blocking.
 (?): Not agreed in ITU. 
 Adrian: Yes, nothing will be done here that defines “What is Evidence” or how to encode
 it or how to measure it. This will come from the ITU. 
 (?): Give us an example of what you would like to collect; I think the TLV should be more
 general. 
 Eve: I have a few questions, which parameters should be measurable. What’s the usage and
 purpose. Clearly anything related to impairments and if the path has integrity, then
 its related to WSON. What did you mean by blocking?
 Marco: Blocking = no other collection can be done at same time.
 Eve: Blocking means something else for me. Wavelength blocking etc.
 Adrian: That tends to suggest that work needs to be done to harmonise terminology. 
 Eve: Should harmonize problem statement and work with WSON. 
 (?): Scope II – first bullet
 Adrian: bad choice of words, choice of language needs sorting. 
 Greg: Need to collect info along the path to perform approving function et al.
 Multiple impairment drafts. We started without impairments. Need to deal with
 terminology. Encourage to bring this within WSON framework.
 Don: I think we need new liaison to ITU. Last one was not clear, conflicting. Need to be
 clear that its not a slam dunk that the performance can be measured by all equipment.
 Typically this is done by measurement equipment. Design rules of vendor x and SP and
 how conservative or aggressive, are specific. This is an over simplification, suggest
 we send a very specific liaison to ITU. Second point that this is signaling between OXCs
 only and not OXCs and routers. 
 Adrian: You made some good points. All we done so far with QUstion 6 is say hey we are 
 starting to sniff around this area. This is not requesting WG status.
 We are just exploring the area. It would be premature to tell anyone yet.

======================

Session II
Time: July 31 (Thursday)
      1300-1500 (1PM-3PM)
-------------------------------------

14. Administrivia (chairs - 5 mins [5/120])
   Slides
 No comments on the agenda.

15. ITU-T and OIF progress report (Jonathan Sadler - 10 mins [15/120])
   Slides
 Jonathan: GMPLS to OIF UNI/E-NNI interworking spec is approved. Gave details.
 Note that this is limited to signaling interworking, no routing. Also no protection,
 may be extended to protection. E-NNI 2.0 specification is in progress. Attempts
 will be made not to diverge too much from ccamp's work. Mentioned specific issues
 with e2e for OIF's sender template format. No OIF liaisons sent or received.
 Nothing to report from ITU-T SG15. No ASON-related activity in this period.
 Deborah: Presented incoming communications needing action. Requested help
 preparing responses.

16. ASON Routing Requirements
    - History and Design Team Charter (chairs - 5 mins [20/130])
      Slides
    - Design Team Progress Report (Jonathan Sadler - 10 mins [30/130])
      Slides
 Adrian: Explained how existing IETF documents characterize ASON requirements
 and move towards addressing them. IETF ASON routing design teams had been formed,
 including key individuals from the ITU-T. This has gone quite well, but 'no cigar",
 as there was a feeling from the ITU-T that it was not being properly listened to.
 Disconnect was that the IETF felt all issues were out-of-scope, whereas the
 ITU-T felt that they were not being heard. A 'bar BoF' in Philadelphia included
 some ITU folks that had travelled specially to attend, and resulted in forming
 a new design team. Adrian talked through the charter. The idea was to respin 4258
 with traceability back to the ITU-T recommendations. No draft available yet,
 Jon will give status.
 Jonathan: Mailing list is ason-routing@ietf.org. Of 32 ITU comments, the
 draft just posted to the list resolves 28 of them. Changes to resolve the
 remaining 4 comments will be posted next week. Responses from ITU-T should be
 available before Minneapolis if can liaison in time for their interim meeting
 in September.
 Adrian: Good news, looking forward to next draft. Work on OSPF extensions draft
 was suspended pending this work. We might now progress this as a solution to the
 existing 4258, in the knowledge that changes to 4258 might require changes to
 this OSPF draft.
 Jonathan: Reasonable.

17. Ethernet

  a. Provider Requirements for GMPLS Control of Ethernet (Tomo Otani - 5 mins [35/120])
     Slides
     Background reading
     - draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.txt
 Tomo: Presented on behalf of Wataru. Explained draft status. Next steps are to add
 several requirements. Wataru has moved to NTT communications, so a new editor will
 take over.
 Adrian: Lucky to have three service providers working on this, if any other
 SPs have an interest, the authors would like to hear from you.
 Deborah: Any comments?  (none)

  b. GMPLS Ethernet Architecture (Lou Berger - 10 mins [45/120])
     Slides
     Background reading
     - draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
 Lou: Will change to say SHOULD NOT use L2SC. There is another update also. Any
 comments to the list, please.
 Adrian: Should this document cover with traceability all the requirements in
 the requirements draft? Should this document cover all the requirements?
 Lou: Yes.
 Adrian: We just heard more requirements are coming, so this is a moving
 target.
 Lou: We understand.  We can't lock this down until the requirements stop
 moving. Or until the group decides to stop and put a stake in the ground.

  c. GMPLS Protocol Extensions for PBB-TE (Dave Allan - 10 mins [55/120]
     Slides
     Background reading
     - draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt
 Presented recent changes to the draft. 802.1Qay is now up to draft v3.5,
 so expect sponsor ballot (tecnical completeness) by early 2009.
 Currently there are decisions to make about protection switching and p2mp.
 Appendix A will be removed from this draft (purely informational). Material
 on PBB-TE regions will be removed, as this does not related to GMPLS
 regions and is therefore confusing. Changes are also required to add an
 I-SID TLV, align with OAM, and continue to track changes to
 802.1Qay. Questions?
 Adrian: Are the authors of this draft happy with the traffic parameters draft
 which we discussed in the first session?
 Dave: I can't speak for all authors.
 Adrian: Are you happy?
 Dave: I believe I am.

18. WSON

  a. WSON Framework (Greg Bernstein - 5 mins [60/120])
     Slides
     Background reading
     - draft-ietf-ccamp-wavelength-switched-framework-00.txt
 Greg: Credited many authors/contributors. Hoped to bring more carriers on
 board in future. Emphasized that impairments are not included in this
 document. They are important but they are controversial. Emphasized that
 dataplanes are not being defined here. ITU provides the dataplanes for
 this work. Supplement 39 and supplement 43 as being full of relevant
 information, especially for impairments. Next steps are to relate
 this to G.872 architecture and add usage scenarios. Gave an optical switching
 example. Explained wavelength converter issues.'Lightpath' is a non-specific term,
 not clear how it relates to OCh channels. G.872 vs G.709 seem confusing on this
 point. Help is solicited from ITU-T on this point. If anyone has feedback,
 please help out with text. Questions?
 Deborah: You mentioned about need for help on OCh?
 Greg: I'd love to turn this over to ITU folks.
 Macolm Betts: Next plenary is December. In the mean time informal communication
 would be fine, it would be good to have then a liaison into the December
 meeting.
 Deborah: As individuals, we could put an informal question on the ITU-T
 exploder and the ccamp exploder. If we just have this one question.
 Greg: We have three things.
 Deborah: Are you on the ITU-T exploder?
 Greg: No.
 Deborah: We're discuss later the best approach.

  b. WSON Information Model (Greg Bernstein - 5 mins [65/120])
     Slides
     Background reading
     - draft-bernstein-ccamp-wson-info-03.txt
 Greg: Credited many authors/contributors. Explained issues with information
 crowding the routing protocol, need to be clear what information is required.
 An information model is required specifically for path computation
 (RWA problem specifically). Actual TLV encoding is now moved out to separate
 documents. All IGP specifics are now deferred until decisions are made on
 what information is needed. Described the problem of modelling asymmetric
 connectivity within ROADMs. Explained that ROADMs can have design differences,
 but are similar enough to fit into a single 'connectivity matrix'
 information model with 'port wavelength constraints'. Acreo have noted that
 the same model applies to Waveband ROADM devices, only the constraints look a
 little different. High-order ROADMs are being developed (high-order meaning
 'more than two ports'). Again the same matrix and constraints can be applied.
 Hybrid ROADMs (where some wavelengths are passed through without seeing
 a switching matrix) create difficulties, but the model can be adapted
 by adding 'fixed blocks'. Next steps: Modeling wavelength coverter pools,
 finalize model. More feedback on switch model is desired, in particular
 from hardware folks. We have 6 venodrs already but more would be good.
 Deborah: How many people have read the document? approx 15 hands.
 Deborah: How many people would like this to be a WG document? 10-15 hands.
 Deborah: Anyone against? No hands.
 Deborah: Will take it to the list.

  c. Data Encoding For WSON Information (Greg Bernstein - 5 mins [70/120])
     Slides
     Background reading
     - draft-bernstein-ccamp-wson-encode-00.txt
 Greg: Explained that it is simple to represent connectivity using many nodes
 and links to represent the internal connectivity. However, routing
 algorithms scale depending on the number of nodes and links present.
 The connectivity is rather sparse, so you might think a smaller number
 of nodes and links might be possible. Greg presented on a way to model
 ROADM internal connectivity using just two nodes and one internal link.
 This is 'as terse as you can get', and captures the complete connectivity
 of this device. This is a hard problem for generic graphs, but ROADMs are
 simpler than that, even higher order ROADMs. Based on this model,
 connectivity matrix is potentially a node attribute rather than a link
 attribute. Next steps are to consider wavelength converter pools, decide
 switch encoding, resolve relationship with encodings for existing GMPLS
 information.
 Adrian: Up-front you said that your objectives were to optimize both for
 transmission and computation. We must make sure we provide enough
 information for computation, and make sure it is not an excessive
 burden, but we don't need to completely optimize the transmission
 method.
 Greg: It's possible to reverse the mapping process.
 Adrian: As long as you're optimizing the transmission method with an eye to
 utility.
 Greg: This is a known matrix compression technique.
 Adrian: Okay, cool. The next question is whether to adopt it as a WG
 document. There is some relationship to Dan's draft. Need to think about the
 amount of information transmitted, especially if a node attribute.
 Deborah: Expect at least another respin [before adoption as a WG document]?
 Greg: Interested in feedback on the encoding proposal.

  d. GMPLS Signaling for WSON (Daniel King - 10 mins [80/120])
     Slides
     Background reading
     - draft-bernstein-ccamp-wson-signaling-02.txt
 Dan: Revelant WSON work is listed in the slides. Should have included
 Giovanni's draft as well. Proposes simple GMPLS extensions for control of WSON
 networks, building on G.709. In this version, requirements and solutions sections
 are separated, as requested by the WG. WSON signal characterization and
 bi-directional distributed wavelength requirement are outstanding problems.
 These might move to other documents. Signal characterization is about transmitting
 information to nodes on the path.  Proposed solution is to define lightpath
 characteristics as traffic parameters (or rather, to use the parameters
 defined in G.959.1). Bidirectional wavelength assignement is solved by
 incorporating the label-set method from draft-xu. Draft-xu has been merged into the
 WSON signaling draft. Presented research on blocking probabilities that was
 also discussed in the PCE meeting this morning. The research will be generally
 available this month (August), if you'd like to see it mail the authors.
 Optional features may affect algorithm choices. Work is still under discussion,
 would be interested to hear opinions from the working group, especially on
 decision to include/exclude RWA. Also would like to finalize signal
 characterization. RFC 3743 is now referenced in terms of the functional
 requirements being satisfied. Feedback is solicited, would be interest in
 hearing from vendors who might like too discuss or implement the mechanism.
 Lou: I buy the idea of bidirectional lightpaths, I don't buy the idea of
 bidirectional lightpaths using different wavelengths in different
 directions. Doubles the probability of failures. Every operator
 I've ever talked to goes through the roof if you mention this. Why not always
 require bidirectional assignment?
 Dan: I get paid by the word.
 Lou: Make it a BCP that assignment should be bidirectional?
 Dan: It's a good point.
 Lou: Is the assignment method per LSP or per network? Anything that relates to
 assignment should be carried in the TSPEC. Things you call signaling
 extensions in fact are TSPEC
 Snigdho: It's confusing when you say 'WSON signal'? Is it a dataplane
 signal? Should it be a G709 signal?
 Dan: Yes, it's building on 709.
 Snigdho: 709 signals are already defined in RFC 4328, you're making
 extensions here?
 Dan: Yes, bandwidth masking
 Snigdho: Should read RFC 4328 and check we're not duplicating work.
 Dan: Ok.
 Snigdho: Bidirectional wavelength assignment is a generic requirement,
 doesn't need to be specific to WSON? We shouldn't include this as specific
 for WSON.
 Adrian: Lou was saying to make this signaling extension go away because it's
 never required for WSON. We can't generalize from WSON and still make it go away.
 Lou: It's a subtle distinction, it's a logical label allocation mechanism that
 is being defined here.
 Eve: We should be careful. WSON is a great acronym, which highlights what
 we're focused on, but the architecture is multi-layered (ODUs and OChs)
 so things can quickly become confusing. We should align this work with
 the terminology in RFC 4328 which does talk about ODU and OCh. Then in
 that context we can decide what are extensions and what is new enough to
 need a new draft.
 Don: Support previous comments. This is not ready for WG status. In
 particular should remove the modulation format as this is not selectable
 and should not be signaled.
 Dirk: Disagreed with Don, suggest it be left in.
 Don: Could be signaled, but it's not a selectable parameter. Note also the
 diversity of FECs out there. Could be learned by NMS signaling as well.
 Would object strongly to modulation format being signaled.
 Malcolm Betts: Need to step back and look at the architecture. Previously,
 what we've connected and what we've switched are the same.
 Here we are just switching the optical lightpath. The OADM just knows about
 the bandwidth and some characteristics of the links. The transmitter and the
 reciever have additonal characteristics that aren't properties of the path.
 Maybe not specific to this draft, but a serious comment. Good to phrase this
 as a question going into Q12 and Q14. Not sure whether we want to ask them
 to review the drafts.
 Lou: Going back to the nit-level, most if not all of the discussed changes
 should be made in the TSPEC/FLOWSPEC not other RSVP objects.
 Dirk: On allocation schemes for 10G and 40G wavelengths,
 there are relationships between FECs and specific wavelengths in
 OEO devices, and this can affect allocation schemes.
 Don: Perhaps there is confusion about what modulation format means (NRZ, QPSK,
 dual polarized or whatever). Happy to signal whether it's 10G or 40G.
 Deborah cut the queue.  Encouraged review.  Agreed to formulate a general
 question to Q14.

  e. G.694 Lambda Labels (Tomo Otani - 10 mins [90/120])
     Slides
     Background reading
     - draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
 Tomo: Updates to draft include change to title and unified label format for
 DWDM and CWDM. Showed the proposed label format. Shows computations, explained
 the lambda range and granularity are sufficient.
 Dan Li: Asked questions about the 16 bit signed number on the format slide.
 Deborah encouraged discussion on the list.

  f. Evaluation of Carrying WSON Information in IGPs (Dan Li - 10 mins [100/120])
     Slides
     Background reading
     - draft-li-ccamp-wson-igp-eval-01.txt
 Dan: This draft builds on other drafts already presented. This draft examines
 what would happen if an IGP was used to distribute wavelength information.
 Explained the point of using an IGP to distribute information, and
 possible pitfalls for the performance of the IGP. Showed detailed computations
 of IGP overheads for various encodings. Concluded that dynamic and static data
 are not issues, but that data classified as 'semi-static' is quite large.
 There are methods avaialble to reduce the size of the 'semi-static' data.
 Also it might be sufficiently stable to consider it static.
 Dave Ward: I was confused about the structure of the draft. It has
 requirements, information on one encoding, and then occupancy
 for that encoding for a single LSA, not a whole network analysis.
 It didn't talk about IGP performance or computational overheads.
 Analysis on the type of graphs is also critical. I also wonder if the
 document it just premature. Section 4 is about what to do if information is
 unavailable. The suggested RSVP behaviour here has a high signaling overhead.
 There are also open questions, interactions with NMS. It's not a failing here
 to have open questions, perhaps it's a failing of the framework document.
 But given the open questions this work might be premature.
 Adrian: In fact the draft is very timely because it gave rise your comments
 and the good feedback into the architecture it contains.
 Dave: Ok.
 Deborah: My feelings are the same.  This is not a WG document, but it should
 stay there so we can think about it.
 Dan: Ok.
 Loa: I haven't read the draft. This is the type of work we need to encourage
 in the current situation. Highly applicable to the working group.

  g. GMPLS WDM Switching (Kang Zhihong - 10 mins [110/120])
     Slides
     Background reading
     - draft-kang-ccamp-wdm-switch-info-00.txt
 Kang: Draft contains an information model for path computation. Link layer and
 optical channel layer constraint (wavelength continuity constraint) displayed.
 Also displayed 'reachable tributary side constraints'. Suggested format for
 'WDM link extension information" including characteristics of input and output
 lambdas or lambda groups. Feedback requested. Will continue to extend switch
 capability info model. For example, tunable laser information.
 Deborah: Sorry, we're limited on time. One question.
 Dave Ward: The way the data is organized is fundamentally different to how
 Dijkstra graphs are structured within OSPF for route computation. A further
 explanation of how the graph is structured is required in order to make it
 clear whether this representation can work at all.
 Kang: Yes, we're working on additional TLV format details.
 Deborah encouraged discussion on the list.

  h. Optical Impairment Signaling (Giovanni Martinelli - 10 mins [120/120])
     Slides
     Background reading
     - draft-martinelli-ccamp-optical-imp-signaling-01.txt
 Giovanni: Will present quickly, not much time. Gave an example of a networks
 in which only one path is feasible due to impairments. A decision has been
 taken to focus on per-channel *linear* parameters of which a subset can be
 chosen. Note RFC 4054 provides that optical effects should be considered.
 Proposal is based on one TLV per signaled wavelengths. Each hop can
 prune or update wavelength information. Presented changes from -00 to -01 draft.
 Deborah: We're out of time, any questions to the list.  Have a good summer,
 see you in Minneapolis.