CCAMP Meeting Minutes
          for the
     73rd IETF Meeting
 Minneapolis November 2008


First Session
  Monday: 1740-1930 (5.40pm - 7.30pm) Afternoon Session III

Chairs: Adrian Farrel 
        Deborah Brungard 

Note takers: Eric Gray (I), Lyndon Ong (I and II), Don Fedyk (II)

-------------------------------------

 0. Administrivia
   (chairs - 5 mins [5/110])
   Slides

Adrian welcomed everyone to the CCAMP WG meeting, discussed the agenda and
noted the "NOTE-WELL".

The Agenda remained unbashed.

 1. WG status, RFCs, drafts, milestones, charter
   (chairs - 15 mins [20/110])
   Slides
2 new (informational) RFCs, 3 drafts recently added to the RFC Editor's queue.

There are a couple of drafts the WG should be aware of: there is an individual
submission analysis draft that is in IETF last call, and Adrian has submitted
another version of a draft on BNF that impacts on CCAMP related signaling.

There are 4 drafts that have completed WG last call and are in various
stages of progression through modification and IESG review.

There are also 5 drafts that may be ready for WG Last Call.

Adrian talked about drafts that would - and would not - be discussed on
the agenda as well as going over the milestone status relative to key drafts,
and reminded people of the MPLS-TP meeting to be held later.

Adrian asked Greg Bernstein for status on VCAT.
Greg said that everything is stable and some code points just need to be
finalized.  Adrian said that we will should do a quick pass on that.

Also Don Fedyk offered some updates on PBB-TE in IEEE 802.1 (relating to
the work on CCAMP control of PBB-TE).

Adrian also mentioned that will be discussion on Ethernet-related work being
done by Attila on using GMPLS to set up OAM.

By March, 2009, we might be ready to take a look at potential new work for
the CCAMP charter.

See slides for further details on the above.

Lou Berger asked a question if the VCAT work has changed the Call_attributes
from previous. Greg said it will be done.

Julien asked a question if the Ethernet Framework draft should wait on this
draft before going for WG Last Call.

Adrian responded he did not think the framework draft was blocked by this.

Julian asked if need an interim meeting. Adrian responded the co-chairs had
discussed, didn't think a need.

Kireeti Kompella asked when and where the interim meeting would be.

Adrian said that -  if there was sufficient interest - there's currently plans to
secure facilities in Malta for any working groups needing to hold an interim
meeting in January which CCAMP could take advantage of. However, there
is no constraint prohibiting the WG from holding an interim anywhere else -
provided there is sufficient interest in doing so.

Adrian polled the room to see how much interest there was among those
attending the current meeting.  There was not much interest.

Nurit Sprecher asked what would be done at such a meeting if it were to
happen.

Adrian said that would depend on what work needed to be done.

 2. ITU-T and OIF progress report
   (Lyndon Ong - 10 mins [30/110])
   Slides
Lyndon Ong presented status on ITU-T and OIF meetings.

ITU-T SG-15 Questions 12 and 14 met in September.  Progressed work on
ASON and there is also work on WSON.  Two liaisons, touching on VCAT
(and LCAT) and on WSON,
were provided out of that meeting.  One point of potential controversy, in the
liaison on WSON work ongoing in ITU-T, was in their request for CCAMP to
not do work yet on WSON optical impairment.

There was a discussion about the apparent restriction on optical impairment
work. One person felt that the wording was a little bit too strong, given that
there are aspects of this work that appear to be more related to routing, path
selection, etc. Lyndon said that because he was not actually at the meeting,
he is not in a position to elaborate on this issue and asked if there was any
one who was at the meeting who might care to comment.  Other comments
were made as well, but it was not clear that there was any resolution of the
concern, or further clarification of the intent - other that to say that the ITU-T
and CCAMP relationship is still a work in progress at this point in this area.

