Re: FW: Draft Minutes of ccamp wg meeting

[[e-mail]]

hi ron,

would you please replace:
* Scope: protection, (pre-planned) rerouting, ??

by
* Scope: LSP protection, (pre-planned) LSP re-routing, dynamic
   LSP re-routing

and
* Not covered: local recovery, end-to-end prot., crankback

by
* Not covered: local recovery, M:N end-to-end LSP prot., crankback
   (ref. to draft-iwata-mpls-crankback-06.txt)

thanks,
- dimitri.

Ron Bonica wrote:

> 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.
>>
>>
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [e-mail]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]