Sixty-eighth IETF, Prague, March 2007

Monday, March 19, 2007
0900-1130 Morning Session I
RTG    ccamp    Common Control and Measurement Plane WG

CCAMP Working Group Minutes, Session 1 of 2
===========================================
CHAIRS: Adrian Farrel 
        Deborah Brungard 

Note takers: David McWalter, Lyndon Ong

Adrian opened, gave Note Well, noted that ccamp will meet *twice* in
Prague.
These minutes cover the Monday am meeting.
Second meeting tomorrow, Tuesday 1pm.

=======================================================
0. Administrivia (chairs) [5 mins: 5/150]
Slides 

Adrian asked for comments on agenda - none, for either session.
=======================================================

=======================================================
1. WG status, RFCs, drafts, milestones (chairs) [10, 15/150]
Slides 

--0905 Adrian gave draft status.  Plenty of work, progressing well.
       6 new RFCs, 4 in editor queue, plus Crankback draft has just been
       sent to the RFC editor.
       Two drafts (rsvp-te-call and rsvp-restart-ext) are tied up in
       IESG review, both on security questions.
       3 drafts in WGLC.
       gmpls-addressing and te-node-cap are ready for last call (Adrian
       believes the latter is already implemented and deployed).
       ethernet-traffic-parameters seems to be stable
       10 more on today's agenda, 4 in pipeline.

Dimitri at mic: commented that some discussion was ongoing as a result
       of OIF liaison.  Adrian suggested closing with Lyndon offline,
       Deborah commented that we could close this in tomorrow's meeting.

--0911 Deborah presented an update on draft-andersson-rtg-gmpls-change,
       which has just been approved as a BCP.
       Adrian noted that this commits ccamp to do work sometimes.  The
       idea is that it encourages other SDOs to bring work to ccamp.

       Deborah went through charter milestones.  We're 'only just
       behind'.

--0913 Adrian recapped GELs progress.  This will make up the first 30
       minutes of tomorrow's agenda.  GMPLS enhancements are required,
       and will happen in ccamp.  Dataplane enhancements will not happen
       at the IETF.  Adrian will discuss possible charter changes with
       Ross and Dave (new AD). ccamp will only work on a control plane
       for a clearly specified dataplane.  IEEE is just starting work on
       this under the heading 802.1Qay, also known as PBBTE.  Adrian
       said that because a dataplane specification is *forthcoming*, it
       is okay to start control plane work now ('pipeline' it).
Dimitri at mic sought to clarify.  Adrian replied that there is work
       that can happen now in advance of definition of label format, for
       example the traffic parameters we have already started on.
Dimitri at mic also asked about scope of work.  Adrian replied that we
       should look at things that break 3945 on a case-by-case basis.
=======================================================

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

Note: Discussion of responses to recent ITU-T and OIF liaisons
will fall in the second CCAMP meeting on Tuesday afternoon.

--0917 Lyndon presented ITU-T and OIF liaison.
       Lyndon was not at the ITU-T meeting a month ago, but has talked
       to the chair and quickly summarized the SG15 Q.14 work ongoing.
       Two liaisons:
       #1  Response to CCAMP reply on ASON, including requests for more
           information, some language concerns, and a clarifying point
           about call/connection separation.  There was also a concern
           about use of liaisons versus use of individual participation.
           ITU felt that liason communicated group concensus and was
           valuable.
Monique asked about about overlap SG13 Q5, which also deals with T-MPLS
           management.  Lyndon wasn't familiar with this, but took an
           action to look at this.
       #2  Requested to review the GMPLS call draft and VCAT/LCAS drafts
           before they get to RFC.

--0925 Lyndon summarized OIF status.  E-NNI routing IA and UNI2.0 and
       E-NNI 2.0 signaling in progress.  Again, two liaisons.
       #1  VLAN ID, where OIF wants to carry many VLAN ID 'labels' as
           part of an RSVP signaling message.  OIF members accept that
           possibly this information isn't really part of a label.  The
           EVC is the connection, and perhaps the VLAN ID list is just
           an attribute of that collection.  Lyndon said OIF was open to
           looking at what was the best solution from a protocol
           standpoint.
       #2  OIF documents liaising current state of UNI 2.0 and E-NNI 2.0
           documents.  OIF will send an update when these documents are
           approved and stable.

Adrian said that there is time at the end of tomorrow's meeting to draft
       a liaison back to OIF.
Lyndon said that the VLAN ID issue is perhaps the priority.
Deborah encouraged folks who could not make tomorrow's meeting to get in
       touch with Lyndon.
=======================================================

=======================================================
3. ASON Routing solutions (Dimitri) [10 35/150]
Slides 
Background reading
  - draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt

--0929 Dimitri recapped on progress since IETF-67.  Dimitri stressed
       that there is no implied relationship in these documents between
       MLN and multi-level routing.  This is a problem for
       implementations. There is also a question of technology-specific
       extensions; these will go in separate documents.  The main
       document will stay generic. For bandwidth accounting, a single
       generic mechanism will be defined that will cover packet, lambda,
       etc.  If any more specific information is defined, then an
       extension document can be written.
       Also discussed resiliency and policy.  Dimitri sought to exclude
       some of these points, on the basis that this document is 'a
       protocol spec', but which would support extensions for specific
       technologies or additional functions/management.
       Next steps: ready for last call? what review process?
Adrian noted that there are questions that are not yet resolved that may
       require changes.  Partly by keeping ITU in the loop, partly by
       closing technical discussions.
Igor Bryskin at mic: asked about TE node identification using TE router
       IDs or routable addresses.  Dimitri replied that this document
       wishes to be as simple as possible, and referred to RFC 3630, and
       asked about the rationale for TE router IDs today.  This has been
       discussed on the list, perhaps a couple of years ago.  Dimitri
       stressed that this has been discussed and agreed, and is not a
       new suggestion.
Adrian asked if node IDs were guaranteed routable in the signaling plane
       Dimitri answered noting that they were an identification.
