Re: Draft minutes from Tove

hi adrian,

a small comment:

> Adrian - Note: Node_Id based Hello has not been updated before
> deadline

i mentioned that the update of the Node_Id based Hello document has been 
effectively submitted before the deadline

thanks,
- dimitri.

Adrian Farrel wrote:

> Hi ccamp!
> Thanks to Lyndon Ong, Deborah Brungard, and Dimitri Papadimitriou we
> can now read about the ccamp meeting, IETF61.
> Please provide your comments no later than 3rd December if you miss any
> important wording (or you like to change the complete meeting;-)
> / Tove
> Tove Madsen
> Acreo AB
> tove.madsen@acreo.se
> ===
> 61st IETF CCAMP Minutes
> 11/11/2004
> Minutes taken by
> Lyndon Ong, Deborah Brungard, Dimitri Papadimitriou
> 
> 1. Admin and agenda bash - Chairs (5 min)
> Agenda bashing - no changes
> 2. Status of WG drafts - Adrian (10 min)
> Drafts - now unblocked, however the removal of the MPLS bundling draft has
> caused another snag. We have got two new RFCs, Architecture (3945) and
> SONET/SDH Extensions (3946).  Six drafts are in the queue.  Five are in 
> IETF
> Last Call, two are in IESG review.  15 active drafts - if you want a draft
> adopted as WG draft, let's finish these first!  Tunnel trace in particular
> seems to have very little interest - will be discussed wrt to rechartering.
> Overall status: almost all milestones completed, should recharter or close
> in March '04!
> Lou - slide does not list all 15 drafts - others are still active? In
> particular Alarm_Spec
> Adrian said no intention to exclude, asked if implementation on alarm 
> draft,
> Lou said at least one, possibly two, Kireeti said only need one, so Ok 
> to go
> forward.
> Adrian - Note: Node_Id based Hello has not been updated before deadline
> Adrian - Milestones and re-chartering will be covered at the end of the
> meeting.
> 3. Link Bundling - Zafar Ali
> -- Issues with current RFCs and drafts
> -- Draft removed from the RFC editor's queue
> -- Issues with scooping type 4/5 TLVs for IF_ID_RSVP_HOP and
> IF_ID_ERROR_SPEC, also recording of route
> -- Plan to address first two issues in an updated draft but component link
> recording will remain outside the scope of the bundling draft.  Will allow
> but recommend against use of types 4/5.
> -- Work on recording/explicit control will be done in a separate ID.  Home
> in MPLS or CCAMP?
> -> see slides
> -- Plans
> Pulled from queue (reviewed slides)
> -- Adrian: procedure -> MPLS WG own document. Do review on what happens in
> this WG
> Note: speed is really important as we have multiple blocking documents in
> the CCAMP WG queue.
> -- Kireeti - this is not free for all on the bundling draft - change to be
> proposed and to be sent on the list (delta only)
> George: as MPLS chair, MPLS group plans to do updates quickly - considered
> as last call comments
> 
> 4. ASON Signaling Solutions - Dimitri P (5min)
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02. 
> 
> txt>
> <http://www.olddog.co.uk/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt> 
> 
> -- Mention OIF response is on the way
> -- ASON signaling - no updates but lots of thinking esp. call setup message
> naming (Notify vs. specialized message), desire not to "piggyback" call
> information in the connection message.  Expect finalized draft around
> Christmas time.
> -- ASON routing solutions design team
> - Evaluation of common "pattern" has taken time, evaluation document should
> be issued by end- November.
> - Model shown - use of terminology - what is TE Router ID, what is OSPF
> Router ID?
> - Further considerations - control plane does not transport the actual
> transport plane ids, but its view of the transport plane, using an
> associated IP addressing space.
> - No internal structure is associated with an abstract node.
> - Hierarchy focus is on exchange of information between peers.
> - Representation of bandwidth needs further thought.
> -- Adrian - it seems the DT has been making good progress, CCAMP WG has
> unfortunately not been aware of the progress, progress must be shown to the
> group by either sending status or updating the draft.
> -- Dimitri - will mail to the list.
> -- Zafar - how does this work relate to the OSPF and ISIS groups?
> -- DP - we are evaluating what may be missing, after this evaluation we can
> address protocol-specific issues.
> -- Zafar - Are you looking at existing mechanisms?
> -- Dimitri - global applicability is next step, currently looking at what
> info is exchanged
> 
> 5. ITU Liaison - Lyndon Ong
> -- ITU continues to be interested in converging the work on signaling and
> routing
> -- ITU thanks CCAMP for its liaisons, and esp. Adrian for attending the 
> last
> Q14 meeting
> -- ITU is currently working on ASON management specifications and thanks
> CCAMP for its liaison of the GMPLS MIB work for its review
> -- Zafar - can we also have a report of OIF status?  Chairs and LO; 
> there is
> nothing formal to report at this time that's why it was not scheduled on 
> the
> agenda.  However, liaisons will be sent to the mailing list for everyone's
> review, and if something formal is made available, it will be scheduled.
> -- Lyndon - there is ongoing discussion and communication just sent back to
> IETF
> -- Adrian - but not there yet (not available)
> -- Lyndon - is there a need for a permanent liaison from the OIF at the
> CCAMP meeting?
> -- Adrian - if there is something to be discussed it will be considered 
> on a
> per-request/per-case basis
> 6. Graceful Shutdown - Zafar Ali (10 min)
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-0 
> 
> 0.txt
> -- Intention is to support a planned shutdown, e.g., for maintenance
> purposes
> -- IGP based solution does not cover Inter-AS/Area scenarios
> -- RSVP-based solution does not convey information to all nodes in the
> network.
> -- Both mechanisms must complement each other
> -- Use existing sub-code of the Path Error message, then perform
> make-before-break for the LSP. Proposed changes are minor and based on
> existing framework.
> -- Would like to propose this ID as a WG document
> Rahul- is this intra or inter?  inter-domain can use hierarchy of LSPs
> (nesting/stitching) to achieve this isolation.
> -- Zafar - though recognize two mechanisms
> -- Rahul- we should clarify these aspects, as well as inter-domain TE
> aspects.
> -- Zafar - can add these aspects in the document
> -- Richard Rabbat - why is this GMPLS rather than MPLS?
> Zafar - could be shutting down any type of link.
> -- Adrian - in terms of problem space it is needed in both cases
> -- Igor Bryskin - this is a data plane problem followed by rerouting - why
> don't we use existing mechanisms such as propagating alarms?
> Zafar - distinguish this from alarms as this is not something that requires
> an immediate reroute. This is not intended to tackle data plane alarms
> -- Kireeti - maintenance of the link/node - out-of-service issue is to get
> traffic out of the link
> Igor- alarms do not only mean "failure". Could it use alarm severity?
> -- Kireeti - not an alarm situation.
> -- Adrian - this is maintenance alarm => requires to scope the work
> -- Igor - Tools already exist to trigger the same thing, the existing tools
> are more powerful than this proposed one
> -- Zafar - point to the capability of the mechanism having the 
> indication to
> perform make-before-break - also suggest put on the list what you think are
> alternative mechanisms
> -- Lou Berger - says if we do this, we should use existing mechanisms such
> as admin status or alarm (Arthi's suggested one, Igor's alarm admin 
> status).
> -- Zafar - this mechanism is already in the spec - JP's re-optimization
> draft
> -- Lou - other mechanisms are in RFCs. We should decide on mechanisms 
> before
> we accept as a WG draft.
> -- Kireeti - step back from the solution, so the point is to write down 
> what
> is to be achieved (take things out gracefully) -> need first to look at
> requirements for what want to do.
> -- Zafar - agreement
> 7. Interdomain Framework - Adrian (5min)
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework 
> 
> -00.txt>
> -- Minor changes since last time, but published as WG draft
> -- Applies to both MPLS and GMPLS, but currently limited to simpler
> functions for initial work
> -- Realize need more discussion on definition of "domain" e.g. Nested
> domains, ensure GMPLS included. Will take to list for discussion.
> -- This covers "simple" functions, what about "advanced" functions such as
> diverse paths, mapping domain-specific constraints such as DiffServ,
> pt-to-mpt, etc.?
> -- Adrian's suggestion is to keep this separate for convenience.
> -- Rahul - MPLS OAM - building blocks are in place, so it can go in this
> document; P2MP is considerably less well understood.
> -- Kireeti - what about GMPLS OAM?
> -- Dimitri - need to understand what we mean by GMPLS OAM. Suggest phased
> approach.
> 8. Interdomain TE Requirements - Tomohiro Otani (5min)
> <http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.t 
> 
> xt>
> -- Joint proposal from NTT/KDDI, can be used for L1VPN, MPLS-TE
> -- Changes:  added section identifying the following general requirements
> - EGP extensions for GMPLS
> - GMPLS Inter-AS signaling, path calculation and recovery
> - GMPLS interdomain TE management
> -- Remaining issues:
> - Investigate added load created by EGP extensions
> - Investigate L1VPN, use of SRLG for consistency, rechartering impacts
> - Propose WG document
> - Zafar - recommended would be a good basis for inter-domain TE framework
> -- Arthi- support effort, but has too many solutions-related aspects in it.
> Also suggest separating requirements into signaling, routing and path
> computation. Need to clarify what is meant by domain - refer to framework
> document.
> -- Dimitri - what about reachability information exchange?  Not addressed,
> but will be an important aspect.
> -- Adrian- this is solution, not requirements. Suggest to separate
> requirements and solutions. General approval of the work, but need to 
> remove
> solutions. Should consider reachability as well as TE aspects.  Restructure
> as Arthi suggests.
> -- Otani- agree, will separate
> -- Kireeti summarizing: separate requirements from solution and structure:
> signaling from routing (in part. reachability)
> 9. Summarize Status and plans of PCE BOF (JP Vasseur) (5 minutes)
> -- Scope issues
> - No intent to come up with new interdomain routing paradigm
> - Scoped applicability to a limited number of TE LSPs
> - Scoped to a "simple" topology of ASes or areas
> -- Previous BOF - clear requirements from many SPs and common theme of
> problem - MPLS TE LSP path computation
> -- Architecture - comments noted global picture needed, but no
> standardization of architecture.  New revision to be submitted soon in the
> meantime please comments!
> -- Note agreed no intention to extend LDP, but possibly other protocols.
> -- Agreed on proposed charter and milestones, proposal to be sent out early
> next week.
> -- Many in favor of new WG, none against - need IESG review and work on
> charter
> -- Bijan Jabbari - what scale of LSPs?
> -- JP - no specific number, not full mesh - does this mean no scalability
> concerns?
> -- Adrian - need to make the problem manageable, at least initially.
> -- Bijan - will WG be open to new architectures?
> -- Kireeti - take this to the list.
> -- Peter Toms - support this, lots of requests for this.
> 10. Inter-Domain RSVP-TE extensions - Arthi Ayyangar (5min)
> <http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp- 
> 
> te-00.txt>
> -- Changes - include separate section on stitching and required extensions,
> clarifications for non-packet LSPs.
> -- Request to make it a WG document - none against, but limited number
> agreeing (note: not many read the draft)- list.
> -- Adrian - stitching has wider applicability - should we pull it out 
> into a
> separate draft?
> 11. Diverse Inter-region Setup - D'Achille - presented by Adrian (5 min)
> <http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup- 
> 
> 04.txt>
> -- Adrian not that familiar with this draft. Flags one slide on message
> exchange where the head end is in the center rather than at the end. Notes
> several claim, explicitly claim of no new protocol seems questionable as 
> new
> objects are defined. Need further feedback.
> Can't take questions as no authors present to discuss - take to list
> 12. Related to 11.  Protection for Inter-AS tunnels - Decnodder - Cristel
> Pelsser
> <http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protectio 
> 
> n-00.txt>
> -- Differs from 11, addresses requirements from TEWG draft
> -- Uses RSVP-TE and FRR
> -- Adds clarifications on SRLG scope, assumed to correspond to a single AS
> -- Looking for feedback, how to generalize to GMPLS
> -- Adrian - need to apply to GMPLS if you want the draft to be in this
> group.
> -- Zafar - SRLG issue - need to solve the scooping issue, applies in a
> number of places.
> -- Adrian - WG should look at a framework for diverse paths, including PCE.
> -- Zafar - needs more discussion to understand, and already work in MPLS WG
> on ABR protection.
> -- Adrian - authors can continue draft, would also like for CCAMP to
> evaluate if PCE is appropriate, or something else
> -- JP - should include the PCE mailing list on this.
> -- Adrian - need discussion on the ccamp list.
> 13. Requirements for multi-region - Kohei Shiomoto
> <http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-requirem 
> 
> ents-00.txt>
> -- Region defined based on switching capability - note region is control
> plane, layer is data plane
> -- Addresses pre-provisioned FA, triggered FA and no FA cases.  Plain and
> hybrid type nodes.
> -- Architecture has generated requirements and solutions drafts
> -- Virtual network topology, application example
> -- Propose as WG document.
> -- Adrian - handling regions are in scope of CCAMP.
> -- Adrian - asks Dimitri to immediately present the extensions then we will
> take questions
> <http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-extensio 
> 
> ns-00.txt>
> -- TE metric inheritance - how to inherit or map metrics
> -- How is recovery abstracted for an FA - e.g., end2end vs. span protected?
> -- Reconvergence of VNT
> -- Handling multiple switching and adaptation capabilities
> -- Zafar - is this a good idea from TE point of view - dynamic FA 
> creation -
> need applicability statement - potential bandwidth segmentation issues - 
> may
> lose aggregation that you would normally get at the boundary - could add
> oscillation.  If still considered a good idea, should it be triggered by
> signaling or some other mechanism?  Document needs to list concerns.
> -- Arthi - some parts of requirements still not clear - what is needed
> outside of the LSP hierarchy draft?  Need to clarify what is missing from
> the existing, and reference where it's covered by existing documents.  
> Don't
> want to reinvent terminology.  Regarding virtual FA setup can be
> pre-provisioned or on demand - hierarchy draft already says this, should 
> not
> be in the requirements document but only in the solutions document.
> Regarding protection - more work needs to be done in the requirements.
> -- Igor - region, layer, hierarchy level are treated interchangeably in the
> draft, confusing.  Regarding stitching, this is a very general capability
> and should be in LSP hierarchy instead. Kireeti - thinks this should have a
> separate document.
> -- Adrian - more clarification would be good on layer/region
> -- Jonathan Sadler - good stuff in general, agree with the goal.  
> Concern is
> that IETF framework is not well aligned to ITU concept of layered network
> (G.805).  It would be good to take into account the ITU framework.  Work on
> extensions is premature at this time.
> -- Deborah Brungard - authors intended to handle multiple layers as in ITU
> (e.g. G.805) - limited to single domain for now, should be addressed to
> GMPLS RFCs. Not intended to discuss data plane concepts. Request for more
> specific comments.
> 
> 14. MPLS-to-GMPLS Migration - Kohei Shiomoto
> <http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-0 
> 
> 4.txt>
> -- Evolution from legacy MPLS to GMPLS -
> -- Differences: architecture (C/D separation, bidirectionality, P&R);
> routing (opaque LSA); signaling (new objects, messages)
> -- Propose WG document
> -- Kireeti - question on whether this is in scope - address on charter
> -- Zafar - multi-layer comments also apply here.
> -- Richard Rabbat - supports the work, suggests looking at odd numbers
> rather than even.
> -- Ping Pan - how does this differ from the overlay model?
> -- Kireeti - different, take this to the list.
> 15. L1 VPN - Tomonori Takeda (10 Min)
> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt>
> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt 
> 
> 
>>
> <http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05 
> 
> .txt>
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt>
> -- Mailing list - www1.ietf.org/mailman/listinfo/l1vpn
> -- Two drafts applicable, ouldbrahim and overlay - guidelines for
> enhancement, deployment scenaros - added terminology refinement, security
> considerations, service models
> -- Further comments solicited, planning further liaison to SG13.
> -- Applicability draft examines existing GMPLS protocols for L1 VPN
> services. Has added Deborah as co-author.
> -- Concept - set up FA LSP between PEs, use stitching to connect this to
> CEs.
> -- Propose to adopt as CCAMP charter item.
> -- Kireeti - supports applicability draft.  Liaison with ITU is very
> important - we need to be responsive.  We will discuss this item as part of
> the extension of the CCAMP charter
> 16. Signaling for L2 LSPs - Dimitri Papadimitriou (10 minutes)
> <http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-ls 
> 
> p-03.txt>
> -- ATM, FR, ETH, etc.  Defines label request processing, label semantics,
> added security section.
> -- Security - threats analysis, attacks on the data plane, L2 LSP 
> signaling,
> attacks on control plane
> -- Ask for WG draft, no plan to respin
> -- Dave Allan - Question on Ethernet VLAN tag swapping - not defined in
> IEEE.
> -- Dimitri- intended to cover GMPLS scope, not data plane.  Should not
> assume tag is per port unique.
> -- Don Fedyk - is this P2P?
> -- Dimitri - Yes (as starting point).
> -- Kireeti - ok, we have a fair consensus, so I would say it's a rough
> consensus point. We will take this to the list, Dave and Dimitri to work 
> out
> VLAN issue.
> -- Note that an MPLS group draft on L2 has come up
> 17. Mesh Carrier Survey - Richard Rabbat (5 min)
> <http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.tx 
> 
> t>
> -- Initially 7 carriers polled, open to others
> -- Also surveys GMPLS control plane deployment
> -- 1 has deployed, 3 within 2-3 years, 3 with no current plans
> -- Concerns with stability, signaling storms
> -- Asking for feedback, new carrier input
> -- Richard - review slides, recommend for CCAMP WG to begin work on shared
> mesh restoration performance
> 18. Milestone and Charter discussion - Kireeti
> -- Current activities winding down, esp. P&R, ASON
> -- Others underway, esp. multi-domain
> -- New: migration, VPNs, control plane resilience, addressing,
> implementation experience, GTTP (?)
> -- Migration
> - GMPLS supersets MPLS, but some objects are different - label request,
> label, upstream label
> - Need BCP on smooth migration, what issues may occur
> -- L1 VPN
> - Should IETF do this?  Should it be in CCAMP?  Tied to UNI and Interdomain
> signaling
> -- Control plane resilience - includes graceful restart but also more
> -- Addressing - transport networks use different kinds of addresses - need
> decoder ring for mapping transport network address types to IP addresses -
> Kireeti considers this useful
> -- Interop results - note that addressing pops up there as well.  BCPs 
> would
> be helpful.
> -- Send out request for new work items, replies due Friday 11/19.
> -- Send out checks for consensus on each item, replies due Friday 12/3
> -- Send resulting list to A-Ds, trimmed if necessary, add appropriate
> milestones
> -- Consensus is a requirement but not a guarantee.
> -- Lou - how about dropping something from the existing charter -
> -- Kireeti - maybe GTTP - Lou - should note on the list also things that 
> may
> be dropped if no support.
> -- Alex - about L1 VPNs - is this research work, or practical?  Need at
> least one implementation - is anyone implementing this within a year or 
> two?
> -- Dimitri - Solutions exist provided by vendors today, but no common
> framework.  Timeframe for implementation is 18-24 months.
> -- Alex reminds the group of the need for running code.
> -- Adrian - what about informational draft on how to use existing functions
> to do the service?  Is there any interest from the research groups or the
> real carrier deployment groups?
> -- Tomonori Takeda - NTT has interest, but not sure of protocols.  
> Timeframe
> - cannot say.  Testing is done.
> -- Yakov Rekhter- vendors cannot disclose future product plans...
> -- Deborah Brungard - carriers also cannot disclose plans, will see 
> interest
> by number of co-authors.
> -- Kireeti - have had carriers ask for this technology.  We don't have all
> the pieces, but have implemented many of them, and as a vendor would 
> like to
> see a solution on how to do. Answer to Alex is yes.
> -- Richard Rabbat - could add this to his survey.
> -- Kireeti supports this.
> MEETING IS ADJOURNED.
> 
> 
> .
> 