Seventy first IETF, Philadelphia, March 2008

CCAMP Working Group Minutes
***************************

Session I
March 10 (Monday)
1300-1500 (1pm-3pm)

Chairs: Adrian Farrel 
        Deborah Brungard 

Note takers: Greg Bernstein, Lyndon Ong, Martin Vigoureux
================================================
0. Administrivia
   (chairs, 5, 5/150)
   Slides

No comments on the agenda.
================================================

================================================
1. WG status, RFCs, drafts, milestones, charter
   (chairs - 10 mins [15/120])
   Slides

Lou Berger is new Working Group Technical Advisor.
Four new RFCs.
Two I-Ds in Editor's Queue.
Security work nearly done in MPLS WG, needs review by CCAMP (comments
on MPLS WG list).
================================================

================================================
2. ITU-T and OIF progress report
   (Lyndon - 10 mins [25/120])
   Slides

Four ITU-T Liaisons to CCAMP.

On Local Connection Type slide:
  Julian: Is this inter or intra carrier?
  Lyndon: Thinks independent of inter or intra.
  Jonathan: Example could be for dual homing support.

Adrian: TLV length computation - we will take it to the list if we
  should fix RFC4420.
================================================

================================================
3. Traffic Engineering Database MIB Module
   (Tomo - 10 mins [35/120])
   Slides

   Background reading
   - draft-ietf-ccamp-gmpls-ted-mib-03.txt

Updated to include traps related with TED MIB and cleaned up text.

Adrian: Are we at the stage that we should consult a MIB Doctor?
Tomo: Yes.
================================================

================================================
4. GMPLS Extensions for VCAT
   (Greg - 10 mins [45/120])
   Slides

   Background reading
   - draft-ietf-ccamp-gmpls-vcat-lcas-04.txt

Changes included adding requirements on keeping preexisting members,
changed to maximum 1 VCG per call. Added Call_Data object, new TLV
for VCAT information. Added list of error conditions. Propose to
clean up and send liaisons to ITU and OIF.

Jonathan: ITU-T had expressed interest in a technology-independent
  inverse muxing method, does this address?
Adrian: Also the Ethernet folks are interested in this mechanism,
  there may be room for making this more technology-independent.
Greg: VCAT already applies to three circuit technologies (PDH, SDH,
  OTN). Packet may be somewhat different, e.g. dealing with delay
  differences.
Adrian: Protocol elements probably the same across different
  technologies. Information elements will have some shared, others
  specific.
Adrian: Recommends should discuss with Lou, hopefully can make the
  draft more technology independent without a total rewrite.
Greg: Ethernet LAG is very different.
Adrian: This is still service-level muxing.

Adrian: Note Call_Data name already taken, we'll have to think of
  another name.
================================================

================================================
5. Updates for Hierarchical LSPs
   (Kohei - 15 mins [60/120])
   Slides

   Background reading
   - draft-ietf-ccamp-lsp-hierarchy-bis-03.txt

Added bundled link indication and an Action field. Improved
readability. Believes technically done, comments and feedback are
needed.
================================================

================================================
6. Moving LSPs between the Management and Control Planes
   (Diego - 15 mins [75/120])
   Slides

   Background reading
   - draft-ietf-ccamp-pc-and-sc-reqs-02
   - draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt

Requirements draft is stable. Dave McDysan added to the author list.
Propose Last Call ready.

On the RSVP-TE extensions draft, added more authors, comments, and
fixed a bug identified by Dimitri.

Adrian: Have you looked at 2nd order errors?
Diego: Not explicitly. May need to add timers.

Dimitri: How do you handle retries of PathErr?
Diego: NMS? We'll clarify in the draft.

Adrian: Is there good support for this solution?
  (some hands supporting, no one opposed)

Dave McDysan: Suggested to add advice to implementers (maybe in the
  requirements). Provide a reference example of moving in either
  direction. Perhaps a separate (small) MIB extensions draft?