Adrian said he wasn't asking whether it should or should not be routable
       he's just trying to understand.  Dmitri replied they could be.
Adrian asked if a summary would be that the node ID doesn't need to be
       routable, but a wise implementation would make it routable?
Dimitri discussed that it may or may not be by 3630.
Igor said he had expected a shorter answer from Dimitri, and raised an
       objection to the case where router IDs were not routable.
       Discussion between Igor and Dimitri continued.
       Summarizing: Igor asserts that the router ID should be a
       routable IP address.  Dimitri says this is just one
       interpretation of RFC 3630, and other interpretations are
       possible; this is nothing new and it's nothing new that this
       draft is introducing.
Igor asked 'how do you force it [TE node ID] to be routable?'
       Dimitri replied by again referring to RFC 3630.

--0948 Adrian closed by suggesting that a clarification section needs
       adding to the draft, to answer Igor's concern.  Dimitri took an
       action to do this and bounce it off Igor.
=======================================================

=======================================================
4. VCAT/LCAS (Adrian) [15, 50/150]
  - Analysis of requirements
  - First proposal for solutions
Slides 
Background reading
  - draft-ietf-ccamp-gmpls-vcat-lcas-01.txt

--0949 Adrian said that for some reason that is not entirely clear to
       him, he gets to present this draft.  This has been taken on as
       a working group draft.  Notes, there has been a long ad hoc
       mailing list discussion on-going. Greg Bernstein is the main
       editor, but he could not make it to this meeting.  Also there is
       a revision to the draft needed, but this didn't quite happen
       before this meeting.  (Adrian will hit people if there is not a
       new revision soon).
       Requirements are stable, and the people listed in the foils are
       in agreement on this, so should make progress.  CCAMP will need
       to liaise this work to ITU and OIF as it progresses.
       To summarize requirements; allow TDM LSPs to be signaled to
       support virual concatenation. RFC 4606 allows this, but then all
       members of VCG are co-routed.  Now hardware allows VCG components
       to follow different paths.  Need to associate LSPs to form a
       single group, with defined capabilities.  Need a pool of 'spare'
       LSPs that can be added to VCGs at short notice.  Determine ports/
       interfaces at egress that can support VCGs, which is dependent on
       hardware capabilities.
       There are two options for associating LSPs.  Can either use the
       association object (used for e2e), or using a GMPLS call.  The
       latter is favoured, because only the endpoints care about the
       association.  The VCG properties become call parameters, which
       works quite nicely.  The problem that arises is management of the
       spare pool.   It is suggested that this function requires LCAS in
       order to work.
       Determination of endpoint capabilities feels like a routing
       function, but doesn't scale well.  So perhaps only basic node and
       link properties should be advertised via routing, with other
       properties negotiated as part of call setup.
Lyndon at mic commented that the OIF has discussed this recently, and
       that there is a developing view in ITU that the dataplane looks
       like a layer built on SONET/SDH or STM.  Does this mean that a
       separate signaling or routing layer is needed?  This is confusing
       people a lot, because it adds flexibility but also overhead.
Deborah asked Lyndon if Q14 or Q11 was developing this view of layering.
       Lyndon replied that he knows about Q14 but is not sure about Q11.
       It's coming out of a G805 idea that VCAT is a layer on its own.
Adrian commented that LCAS is perhaps a separate layer, so VCG is really
       a client layer, which requests that LSPs are set up, co-ordinated
       and delivered to it as a service.  So all that we have talked
       about is within a layer, but with something above it that says
       'I want VCAT'.
Adrian asked whether we should liaise with Q11 as well as Q14.  Lyndon
       was unsure but agreed.
=======================================================

=======================================================
5. Multi-Layer Networks (Kohei) [10, 60/150]
  - Strategy and plans to complete this work
Slides 
Background reading
  - draft-ietf-ccamp-gmpls-mln-reqs-02.txt
  - draft-ietf-ccamp-gmpls-mln-eval-02.txt
  - draft-papadimitriou-ccamp-gmpls-mrn-extensions-03.txt

--1001 Kohei presented the MLN document set.
       Protocol extensions being defined; for example IACD (Internal
       Adaptation Capabilities Descriptor) TLV added to IGPs.
       There are two approaches to Virtual TE links at present.
       (i) Soft FA, which is a signaled LSP not established in the
           dataplane, and
       (ii) remote association, where LSPs are not signaled, but
            properties are exchanged between FA endpoint.
       These have different pros and cons. Comments have been received
       about Path diversity and SRLG inheritance. Kohei feels no
       protocol extensions are required, but that this is an issue for
       the management plane.  Comments have also been received about
       directionality-ambiguity in adaptation information, but Kohei
       felt there was no ambiguity.
       Next steps are that the -reqs and -eval documents are close to
       WGLC.
       The solution doc is proposed as a WG document.