From the OIF, Lyndon reported on several work items in progress there and
indicated that there was an intention to send a liaison (on carrier requirements
for multi-domain restoration) but that the liaison is not complete and has not
therefore been sent to CCAMP yet.

See slides for further details.

Adrian asked if Lyndon had any sort of feel for when the liaison should be
coming to CCAMP and Lyndon responded that hopefully CCAMP should
see it in December.

 3. Protocol extensions for conversion between management and control planes
   (Daniele Ceccarelli or Diego Caviglia - 10 mins [40/110])
   Slides
   Background reading
   - draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt
Daniele presented this draft.

Talked about two different drafts:
    draft-ietf-ccamp-pc-and-sc-reqs-06 (Requirements draft)
    draft-ietf-ccamp-pc-spc-rsvpte-ext-02 (Solutions draft)

See slides for further details.

Adrian asked how many people had read the latest version of the drafts.
About 15 hands were raised.

He then asked if there was anyone who would object to last call on the
draft. There were no objections.

He then said that the question should then go to the list.

 4. Dynamically signaled hierarchical LSPs
   (Adrian Farrel - 10 mins [50/110])
   Slides
   Background reading
   - draft-ietf-ccamp-lsp-hierarchy-bis-05.txt
Adrian presented, giving a history and the background of
the work.

See slides for further details.

George Swallow had some issues with the use of the term forwarding
adjacencies in this work (as opposed to IGP advertised TE link).

Adrian said he would be happy to word-smith this with George.  He also
indicated that there was some history behind the usage in this draft.

Jonathan Saddler pointed out that in OIF it was viewed the information exchanged
here is a lot like the information exchanged in neighbor discovery.

Adrian asked if he could get a pointer to this work off-line.

 5. Framework and Requirements for Composite Transport Group (CTG)
   (Ning So - 10 mins [60/110])
   Slides
   Background reading
   - draft-so-yong-mpls-ctg-framework-requirement-00.txt
Ning So presented.

Motivation is the challenges and issues in deploying parallel links in
their network.  The problems are associated with unequal link usage
and can be exacerbated by having multiple routing instances in the
same device.

What they are seeing is poor link utilization.  This is especially true
if they do not use routing and signaling protocols with TE information.

His proposal is to advertise traffic load for composite links.

This is an initial draft and they are seeking feedback on the work and
potential co-authors and contributors to work on solutions.  They are
also interested in direction as to what WGs this work should be done
in.  Currently this work is being presented FYI to CCAMP, PWE3 and
MPLS.

Dimitri asked what scenarios have been considered in the solution space:
using dynamic signaling or using pre-configured solutions?

Ning said that he prefers to take baby steps initially and pre-configured
solutions are the easier ones to work with.

Howard Green asked if they could make the requirements clearer.

Ning said he would be happy to get input on how to make the CTG
requirements clearer.

 6. RSVP-TE extensions for path key support
   (Adrian - 10 mins [70/110])
   Slides
   Background reading
   - draft-ietf-ccamp-path-key-ero-02.txt
Adrian presented.  This is PCE WG work in
progress being presented in CCAMP because it is related to CCAMP
control/signaling.  It talks about the use of a key to represent a path
abstraction for use in an ERO.

What we don't have yet is a means to carry this key in an ERO.

Simple needs: code point and small description of the contents of the
sub-object.

See slides for more details.

Lou: Asked why the key should be only a 16-bit value.
This led to a discussion of the scope and life-time of the key.  Lou seemed to
feel that 16 bits may be not enough.

Adrian said he would consider it and take it to the PCE list

 7. RSVP-TE Recovery Signaling Fixes
   (Nic Neate - 15 mins [85/110])
   Slides
   Background reading
   - draft-rhodes-ccamp-rsvp-recovery-fix-00.txt
   - draft-rhodes-rsvp-recovery-signaling-00.txt

Nic presented.

Lou, Dimitri, and others commented that this work is based on
incorrect assumptions and interpretations of CCAMP related
drafts/RFCs.

Nurit: This will be solved in MPLS-TP.
Lou: This is already supported.

