2.5.2 Common Control and Measurement Plane (ccamp)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional CCAMP Web Page

Last Modified: 2005-06-13


Kireeti Kompella <kireeti@juniper.net>
Adrian Farrel <adrian@olddog.co.uk>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Alex Zinin <zinin@psg.com>

Technical Advisor(s):

Alex Zinin <zinin@psg.com>

Mailing Lists:

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

Description of 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
physical path and core tunneling technologies of Internet and telecom
service providers (ISPs and SPs), e.g. O-O and O-E-O optical
switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
with the MPLS WG. In this context, measurement refers to the
acquisition and distribution of attributes relevant to the setting up
of tunnels and paths.

CCAMP WG work scope includes:

- Definition of protocol-independent metrics and parameters
  (measurement attributes) for describing links and paths that are
  required for routing and signaling. These will be developed in
  conjunction with requests and requirements from other WGs (e.g.
  TEWG) to insure overall usefulness.

- Definition of protocol(s) and extensions to them required for
  link and path attribute measurement. Link Management Protocol (LMP)
  is included here.

- Functional specification of extensions for routing (OSPF, ISIS) and
  signalling (RSVP-TE) required for path establishment. Protocol
  formats and procedures that embody these extensions will be done
  jointly with the WGs supervising those protocols.

- Definition of the mechanisms required to determine the route and
  properties of an established path (tunnel tracing).

- Definition of MIB modules relevant to the protocols and extensions
  specified within the WG.

CCAMP WG currently works on the following tasks:

- Define how the properties of network resources gathered by a
  measurement protocol can be distributed in existing routing
  protocols, such as OSPF and IS-IS. CCAMP defines the generic
  description of the properties and how they are distributed in OSPF.
  The specifics of distribution within IS-IS are being addressed in
  the ISIS WG.

- Define signaling and routing mechanisms to make possible the creation
  of paths that span multiple IGP areas, multiple ASes, and multiple
  providers, including techniques for crankback.

- Define abstract link and path properties needed for link and path
  protection. Specify 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, routing, and measurement protocols, either
  separately or in combination.

- Identify which requirements for signaling and routing for ASON are
  not currently met by protocols defined in CCAMP; based on these,
  define mechanisms to address these requirements.

- Define a protocol that can determine the actual route and other
  properties of paths set up by CCAMP signaling protocols, as well
  as other types of tunnels (tunnel tracing).

In doing this work, the WG will work closely with at least the
following other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also
with ITU-T.

Goals and Milestones:

