Draft minutes

["BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>]

Here's the minutes of the first session, much thanks to to the great
notes of David McWalter and Lyndon Ong. Please check them, comment on
missing items or corrections, and start to work on the items identified.
Thanks,
Deborah and Adrian
---------------------------------------------------------------
 
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.

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