RE: Draft Minutes of ccamp wg meeting

["Jonathan Lang" <[e-mail]>]

Ron,
  My name is mentioned a couple places with comments from the meeting,
but I didn't attend the meeting.    Based on the comments (and same
first name), I think it might have been Jonathan Sadler.

Thanks,
Jonathan

> -----Original Message-----
> From: Ron Bonica [mailto:[e-mail]] 
> Sent: Tuesday, August 12, 2003 8:14 PM
> To: [e-mail]
> Subject: FW: Draft Minutes of ccamp wg meeting
> 
> 
> 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.
> >
> >
> 
> 
>