Adrian is pleased to see this work proceeding again after a period of
       silence. Adrian said chairs should look at the documents to
       ensure they're ready for WGLC, and perhaps liaise them to ITU
       immediately (as they've expressed an interest), and this should
       allow them to respond in time for the end of last call.  The
       timescales for the requirements drafts look about right.  We'll
       poll the mailing list about adoption of the solutions draft after
       this meeting.
=======================================================

=======================================================
6. MIB Module for GMPLS TE Database (Kenichi) [10, 70/150]
Slides 
Background reading
  - draft-ietf-ccamp-gmpls-ted-mib-01.txt

--1009 Kenichi said that Tomohiro Otani could not attend.
       Originally this draft was created as an extension of OSPF MIBs
       for TE, but is being generalized to include both OSPF and IS-IS.
       Recent changes to this MIB module generalize OSPF-specific
       objects, and renames several objects.
Adrian encouraged input from people who are going to implement and use
       this.
=======================================================

=======================================================
7. OAM Requirements for GMPLS Networks (Kenichi) [10, 80/150]
Slides 
Background reading
  - draft-nadeau-ccamp-gmpls-oam-requirements-01.txt

--1014 Kenichi also presented this, as Tomohiro Otani is not here.  He
       explained how this responds to the WG charter item.  It is also
       an issue that there is no definition of GMPLS OAM requirements
       beyond the RFC4377 MPLS requirements.  Kenichi summarized a set
       of possible GMPLS OAM requirements (see slides).
Loa Andersson (MPLS chair) at mic asked about relationship to MPLS OAM
       requirements; is a revision of the MPLS requirements document
       proposed?
Adrian would not want to see anything that replaced or revised the MPLS
       work; would prefer a new document that pointed at the MPLS work
       and stated what was relevant and how they were extended.
Loa Andersson: okay
Dimitri asked a long question about control plane properties, and
       whether there was synchronous access to what it was transporting,
       and whether there were different requirements for circuit versus
       packet, and we should be clear about scope for the future.
Adrian: I don't know.  We should not be specifying Ethernet OAM; it is
       not our business.  But maybe there are questions of co-ordination
       of OAM (for example between different layers) that we could help
       with.  Control plane OAM is clearly ours.  Adrian is struggling
       with this work, and is not clear what there is that should be
       done; Adrian is hopeful that this document will cystalize issues,
       and discussion on the list should make it clear whether there is
       really some work here.
Dimitri worried that we shouldn't put too many purposes together into a
       single document.
Adrian: Good advice.
Don Fedyk agreed with Dimitri.  When it says 'requirements', you need to
       have a technology in mind.  It's good to have a list that says
       what OAM needs to do, but how this is satisfied depends on the
       technology.
Adrian agreed.
Dimitri doesn't want to see overloading of the GMPLS control plane.
Deborah: Suggests look at the document; question of whether GMPLS will
       provide OAM for the dataplane is reviewed by the document; take a
       look at it.
=======================================================

=======================================================
8. Conversion between Permanent Connections and Switched Connections (Diego) [10, 90/150]
Slides 
Background reading
  - draft-ietf-ccamp-pc-and-sc-reqs-00.txt

--1024 Diego: No comments received on the requirements ID since made a
       WG item. For caviglia solution draft, have received some comments
       from Dimitri on the list.  Main problems are with failure
       scenarios during handover, to be solved in a draft update after
       this IETF.
Adrian: We want to see that update, and then decide whether this is the
       solution we want for this problem space.  Any questions? .
=======================================================

=======================================================
9. Multiple Nodes Graceful Restart (Dan) [10, 100/150]
Slides 
Background reading
  - draft-li-ccamp-multinodes-gr-proc-01.txt

--1028 Dan: Summarized changes to draft since -00.  Note that this draft
       now targets Informational status.  Draft is stable, seeks WG
       acceptance.
Adrian: When we were discussing the previous version, there were
       questions of whether this was needed at all.  But there was a
       feeling that it would help people understand GR, and prevent
       needless development of protocol extensions already supported by
       GR.  Show of hands; who would find this helpful? (6 or 7).  Any
       objections (0).
Lou Berger (at back mic) said the document still implies it is more than
       just an informational clarification.  Document needs to be
       consistent with the proposal that no new procedures are defined.
       This is just an educational document, not a BCP.
Adrian: Understand.  We'll discuss on the list.
Ina at mic: I haven't heard any requirement for this work from
       providers.
Adrian: Agree, it would be good to have providers commenting.
=======================================================

=======================================================
10. Graceful Shutdown (Zafar) [10, 110/150]
Slides 
Background reading
  - draft-ietf-ccamp-mpls-graceful-shutdown-02.txt

--1035 Zafar Presented some protocol details that have been discussed:
       One comment on the list was with respect to how to get out of
       graceful shutdown state so traffic can be moved to alternate
       path.  Both MBB and FRR segment recovery have been suggested.
       This has been addressed by saying that PathError must be
       propagated to Ingress, but branch nodes can make local decisions
       about applying FRR.
       Another comment about shutdown of stitched LSPs, which are
       signaled as distinct LSPs in the control plane.  The document has
       been updated with a solution about these and for the case of
       bundled links.
       Finally, overloading error code from RFC 4736, which requires
       LSPs to do re-optimization on receipt of certain error codes.
       This draft relies on optimization at ingress, but extends this
       handling to other branch nodes on the path.  Wording is difficult
       here; anyone with objections should let authors know.
       Next steps, need to address a nit.
Adrian: What is this nit? Zafar: just need to clarify a sentence about
       how something or other applies to a link.
Adrian: Okay, just need to address this in next revision and then will
       be ready for last call.
Adrian: Do we know of any implementations?  Zaar: No.  Adrian: Okay,
       I'll ask on the list and people can reply in private if they need
       to.
Zafar: Thank-you.
=======================================================

=======================================================
11. MPLS/GMPLS Security Discussions
11a. MPLS/GMPLS Security Framework (Luyuan) [15, 125/150]
     Slides 
     Background reading
       - draft-fang-mpls-gmpls-security-framework-00.txt

--1042 Luyuan: There is a large design team for this work (see 1st slide).
     We presented this in IETF-67, and called for interest.  The design
     team then formed.  -00 draft was issued before this meeting.  Will
     be presented at both MPLS and CCAMP.  Why did we start a security
     framework at this point, given what has been done in MPLS already?
     The trigger was that the security ADs and reviewers had questioned
     some GMPLS drafts, and wondered whether GMPLS security had been
     adequately addressed in the past.
     Questions started with p2mp, but then went back to TE and
     fundamental parts of GMPLS.  Ross and others asked for a single
     draft to discuss all MPLS/GMPLS security issues.  Any other drafts
     in MPLS/GMPLS should point to this draft as the general framework.
     Protocol extensions with their own security concerns must address
     them themselves.
     Objective is to make this an informational RFC as quickly as
     possible. Will address security implementation implications for
     several protocols, including LDP, RSVP-TE, PCE, P2MP/LDP, VPNs,
     PWs, inter-provider, etc. Scope is broader than core just GMPLS.
     However, general security concerns will not be addressed (will
     reference existing security drafts).
     Luyuan then outlined the content of the -00 draft.
Adrian: I'm really impressed with the quantity and quality of work that
     has gone into this draft in a short time.
Luyuan: Thanks, it was a team effort.
Dimitri: Wondered about duplication of work between this an rpsec/sidr.
Luyuan: Scope is a little bit fuzzy. Some content will touch on routing
     protocols but this is not the focus.
Dimitri: Further question about assuming modes of operation; should the
     draft state the modes of operation under which the network is
     assumed to run.
Luyuan: Again, scope is difficult. Document looks to demonstrate that
     with proper procedure adding MPLS/GMPLS to a network does not make
     it less secure.
Dimitri: Again sought to clarify which 'running mechanisms' were being
     employed in particular deployments being considered by this
     security draft.
Luyuan/Dimitri closed agreeably.

Adrian: Asked George if this work would be owned by the MPLS WG.
George Swallow: That's my understanding, but Ross can overrule me.
Adrian: He wouldn't dare.
Loa: Agree with George.
Ross: Has no opinion on whether this is MPLS/CCAMP.  Can last call it in
     both. No strong opinion, but tend to prefer MPLS unless others
     object.
Kireeti: Should be owned by MPLS, because some bits are MPLS-specific.
Adrian is happy that someone else is doing the work.
Adrian: Asked Monique about whether this overlaps with work done by
     IPSphere.
Monique (from floor): No.

11b. Security AD issues with TE Calls (Adrian) [10, 135/150]
     Slides 
     Background reading
       - draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt

11c. Security AD issues with Graceful Restart (Adrian) [10, 145/150]
     Slides 
     Background reading
     - draft-ietf-ccamp-rsvp-restart-ext-08.txt

-1058 Adrian: To close, want to look at two drafts going through
     security AD review, related to what Luyuan has just presented.
     There are two major questions about the GR draft.
     #1  What would happen if a downstream neighbour of a restarting
         node sent a false RecoveryPath message, either accidentally or
         as a result of downstream node being subverted.
     #2  What damage could be done to the restarting node control/data
         plane as a result of such a bogus message?
     Adrian has pasted a long discussion thread on this to ccamp list.
     Trust model in ccamp is peer-to-peer; peers with whom messages are
     exchanged are authenticated.  This isn't about attacks from
     strangers; it is about subverted RSVP-TE nodes.  Adrian questions
     why this is of particular reference to GR?  Surely any subverted
     node could take a variety of actions at any time in the protocol
     (for example, corrupting routes in path messages).  Adrian also
     points out that RecoveryPath is verified against the dataplane on
     the restarting node.  There was also a discussion about falsified
     EROs, and what the consequences might be.

     On the TE-Call draft there were issues about Notify messages which
     are end-to-end communication; a new concept?  How are keys
     established with Notify recipients?  Is Notify processing a
     necessary part of call processing?  This leads to a question of
     whether an automated key distribution mechanism is required.
     Security of calls is definitely a concern, but again Notify
     processing is not specific to calls.  Either RSVP-TE security or
     IPeec (if tunneling) can be used to authenticate origin of Notify
     messages.  Can also use RSVP forwarding to propagate Notify
     messages hop-by-hop, which makes use of RSVP peer authentication as
     above.

     For the restart draft, the ADs are not really totally convinced,
     and would like ccamp to describe what could happen if each message
     was spoofed.  This strikes Adrian as being a lot of work.

     For the call draft, an RFC 4107 analysis is asked for.

     Next step will be to have face-to-face discussions with ADs at this
     IETF to try to get these drafts moved forward, and to clarify the
     security framework so this does not happen to other drafts in
     future.

Yakov Rechter at mic: Would it address GR concern if processing was
     restricted to a single service provider (implying same trust
     domain).  Adrian doesn't see that the Security AD would be happy
     with this because he is talking about node subversion which could
     be in a domain.
Yakov: Indeed, what would happen if all your routers were subverted?
Adrian: I don't know.

Lou: (commented about unreasonableness of feedback from ADs)
Adrian: Yes, perhaps ADs will say 'all of your work is broken, stop'.
Lou: Come on, there's history and deployed protocols here.  ADs are
     welcome to say it's all broken, and there is a new work item to
     make a working protocol to address all this.  We should push back
     very strongly, and not let this stop us from doing our work.
Adrian: Thanks.

Dimitri: Tried to clarify what the questions being answered were.

Ross: I'm trying to figure out what I should actually say.  I don't want
     to get shot.  I have mixed feelings.  When my laptop boots up, it
     says 'you might be infected'.  Actually I know my laptop is
     infected.  Routers might be too.  It's not hard to infect routers;
     administrators use stupid passwords, you can configure routers to
     bring down the network.  However, no vendor is going to implement
     the command 'please send wrong information on graceful restart'.
     The bottom line is that there's not a lot of reason for us to
     define something that no-one has any interest in buying.  That's
     one view.
     Another view is that the internet isn't as secure as it should be.
     But if no-one builds it, there's no point the spec saying it.  In
     the specific case of the restart work, Ross talked to a member of
     the security directorate.  Perhaps we don't need to do anything
     about it, but the directorate would like to know what a router
     would do if it was subverted. Would the conflicting information be
     detected?  We could try to figure out what an implementation would
     do if it got different information from downstream neighbours and
     put that in the draft.  That might be enough for this draft, I
     hope.

Zafar: I'm a little bit concerned about the notify message.  There's
     something you mentioned about making it hop-by-hop, but this would
     be more like a PathErr message.  Could you specify what you mean?
Adrian: On notify, RFC 3473 specifies these two methods, and points out
     a way to do security is hop-by-hop.
Zafar: Has concerns with this.
Adrian: Yes, but these are tradeoffs you may need to make to get e2e
     security.

Yakov Rechter: Wanted to respond to Ross's point about how things only
     get implemented if people are prepared to pay for it.  It's
     presumptious to say that 2 or 3 people in the IESG know what's good
     for everyone.  The IETF needs to address this problem.

Adrian: Watch this space.  Ross and I will report back to the mailing
     list after we've held our side-meetings.

Zafar: Every node does local checks it can do against the ERO.  If every
     node does that (I think implementations do), much of the
     information passed by the neighbor is checked.


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

1121 Adrain: Okay, if we're done then perhaps this is a good time for
     folks interested in MEF to gather at the front and talk about it.

     We're done, see you tomorrow.
**********************************************************
**********************************************************
Tuesday, March 20, 2007
1300-1500 Afternoon Session I
RTG     ccamp     Common Control and Measurement Plane WG

CCAMP Working Group Agenda Session II
======================================
CHAIRS: Adrian Farrel 
        Deborah Brungard 

Note takers: Giles Heron, Julien Meuric, Tomonori Takeda
============================
0. Administrivia (chairs) [5, 5/120]

Slides

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

Agenda agreed.

=======================================================
1. Control plane requirements for GELS (Loa and Don) [30, 35/120]

Slides

Background reading
  - draft-andersson-gels-exp-rsvp-te-01.txt
  - draft-fedyk-gmpls-ethernet-pbb-te-00.txt
=======================================================

Don - Fedyk draft (PBB-TE) is rev of PBT draft.  Tracking IEEE work on
      data plane. Project will be approved imminently in IEEE.  Currently in
      the appendix EPEE the data plane aspects are defined.  IETF just defining how to
      use GMPLS for control.

Loa - Andersson draft (GELS-EXP-RSVP-TE) is updated post comments.  Not
      just doc of an experimental implentation (not impl. this version
      yet).  Use GMPLS for "all" modes of connection types (where "all"
      is P2P - not using yet for P2MP though have soln).  Variance with
      Fedyk is have more than one label type.

Don - GELS concluded that needed IEEE data plane.   IEEE doing 802.1Qay.
      IEEE projects are rolled up into larger specs - so Qay will be
      rolled up into Q spec.

Loa - Acreo did 802.1Q-based implementation.  Describes certain
      conditions that we operate under.  Works for 802.1Q.

Don - trying to define superset that will work for other defined
      switching paradigms.

Don - presented "Conventional Ethernet Bridging" and then "Configured
      Ethernet Bridging" where STP is removed and configure connections
      instead. So now have data plane and management plane.  Finally
      GELS - where GMPLS is used to add back the missing control
      plane...

Loa - I looked at Don's pictures and didn't understand them until I
      slept on it!

Don - there is a std for partitioning the VLAN space as part of existing
      project on shortest path bridging...  So will be an official way
      to do it.

Dimitri - when I looked at your "triangle" diagrams.   Issue is we have
          some 802.1 impacts.  Cross-correlation in terms of what you
          can do even if you segment the VLAN space.  That will be the
          major points in terms of getting this accepted by IEEE.

Loa - yes, agree is important to record interactions.  But what has
      happened to me repeatedly is that when I come up with a problem
      and tell the IEEE guys they tell me there's an ongoing project
      that will fix the problem...
      that also needs to be part of documentation...

Don - diagram where remove CP dependencies is part of an IEEE project...

Don - back to GELS motives.  Dave Allen has draft on PW interworking
      with PBT.

Loa - we have draft using MPLS with some G-MPLS extensions on top of L2
      Ethernet and optical L1.  Takes about an hour to learn to
      configure all 3 layers.  If you want to run different layers in
      "augmented" mode where can request services from lower layers you
      have good automatic support here with GMPLS.

Don - We separated components so could e.g. use management plane with
      signalling.  So limited IP control plane for signalling.

Loa - need to be careful not to get packet forwarding through the
      control plane!

Don - LMP is like a superset of 802.1AB link management.  So can
      leverage AB and use LMP.

Stewart - did I hear "sending control plane traffic through the data
          plane"?

Loa - no the reverse.

Stewart - well we mix the two all the time in the IP world

Loa - CP is not dimensioned here to handle data plane traffic.  If you
      don't get costs on links you'll advertise the CP links into the
      data plane.

Adrian - issue is that is bad to send data traffic down control "
         channel", not control "plane"

Kireeti - issue here is that GMPLS is out-of-band, MPLS is in-band CP.

Zafar - how do you solve this?  In GMPLS we normally have completely
        separated CP network and data network.  So no way data can get
        into control network.

Loa - problem here is how do you define "completely different".  Is
      totally separated in that no other IP connectivity between
      Ethernet LSRS than control plane but rides on same wavelengths
      etc.

Adrian - could use one fibre for control and one for data?  Alternative
         seems to be to implement the LSRs correctly so they don't
         forward data on control channel.

Loa - so this is the issue of vendors' routers + inexperience setting up
      IP networks.

Dimitri - problem here is that always left flexibility as to how to
          route the IP traffic.  Not been work in CCAMP since inception.
          Something unintelligable...

Loa - model we used for other data planes works quite well...

Don - GELS axioms.  Some discussion on list on asymmetric b/w
      reservation.  Idea is to fully exploit what Ethernet data plane
      can do - hence choice of VID configuration or VID+MAC
      configuration...

Dimitri - PBB-TE being done in IEEE.  Not speaking about labels in IEEE?

Don - yes, don't call things "labels" in IEEE.

Dimitri - we know IEEE will speak of bridging.  Are we forward looking
          about what IEEE will do?

Don - we took details of what IEEE is doing out, partly because is not
      an official project yet.

Adrian - assumption is that if we go back to IEEE and say we've started
         on a CP to control this sort of switching and they say "no",
         then we'll stop.

Dimitri - if PBB-TE is bridging with TE then doesn't it mean this sort
          of config is acceptable for bridging.

Loa - yes you can do this from a management station.

Loa - ATM forum talked about ATM headers.  It was only in IETF that we
      talked about ATM labels.

Dimitri - we know PBB is operating.  We don't know about PBB-TE at this
          point. Would like more info on how their initial framework is
          detailed.

Dave - given that PBB and PBB-TE can work together we won't alter the
       semantics of MAC addresses.

Don - pretty far along.  Point is taken that we're not defining a data
      plane here but are using a defined one.

Loa - we know how .1Q, .1ad, .1ah etc. work.  Will be amendments to .1Q.
      If we expect something new to turn up we have to consider that
      now.  But according to IEEE credo all new standards will be
      backwards-compatible.

Dimitri - are we relying on backwards-compatibility of bridging to make
          these steps now?

Don - yes.

Don - (Types of LSPs).  Been looking at P2P and P2MP in our draft.  Loa
      can talk to the other aspects.  Terminology differences.

Loa - there is shared forwarding in .1Q.  Rely on source address to have
      an identity that is extended to exactly where things are going.
      In our mindset we drop the source address (not sure is right thing
      to do).  So then have a MP2P LSP.  Is largely overlapping with
      what Don talks about as P2P.  We have done experiments on MP2MP
      LSP.  Standard IEEE VLAN.  Same VLAN configured on multiple ports
      and turn on learning/STP etc. once set up.  But basically a
      standard VLAN.  Possible to configure it pretty quickly with
      scripts etc. (as need to reset testbed several times a day).

Igor - my understanding of PBB is single source.

Loa - not implemented PBT.  What I've done is .1Q plus a couple of
      deltas we find in most switches.

Igor - so don't require single source for the connection...

Loa - only use VLAN ID and dest address to point to an LSP.

George -  When you say .1Q do you mean .1ad Provider Bridges?  Are you
          doing QinQ?

Loa - no.  Just using one Q tag.  Though the next step is QinQ.  Behaves
      the same way as the start of an MPLS tunnel.  Set it up and put
      traffic in.

Kireeti - what signalling do you use for MP2P and MP2MP LSPs?
          Signalling or provisioning?

Loa - All signalled except MP2MP (which is set up with a script - mgmt
      plane).

Kireeti - so what signalling do you use for MP2P?  Do you swap VLANs?

Loa - no, same VLAN through LSP.  That's one of the differences with
      what we did earlier.

Don - changes we need in Gen label request for Ethernet.

Dimitri - Quesiton on MP2P techniques.  Is Loa's implemantation
          compatible with Don's?

Loa - need to compare and clarify.  We can do P2P with MAC and dest addr
      and then allow or not allow merging.  Need to sort out terminology
      for shared forwarding.

Don - our view of MP2P is shared forwarding.  Two independent LSPs that
      share the same label at the merge point.  No difference
      signalling-wise if they don't share the label.

Kireeti - so basically MP2P LSP is multiple P2P LSPs that happen to
          share the last few hops.

Igor - is MP2P same as N x P2P which merge at same destination.

Don - "shared forwarding" is two individual LSPs sharing same tail-end
       label.

George - do all sources use same dest address?  And how do you avoid
         paths that criss-cross?

Loa - criss-cross can be solved in routing protocol.  Once you merge you
      merge.

George - so not sending explicit path in RSVP message.

Loa - send explicit path to merge point, but once resolve is same as an
      existing path we allow you to merge onto it unless we set that you
      can't do it.

Adrian - George and I need to work on this.  MP2P-TE needs to be solved
         in a generalised way for MPLS, GMPLS and GELS.

George - this sounds a little non-standard as compared to what RSVP-TE
         does at the moment.

Loa - I admit to that.

George - so you have full ERO and then if you hit a merge point and
         merge is allowed then you merge?

Loa - yes.  And don't have b/w reservations.  If TSPEC is the same can
      merge.

Don - shared forwarding is a limited version of merging.  No merging of
      b/w etc.  More definition required around this term in the
      documentation.

Loa - what you can accuse me of is using RSVP-TE in an LDP fashion.  We
      admit this is not standard.  We are building our experimental
      platform.  If what we do is good then fine, of not will change
      it...

Loa - this slide (Gen Label Request) is additions, not changes.

Don - using Dimitri's T-spec as a good starting point.

Don - 2 diags stolen from Dave Allen as to where this is applicable:
      1) PBB net with edge and core bridges offering a native Ethernet
         VLAN over the top.  Looks like VPLS but is all native Ethernet.
      2) case like a PW for aggregation.