================================================

================================================
7. RSVP-TE Extensions to Support PCE Path Keys
   (Adrian - 10 mins [85/120])
   Slides

   Background reading
   - draft-bradford-ccamp-path-key-ero-01.txt

Defines a new ERO subobject to carry Path key, content defined by
PCE WG.
Adrian prefers this draft done in CCAMP rather than PCE.

John: What is the relationship of this draft and Bradford's work?
Adrian: This is the same.

Adrian: Proposes to make a WG draft?
(Good support, none opposed.)
Will take to list.
================================================

================================================
8. LMP Extensions to Confirm Data Channel Status
   (Dan - 15 mins [100/120])
   Slides

   Background reading
   - draft-li-ccamp-confirm-data-channel-status-03.txt

Some minor editorial updates. Autors feel ready for WG status.
Two implementations, no impact on existing LMP functionalities.

Adrian: Working Group draft?
(Fair show of hands, none opposed.)
Will take to list.
================================================

================================================
9. OAM Techniques for GMPLS
   (Zafar - 10 mins [110/120])
   Slides

   Background reading
   - draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt

Igor: What happens if PATH or RESV is lost? Data that you collect may
  not be possible to correlate. For both blocking and non-blocking
  case.
Zafar: LSP is assumed to be up during this procedure. Refresh is not
  involved.
Igor: What if PATH or RESV disappears for a long time?
Zafar: Ingress node retries.
Igor: Suggest adding a time stamp, otherwise may be hard to correlate
  the data.

Snigdo: Do you assume L1 interoperability? If you have a multi-vendor
  network, may not be able to collect interoperable data.
Zafar: Minimum level of interoperability required.

Don O'Connor: This is the T-MPLS development process in reverse. You
  Should take this to ITU, you are defining a new OTN network.

Deborah: The draft states that G.709 is only applicable for OEO capable
  nodes, that's not true. It also applies to OOO. This is done in ITU.

Malcolm: Important is what can you measure and how you can measure
  it. That's ITU work. You should submit to ITU-T (SG15 Question 6
  and Question 9).

Adrian: On measurements should submit as your own contribution to the
  ITU. You should also should look at the WSON related drafts.
================================================

***********************************************************************

Session II
March 12 (Wednesday)
0900-1130

Note takers: Lyndon Ong, Martin Vigoureux
================================================
0. Administrivia (chairs - 5 mins [5/150])
   Slides

No comments on the agenda.
================================================

================================================
1. Ethernet

---------------------------------------------
   a. Ethernet Architecture I-D
      (Don - 10 mins [15/150])
      Slides

      Background reading
      - draft-ietf-ccamp-gmpls-ethernet-arch-01.txt

Switching type under discussion. L2SC was defined to be used for
Ethernet and ATM (and others). Discussing if need more specific type
and not clear if Ethernet has a true hierarchy.

Next steps: Will continue to update draft based on discussion.
  There were no questions on the draft.
---------------------------------------------

---------------------------------------------
   b. Ethernet Architectural Issues and Concerns
      (Dimitri - 10 mins [25/150])
      Slides

Discussed control driven vs. scaling and forwarding vs. label in
Ethernet.

Nurit: Forwarding could be based on VID only.
Dimitri: Yes.

Lou: I do not understand the comment of non-nesting wrt to C-VID,
  S-VID.
Dimitri: C-VID > S-VID is not tunneling, this is appending.
Lou: Difference is between appending and push?
Dimitri: Forwarding is MAC+VID based.

Don: Believes context limited to PBBN, the rest is payload to
  PBBN domain.
Dimitri: Between Which boxes are we working? Did we agree to limit?
Don: The dark blue ones (see slides)