Done  Post strawman WG goals and charter
Done  Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts.
Done  Build appropriate design teams
Done  Submit WG document defining path setup portions of common control plane protocol
Done  Submit WG document defining common measurement plane protocol
Done  Submit LMP MIB to IESG
Done  Submit protection & restoration documents to IESG
Done  Submit ASON signaling requirements doc to IESG
Done  Submit GMPLS MIBs to IESG
Done  Produce CCAMP WG document for generic tunnel tracing protocol
Done  Produce CCAMP WG document for multi-area/AS signaling and routing
Done  Submit ASON routing requirements doc to IESG
Mar 04  Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG


  • draft-ietf-ccamp-lmp-10.txt
  • draft-ietf-ccamp-gmpls-routing-09.txt
  • draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
  • draft-ietf-ccamp-lmp-mib-10.txt
  • draft-ietf-ccamp-lmp-wdm-03.txt
  • draft-ietf-ccamp-sdhsonet-control-05.txt
  • draft-ietf-ccamp-gmpls-g709-09.txt
  • draft-ietf-ccamp-gmpls-tc-mib-07.txt
  • draft-ietf-ccamp-gmpls-te-mib-09.txt
  • draft-ietf-ccamp-gmpls-lsr-mib-08.txt
  • draft-ietf-ccamp-gmpls-recovery-terminology-06.txt
  • draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt
  • draft-ietf-ccamp-gmpls-overlay-05.txt
  • draft-ietf-ccamp-gmpls-recovery-analysis-05.txt
  • draft-ietf-ccamp-gmpls-ason-reqts-07.txt
  • draft-ietf-ccamp-rsvp-te-exclude-route-04.txt
  • draft-ietf-ccamp-gmpls-recovery-functional-04.txt
  • draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt
  • draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt
  • draft-ietf-ccamp-crankback-05.txt
  • draft-ietf-ccamp-gmpls-alarm-spec-02.txt
  • draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt
  • draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt
  • draft-ietf-ccamp-gmpls-segment-recovery-02.txt
  • draft-ietf-ccamp-inter-domain-framework-04.txt
  • draft-ietf-ccamp-loose-path-reopt-01.txt
  • draft-ietf-ccamp-transport-lmp-02.txt
  • draft-ietf-ccamp-rsvp-restart-ext-03.txt
  • draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
  • draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
  • draft-ietf-ccamp-lsp-stitching-01.txt
  • draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
  • draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt
  • draft-ietf-ccamp-gmpls-addressing-01.txt

    Request For Comments:

    RFC3471 PS Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
    RFC3472 PS Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
    RFC3473 PS Generalized Multi-Protocol Label Switching (GMPLS)Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
    RFC3609 I Tracing Requirements for Generic Tunnels
    RFC3945 Standard Generalized Multi-Protocol Label Switching Architecture
    RFC3946 Standard Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control
    RFC4003 Standard GMPLS Signaling Procedure For Egress Control

    Current Meeting Report

    IETF-63 Paris August 2005
    CCAMP Working Group
    Minutes thanks to Deborah Brungard and Don Fedyk
    1) Admin

    Adrian reviewed slides of agenda

    2) WG Status

    Adrian reviewed draft status and milestones

    3) ITU and OIF liaison report - Lyndon Ong

    Reviewed slides
    • Q14 Plan to share g7713 before goes for consent
    • No signaling activities, routing they are waiting for our DT response, next meeting in Chicago
    • OIF activities
      • OIF communication to IETF with identified issues from demo
    Adrian: Understand that there is no urgency for responding. Will respond as quickly as possible, will post on mailing list.

    Lyndon: These are results of the demo so there is no dependence but they are important.

    Dimitri: Were these issues identified before or after demo?

    Lyndon: Some before, some after.

    Dimitri: Why not asked over the list for those before?

    Lyndon: Some of the issues were, like the encoding. The first issue was on an informal response. So we want a formal response. The other issues we made some implementation decisions so we want to verify the decisions.


    4) Interdomain RSVP - Arthi Ayyangar

    Reviewed slides
    • Hope to get comments before do next revision (soon) then hope to go for last call
    Dimitri: Do you plan to keep the examples in the document or as appendix?

    Arthi: Do you think it affects readability?

    Dimitri: Prefer as appendix

    Arthi: OK

    Adrian: Is this an example or is it normative?

    Arthi: The example only describes the overall working.

    5) LSP stitching: Arthi Ayyangar

    Reviewed slides
    • Summarized discussion on list
    • First point
      • Are procedures required for both PSC and non-PSC LSPs?
      • Discussion on list indicated yes

      Adrian: Also from a control plane point of view it is better to have a consistent behavior

    • 2nd point
      • Should allow stitching while traversing region boundaries?

      Dimitri: I see no reason for this, why are we still discussing?

      Adrian: I said yes on the list because of the last bullet on the slide. Why disallow it?

      Kireeti: I think yes also, why disallow it?

      Dimitri: Why allow it?

      Adrian: If we take it out of scope now, we may have to change later, so why remove it now? Yet we don't want to do it speculatively.

      Igor: Question for kireeti: Can we stitch PSC1 with PSC2 LSP? And we said while we could do this with a label stack, but we shouldn't allow it as these LSPs were provisioned for a reason as two different types (PSC1 and PSC2). In the non-packet world this more clear. Use hierarchy and adaptation.

      Kireeti: Not so clear for me. PSC1 & PSC2 We understand but Non-PSC we don't understand. For non PSC, we don't know where it will go, e.g. wavelength switching. So why prevent it?

      Igor: It is not complex but it is pointless.

      Kireeti: You can always say no when you receive a request to stitch.

      Arthi and Igor: No, you can't say no

      Lou: What is the difference between stitching and hierarchical LSP. The LSP on top (inner label) uses all the bandwidth of the one below (outer label).

      Adrian: The difference is if you add a label for the passenger LSP.

      Arthi: It's not just label allocation it's resource allocation. I'll address this later.

    • Bidirectional LSPs and control of labels
      • Current proposal resolves this by not sending a Label.
      • options: In Slides:

      Lou: Minor suggestion; use a different C-type. Call it Option 2 Prime.

      Arthi: You can, but it is still an issue.

      Adrian: You have to do special processing when you do stitching anyway.

      Arthi: You still have to implement the C-type.

      Kireeti: You don't have to allocate a special label.

      Adrian: Agree Point 4: Need to provide end-to-end bidirectional service. For example for mpls/gmpls migration. Need to stitch two unidirectional LSPs in the middle.

      Arthi: Or could do 2nd part of (4). This is not really any changes Just need stronger description on what we are doing Personally like a sending label that is ignored.

      Adrian: Who likes this 2nd part? - Send any label and have receiver ignore it # Some show of hands

      Adrian: Anyone prefer one of the other solutions? # (No one?)

      Adrian: Seems a preference for this 2nd option, will take to list

      Lou: Clear to make the change. Change the text to Must.

      Dimitri: Can you make document clearer by adding a specific section on the stitching rules wrt directionality

      Arthi: Should it be required for non PSC?

      Lou: Anyone that supports stitching MUST support the procedures if they support stitching.

      Arthi: But if you are not following this document. You could be doing data plane stitching and not control plane stitching.

      Lou: If it is outside the standard then it is out of scope. If you follow the document you MUST follow the procedures.

    6) Per-Domain-Paths - JP Vasseur

    Would like to get feedback on last issue on slides.
    Adrian: I think the use of IP reachability information is important. The WG must make a conscious decision.

    JP: This I-D is only describing reachability outside of domain

    Adrian: We should say so more clearly

    Dimitri: I sent feedback. We should cover this question. Not sure if part of this document. This is a problem in several documents. If we have IP reachability, but don't know switching capability, then it's not sure if we can make the connection. This an issue when have a mixture of switching capabilities.

    Igor: When we compute path, we consider TE resources, not IP reachability. Should not rely on knowing reachability. Once you have a mix of terminating points this is a real issue.

    Adrian: We need to have a global solution.

    Igor: You want to compute path consider the resources TE resource reachability of destination. Not to rely on the IP but have static information that you can reach the path.

    JP: Just want to rely on IP reachability to reach next domain, and then let next domain decide if it can satisfy the request.

    Igor: OK - maybe could do aggregation rules You can have a static TE entry.

    JP: But we don't have information on resources

    Janis ??: Agree that if we are separating data and control plane, this will not work

    Adrian: Specifying what information to use for path computation is not covered anywhere. It is part of the algorithm, but not part of the protocol. CSPF can use any information including IP reachability or the weather.

    Arthi: So how do we find next hop? How do you get to the next domain?

    Adrian: If we don't do this process inside the domain, why do we have to have a way to get out of the domain?

    JP: So we should remove next hop?

    Arthi: Does not make sense. How to do crankback?

    Kireeti: OK - we need to consider further



    7) Addresses in GMPLS networks - Richard Rabbat

    Reviewed slides
    Arthi: why you are proposing as a std track?

    Adrian: This decision was a result of a loose poll based on whether this advises, recommends or mandates.

    Arthi: Can we do again the poll

    Adrian: We can, who prefers:
    • # BCP - some show of hands
    • # Stds track - less show of hands
    Arthi: My concern is that it is good to have this document, but it is using items from other docs and making some changes Have to change the Musts and Shoulds.

    Adrian: If text is repeating the same must/should from another document then it should be deleted. If this is new must/should language then it should be std track Need to clarify definitions. If you are Restating with same values, its BCP. If you change values it is Standards updating an existing RFC or a new Standards track document.

    Arthi: Then this should be std track as it is already doing it

    Lou: It is bringing together many items - would suggest informational. Could be informational. I did not vote because I was waiting for informational.

    Adrian: Who wants informational? # almost same show of hands as BCP

    Lou: If it's implementation then BCP, but if bringing together info, then informational. The document is putting recommendations on implementing. Is it just for building and deploying? Or is it Defining a new field or procedure?

    Adrian: OK we should discuss more

    Dimitri: I thought the same - it is bringing together experience on using addresses, not saying how to do, and not covering future issues. So I have issue with 9.3 which is not based on experience

    Adrian: The WG needs to decide how want to do

    Kireeti: We will discuss with ADs and take to list

    Arthi: For example, for the FA it says a MUST for how to use, but it doesn't say what to do for static case, so doesn't cover all cases

    Richard: This is an oversight. we'll correct it in the next revision to say that we're talking about the dynamic case.

    Yakov: Slide #3. Why the decision on FA LSP, this is a change to the protocol.

    Richard: You don't know it is a FA LSP. How do you know that it is to be advertised back?

    John Drake: It is covered in RFC3477.

    Lou: That is unnumbered interfaces.

    Adrian: Numbered FA LSPs need a way to indicate to the egress that they will be used as FAs. Compare with unnumbered LSPs that have a special object.

    Arthi: What is the point of changing it to 0?

    Kireeti: Let's discuss on the list

    8) GMPLS/ASON Lexicography - Igor Bryskin

    Reviewed slides
    Igor: If anyone is interested in furthering ason-gmpls convergence, talk to Adrian or myself to help

    Richard: What is your objective?

    Igor: Have consensus in the group and expand the dictionary.

    Richard: Saw in one the drafts on ASON there is an appendix. With ASON terms. Should we integrate the ason-gmpls documents' reference terms into this document?

    Dimitri: No, that work was for CCAMP people to understand ASON. This is a different purpose

    Igor: Agree. This is for ITU people to understand GMPLS

    9) ASON routing evaluation - Dimitri Papadimitriou

    Reviewed slides
    Adrian: Who from DT is in the room? # Dimitri and Lyndon

    Adrian: Thanks for work. Does the DT think this is ready for last call?

    Lyndon: Yes. Just some minor editing

    Adrian: Anyone object to last call # None

    Alex: Doesn't WG need to read this first

    Adrian: Yes, need to read it for last call OK take to list for last call

    10) ASON signaling - Dimitri Papadimitriou

    Reviewed slides
    Dimitri: The community that wants to use this document needs it to be recognized as an RFC, it is important to finish

    Alex: Any technical issues on this or the last document that need to discuss now?

    Dimitri: Only this item on simultaneous call/connection signaling

    Alex: Please summarize the technical issues. Please focus the time in the meeting to raise and discuss open issues

    Lyndon: Will you liaison to SG15 before last call?

    Kireeti: Yes

    Steve Trowbridge: Should also include specific changes against g7713.2

    Adrian: What is the intention?

    Steve: Should be for alignment, should not have two normative versions of ASON signaling

    Adrian: ITU already has versions .1, .2, .3

    Steve: State how it differs from .2 version

    Adrian: OK. This is GMPLS. 7713.2 is not GMPLS. We can do a comparative analysis. Principal difference is call/connection piggybacking

    Lyndon: Is this UNI/ENNI/INNI?

    Dimitri: The document states clearly this if you read it It covers client-initiated and network-initiated calls and so call/connection signaling at UNI and E-NNI/I-NNI

    Alex: Are the technical issues complete? It would be much better if we have the technical summary. Not just say this work is ready or work is stable.

    Adrian: We owe the WG status.

    Kireeti: Dimitri, can you start the liaison?

    Dimitri: OK

    11) CCAMP Work Plan

    Kireeti reviewed the slide on options what to do
    • We have pretty much cleared the documents in our queue, and we are reviewing the charter to update
    • I have 12 documents submitted to me, 10 docs in id list.
    • Documents are done when finished also IESG review, I don't expect to wait for this though before going on to new items.
    Alex reviewed slide on potential new work
    • Inter domain OK
    • Layer 2 switching: where is this?
    Kireeti: We will have a discussion on where to put it

    Alex continues:
    • L1VPN New WG
    • doesn't seem any objection, should prioritize and timeline
    • Are these Milestones or Work items?
    • Could do milestones, but defining work items is easier
    • For example, MPLS/GMPLS interworking is implicit in the charter but not specifically covered.
    Alex: Can identify high priority items now

    • We already asked the working group and this is on the first slide.
    • There are six items shown on the slide
    Alex: Six items that need some work. Is that too much?

    • Not all things are the same size.
    • Interoperability issues are already on the plate.
    • Layer 2 switching Moderate size thing.
    • MPLS/GMPLS migration moderate size.
    • Second slide shows recent new topics. Maybe take on new items.
      • Signaling Issues:
      • Routing issues
      • GMPLS OAM requirements.
    Alex: These items are also important

    Kireeti: Should look at pipelining work as we already started first slide. It all depends on how long it takes to do charter. We have been waiting now for more than a year

    Alex: Can prioritize and identify if can spin off work to a new, separate working group. Just like Layer 1 VPN that uses GMPLS. Take out other lumps and put in other WGs? Chairs should identify items.

    Adrian: We can discuss which could spin off, though we need to decide, and not delay, as many items are already being worked on.

    Bijan Jabbari: When I look at what is being implemented by vendors there is a mismatch with what this group is doing. Perhaps should look at short term.

    Alex: Yes my thoughts should look at 1 year to 2 years.

    Bijan: Not really clear what is being implemented

    Bijan: I work with Academia and industry, and the answer is not clear. You see implementations but you don't see deployments. Business reasons etc. New way of thinking that takes time.

    Alex: When go for standard track, do need implementation

    Kireeti: Also need deployments, and that takes time

    JP: Regarding the item on "input to PCE requirements". Not sure if need this input

    Adrian: Explain history is that CCAMP made a commitment to assist PCE Could agree to remove this commitment

    Alex: Yes we should discuss more in both groups. Don't want to make commitment to remove this before discussing it. If we have consensus maybe we don't need the document.

    JP: On advertisement of TE/GMPLS capabilities, we're about to celebrate the third anniversary of this ID. The ID has been discussed, implemented and deployed in 5 large service providers, so would like to expedite this.

    Lou: Slide Back to Slide3: For the item on charter - missing is ASON. What do we do about alignment, and that we have two versions of RSVP? There is only one version of GMPLS, what do we need to do? What steps that we need to take as a WG?

    Alex: ASON is on our charter

    Lou: It's on charter - we have completed our documents. We can send to SG15, but what do we do from there to align GMPLS and ASON solutions?

    Adrian: Added it to slides

    Richard: On recent new topics - do we know what is in-charter currently?

    Alex: It is up to chairs:

    Adrian: If it is in the scope of the charter, we will do milestones There will be discussion on the list.

    Dimitri: Why is "deployment considerations" considered marginal? If you want feedback, how can this be classified as marginal? Please prioritize and please discuss.

    Adrian: This is from the community view gathered on the list last year

    Dimitri: Then how will we have deployment

    Kireeti: You can do canvassing to get people to discuss. We will take back to the list to do a poll again



    12) GMPLS for Ethernet - Dimitri Papadimitriou

    Reviewed slides

    Define a set of scenarios:

    4 Scenarios
    • Aggregation
    • Metro
    • Unified? Core
    • Transport
    Dimitri asked if interest to do this work
    Don Fedyk: We still don't know what is actually meant by GMPLS Ethernet. The document does not go far enough today with enough detail. The document is too open ended and we don't know what exactly is being specified. I asked for more detailed specification.


    Ali Sajassi: Ethernet differs from other data planes as it's not point to point. Do you want to keep it as in the perspective of IEEE? Other comments: you want to replace existing Ethernet control plane with GMPLS: again how will you do multipoint? Shortest path may overlap with issues discussed in TRILL. How are you going to coordinate with other WGs?

    Loa: Not speaking for the DT as we didn't discuss it: I have experience running a medium/large scale Ethernet network as a point-to-point network (unified/core). It would be very applicable to add a gmpls control plane. Note that if we can't do it as a standard we (deployers) will do it ourselves. It is pretty straight forward.

    Ali: I can see for point to point, it's for multipoint that I see it will have issues

    Dimitri: OK. Can you input specifics? This said these questions are relevant but the scope (of the document) has been restricted to point-to-point. The issues on how we coordinate and potentially overlap with other working groups must also be addressed (implicitly: if we decide to move forward with this item.)

    Richard Spencer: Can you confirm that using GMPLS in enterprise is out of scope?

    Dimitri: As no one has expressed interest I would say it is out of scope

    Richard S: Will there be any changes to Ethernet control/data plane? What would be the potential difficulties? Have a discussion with the IEEE and see where they would be impacted.

    Dimitri: I can not say what will be the solution chosen, we already suggested we work with IEEE to assess impact

    Richard S: I see little value for aggregation. I don't see in metro why a provider would want to use this instead of VPLS

    Dimitri: I have replied to some of the issues you are currently raising on the list. If further clarification required we should discuss them on the list.

    Kireeti: We will not change the Ethernet data plane here. If we conclude it may need to be changed, we will liaise to IEEE and get their agreement. CCAMP is focused on core tunneling technologies, though we don't say how you will use them - metro or core - I would like us to continue not to be specific for access or core. If there is anything specifically different for access, then need to add to charter.

    Lyndon: There is a lot of interest in other groups (ITU, OIF, MEF). I think there is interest. Where people are uncertain is how. Need to look at more on supporting pt to pt or multipt.

    Don O'Conner: How does this differ from l2vpn?

    Dimitri: As explained in the introduction of the problem statement document it differs from the forwarding which is not based on packet header (as in MPLS) but based on the Layer-2 frame header.

    Kireeti: L2VPON charter is different. L2VPN sets up vpns. This work is on signaling and routing in Ethernet networks.

    Tom Nadeau: Is this in the scope of CCAMP today?

    Adrian: Yes this is in the scope as a core network. GMPLS handles packet transport networks. Maybe this is could be a new working group. Note, however, that changes to the data plane are not in scope for CCAMP and would require action by other SDOs, in this case IEEE.

    Tom: Seems similar to TRILL.

    Adrian: Yes. Need to determine if there is overlap. Perhaps this work should go there. Alternatively, perhaps this work goes in a new WG.

    Dimitri: Some of these items such as the difference with TRILL have been discussed on the mailing list.

    Loa: Trill is in campus networks.

    Alex: For structuring this work, we need to be very clear what data path modifications need to be done. Should communicate with IEEE liaison, preferably before BOF. TRILL working group is a specific example.

    Dimitri: What would be the way to contact the IEEE to do this? Is there a liaison with IEEE that we can make use of?

    Alex: We have an established liaison relationship with IEEE.

    Dimitri: OK, we will enter in contact with the liaison representative.

    Kireeti: First need to decide if we need a change in the data plane. Then talk to the IEEE.

    Adrian: Also need to tell IEEE what we plan to do, no matter how we do it.

    Smith: There are limits to the use of VLAN-ID. There are only 4K of them. Will you use this as the label?

    Adrian: We haven't decided anything about how forwarding will occur yet

    Dinesh Mohan: I haven't heard yet that there is planned a change to the data plane. Need to understand better. Should look at this as a new control plane using existing data plane. It would be nice to have the GMPLS Control plane but is there no intent to change the control plane? The basic assumption is that you have a different control plane then that should be the assumption. This is fine to explore, but the starting point is not to modify the data plane.

    Adrian: When we control SDH we did not mess with the data plane. We should not be modifying the transport technology.

    Monique Morrow: Echo what Alex said, any modification we need to talk to the IEEE.

    Dimitri: OK, but we are not talking in the context that there is a change to data plane.

    Ali: Trill and this are using ISIS. Trill plan to change the data plane.

    Kireeti: Please stop, take to list.

    Ali: Several vendors offer Ethernet switches that offer point to point using MPLS control plane supporting millions of connections.

    Yakov: How? Could you tell me whether they carry a label?

    Ali: Yes. They are MPLS switches

    Yakov: So it is a router, an LSR , that you can call an Ethernet switch and you are done?

    Adrian: That is indeed a suggestion.

    Don O'C: Ethernet is connectionless and now GMPLS is connection-oriented, so this is different. This is redefining Ethernet to make it connection oriented. Is that the intent? Is this making VLAN tags look like GMPLS labels?

    Adrian: Again, this has not been discussed

    Loa: From experience, we don't want to remove VLAN tags. Need something else. And the chairs said to the design team not to do that, yet 80% of CCAMP are already assuming this is what we want to do.

    Adrian: Design team job is done - Thanks. We need now for the WG to discuss.


    Time is over. Other drafts that we didn't get to discuss, take to list.


    Agenda and Working Group Status
    ITU-T Liaison Report
    Inter-Domain RSVP-TE
    LSP Stitching
    GMPLS Per-Domain Path Computation
    GMPLS Addressing
    GMPLS/ASON Lexicography
    ASON Routing Evaluation
    ASON Signaling
    CCAMP Work Plan
    GMPLS Control of Ethernet Networks
    TE Node Capability Advertisement and Automesh Advertisement
    Interpretaiton of CPSF constraints
    Routing Constraints for GMPLS
    GMPLS Control of VCAT and LCAS
    GMPLS Control of VCAT and LCAS