[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Draft Minutes of ccamp wg meeting
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:Ronald.P.Bonica@mci.com]
> Sent: Tuesday, August 12, 2003 8:14 PM
> To: ccamp@ops.ietf.org
> 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.
> >
> >
>
>
>