Lou: Scope is PBBN and UNI (point to point of green box to dark blue).
Dimitri: So where is the ENNI which Don mentioned?
Lou: The SDOs concerned are planning to work on this (future).
Dimitri: ISID is service identification. How do you put it in an NNI?
We are working on control based on assumptions we make on the
forwarding.
Don: There has been talk about interdomain OAM. Translate I-SIDs
  between domains.

Lou: Enrique, can say what MEF is looking at?
Enrique: Which UNI? MEF UNI is at the green boxes. The blue boxes
  would be inside the domain for MEF.
Lou: The framework document doesn't use this figure.
  The only UNI we are supporting is those defined by MEF and ITU.

Nurit: Architecture document covers PBBN only, not PBN. Should be
  titled PBBN, not Ethernet if it only covers PBBN.
Adrian: That would be an error in the long term, should be technology
  agnostic.
Don: Framework is limited as we don't know how to interpret GMPLS
  applied in the grey domains.
Dimitri: Ok, then are we going to have a unified control plane or
  specialized ones for PBBN, PBN, etc.?

Don O'Connor: PBN is connection-less. Can not use GMPLS in the grey
  domain. So should only be for PBB-TE.
  MEF does not have a UNI for dark blue boxes.

Adrian: Should we scope only between the dark blue boxes? What about
  the green boxes connected to the dark blue boxes?
Don: MEF UNI as currently defined at the edge of the PBN.

Igor: Agree with Don. We do not consider MAC learning for GMPLS, no
  case for GMPLS in PBN.

Kireeti: I do not agree. PBN today is MAC learning + spanning tree.
  But what will it be tomorrow? No one knows.

Dave: Control plane in PBBN environment. Beyond that, is open for us
  to think about.
Dimitri: It is proposed to carry network MAC as part of the label.
  What if scope expands, what does this do to scaling?
Dave: No difference to 32-bit FEC.
Igor: This is masked by hierarchy as a different layer network, so
  signalling MAC addresses doesn't introduce any scaling issue.
Dimitri: Do we want to have multiple definitions of label depending on
  the network we are in? We can't use MAC of client space as part of
  the label for PBN domain.
Igor: We don't have a clear idea of what technology for PBN domain.
  Makes sense to concentrate on PBBN domain, that's where we know what
  is used.

Dimitri: How will we distinguish between bridged and non-bridged VIDs?
Don O'Connor: If between dark blue boxes, it is then alternative 2.
  However, don't need this to be L2SC.
Kireeti: Should be alternative 1, can't take out green boxes that
  early.

Lou: Should not get hooked up on the name. The architecture should
  not be specific, we should be specific in the technology specific
  documents.
  There's two different points - are we allowing hierarchy (Alt. 1)
  and what's in a name (L2SC).

Dimitri: The way the label value space is inferred in 3471 is linked
  to link characteristics, there is no label type.
Lou: If link characteristics include a switching type, I agree.
  We can remove the sentence on L2SC.

Don O'Connor: Are you proposing to have neither Alt. 1 or Alt. 2 in
  architecture document?
Lou: Yes.
Don O'Connor: I suggest you go to IEEE and convince them that you
  want to use GMPLS to control an 802.1ad connectionless network.

Adrian: Support taking out the phrase on L2SC in the architecture
  draft, does this solve the issue?
  (several said they could agree with this)

Igor: It should though be different from L2SC.
Dimitri: Why didn't anybody complain at the time of the GMPLS arch RFC?
Igor: We have more knowledge now.

Kireeti: Alt 1 does not mean IEEE must do connection oriented.

Loa: Why do people want to use the same switching type? We do not
  want to close the door on hierarchy, so alternative 1.
Lou: There might be an alternative 3. We allow multiple switching
  types but do not describe them. Give meaning in the technology
  specific documents.
Loa: I think that's what I said.
Lou: Yes, but I'm proposing a 3rd alternative, we should agree not to
  use L2SC.
Loa: If I was planning serious work on Frame Relay, I would like to
  have my own value as well.