Loa - my comparible picture shows network from "above" and "the side".
      Yellow part is GELS.  So have MPLS over GELS over X?  X != optical
      switches in this testbed.

Igor - you said GELS could help for optical networks.

Loa - was a bit more careful than that.  When we get people into our
      network we want to do test incorporation.  Want to help people
      understand the idea.  The operational paradigms of the layers are
      very close.  If you want inter-layer signalling that works over
      UNI.

Igor - so in your opinion the CP similarity helps integration.

Loa - yes, helps operational side at least.

Igor - so people need to learn less?  If familiar with optical CP can
       learn Ethernet CP?

Igor - you also said GELS helped interwork configured Ethernet with
       MPLS. What did you mean?  I read it as it helps by removing MPLS.
       Is that correct?

Don - is interfacing Ethernet MAN to an MPLS network.

Igor - I don't see MPLS here.

Don - is in the WAN.

Dimitri - Where does the LSP start and finish in these diagrams?  Is it
          an S-PVC mode or an SVC mode.

Loa - in our network Ethernet LSP starts at Ethernet I/F of the IP
      router. Optical LSP starts on Optical interface of Ethenret
      switch.

Dimitri - is is always a switched mode from access to S-PE?

Don - in this case would have a PW that could be terminated or stitched.
      You can always choose to terminate and then interface at a service level
      i.e. Ethernet or other.