Other issue was related to OIF interdomain LSPs, if the Session IDs
are changed at domain boundaries and the need to support protection
across domains.
Adrian: Then the LSP is not a single LSP but multiple LSPs. Protection
must be closed at domain boundaries.
Deborah: Is that an ENNI then?
Nic: Yes.
Deborah: G.8080 does not support a specific protection parameter across
domains (on the ENNI). OIF should talk with Q12 on this and architecture.
Adrian: Yes, this is OIF specific, not a GMPLS issue.
Lou: Even if OIF changes addresses at the boundaries, should work.
If you don't map consistently, then it will not work.

 8. Call Parameter Negotiation with GMPLS Calls
   (Fatai (Fighter) Zhang - 10 mins [95/110])
   Slides
   Background reading
   - draft-xia-ccamp-gmpls-call-application-00.txt

Fatai presented the slides.

9. Framework for control and configuration of OAM and Ethernet OAM specifics
   (Attila Takacs - 10 mins [105/110])
   Slides
   Background reading
   - draft-takacs-ccamp-oam-configuration-fwk-01.txt
   - draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt

Attila talked about progress on these two drafts.  These drafts address
the issue of performing configuration of OAM entities via the CCAMP
signaling protocol.

The framework talks about the motivations and considerations, and the
mechanisms that apply in the general case.

The second draft talks about the proposed approach as it applies to
ethernet OAM case.

The slides show both the framework and how it is applied for Ethernet.

Nitin: Currently use LSP-ping. Why can't use?
Attila: using RSVP instead.
Lou: are you trying to define a generic mechanism, first use will be
Ethernet?
Attila: Yes, we have already broken out the Ethernet specific part.
Loa: one nit, should say for MPLS-TP, it is only conditional that an
MPLS-TP operator will want to use a control plane.

Adrian said that he was hearing a lot of input that this seemed like a
good idea and then asked if there was anyone who feels it is a bad
idea.  One hand came up.

Lou: adding to what Loa had said earlier that this proposal will
probably address the concerns that many have about having a two
step OAM setup. If MPLS-TP uses a control plane, it would need
a mechanism for OAM.

In response to Loa's comment, Adrian said that he thinks we ought
to make it clear that GMPLS should be used only in network where
GMPLS is being used.

See presentation for details.

Adrian: we will take these drafts to the mailing list to determine
if there is general acceptance that these drafts should become
WG drafts.

10. Signaling WTR and HROFF timers for reversion
   (Attila Takacs - 5 mins [110/110])
   Slides
   Background reading
   - draft-takacs-ccamp-revertive-ps-02.txt

Attila presented the progress on this draft.

The presentation talks about background, motivation and objectives
of the work.  It also talks about the addition of two fields to the
protection object (HOFF [for Hold-Off] and WTR [for wait to restore]).

Lou: where does this parameter range information come from
(ITU?) and commented that the ranges (WTR [5 - 12 minutes in one
minute intervals] and HOFF [0-10 seconds in 100 msec intervals])
seem pretty narrow.  He asked that the authors check very carefully
to ensure that this range is big enough for the general case.  He has
seen different values used in actual equipment.
Attila: thinks they are ITU values.
Lou: should check.
George Swallow: I don't see any reason why we can't use larger values.
Adrian: this being a new C-Type, it may
be increased in size to meet whatever is needed.

Adrian then closed the meeting until Wednesday afternoon.

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

Second Session
  Wednesday: 0900-1015 (9am - 10.15am) Morning Session I
  ** Note ** We intend to run through the 15 minute break **
  Wednesday: 1030-1130 (10.30am - 11.30am) Morning Session II

-------------------------------------

11. Administrivia
   (chairs - 5 mins [5/150])
   Slides

12. Ethernet drafts
   (Lou Berger - 10 mins [15/150])
   Slides
   Background reading
   - draft-ietf-ccamp-gmpls-mef-uni-01.txt
   - draft-ietf-ccamp-gmpls-ether-svcs-02.txt
   - draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt

Lou presented. Drafts are now aligned and stable.
Adrian: is the reference to MLN is normative?
Lou: could still last call and then publishing will be held for the MLN.
If think MLN will be held up, could split out the Call_attributes and do as
seperate draft.
Adrian: I think MLN will progress soon.

13. Report on GELS interop tests
   (Attila Takacs - 10 mins [25/150])
   Slides
   Background reading
   - draft-takacs-ccamp-gels-tests-00.txt

Attila presented. GELs was tested at ISOCORE with 3 independent implementations.
LSP establishment and recovery were tested successfully. Some interpretation issues.
CBP is an internal port. May need to provide what CBPs are available.
Don Fedyk: Agree, CBP is needed in the ERO. Text needs to added to the draft.

14. Progress with Working Group I-Ds for RWA WSON
   (Young Lee - 15 mins [40/150])
   Slides - Framework
   Slides - Info Model
   Background reading
   - draft-ietf-ccamp-wavelength-switched-framework-01.txt
   - draft-ietf-ccamp-rwa-info-01.txt

Young presented. On the framework, references ITU-T on data plane, discussions have
begun in ITU also. Now did separate sections for different alternatives. On
informational model, noted this is a high level path computation model, not
management model. Updated the wavelength converter section.
Zafar: on encoding, who defines encoding? Us or ITU?
Adrian: propose to change the title to include RWA to clarify as Zafar's question
has to do with optical impairments, which are not in these first two drafts.

15. Protocol work for RWA WSON
   (Greg Bernstein - 10 mins [50/150])
   Slides - Encoding
   Slides - Signalling
   Background reading
   - draft-bernstein-ccamp-wson-encode-01.txt
   - draft-bernstein-ccamp-wson-signaling-03.txt

Greg presented the encoding draft. Main change is incorporation of RBNF.
Malcolm: would like to see the draft clarified that it does not try to standardize
a path computation algorithm, just information used.
Adrian: agree. Also should run past Q6 in ITU to verify the switch model is going
to be sufficient.
Greg: can ask the Q12 rap (Malcolm) to help?
Malcolm: yes.
Adrian: we don't want to liaison as this is not a WG draft yet.
Malcolm: we can do informally.
Don O'conner: Support Malcolm, also suggest looking at G.698 which are ROADM models
of a sort - does as a black box.
Greg: aware of them, likes material and will attempt to add this, except parts
dealing with impairments.
Don: Q.6 will probably have an interim meeting in spring, good target to try and
have more discussion
to validate models.
Don: believes should not be WG draft until validated by Q.6, harder to change
after that.
Adrian: however, its easier for WG to change this, once its a WG draft, now only
the author can change it.
Don: whatever the chairs thinks is best.
Lou: channel set from Ethernet may be useful model for wavelength set.
Adrian: can ask ITU to look at wording on bipartite graphs.