Lou: Could we have consensus on path to follow?
Adrian: We can take this idea as room consensus, and then the editor
  post their proposal on the list to see if consensus.

Dimitri: My presentation is not finished.
Adrian: Understand, but we got to move on.

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

---------------------------------------------
   c. Ethernet Architectural Discussions (19 mins [44/150])
      No slides
Refer to above discussion on (b).
---------------------------------------------

---------------------------------------------
   d. Ethernet Requirements
      (Wataru - 10 mins [54/150])
      Slides

     Background reading
     - draft-imajuku-ccamp-ethernet-gmpls-req-01.txt

Noted one issue on support of dynamic link aggregation. Needs input
from other service providers.

Don O'Connor: What is "legacy" Ethernet.
Wataru: Connection-less.
Don O'Connor: No intention to change IEEE control planes?
Wataru: Do not exclude possibility of IEEE control plane and GMPLS
  control plane coexisting.

Lou: Having inputs from carriers is extremely valuable. Would like WG
to continue on this. What about UNI, ENNI - did I miss it?

George: Agree with Don O'Connor, but IEEE control plane does not
do everything.

Loa: Supports document as well. I see you included in-band control
  channel, is out-of-band control channel not needed as well?
Wataru: No.

Florin: I see inter-domain is a requirement. Need to sync with IEEE,
  because this is not part of IEEE scope. Need to push in IEEE.
Wataru: There is some discussion in IEEE, they do not exclude it.
Don O'Connor: Should liaise this to IEEE.

Dimitri: What does hybrid operation with legacy mean?
Wataru: Ships in the night (different VLANs).

Adrian: This is what service providers would like to do with Ethernet.
  May need to scope to CCAMP and our charter.

Nurit: No requirement for P2MP?
Wataru: Because solution is unclear. Need to include in future.

Adrian: Hear a hum for adopting as WG document?
(Good Hum)

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

---------------------------------------------
   e. Ethernet Traffic Parameters
      (Chairs - 1 min [55/150])
      Slides

      Background reading
      - draft-ietf-ccamp-ethernet-traffic-parameters-03.txt

Adrian: We will fix the TLV definition in RFC 4420. Then we will
  update this I-D.
---------------------------------------------