Dimitri - this is one of the limitations in UNI deployments today.  Do
          we gain something by only having a switched mode that goes
          router to router, or do we need a mode that goes edge to edge.
          So from ingress PE to egress PE that doesn't impact the IP
          routers (S-PVC mode rather than SVC mode).  When I look at
          usage of GMPLS we may need to consider both modes.

Adrian - don't see anything in protocol that prohibits either mode.  If
         something shows up then should flag it as we need to keep both
         modes available.

Dimitri - asking other way round.  If we only have switched mode then
          can only deploy GMPLS on nodes that today aren't able to do
          it.  I'm stating about our experience of deployment...  That's
          a concern.  Let's look at today's access nodes...

Loa - I've kind of lost the Q?  I suggest you write the Q down and put
      it on the list...

Don - we don't need to add that much to GMPLS.  Next step is to add a
      milestone for WG charter for experimental GELS spec (Loa's
      suggestion).  Add milestone to develop a spec for GELS
      signalling/routing (combined suggestion).

Adrian - at all future meets GELS will be at end of agenda and you can
         carry on in your own time.  Think we're premature for milestone
         requests.  Both of you can continue experimental work, but
         doesn't come into WG quite yet.  Rules still apply as to how to
         bring stuff into WG.  Consider yourselves lucky that you were
         allowed to present this.  Rules say that if you believe you
         have an IEEE-conformant data plane then we liase to IEEE and
         say that we wish to control it, is that ok?

