2.5.2 Common Control and Measurement Plane (ccamp)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.olddog.co.uk/ccamp.htm -- Additional CCAMP Web Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-15

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: http://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 cooperate 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
Dec 03  Submit GMPLS MIBs to IESG
Dec 03  Submit protection & restoration documents to IESG
Dec 03  Submit ASON signaling requirements doc to IESG
Jan 04  Produce CCAMP WG document for multi-area/AS signaling and routing
Jan 04  Produce CCAMP WG document for generic tunnel tracing protocol
Jan 04  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-gmpls-sonet-sdh-08.txt
  • - draft-ietf-ccamp-gmpls-architecture-07.txt
  • - 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-09.txt
  • - draft-ietf-ccamp-lmp-wdm-03.txt
  • - draft-ietf-ccamp-sdhsonet-control-03.txt
  • - draft-ietf-ccamp-gmpls-g709-07.txt
  • - draft-ietf-ccamp-gmpls-tc-mib-05.txt
  • - draft-ietf-ccamp-gmpls-te-mib-05.txt
  • - draft-ietf-ccamp-gmpls-lsr-mib-05.txt
  • - draft-ietf-ccamp-gmpls-recovery-terminology-04.txt
  • - draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt
  • - draft-ietf-ccamp-gmpls-overlay-04.txt
  • - draft-ietf-ccamp-gmpls-recovery-analysis-03.txt
  • - draft-ietf-ccamp-gmpls-ason-reqts-06.txt
  • - draft-ietf-ccamp-rsvp-te-exclude-route-02.txt
  • - draft-ietf-ccamp-gmpls-recovery-functional-02.txt
  • - draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt
  • - draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt
  • - draft-ietf-ccamp-crankback-02.txt
  • - draft-ietf-ccamp-gmpls-egress-control-02.txt
  • - draft-ietf-ccamp-gmpls-alarm-spec-00.txt
  • - draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01.txt
  • - draft-ietf-ccamp-tunproto-00.txt
  • - draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt
  • - draft-ietf-ccamp-gmpls-segment-recovery-00.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

    Current Meeting Report


    Agenda bashing - Adrian

    no new RFCs since Seoul. Waiting for Aug 9th to push a bunch of stuff through. G.709 with Alex (AD). Will publish 15 RFCs once done.

    Bunch of drafts not being covered today:

    JP's router capability stuff. Need some discussion on list.

    JP's loose path reoptimisation. Is this something we want? interdomain but with intradomain usage. <10 hands showing have read it. Will go to list to check we're happy before taking into WG.

    Alarm info. Said on list a while ago that considered it done and considering WG last call. anyone objecting to last call? No.

    Crankback and route exclusing waiting for multi-domain. Both have implementations.

    Tom and Adrian will sit down this week to work on MIBs. Lack of interest so far. Anyone MIB-interested willing to help?

    Tunnel trace - no interest shown at all.

    Link bundling - perhaps needs a clarification draft to show what was intended.

    MPLS/GMPLS migration/interworking is something we ought to care about (will be networks that need to talk and perhaps gradual migration). Needs review and comment from WG.

    Useful new draft on misconnection analysis. Authors planning new rev so now's a good time to comment on-list.

    Survey for mesh restoration. Fair bit of input, would be useful to get feedback from SPs who'd be answering the survey and from implementors (who'll want to know what to implement). Feedback on list or to authors would be good.

    Q (Vishal). Diverse path routing draft?

    A (Kireeti). Have a set of slides on inter-area strategy.

    Milestones - Kireeti

    Going well but got the year wrong!

    There will be one more revision of protection/restoration.

    Minor edtis needed on ASON.

    Will talk later on strategy for inter-whatever.

    GTTP is stuck. People who were driving have driven away. Need to poll authors and WG to see if there's any interest. if not will take off the charter.

    Minor edits for ASON routing reqs.

    Need to talk about charter. Adrian went over much of work that needs to be done.

    Promised us again that MIBs will be done. Can't progress standards work without MIBs. Need to close off ASON stuff, multi-region and protection/restoration. Various misc. docs that are WG docs so we need to decide whether to complete or drop.

    Need to realise how much work we have on our plate before we add more work.

    Clarification required on label allocation for different switching types. Also on how to take the switching/encoding type into consideration when doing CSPF. Might need to modify old docs, do new ones, or do "clarifications" doc.

    New work items

    MPLS/GMPLS interworking/migration. e.g. two ways to signal a PSC label (MPLS or GMPLS). Need to work it out and have migration path. Putting on charter will help.

    Inter-domain signalling/routing. Already working on it. Nice to have a work item explicitly saying it.

    Big one is L1VPN. SG13 have said they're working on it. Want the same relationship with SG13 as we're trying to forge with SG15. They do reqs, we do protocol work. But who is "we" - just someone in IETF. One option is a new WG. Other option is to do in CCAMP. If we do in CCAMP it will take the following (note two issues - is this a good summary of work to be done, is this what we want to do in which case take to ADs who hopefully will say no):

    Once we get framework/applicability done then:

    Do protocol work. Will have to liase within IETF (e.g. with L3VPN WG as have VPN discovery and CE-PE ID exchange docs). Also with ITU-T. Of course if we have routing extensions then OSPF/ISIS will get involved.

    If we go down this path then we need a design team.

    So plan is :

    1) take to list to see if have consensus in CCAMP for charter extension.

    seemed enough hands to take to list.


    Have 3 drafts. 2 gone through AD review. Last one on Alex's "to read" list. Just before this meeting couple of people pointed out that there's a disconnect with key ITU spec. So DT needs to sit with these people and figure out what disconnect is and how significant it is. Will attempt to start discussion this week (face to face).

    Dimitri - RSVP-TE for ASON

    refreshed since last IETF.

    2 discussion points:

    Is the definition of link capability usable in wider scope?

    Can we define the notify message usage in detail?

    Doc has been shown to be stable. Needs editorial review ASAP.

    Aim was to be ready for last call post San Diego.

    Dimitri - ASON Routing DT

    Aim is to evaluate routing protocols against ASON routing requirements.

    Need to elaborate the applicability scenarios. DT looking at two scenarios. If anyone has a good scenario that needs to be addressed they can pass it to the DT.

    Result of evaluation will be integral part of draft.

    First cut at Adrian's website.

    ToC of reqs.

    Needs scenarios and needs user community to feed scenarios in.

    First CCAMP WG doc needed by end of this month so will have to push hard.

    Will be liased with SG15/OIF to get inputs before doing protocol work. Need to focus on the evaluation work.

    Q (Zafar). One comment regarding template. Would recommend not having reqs section as already have a requirements doc. If repeated it can become confusing.

    Dimitri - want at least to have pointers to the requirements. That way people have in mind the scope of the architecture. Structure of doc may change.

    Don Fedyk - Transport review of LMP.

    Aim is to facilitate ITU/IETF communication. Issue with discovery is involves databases used to control optical networks.

    LMP discovery is there to find a TE link.

    Documents ITU discovery terminology.

    Idea here is to document "secret decoder ring".


    1) Clarified G.7714

    2) TE link definition.

    3) General clarification.

    Think is useful for IETF people to understand where ITU-T discovery procedures are and vice-versa. Hence requesting is WG doc.

    Q (Vishal) - any attempt to work on discovery procedures or does this just clarify definitions?

    A (Don) - just informational. Stories on either side aren't complete yet. So will live until those are solidified. Not aiming to define here.

    Q. (Vishal) - Think it is a good doc. Is there any work to unify the procedures or do procedures here to mirror ITU work?

    A. (Kireeti) - first thing is identifying the secret decoder ring. Show diffs between ITU and IETF. Second is to start series of liasons to SG15 (or whatever) to figure out if we fix it, they fix it, or work together. So get better picture of how to proceed. But right now need to understand each other.

    Adrain - have heard comment about it being good and useful from many people recently. fits in charter. would like to see it as a WG doc. show of hands!

    handful of hands. (Adrian thinks reasonable). Nobody saying should not be WG doc. Take to list.

    Wesam Alanqar - ITU-T SG 15

    Various links to liason info.

    Picture of optical control plane (ITU-T SG-15 Q14/Q15)

    ITU-T wants to thank CCAMP - especially ASON reqs DT for capturing reqs for link-state routing. Q14 wants to extend this. Analysing OSPF/IS-IS/PNNI for use in ASON. Encouraging work with different standards bodies to look at implications for routing protocols. Have template for this.

    Q14 thinks a cross-body DT may be useful to look at use of IETF routing protocols. Similar to the ASON routing reqs. DT. Various things to look at.

    Recent docs finished in ITU-T:

    G.7715.1 on Link state reqs for ASON
    G.7713 call connection mgmt.

    Meeting Nov 1-5 in Berlin. IETF welcome to come. Contact Kam Lan for more info by 24/9. Contributions by 25/10.

    Q. (Zafar). Last IETF had discussions on OIF also.
    Do chairs want to comment?

    Kireeti - what do you want to talk about?

    Q. (Zafar) What's the feel of liason with OIF? Is it progressing?

    Kireeti - No formal liason relationship with OIF. Been communicating. OIF has asked for formal liason. Figuring out what needs to be done on each side. Most interesting is to synchronise routing work. ITU relationship is good - ITU does reqs, IETF does protocol work and liase back. Would like to do same with OIF either formally or not. Form of relationship still to be figured out - but again want OIF to give us reqs, we do protocol, they say if is good. avoids redoing work.

    Q. (Monique) - OIF meeting last week. Trend towards OIF/ITU alignment as well as OIF/IETF. will be contribuition to that effect.

    Adrian - we'll try to nail down the lacuna in comprehension for requirements after meeting.

    Protection drafts - Adrian

    3 drafts. Been through WG last call and marked up. With chairs (Kireeti) to check markups are fine before pushing forward.

    Dimitri - RSVP-TE extns for e2e GMPLS-based recovery

    v01 submitted in may.

    have addressed issues raised on list:

    1) mis-ordering during secondary LSP full instantiation (8.3)
    2) preempt resource of lower pri LSPs when protecting LSP activated (10).

    Updates since v00 addressing concerns/expectation.

    Need to check sec 13 (external commands).

    Check Implementations status out there, external commands still open.

    Once that issue closed then we can go to last call.

    Also had editorial review already.

    Adrian - so not quite ready for last call?

    Dimitri - we should see whether impl. of section 13 is also there then respin with or without that section.

    Q (Zafar) - Later on will work on inter-as recovery. would be good if this doc addresses intra-region. is that (or will it be) stated in the doc?

    Kireeti - base spec doesn't say so won't start now keep separate.

    Q (Zafar) - Issue on reoptimisation of bidirectional LSP.

    Adrian - not sure this draft is relevant to that. Worth having discussion, but distinct from this.

    Lou Berger - Extensions to GMPLS RSVP graceful restart

    Arun's draft. Lou's reordered a couple of slides.

    Merged draft (following consensus from Seoul). (draft-aruns and draft-rahman).

    Major change is addition of support for improved scalability. In Aruns original draft every piece of state had to be sent. Now can use summary refresh to decide which pieces to resignal. Way this is done is that node adj. to restarting node can send back path message from restarting node so restarting node can recover the state it originally advertised. Big step forward from (RFC)3473. In 3473 no way for ingress to recover state. As compared to prev. version only sends state that is needed. Use summary refresh for this. Have added recovery path summary refresh so restarting node can just look at stuff it hasn't kept across restart. If adj nodes support this extn (can discover that) then can use these procedures.

    To do:

    1) Need to agree message type

    2) discussion amongst authors about adj node startarts. If two adj nodes restart then how does 2nd one know the 1st is in restart condition. Impacts sending of path msg and recovery labels. This is a broader problem than just this draft. Applies to 3473 independent of these extns. So issue is both what to do and where to do it.

    Next steps:

    Authors think ready for WG doc. Chairs?

    Kireeti - how many people have read this. Scattering.

    How many thinks it should be WG doc - most of them

    How many opposed - zero.

    some support - take to list.

    Kireeti - one comment on adj node restart. Most other protocols don't care about this. Idea is that if lots of nodes restart at once then your network is screwed anyhow. With OSPF nodes abandon restart if that occurs. BGP, OSPF, IS-IS and prob LDP do this.

    Lou - not all that difficult to do. One prob is where put recovery stuff in path msg. Other issue is timer adjustments if you see your neighbour restarting. Could argue is in 3473 already - may just need clarification. But good comment.

    Adrian - chairs in violent disagreement over Kireeti's last comment. Highlight is that restart is complex as well as important. There are people out there who do a lot with it.

    Zafar Ali - Node ID based RSVP Hello

    Incorporated feedback from mailing list and Seoul discussions.

    Remaining work is minimal.

    Draft is short/straightforward.

    >=5 implementations.

    Some inter-op testing done.

    want to do WG last call.

    Adrian - who's has not read the draft who is responsible for MPLS/GMPLS impl. Lou.

    Adrian - have met all criteria to go forward. Authors happy, draft stable, comments dried up. So will debate last call on list.

    Kireeti - Multi zone

    2 drafts for this. Issue is what is a zone - IGP area, AS, tech domain, protect domain.

    Also want to have one way to do this - esp as both drafts were RSVP-TE based.

    Single common doc now. Many iterations/rewrites. Now one mechanism with diff options.

    have functional docs:

    1) Framework (not on slide)
    2) signalling
    3) path computation
    4) (not a doc) BOF on PCE to look at other ways of doing this (run by Adrian and JP).

    Need more docs:

    1) Applicability - what options to use for a given req.
    2) Stitching. Similar but different to nested LSP. Does it become a separate doc. Certainly need doc on it.

    Debate on protection/restoration and diverse routing inter-domain. Aim is to get base spec out. Once stable work on diverse path setup across domains.

    Vishal - have had discussion on list. Basic req in reqs doc is diverse path routing. Could do solution for single path routing that might not work at all for diverse paths. Suggestion is to break up items and push diverse path routing etc. into "advanced applications". Needs to be taken into consideration for signalling/routing. Need to look at problem together and not separate.

    Kireeti - what we've done (successful so far). Did base spec for signalling and had separate DT to do protection/restoration. Base spec for routing, and added on stuff afterwards. If you can give us a concrete example of where this won't work then we'll look at it.

    Vishal - not just me. SPs want to link it together.

    Kireeti - fine. That's one opinion.

    Vishal - not resolved yet.

    JP - this has been taken into consideration. scenarios 1 and 2 for path computation consider this, so already part of base spec. Not true to say it has been excluded.

    Vishal - but not being discussed. Draft says it is advanced application. This shouldn't be.

    JP - not being excluded.

    Kireeti - not taking off the agenda. Will do it but want to get base spec out. Want to leave room in spec for other applications (not just diverse path routing). But doesn't mean we have to spec that out now. If JP's done the work to ensure it's possible then Kireeti's happy.

    Vishal - I raised Qs on list which weren't answered. Especially regarding scalability. Is not even clear how single path works.

    Arthi - what do you mean by "let's get base spec out"? Currently docs aren't even WG docs. I think Vishal is saying at least we need to move forward to some extent with base docs. They're just individual contributions right now.

    Kireeti - that's what I'm saying. Not vishal

    Adrian - nobody's saying we'll take unprotected to RFC before we even look at protected stuff. We're rather saying we want to understand unprotected before we understand protected since latter is built on former.

    Vishal - issue is diverse paths. Doesn't work if you build on single path approaches. Diverse paths is a key issue - so consider at the beginning, don't retrofit.

    JP - that was the case.

    Zafar - to answer Vishal there are enough cases to show that base stuff works and is extendible for future. Crankback is an example. Lots of stuff needs to be done later, and need stake in ground for base work with enough hooks. Nothing is excluded today.

    Dimitri - can we make it clear that as docs are extended they take G of GMPLS into account.

    Lou - question re stitching?

    Kireeti - details have to be done. That's not a question. Question is is this new draft or existing drafts.

    Vishal - are we going to poll the WG?

    Kireeti - can I finish my slides first?

    Kireeti again:

    how to progress:

    Have an idea of what docs we need.

    Reqs came from TEWG.

    In light of proposed solutions should revisit the TEWG reqs. and check reqs are reasonable.

    Sep docs for sep. functions (signalling/path computation/poss. rechability).

    Progres each doc separately - but may send for RFC as a block.

    Once have base spec done will look at re-optimisation and diverse paths. Want to do base spec first. If in our evaluation that isn't a major retrofit then will progress base spec while working on rest in parallel. If turns out is a major retrofit then will halt progress and retrofit first.

    Vishal - my point still stands.

    Kireeti - we've heard it several times.

    Vishal - so what are you going to do?

    Kireeti - nothing.

    Vishal - but WG hasn't been polled.

    Adrian - WG chairs exist to judge consensus. We believe we have judged it and the right way to do this technically. You're welcome to disagree and build an opinion against it.

    Vishal - want to get work done not build opinions.

    Adrian - so do we.

    Vishal - so what will we do about diverse paths?

    Adrian - keep draft alive as a private draft. Then have basis when WG ready to take on. That's good.

    Kireeti - you might be missing that the difference in what you're saying and what we're saying is just sequencing. We want to do a then b. you want to do in parallel. If we find that base doc needs major retrofit then we'll halt it.
    We need to have a tech reason for doing this, and don't have a base doc yet.

    Vishal - so can keep individual docs going?

    Kireeti - yes, renew it every 5 months and 29 days.

    Adrian (with chair hat removed)

    Had couple of proposals for inter-region/inter-AS TE a while back.

    Ended up with a useful, but long, draft.

    Have split into diff parts. JP and Arthi will talk about soln. specific texts.

    This draft is just framework to point to what you could do.

    Key is defn of a domain:

    seems necessary to extend this beyond just IGP areas and ASes to protection domains and zones of limited TE visibility. So domain is a loose concept.

    Aim is not to recommend solution but to break problem down to show different ways of signalling, path computation and routing.

    Describes some "easy" advanced features and applicable to MPLS/GMPLS.

    Not attempting to look at harder issues (e.g. diversity, OAM, P2MP).

    Not making judgements as to why you'd pick one method rather than another (or documenting those methods/solns).

    TEWG produced two reqs docs. had quite a bashing and rework. Question is whether we're happy to freeze the docs as RFCs or keep alive as do solution work in case we find ambiguities/contradictions and need to fix them. Adrian prefers to say they're done but keep them alive in case need to fix.

    Issue on GMPLS reqs (TEWG reqs were MPLS only).

    Issue of bringing complex functions in. Option might be to start work on partner draft for framework for more complex functions.

    Authors are asking if we need a WG framework, if this is the right WG framework and if this is the time to make it WG doc.

    Dimitri - if we combine TEWG reqs with GMPLS reqs does that mean we have separate reqs. Or do we just extend TEWG reqs. for GMPLS. Or do we merge MPLS/GMPLS drafts?

    Adrian (speaking as an author) - think we need to understand if GMPLS reqs are different. If they're not in existing reqs drafts and are not contradictory then don't care much where we do them (but 3rd draft might be good for GMPLS extns to requirements - allowing people to do MPLS alone). PSC will probably be done with pointer to MPLS.

    Richard Rabbat - interdomain OAM you're saying have reqs for LSP ping or poss. GTTP. Would GTTP solve problems? Want to see if we can increase importance of GTTP in WG.

    Adrian - people have commented that one issue with MPLS was that OAM was left until later as a req. We need to start to look at multi-area OAM reqs. May take us down GTTP path. Not clear that because we have req that anyone will want to work on GTTP.

    Richard Rabbat - agree but may need to keep alive.

    John Sadler - thanks for draft, helps identify gap on ASON. Additional req for ASON is identified. Not sure where to capture as has ramifications to signalling.

    Adrian - expect over time to have overlap in ASON DT and this work.

    Q.(?) - discussion on converging inter-area and intra-area. WG has decided not to. I support sep draft for GMPLS. Makes docs much more scalable/readable. 2nd q - you said that the diversity/reoptimisation isn't part of base spec. But should include as is already being talked about in converged signalling draft.

    Lou - for each MPLS solutionn doc (JP's)?

    Arthi - read more carefully. Not all reqs are solved. But want a single solution doc for MPLS and GMPLS.

    Anon - liason to ITU would be good.

    Kireeti - how many have read? Good number. How many like it? good number. Only vishal thinks is not ready?

    step 1 is take to mailing list but note consensus in room.

    will do for other docs once presented.

    Arthi inter-domain MPLS TE RSVP-TE extns

    As requested by WG at IETF59 split doc into 3. This is one of the solution docs (signalling). JP's draft does path computation. Will have applicability doc ready for IETF61.

    Idea was to only look at signalling aspects for interdomain TE LSP setup. Looks at contiguous, nested and stitched LSPs.

    Domain def. is aligned with framework (i.e. very flexible).

    Intention was GMPLS/MPLS applicability (packet and non-packet). May be some gaps.

    Cover other aspects - ERO processing, FRR, re-optimisaton (just talks about signalling issues wrt re-optimisation).

    3 signalling methods (contig, nested, stitched). Needs two bits to ask for contiguous LSP or stitched LSP. Latter is set by head end LSR of segment (not e2e LSP). Has a corresponding bit in RRO attributes.


    enables packet LSP to get right label exchange between egress and penultimate nodes.

    don't want to have label exchange over LSP segment hop.

    allows ingress to be notified that egress has done the right thing.

    similarity to hierarchy - uses non-adj signalling and all signalling extns. Can use segment as FA-LSP (but is a special case as can only carry one LSP).

    differences are one-to-one nature. Lack of label exchange over segment. no b/w reservation on segment. Either have b/w or you don't - so is exact match.

    Need to clarify similarity/diffs in doc.

    1st question is how head end can control downstream choice of signalling method. Some discussion on mailing list (incl CCAMP). Discussed in context of inter-area reqs. No conclusion on thread - are we OK with that? If not OK then what do we do?

    2nd question is GMPLS. Need to clarify this better. Do we need any more signalling for it?

    3rd question is whether we need a stitching draft. Doc talks about stitching but might need clearer applicability. should that be in this doc or in a sep draft.

    Next steps:

    No major changes expected as basic issues finalised so would appreciate more feedback.

    Since ready (bar a few clarifications) want to know if chairs/WG think is ready for WG doc.

    Vishal - good to have some clarification of stitching in this doc. Later we can see if need a diff doc. Same for GMPLS - put more stuff in for now.

    Adrian - thanks Vishal, you've just made the same 2 comments the chairs wanted to make.

    Alia - need more detail on stitching. perhaps in a sep section. For instance nowhere does it say how you correlate intra-domain LSP to inter-domain LSP.

    Adrian - will ask authors to tidy up GMPLS, break stitching out into sep section. Bring back for consideration as a WG doc.

    JP - path computation methods

    Proposes two methods for packet/non-packet LSPs.

    Aim is to fulfil both inter-area and inter-AS reqs from TEWG.

    overview of two scenarios:

    1) per-domain path computation - do path on per-area basis. Head end to first ABR, 1st ABR to next, last ABR to egress. Could be areas, could be ASes. Can discover next-hop dynamically, using heuristics, policy etc. Or can specify loose hops at head end or abstract strict hops (list of ASes etc.)

    2) End to end shortest path computation using PCE. Head-end sends request to PCE. Recursively construct shortest path where tree is rooted at tail end. Welcome to come to PCE BOF. Draft talks about how to signal from head end to PCE.

    Note that both scenarios can work together. So can have policy to control set of ASes but use PCE intra-AS (for example).

    Want to restate that we don't require flooring across domains. No impact on scalability.

    Have proposed optimisation to flood inter-AS TE info. Reduces probability of call setup failure (increases as load increases and as you have more ASBRs) so can reduce call setup time. ALso reduces number of ERO expansions and gives more optimal path selection. Note no IGP impact.

    Need to elaborate more on applicability - will do this in separate draft.

    Again want to point out that inter-AS and inter-area are very similar (only difference is inter-ASBR link in the first case).

    Nothing too specific on FRR except for inter-ASBR link and ABR/ASBR failures.

    separate draft for re-optimisation of contiguous TE LSPs based on scenario 1. Proposing soln for scenario 2.

    For stitched/nested this is a local reoptimisation intra-domain.

    Will discuss more tomorrow about how to signal from head end to PCE. 3 ideas already on IGP-TE capability (in CCAMP, ISIS, OSPF).

    SPs will come up with ID for next IETF on BCP for security/confidentiality.

    next steps:

    New ID on applicability.

    Progress signalling and path computation IDs (and make WG docs).

    Q (Bijan Jabbari). Not so sure that need to standardise optimisation algorithm. Specifically as long as can exchange parms between ASBRs that should be enough. Need to discuss more on Thursday.

    JP - will discuss more on Thursday. What we want to agree is method for sending requests. On PCE itself can use CSPF and various optimisation criteria. No need to standardise.

    Q (Vishal) - does inter-area optimisation apply to 1 and 2?

    JP - if you don't flood TE info between ASBRs then only have visibility to boundary node. So applies to both.

    Dimitri - there is a PCE BOF. What is impact on PCE BOF on CCAMP? If doesn't get progressed as BOF then should we still progress. Can we progress this independently of PCE BOF outcome?

    Adrian - yes.

    Q (ECI Telecom) - regarding applicability statement, will there be recommendation on impl. issues (e.g centralised/distributed PCE). Or will this stay open? Often standards say which of options is most endorsed.

    JP - like RR for BGP can be put on a router that also does forwarding, or not. so we're just describing fn of PCE - depends on your network design as to where you put it.

    Kireeti - so are you asking if applicability spec will recommend centralised or distributed. Ideally in applicability spec will just say "here are options, and here are scenarios that work for each of them". Won't have global recommendation.

    Richard - your ASCII figures are hard to follow. Can you please clean them up or do PDF?

    JP - we'll fix it.

    Adrian - need to suspend decision on moving this forward until after PCE BoF.

    Tomohiro Otani - TE parms to be exchanged


    fits charter item on signalling/routing mechanisms for paths spanning multiple areas/ASes/providers.

    clarifies need for dynamic/static info exchange and reqs. for TE parms.

    SP proposal. KDDI and NTT already interconnect at L1, L2, L3. Need to set up paths while hiding internal topology.

    Assumption is 2 GMPLS ASes. AS1 knows its topology and AS2's border routers/reachability.

    Once create LSP from ingress to egress. If AS 1 only knows AS 2 reachability then how does it get shortest path in AS 2. AS 2 may send back path err if constraint can't be met. So may need non-shortest path in AS1 to then get to border router which meets constraint in AS2.

    Of course have whole bunch of constraints (switching capability, encoding type, bandwidth, SRLG etc.)

    GMPLS border nodes announce end-pt reachability with the constraints met to those end-points.

    To get resilient LSPs may need globally significant SRLGs.

    Next steps:

    1) Add GMPLS EGP reqs. (so need BGP experts). And will look at extra load here (suggested by Adrian). May need light mechanism for dynamic exchange of info between ASBRs.

    2) Go for WG doc (need to do 1 first).

    3) Will look at any BGP extentions

    4) Will look at how to get SRLGs that are globally consistent (bit assignments).

    Adrian - is this really limited to GMPLS? Or can it apply to MPLS TE?

    Tomohiro - limited to GMPLS, but could expand to MPLS.

    Adrian - bit of a contradition between reqs. here and in TEWG docs. In as much as discussion here on distribution of TE info inter-domain we are going to have to resolve the contradiction. Adrain thinks is good. JP doesn't.

    Zafar - next steps slide. would like to tie this to GMPLS reqs before doing solution.

    Tomohiro - yes would like to do GMPLS reqs first.

    Arthi - I think we need to start discussion about whether BGP would req this for MPLS as well as GMPLS.

    JP - It's not that I think this isn't good. Am just trying to reflect what the TE reqs draft says. Aim is not to leak summarised TE info inter-domain.

    JP - the draft seems to flood quite a lot of unsummarised info. Big req of SPs is to preserve confidentiality. How do we sort that out?

    Tomohiro - we don't want to flood all info to other ASes. So we need summarisation in each AS.

    JP - do you think can both summarise to preserve confidentiality and have enough info to be useful?

    Kireeti - as I understand it this isn't summarisation. It's more passing switching caps so don't attempt what isn't possible. Is quite useful for L1VPN. Could be used from CE to CE in L1VPN. Answers first q on leaking constraints. RTs etc. can be used in VPN. So can be used inter-AS and in L1VPN.

    Susan Hares - thought I heard mention of ORFs.

    Kireeti - no, just RTs - for L1VPN.

    Susan - so we haven't settled on RTs, ORFs etc.?

    Arthi - can we say that this is basically an optimisation to per-domain path computation to reduce crankback?

    Kireeti - yes.

    JP - that's exactly back to my question. To reduce crankback you have to summarise info from other AS, but then you break confidentiality and scalability.

    Adrian - so potential tradeoffs and we need to work on them.

    Anon - there could be networks that want to transfer all the data across ASes (e.g. research networks - where 2 ASes don't mind sharing info and security is achieved in diff fashion). Providing network summary isn't sufficient. Need to provide more info to get optimal path across ASes.

    Adrian - come to PCE BoF and we'll debate this.

    Vishal - are we going to work on reqs. for GMPLS TE? Is anyone doing it?

    Kireeti - yes, but nobody is doing it yet.

    Dimitri - GMPLS for L2LSPs

    Changes since last version:

    Explain motivation for L2SC LSPs (RFC3473)

    Generalised to any L2 (ATM/FR/ETh etc.)

    New L2 TSPEC FLOWSPEC etc.

    L2 label spaces and encoding all details are in the doc.

    General feeling that's worth spending cycles on this.

    Think it's a good basis for the work.

    How is consensus wrt WG doc?

    Kireeti - GMPLS charter covers this implicitly, but want to make it explicit and then take this to WG doc.


    Progressing "under care of CCAMP". Submitted applicability. Idea is to show how we use GMPLS and deltas from "normal" GMPLS.

    Few issues in framework.

    In summary existing drafts cover most of applicability. Identified 7 items that may need more work.

    Next steps - covered some of this at start of meeting. But need to discuss on L1VPN list and CCAMP list. Want to make L1VPN part of CCAMP. 100 subs on L1VPN list and expecting protocol work to be minor. Good links to ITU-T etc. Want feedback.

    Hamid - good work has been done on L1VPN for applic/framework/auto-discovery/use of GMPLS.

    Anon - want to observe that am looking forward to huge market for lambda services and more and seems like a good idea to do in a different WG. Can we do that without huge admin overhead. More issues will come up once this gets publicised.

    Lou - segment recovery

    biggest change from last meeting is that draft became WG. Also bunch of minor fixes (some coming from list discussions).

    2 comments not integrated:

    1) more words needed on RESV processing of notify request object. Good text for path so need equivalent for RESV.

    2) internal discussion on FRR interaction. Need more words there.

    One other comment - know of 2 implementations; various stages of maturity. Would love to hear of others.

    Zafar - 2 things I'd like to see:
    1) info on local recovery
    2) applicability for FRR. Pros vs technique described here.

    Lou - if you can enumerate reqs and contribute text that'd be great. As for applic statements they are in sep docs, so perhaps we need companion draft.

    Richard - adrian sent email re misconnections being living list against which protection mechanisms are tested. Have you checked against that?

    Lou - no. Might be dimitri and others have.

    Dimitri - is ongoing. In next release will have conclusion.

    Zafar - graceful shutdown in MPLS-TE networks

    reqs - this is problem that NSPs try to solve today using ad-hoc mechanisms. Problem is resources in nodes/TE links. Want to upgrade node. So how do we divert traffic to other places in network so that we can do the maintenance. Currently SPs play with IGP metrics etc. Problem is that can be inconsistent. Also not applicable to inter-area or inter-AS. This ID puts togeher framework for existing mechanisms to do graceful shutdown of TE link or node.

    Draft is straightforward. Talks about IGP and RSVP-TE mechanisms. Issue is IGP isn't applicable to inter-area or inter-AS. RSVP-TE only sends info to nodes along path.

    changes are minor and rely on existing framework.

    RSVP-TE mechanism

    IGP based mechanism.

    Have had feedback and will publish next rev by end of aug.

    can we be WG doc?

    Arthi - not entirely fair that this is based on existing docs. Loose hop reoptimisation not defined elsewhere. Might be better to add here than to add elsewhere and then claim we are using other mechanisms. Also there are existing mechanisms which are used today for graceful turn-off of links at least in GMPLS networks.

    Zafar - all fair comments. Can take comments re other draft offline.

    Adrian - let's discuss offline once have a respin and take it from there.


    Complete ASON drafts
    ASON Signaling Solutions
    ASON Routing Solutions Design Team status
    A Transport Network View of LMP
    SG15 liaison
    Protection Drafts in AD review
    End-to-end recovery
    Graceful restart
    Node-id-based Hello
    Inter-domain Framework
    Inter-domain RSVP-TE
    Inter-domain TE LSP path computation methods
    GMPLS Inter-AS requirements
    Layer 2 GMPLS
    Layer 1 VPNs
    Segment Recovery
    Graceful shutdown