FW: Draft Minutes of ccamp wg meeting

[Ron Bonica <[e-mail]>]

Folks,

If nobody objects by COB Wednesday, I will post the following minutes of the
CCAMP WG

                                     Ron


>
> Chairs  	   Doc status - Kireeti presented slides (could not
> keep notes on
> all)
> ------------------------------------------------------------------
> ----------
> -----
> GMPLS signaling for SONET/SDH - RF Ed Q
> GMPLS Non-std SONET SDH features - killed
> GMPLS RSVP support for overlay model - authors to respond to list comment
> ASON requirments for signaling - one more update prior to straw
> poll WG last
> call
> Exclude routes ext to RSVP-TE - Adrian add appendices to describe usage
> Routing ext to support GMPLS - Kireeti did update, planned mtg prior to WG
> last call
> 			           - Number of docs stacked up
> based on this doc
> OSPF ext in support of GMPLS - awaiting above
> ASON routing rqmts - Design team created, members, milestones and schedule
> to be posted to list
> LMP - security section needs work
> SONET/SDH
> ??
> GMPLS recovery - Design team says ready for last call
> GMPLS MIBs waiting on MPLS MIBs (Adrian - 99% complete)
> GMPLS architecture - waiting on normative refs
> GMPLS trace in RFC ed Q
> Framework for GMPLS-based control of SONET/SDH - Informational
>
> Several individual contribs and WG docs not covered. Would like
> to progress
> the above mature docs.
>
> Alanqar	   ITU SG15 Liaisons
> --------------------------------
> * Links to liasion statements in slides
> * Focus is ASON signaling protocol and routing extensions
> * Thanks extended to chair and invited experts
> * Snapshot of approved and under development stds
>
> * Signaling updates
> 	- G.7713 terminology alignment with G.8080
> 	- support for crankback
> 	- Call/connection separation
> * Comments on G.7713 solicited
> * No need to develop alternative solution
>
> * Routing updates G.7715.1
> 	- Goal is consent in Oct 2003 Geneva
> 	- OSPF ext for ASON
> 	- Potential use of PNNI
>
> * Addressing: signaling, control and management usage important
> 	- separate address spaces for control and management
>
> * Auto discover G.7714.1
> 	- Further investigation initiated
> 	- Focus on type A (trail overhead)
>
> * Arch for discover & control plane G.disc_arch
> 	- New scope/title for G.7716
>
> * Management framework - new doc created in Chicago G.frame
> 	- Goal of consent by May 2004
>
> No questions
>
> Kireeti - ccamp needs to formal liaisons
>
> Papadimitriou draft-ietf-ccamp-gmpls-ason-reqts-01.txt
> ------------------------------------------------------
> * Presented by Jerry Ash
> * background, overview, issues presented
> * History has created need for better communication
> * Need to continue/ensure joint IETF/ITU-T working team
> * Much discussion on this draft since work has already been done in G.8080
> * Intent is to have extensions
> * Six broad areas of requirements
> 	 - Support for soft permanent connection capability
>       - Support for call and connection separation
>       - Support for call segments
>       - Support for extended restart capabilities during control plane
>         failures
>       - Support for extended label usage
>       - Support for crankback capability
>       - Support for additional error cases
> * Enssure GMPLS extensions interoperable with G.7713.2
>
> * Another iteration and then WG last call
> * Progress signaling extensions
> * Invitation for participation in routing requirements and protocol
> extensions
>
> * No questions nor discussion
> * Kireeti will float draft of liaison next week for comment
>
> Aboul-Magd	   draft-aboulmagd-ccamp-transport-lmp-01.txt
> ------------------------------------------------------
> * Could change title to "ASON discovery framework"
> * Is a terminology "decoder ring" mapping ASON <-> GMPLS LMP terminology
> 	- includes port and component link types
> * G.8080 has transport (data) and control plane discovery with separate
> addresses (draft says name space and not address?)
> * Proposed considering draft as WG document
> 	- A number of people had read this draft
> 	- not a broad consensus in support of this proposal
> * Lyndon Ong - Good doc, need to resolve decoder ring comments.
> * Jonathon Lang (Tellabs) - WG23 doc from ITU-T Chicago discusses some of
> these issues
> * Malcom Betts - Question on control/data plane addresses in ITU
> documentati
> on. IP address in header, NHOP, PHOP have transport address.  Intent is to
> clarify usage, if already done then no need to repeat.
>
> Papadimitriou Protection and Recovery update
> --------------------------------------------
> * Presented by Dimitri
> * Effort positioning, status and timing over past 1.5 years
> * Scope: protection, (pre-planned) rerouting, ??
> * Not covered: local recovery, end-to-end prot., crankback
> * Summarized comments received
> * Proposed acceptance as WG document
> 	- consensus was that this is ready
> 	- Kireeti - take to the list
> * Discuss the extra traffic concept in a list thread
> 	- Dimitri will propose text to clarify this
>
> Farrel	   draft-iwata-mpls-crankback-06.txt
> ------------------------------------------------
> * Adrian Farrel presented
> * Has been around for several years and this version is a major re-spin
> 	- May be more complex than single node/interface
> 	- Objective is to fail back to some intermediate point (e.g., region
> boundary or loose route identified node)
> 	- Requirement from ASON ITU-T
> 	- New co-author, John Drake
> * Summarize major changes in slides
> 	- long list of TLVs, but no adivce on which to include and when
> * Wanted to start thread on list re: remaining issues - some very thorny
> 	- session attribute bits (all would be used by this draft)
> 	- too many TLVs, need to confirm all are actually required
> 	- right place to handle unnumbered bundles
> 	- Is this the right approach, or should RRO be used?
> * Feedback solicited, resolve open issues
> * Add pointer from ASON signaling since it is long (different from slide
> presented)
> * Kireeti: close on issues, bounce use of final 3 bits off MPLS WG
> 	- decide on approach (TLVs vs RRO) and with new charter
> decide on WG status
> * Dimitri - What is the basic set of TLVs needed and then address larger
> scope.
> * Adrian - What is needed is implementation dependent. Need input
> from other
> service providers.
> * Kireeti: relate this to multi-area, multi-AS documents since a primary
> application is setup failures in multi-region.
> * Adrian: Need more explicity requirements from te-wg on crankback
> requirements.
>
> Kim	         draft-kim-ccamp-cc-protection-03.txt
> ---------------------------------------------------
> * Presented by Young Hwa Kim
> * Summarized survivability of control channels and neworks(from G.807)
> 	- assoc, non-assoc, quasi-assoc, in or out of fiber, SCN/ASTN
> implementation
> * Stated problem as no provision of protection features in current GMPLS
> control plane
> * Summarized requirements and functions for resilience of control plane
> 	- e.g., primary and secondary on separate fibers (shown in figure)
> * Next steps: proposed refine/complete requirements, 	protocol
> specification, WG document in 2003/2004
>
> * Aboul-Magd: Are control channels visible to LMP? Why are current control
> plane methods not sufficient? What are the deficiences?
> * Kireeti: Control plane is an IP network, not trying to redesign IP
> resiliency. Are some issues: is graceful restart sufficient? Need to
> convince WG that there is a problem to resolve. Do this on the
> mailing list.
> * Kim: Gigabit Ethernet has no protection, but SONET/SDH and Lamba network
> does.
> *  Malcom Betts - Control plane relies on IP network resiliency.
> G.8080 has
> a number of resiliency considerations listed.
>
> Rabbat	   draft-rabbat-optical-recovery-reqs-00.txt et al
> --------------------------------------------------------------
> * Summarized changes
> * Solicited feedback
> * Kireeti: Had requirements from te-wg, keep this as separate doc, start
> thread on mailing list
> * Draft stable, proposed adoption as WG draft
> * Need more discussion on WG list
>
> * soumiya-lmp-fault (not on agenda from Bonica)
> -----------------------------------------------
> * How we reduce message overhead slide
> * Alex Zinin - Q: Is flooding done reliably? A: Yes. Need to include
> acknowledgement messages when assessing complexity.
> * Adrian: arrows on lhs (signaling) indicate a pair of messages for
> signaling.
> * Kireeti: Was discussion comparing signaling message vs sending flooding
> messages. Signaling is often faster (contrary to stmt that it is slower).
> Flooding has a hold down timer aspect, but signaling is faster. Issue with
> using LSPs for flooding since they are link local - seems
> redundant with IGP
> (OSPF, IS-IS). Usurps LMP for different purpose. Important point is that
> flooding is slower, but fewer messages as compared with signaling.  Should
> discuss further on list. Concerned about resolving problem of flooding
> already solved in GP.
> * Aboul-Magd: Same comment as Kireeti. Need to synchronize signaling and
> routing. Don't understand why there is a need for this.
> * Jonathon Lang: Concern that message indicates a fiber cut and
> not messages
> for each affected LSP. A: Protection algorithms expect knowledge
> that nodes
> know this mapping at a protection point. Issue is that nodes may not know
> this mapping when multiple levels of indirection exist. Presenter
> requested
> feedback on the list.
> * Bonica: Take further discussion to the list.
>
> Shiomoto	   draft-pil-ccamp-extra-lsp-00.txt
> -----------------------------------------------
> * Presented by Shimoto
> * Brief overview of draft for shared mesh restoration
> 	- protecting LSP resource is reserved, but not cross-connected
> 	- extra class LSP can use this unused restoration capacity, which is
> preemptable when needed for restoration (expected to be rare occurence)
> 	- problems: advertise available resources, LSP indications
> and preemption
> in signaling, prevent unintended connections, also protect confidentiality
> * Discuss comments from mailing list
> 	- can do using existing priority mechanisms where extra
> class has lower
> holding priority than restoration LSP
> 	- complexity
> 	- soft preemption (not addressed in this draft)
> * Solicit comments/feedback
> * Proposed accepting this for ccamp wg
> * Dimitri: Question re: soft preemption as document or charter? A: Propose
> adding to charter.
> * JP Vasseur: Elaborate on soft preemption. A: Need to describe concept in
> this draft. Q: Are you aware of draft on soft preemption? A: No.
> Q: What is
> to be done with existing mechanisms?
> * Kireeti: Can be achieved with current mechanisms. Discuss on list.
> Proposed action was for Dimitri/JP Vasseur to describe on list
> how this can
> be done using existing mechanisms and Shiomoto to identify what
> is missing.
>
> Papadimitriou draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
> -----------------------------------------------------------
> * Presented by Deborah Brungard
> * Address requirements in GMPLS ASON presented earlier
> * Backward/forward compatible with GMPLS
> * Agnostic to network UNI implementation
> * Call/connection separation objects simply forwarded and not processed
> * Described proposed mechanism for call/connection separation in detail
> * Summarized other additional ASON functionalities
> * Next version - add crankback signaling and call segments
> * Solicting feedback
> * Lyndon Ong: Requesting interpretation of "backward compatibility" 7713.2
> interpretation is to carry an object if is not understood.
> * Kireeti: Need liaison to ITU-T with comments on 7713, 7713.2, and ITU-T
> liaisons and then decide how to progress this document.
>
> Ali draft-zamfir-explicit-resource-control-bundle-01.txt
> --------------------------------------------------------
> * Presented by Zafar Ali
> * Explicit Resrouce Control and Recording
> 	- Unbundled or bundled TE link type
> 	- Focus is case where component interface cannot be
> inferred from label
> value
> * Current spec supports unbundled case for LSP splicing uni- and
> bi-directional
> * Can support bundled case by specifying component ID for LSP splicing
> * Cannot support bundled case for LSP splicing when forward and backward
> component IDs are different in bi-directional
> * Propose optional interface identifier ERO subobject to address this case
> * RRO with label recording
> 	- could use to signal label values used within the bundle
> 	- cannot currently identify component interface used withing bundle
> 	- proposed solution is interface identifier RRO subobject,
> similar to above
> * Propose accepting this as WG doc
> * Kireeti: Missing element in taxonomy (matrix) of these approaches not
> sufficient for WG adoption. Understand RRO case. What is
> motivation for ERO?
> A: Could have case where component links are different where upstream and
> downstream differ. Bundle draft says that up- and down-stream can
> differ. Q:
> Why don't the local nodes assign this (and communicate selection
> in RRO). A:
> Consideration is on egress specification of component ID. Don't understand
> resistance.
> * Kireeti: Post rationale to the list, beyond missing support in
> taxonomy/martix for both RRO and ERO cases. If agreement, then
> can proceed.
> * Swallow: Provider feedback is to keep up- and down-stream on same fiber
> (pair).
> * Dimitri: Can provide examples for RRO, but believes there will
> be few for
> ERO. Please expand compatibility statement in the last section.
>
> Choi	         draft-choi-gmpls-resource-mapping-00.txt
> -------------------------------------------------------
> *  Resource Mapping for GMPLS with Heterogeneous Interfaces
> * Problem: Label format for optical interface defined, but
> specific mapping
> rule is not
> 	- Identify fiber, waveband, and lambda labels
> * Issue -1
> 	- Need aggregation for sharing in protection/restoration
> 	- Support mechanism similar to label stacking in electrical
> domain for
> optical interfaces
> * Issue -2
> 	- Logical resoure aggregation at switching interface -
> mapping, aggregation
> 	(examples given)
> 	- Miscellaneous other issues (unnumbered links, bundling,
> SRLG mapping,
> signaling, routing)
> * Is proposal acceptable to ccamp WG
> * Kireeti: Some routing and signaling defined in hierarchy draft. Here,
> FA-LSP adverstises aggregate into IGP. Asked presenter to state
> why this is
> needed on the mailing list.
>
> Fu		   draft-fu-ccamp-traceroute-00.txt
> -----------------------------------------------
> * Presented by Xiaoming Fu
> * A Proposal for Generic Traceroute Over Tunnels
> * A few issues with current GTTP draft
> 	- each hop supports GTTP
> 	- UDP issues: ports could be blocked by some ISPs, TTL=1,
> msg size>MTU
> 	- Reverse trace may not traverse same tunnel
> * Summarized potential solutions described in draft based on NSIS
> 	- Based on two-layer NTLP and NSLP NSIS protocol model
> 	- Can reuse TCP and SCTP to deliver trace messages (address
> firewall issue)
> 	- NSIS discovery finds next (NSLP?) hop and uses
> traditional traceroute
> between NSIS-enabled nodes
> * Should issues & concepts be considered in traceroute/GTTP design
> * Bonica (as individual contributor): Q: Does probe sent to destination
> visit intermediate nodes forward or backward? A: Still investigating. Q:
> Would have to use alert? A: No, signaling can used without routing alert.
> Should discovery of next hop be separate from signaling. Q: Is
> trace control
> or data plane? A: NSIS direction is discovering data path. Q: Will
> intermediate routers pass w/o change? A: Yes, traditional traceroute does
> this.
>
> Chairs	   Wrap up
> ----------------------
> * See you in Minneapolis.
> * All presenters send slides to bonica and kireeti.
>
>