Loa - brought 802.1Q.

Adrian - just say "please" ;-)  let's talk offline, I need to understand
         the dataplane we're liasing a request about...

=======================================================
2. ARP over GMPLS (Zafar) [10, 45/120]

Slides

Background reading
  - draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
=======================================================

Zafar went over the slides, explaining changes and requesting to be a
WG I-D. Suggest to use tunnel interface address for ARP request.

Lou - Why is it different from other p-to-p link between routers?

Zafar - This is ethernet, so need ARP.

Lou - It exists without GMPLS, right? Is your solution applicable to
      those spaces?

Zafar - We never have two addresses for the same physical address, this
        is what you see in GMPLS.

Lou - The issue of p-to-p ethernet is new for some router vendors?

Zafar - Typically we don't use unnumbered ethernet IF. The second point
        is that we typically don't use two addresses.

Lou - The first point is just unnumbered ethernet, and some vendors
      don't understand it. Sounds like it is not CCAMP issue.

Zafar - Why? We are using signaling.

Lou - That is the second problem.

Lou - The second problem sounds like GMPLS stuff. But it seems just a
      broken implementation.

Zafar - It is unclear implementation.

Lou - What category do you intend for this I-D?

Zafar - BCP.

Igor - Where does the optical LSP start and end?

Zafar - Between routers.
Igor - Where is the ethernet connection?