---------------------------------------------
   f. Protocol Extensions for PBB-TE
      (Don - 15 mins [70/150]
      Slides

      Background reading
      - draft-fedyk-gmpls-ethernet-pbb-te-02.txt

Asking for WG document.

Adrian: Important is the middle bullet that it will stay in sync
   with IEEE work.

Dimitri: We can not export the label merging technologies of MPLS
  in this environment.

Andy: Making this a WG document is the best way to stay in sync.
Adrian: Who is opposed?
  (no hands)
  Who is in favor?
  (Adrian: best show of hands we've had in a long time)
---------------------------------------------

---------------------------------------------
   g. Asymetrical Bandwidth Bidirectional LSPs
      (Lou - 5 mins [75/150])
      Slides

      Background reading
      - draft-berger-ccamp-asymm-bw-bidir-lsps-01.txt

Intention for generic approach.
Question if this should be experimental (WG)?
Proposal is experimental.

Adrian: Want to Last Call in CCAMP. Could be as individual,
  but WG draft could be easier.
Lou: I'll submit as a WG document so we can last call at once.
---------------------------------------------

---------------------------------------------
   h. Ethernet Services
      (Lou - 5 mins [80/150])
      Slides

      Background reading
      - draft-berger-ccamp-gmpls-ether-svcs-01.txt

Most recent version has incorporated comments from Dimitri.
Question - Should generic extensions be separated into a generic draft
or left in this technology specific draft? These include addition of
LSP_attributes in Notify, SC type for switching of all traffic coming
to one port (not specific for Ethernet).

Igor: Notify should only carry attributes of a service, not
  LSP_attributes. Would like to see a different object.

Adrian: Poll the room - ready for WG draft?
  (No objection)
  Will ask the list.
---------------------------------------------

---------------------------------------------
   i. MEF UNI
      (Lou - 5 mins [85/150])
      Slides

      Background reading
      - draft-berger-ccamp-gmpls-mef-uni-02.txt

Aligned terminology with Ethernet services. New issue from Dimitri
- UNI endpoint ID to IP address resolution
Propose 2-stage resolution. Also, associated session processing.
Propose use of Notify, consistent with 4974 or 4974bis.

Dimitri: Was not clear on how information is propagated - currently
  4974 assumption that originator knows address of destination, but
  that could only be a token identifier.
  Should we add a mechanism for privacy?

Adrian: Do we think ready for WG document?
  (No one opposed)
  Will take to list.
---------------------------------------------

---------------------------------------------
   j. Control of Ethernet (and other) OAM
      (Attila - 10 mins [95/150])
      Slides

      Background reading
      - draft-takacs-ccamp-rsvp-te-eth-oam-ext-01.txt

Adrian: Chairs will review and give you input before we take to
  the list on WG status.
---------------------------------------------
================================================

================================================
 2. WSON

Adrian: Note, we are not defining optical constraints or hardware,
  this is done in Q6/15. If there is interest in expressing optical
  constraints in GMPLS, need to reference ITU documents approprately.

---------------------------------------------
   a. Framework for WSON
      (Greg - 10 mins [105/150])
      Slides

      Background reading
      - draft-bernstein-ccamp-wavelength-switched-03.txt

Greg: Notes, focus of this is on metro networks where constraints play
  a lesser role.
  We have referenced ITU.
  Changes are primarily editorial.
  Asks to be WG draft.

Adrian: No question this is useful information. However, not sure
  ready to take on both Ethernet and WSON at the same time. Would
  prefer to get Ethernet stabilized first and take up WSON more
  around Dublin.

Loa: Don't see overlap (except for the WG Chairs' work). Would
  support making a WG document.

Adrian: Show of hands in support?
  (Pretty good show of hands in support)
---------------------------------------------

----------------------------------------------
   b. Information Requirements for WSON Path Computation
      (Greg - 10 mins [115/150])
      Slides

      Background reading
      - draft-bernstein-ccamp-wson-info-02.txt

Question of scale - how much information is needed? Characterize static
vs. dynamic information.

Adrian: This document needs to be protocol-independent, needs to
  avoid defining formats for specific protocols.
---------------------------------------------

---------------------------------------------
   c. Signaling Extensions for WSON
      (Greg - 10 mins [125/150])
      Slides

      Background reading
      - draft-bernstein-ccamp-wson-signaling-01.txt

Deferred due to lack of time
(WG should read and comment on the list).
---------------------------------------------

---------------------------------------------
   d. Lambda Labels
      (Tomo - 10 mins [135/150])
      Slides

      Background reading
      - draft-otani-ccamp-gmpls-lambda-labels-02.txt

Aligned with WSON work - propose to adopt as WG draft.

Adrian: This draft is a fundamental building block.
  There was more debate in Vancouver than expected.
  Does anyone still have major open issues?
  (no comments made)
  We will take it to the list.
---------------------------------------------

---------------------------------------------
   e. Evaluation of Carrying WSON Information in IGPs
      (Dan - 10 mins [145/150])
      Slides

      Background reading
      - draft-li-ccamp-wson-igp-eval-00.txt

Evaluated potential of overhead for advertising full wavelength
connectivity constraints. Need to discuss what should be advertised.
Need to work with other WSON drafts for consistency.
Comments appreciated.

Snigdo: Question on the equation - currently does not include
  add/drop capability, only thru connectivity.
Dan: Yes. Could add this.

Adrian: Should also include more text on the difference between using
  the existing LSA versus using a new opaque LSA or a separate OSPF
  instance.
---------------------------------------------
================================================