Greg presented the signaling extensions draft. Added requirements for DWA, wavelength
set metric, explanatory text on new applications. Metric allows selection of distributed
wavelength assignment criterion.  Need to finalize signal characterization (with ITU),
assess demand for distributed bidirectional assignment using different wavelength.
George: isn't this more "research"? are these things ready for use?
Greg: suggesting to reserve bits, but not put in codepoints yet.  Leave space.
George: would agree with that, need experimental codepoints also.
Lou: wavelength set metric - passes indications of techniques for assignment,
this has not been done in the past for label allocation.  Have avoided
standardization of this - why here?
Greg: needs distributed coordination.
Lou: we can do this for avoiding loops without actually specifying algorithms.
This is a radical departure and needs to be carefully considered.
Don't want to have to allocate codepoints for everyone's different algorithm.
Greg: do we need something vendor specific instead?
Lou: think that bringing in these algorithms is a big stretch.
Adrian: slightly unfair, 3473 does for example say how to react for different
information, a type of algorithm specification.
Lou: can be handled as interoperability issue, where do we draw the line?
Malcolm: agrees with concern, difficult issue. What do I share to
make a decision vs. what kind of decision.
Greg: if this approach needs to be matured, that's OK with him.
DWA is just one of the 3 basic mechanisms. Recognizes that this is complex.
Malcolm: close to specifying path computation algorithm, but not clear how to step
back from this.
Greg: possibly an alternative is to provide the wavelength set and let the endpoint
decide.
Lou: maybe service optimization points rather than algorithm.  Context and
references are still useful, but more in earlier framework documents.
Greg: could roll back into the framework.
Don: agree, maybe signal service goal.
George: want interoperability, issue if box A signals for algorithm
and Box B doesn't know it or can't support it.  Brings up possibility of
advertising something in routing about node capabilities for handling information
in path computation.
Igor: basic problem that Framework is too general. Danger is that this becomes
research and not helpful for implementation.  Would like to know who actually
wants to do DWA, for example, is it just research?  Perhaps we should narrow
framework to what vendors and operators want to implement.
Adrian: what if framework is broad but encoding is narrow?
Igor: likes R&W, for example, thinks DWA is unrealistic. Would be much more
interested in this area if it is narrowed down.
Greg: could list options in framework and see what the interest is in different
methods.
Young: also support RWA centrally, but what happens in failure cases?  Might need
distributed assignment.
Igor: if central fails, other methods will probably fail as well.
Malcolm: we should not standardize DWA until convinced that we can run this without
defining the algorithm.
Adrian: 3473 supports DWA. What this does is further optimization, we need to know if
this can be done.
Igor: if this is only for research, we are not interested, not sure if other vendors
and operators are either.

16. Impairment-aware WSON

 a. Framework for control and measurement
   (Greg Bernstein - 10 mins [60/150])
   Slides
   Background reading
   - draft-bernstein-ccamp-wson-impairments-01.txt

Greg presented. There's been lots of ITU work on this.  Trying to classify approaches,
using GMPLS/control plane perspective.  Multivendor introduces an issue of what vendors
will tell you about impairments they introduce.  Next step - assess interest.
Igor: like the presentation, but this is why we don't want a general framework.
Will have to multiply options by options.  DWA less likely to work with impairments.
Malcolm: like the work, agree with Igor's comments, centralized is doable but distributed
is a challenge.  Again need to separate calculation from the input information.

 b. Framework for defining optical parameters for GMPLS control of WSON
   (Zafar Ali - 10 mins [70/150])
   Slides
   Background reading
   - draft-martinelli-ccamp-opt-imp-fwk-00.txt