Zafar - It is also netween routers

Igor - What type of connection?

Dimitri - Good point. You can carry anything over optical LSP, so need
          to be sure whether we want to say framing etc.

Deborah - Good discussion. Igor raised a good question - is the
          connection optical or ethernet. Take it to the list.

Adrian - (To Zafar) Please drive the discussion so we get progress
         before the next IETF.

=======================================================
3. Traffic Engineering Extensions to OSPF in support of inter-AS TE
(Mach Chen) [10, 55/120]

Slides

Background reading
  - draft-chen-ccamp-ospf-interas-te-extension-01.txt
=======================================================

Mach went over the slides, explaining motivations and protocol
extensions.

Yakov - Overlap with OSPF auto-discovery in L1VPN. Encourage you to look
        at L1VPN WG.

JP - You say this is mandatory for BRPC, please clarify in which case
     you may need it. Can you also make sure you do a cut and paste of
     the "not to do" slide into the draft.  The draft is fine.  Want to
     make sure that the draft tells us what we're not trying to do to
     prevent people coming up with silly ideas. Are you writing down in
     the document that not doing TE aggregation?

Mach - Yes.

Acee - Could you replace extensions to OSPF to extensions to OSPF-TE?
       Add OSPFv3 for refernece as well. This should be applicable to
       both, but need to define if that is the case. Also not sure I
       agree that it should be bundled with L1VPN autodiscovery.

Stewart Bryant - The reason for ASs and BGP, etc, is for info hiding.
                 Can we make sure that you are not feeding private
                 information?

Adrian - doesn't that follow from saying that don't share TE info
         outside AS?

Stewart- Yes, but need to be v. strict...

=======================================================
4. Bidirectional LSPs with asymmetric bandwidth requirements
(Attila) [10, 65/120]

Slides

Background reading
  - draft-takacs-asym-bw-lsp-00.txt
=======================================================

Attila went over the slides explaining motivations, options for
achieving this, and futher works.

Zafar - can you explain why you need both LSPs to follow the same route?

Attila - in some scenarios is beneficial to do that for management and a
couple of other issues.

Zafar - think Q is back to requirements of draft.  I think you need to
        spell out more on the application why you need same path.

Julien - I agree that co-routed asymmetrical services is needed.  But
         you may have missed possible scenario where you could associate
         bidirectional LSP at ingress.

Lou - I think Zafar has a good point.  Before we jump into
      implementation need to say that this is a needed service and that
      what we have today is not sufficient.  We did bidirectional
      symmetric service because the transport network needed it.  if we
      don't have such a transport network then what we have here may be
      sufficient.

Attila - this extension is an optional optimisation.  Not a requirement

Lou - so need to enumerate the cases where it's useful and what the
      benefit is.

Rowen Soloman - sometimes bundling 2 unidirectional LSPs and doing low
                level config of egress traffic management is complex.
                but want to see a relationship between this new object
                and CAC funtionality.  When do you go to CAC to reserve
                b/w for the alternate direction?  When is error sent if
                there's insufficient b/w.

Attila - this is implementation Q.

Rowen - would like to see recommendation.

Igor - like to see whether we need such service.  If have service that
       is symmetrical in all contexts except b/w then this might be
       reasonable.  The reason for bidirectional LSP wasn't just driven
       by technology but also by benefits in setup time and recovery.
       Much easier to handle one bidirectional LSP than a combination of
       two LSPs.

Attila - so summary is: do we have a strong use-case for this?  Need
         mailing list discussion.

Lucy - need to think about P2MP as an application.

Dimitri - What is P2MP asymetric bidirectional LSP about?

Lucy - Discuss offline.

=======================================================
5. Data Channel Status using LMP (Dan) [10, 75/120]

Slides

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

Dan went over the slides, explaining changes and protocol extensions

Adrian - We don't have many people doing LMP here, but two on this
         draft. Who in the room read this? -> 5
         Any strong feeling against? None, but...

Zafar - Raised some concern

Dan - Have you read this I-D?

Zafar - Some comments. Personally not sure about requirements. Not sure
        if the group has enough interest to solve this problem.

Adrian- we do have to be sure we're solving a problem that needs
        solving. Just because vendors are on the draft doesn't mean they
        intend to implement and deploy.  Would like feedback from
        carriers as to whether this is a real problem and whether they'd
        look to LMP to solve it.

Diego - We have implemented LMP. This draft solves a real problem.

Julien - Feel that this is an interesting issue to solve. This may be
         specific to transmission devices. Not really issue for packet
         networks.

=======================================================
6. LSP Dynamical Provisioning Performance Metrics in GMPLS Networks
(Guoying Zhang) [10, 85/120]

Slides

Background reading
  - draft-xie-ccamp-lsp-dppm-00.txt
=======================================================

Guoying went over the slides, explaining motivations and open issues.

Adrian - is this project alive, or complete?  Is the draft + the
         research  finished?

Guoying - project is still going.  Want to do work on e.g. multipoint
          LSPs and rerouting.

Adrian - feedback you want from group is questions, also what else the
         group would like measured?

Guoying - also whether the group thinks this is useful.

Adrian - please comment/discuss on mic or on list.

Zafar - why is graceful release delay important?

Guoying - why graceful, or why release?

Zafar - why is graceful release delay important?

Guoying - release delay is important as both setup and release impact
          the application performance.  if release is not good then
          won't meet requirements.  So need to define performance for
          release.  Only looking at graceful release here as forced
          release will cause problems anyway...

Lucy - when you talk about control plane management, is that just
       signalling or also data plane setup?

Guoying - only CP setup time today. Issues with control/data sync.
          hard to measure the sync.

=======================================================
7. Transport Resource Management and Time-Based Bandwidth Services
(Lucy Yong) [10, 95/120]

Slides

Background reading
  - draft-yong-ccamp-ason-gmpls-autobw-service-00
=======================================================

Lucy went over the slides, explaining motivations and asking the group
whether this is interesting.

Dimitri - what shall we standardise here?

Lucy - we need to have a CP that can handle reservation.

Dimitri - is there something today that prevents you using this model?
          What do we need to standardise here (where we work on
          protocols)?

Adrian - yes, we do protocols.  In order to decide if we need a protocol
         we need to see what architecture we're trying to build.  If we
         can solve the architecture with existing protocols then we're
         done.  If we need new protocol then we need to do it (either in
         CCAMP or elesewhere).  But before we even define the arch we
         need to answer Lucy's Q of whether this is something we need to
         solve.

Lucy - I don't think the current protocol and architecture lets you do
       this.

Dimitri - what prevents us today from saying we'd establish a connection
          at a given point in time?

Lucy - all three options today don't work.

Zafar - can't see what we need beyond what GMPLS provides.

Lucy - your connection request doesn't have a future time in it.

Zafar - there are so many ways you could do it.  Nothing to do with
        protocol.

Lucy - carriers currently rely on management plane to do it.  If we have
       a CP then how do we combine them?

Zafar - local decision?

Lucy - A network resource you need to reserve.  Signalling doesn't let
       you know time.

Zafar - can take offline...

Rowen - you do signalling to future allocate resources? So do you keep
        full state of future services?

Lucy - we can work that out in implementation.

Rowen - do you keep states in network for services that aren't running?
        That's a major scaling issue.

Lucy - that's an implementation issue.

George - It's a major scaling issue in building a switch.  Also issues
         in terms of recovering stuff in event of failure.  Better to
         leave stuff in the mgmt system and have CP as a slave.

Lucy - we already have PCE etc. so don't need to embed this in the nodes

George - when pull out of network, it is mgmt plane.

Lucy - PCE is out of network but is CP.

George - PCE isn't part of GMPLS CP.  Not suggesting we put this in
         routing and signalling?  E.g. signal with RSVP-TE ahead of
         time?

Lucy - there are different ways to implement this, not suggesting one
       here.

George - don't think is good idea to put this in the switches.  Topology
         may change between making request and reserving it.  So not
         very useful to embed the info too close to where you're going
         to deploy it.

Lucy - I agree.

George - two things need to happen before we consider this.  (1) need to
         hear from SPs that it's a real need.  Not many SPs want to keep
         dark fibre around to light up instantaneously.  (2) need to
         clarify the architecture in terms of what is control and what
         is management...

Gert - we have application like this running for two years.  Never had
       req. from service provider to put anything in the control plane.
       So doubt if this is useful...

Dimitri - I have one question.  where shall I put the resource
          management state.  If I don't see a cost/benefit ratio which
          is better than what we do today then won't do it.  There is a
          temptation to make the control plane have all the features of
          the management plane - really dangerous as end up with a
          distributed management plane...

Adrian - Keep hearing people say don't put mgmt plane in CP.  I think I
         heard Lucy say that too. So we all agreed...

=======================================================
8. CCAMP Liaison responses (chairs) [25, 120/120]
  - OIF Signaling for MEF Requirements
  - OIF VLAN ID Requirements
  - OIF Interworking Cookbook
  - SG15 Related

Slides

Background reading
  - CCAMP incoming correspondence
=======================================================

Dropped from the agenda due to lack of time.
Adrian - please look at slides on liaison work.

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