Zafar presented. This draft provides a different approach but similar ideas.  Want to
rely on ITU for definitions and techniques, but determine how impairment information
can be used in the control plane.  Discusses use of offline and online tools, a
priori path validation.  Classification into scalar, multi-hop, etc. types.
Discusses use of routing, signaling and PCE.  Lists parameters based on ITU.
Next gauge interest level, possibly merge with Greg's draft.
Malcolm: I have real concerns with this draft, slips into how computation is done,
whereas Greg's draft does not.  Especially where it discusses Q factor and how
impairments are aggregated.  Disagree with being able to collect measurements along a
path.
Zafar: does not discuss collection, that's a different draft.
Malcolm: aggregation and use of impairments is Q.6, in some cases Q.6 agreed it was
vendor proprietary.  IETF should not go there.  Control plane should be able to
carry information to allow computation, but not computation itself.
Don: should be coordinated with Q.6.  Even for estimation, implies ROADM needs to
do some measurements to enable this, but Q.6 would need to specify what these are.
Second thing is what ROADM must advertise, esp. what impairments it introduces,
this only works with single vendor domains, including the PCE - vendors will not
advertise this information to other vendors.  Related drafts will need to limit
applicability to single vendor domain. Q.6 may generate update to G.680 to cover
this application.
Lou: agree and disagree with Malcolm - agree in principle, but this draft is still
useful background, OK for framework.
Igor: control plane limited to passing information, but control plane is not the
only means for doing this, e.g., different PCE communication mechanisms.
Otherwise control plane is unaware.  Keep control plane simple and robust.
Wataru: supports drafts as background, but more interested in passing, e.g.,
dispersion compensation information, more interesting than routing issues.
Operators still do routing as a planning process, not real time process.
Tunable compensator management would be more immediately helpful.
Eve: agree with Malcolm and Igor, framework draft should set more direction
about what the control plane is actually being used for.
Malcolm: disagree with "evidence transport", has problems with real time measurement.
Transporting static parameters is better.  PMD, loss does not change.
Don: not comfortable with Greg's draft because not yet scoped to single vendor,
not clear about requirements on ROADMs.
Malcolm: we should not judge if this is single vendor or not, up to Q.6, hope to make
this multivendor eventually when using estimation with margin.
If we don't achieve that, we don't need IETF drafts, for proprietary solutions.
Don: no standard for management through GCC at this time, G.709 OTU missing details
about management.  Not interoperable, different FEC used, fundamentally single vendor
domains.  G.680 does a good job of modeling, but would Malcolm be comfortable for his
equipment to be advertising G.680 parameters?
Julien: even for single vendor, documentation is valuable for consistency for operators.
CCAMP means commonality.

 c. Information model for impairment-aware WSON
   (Greg Bernstein - 10 mins [80/150])
   Slides
   Background reading
   - draft-bernstein-wson-impairment-info-00.txt

Greg presented.
Adrian: Need to clearly identify issues needing work in Q.6 as opposed to here.
Don: agree.  Also, G.680 qualifies use case as single vendor. Non-linear impairments
out of scope of G.680.

 d. Discussion of GMPLS control of impairment-aware WSON
   (Greg and Zafar - 15 mins [95/150])

17. Protocol extensions for impairment-aware WSON

 a. RSVP-TE based impairment collection mechanism
   (Zafar Ali - 10 mins [105/150])
   Slides
   Background reading
   - draft-ali-ccamp-rsvp-te-based-evidence-collection-01.txt

Zafar presented.
Malcolm: innovative but does not solve any problem. Need to go to Q.6 and identify
the problem being solved.
Zafar: want to do feasibility analysis and fault isolation.
Malcolm: control plane doing fault isolation? Is this in scope?
Don: is this only for transparent networks? That was the context of discussion in ITU,
with no G.709 OAM. WSON work is assuming OEO and G.709 OAM and FEC.
Zafar: initially yes, but feel this is generic.
Don: not needed for G.709 for fault isolation, etc.  G.979 was for non-709 networks.
Eve: intent to do real time assessment of path - is that valuable?  This does not,
for example, assess impact of a new path on existing paths. What do you do with this
information? Needs to be defined.
Zafar: could be used for set up LSPs on non-blocking information, also could be used
for LSPs being set up. Or for exploring feasibility.
Malcolm: what is the problem statement? This body is not competent to answer that question,
needs to be posed to Q.6. Believe trying to set up path to see if it works is essentially
crankback instead of path computation, with accompanying inefficiency.
Zafar: will take this to ITU for discussion.
Don: agree with Malcolm, also need to talk with Q.11 on fault isolation.
Malcolm: what is the scenario for fault isolation? E.g., existing path has failed,
need to find where fault occurred. But is this a CCAMP function?
Zafar: OK discuss in ITU.
Eve: suggests remove signaling and routing details when discussing with ITU.
Impacts Q.6, Q.11, Q.12, Q.14 if you get into protocol aspects.

 b. Signaling extensions for impairment-aware LSPs
   (Zafar Ali - 10 mins [115/150])
   Slides
   Background reading (expired!)
   - draft-martinelli-ccamp-optical-imp-signaling-02.txt

Zafar presented. No slides. The draft has expired. We intend to work on the framework
draft first.