Re: IETF 56 CCAMP minutes - UPDATE
"Cheng-Yin Lee" <Cheng-Yin.Lee@alcatel.com> Tue, 01 April 2003 18:42 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 01 Apr 2003 10:44:57 -0800
Message-ID: <3E89DD8B.A2F32E84@alcatel.com>
Date: Tue, 01 Apr 2003 13:42:19 -0500
From: Cheng-Yin Lee <Cheng-Yin.Lee@alcatel.com>
Reply-To: Cheng-Yin.Lee@alcatel.com
MIME-Version: 1.0
To: Ron Bonica <Ronald.P.Bonica@wcom.com>
CC: ccamp@ops.ietf.org, minutes@ietf.org
Subject: Re: IETF 56 CCAMP minutes - UPDATE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Ron, I think Kireeti also said the CCAMP chairs will look for a WG for this : > Adrian: draft-lee-ccamp-rsvp-te-exclude-route-01 > ------------------------------------------------ > ..... > > Questions to room: > ~15 have read the draft > ~20 find it useful > ~30 think it should become wg doc in some wg > 0 find it not ready thanks Cheng-Yin Ron Bonica wrote: > > Folks, > > Please accept the following updated minutes from IETF 56 - CCAMP. There is > one minor change. > > Ron > > ============================================ > > Kireeti: WG status > ------------------ > > Short overview on status of WG documents as listed on web page. > > Questions: > - framework for sonet/sdh control draft ready for LC? -> unclear > - LMP MIB to Last Call? > Bert asked for checkup > Authors will provide new version and then last call on mailing list > - non-standard sonet/sdh extensions? -> no interest in room > Bert Wijnen: There is still no document describing what exactly > is signaled. If that is not provided, this draft should go to wastebin. > **no referenced document** > > Wesam Alanqar: ITU liaison report > --------------------------------- > > ITU-T SG15 update to ccamp. This presentation has also been sent > to the mailing list. > 3 liaison statements exist: ason routing, discovery, restoration/re-routing. > > IETF routing experts are invited to come to next ITU meeting. > > Dimitri Papadimitriou: Ext. in support of end-to-end GMPLS-based recovery > ------------------------------------------------------------------------- > > draft-lang-ccamp-gmpls-recovery-e2e-signaling-00 > > After 1 year of work: terminology starts to be widely adopted, > analysis i-d still too largely scoped. > Still needs to be covered: bulk lsp recovery, reversion (switch back) > > Next steps: > next report April 03, func spec ready for LC > Functional spec to be ready for LC *in April'03* > protocol spec expected to be ready in July 03 > > Should the terminology doc become PS? > - AD will check whether it should be informational or PS > > Peter Czezowski: recovery requirements, fault notification protocol and LMP > ---------------------------------------------------------------------------- > > Presenting 3 drafts and changes to them: > - draft-czezowski-optical-recovery-reqs-01.txt > - draft-rabbat-fault-notification-protocol-02.txt > - draft-soumiya-lmp-fault-notification-ext-00.txt > > The first 2 drafts believed to be ready. There is running code for > the third draft, but is there any interest? > Comments are requested from mailing list. > > George: Changing pt-to-pt protocol to a flooding protocol is more than > just adding a message. It results in a different implementation > model for LMP. > Kireeti: Don't start by modifying LMP, first look into problem and > requirements. Need mailing list discussion whether LMP is right. > Alex: It took several net meltdowns to learn how to do flooding right. > > Dimitri: draft-lang-ccamp-lmp-bootstrap-03 > ------------------------------------------ > > Changes: modified J0/J1/J2-16 string to fit within 80 bits, > added layer adjacency discovery > Next steps: believes all technical issues raised on the mailing list solved, > accept as wg doc? > > Is this a worthwhile LMP extension (apart from questions about format > details)? > > Kireeti: needs discussion on list > Jonathan Sadler: mechanism worthwhile, encoding still has problems > Dimitri: suggest to create document with common bootstrap mechanism, > then sonet/sdh specific doc, where sonet/sdh encoding specifics would be > specified > Jonathan Lang: is feature desired by community? find out before splitting > docs and put more work in it > > Question to room: ~7 think it's useful, nobody against -> take to list > > George: draft-ietf-ccamp-gmpls-overlay-01 > ----------------------------------------- > > Question to room: "ready for WG LC?": > ~20 yes, 0 no > -> check consensus on list > -> start WG last call after meeting > > Dimitri: technology specific routing extensions to GMPLS routing > ---------------------------------------------------------------- > > draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis} > > Changes: discussion concerning bandwidth encoding, section on scalability > and backward compatibility consideration. > > Falls within Sonet/SDH basket. Some assertions have been made on list, > addressed one-by-one in the presentation. > > Jonathan Sadler: need discussion on list instead of rhetorical questions > here > > A layering discussion ensued. > > Kireeti: need layer relationship document (refering to the mrn i-d) > > Poll of the room: ~15 think it's a useful idea, ~5 against making it wg doc > Kireeti: reasonable support, take to list > > Adrian Farrel: GMPLS MIBs > ------------------------- > > 3 drafts became WG drafts in June 02, nothing happened since. > Waiting for MPLS MIBS to go to LC before republishing GMPLS MIBs. > Plan: > wait for MPLS MIBs republication and LC > quick editorial respin to bring in line (~4 weeks after MPLS MIBs) > content additions, republish before Vienna > chairs would like LC in August (but need WG feedback) > > Adrian: draft-lee-ccamp-rsvp-te-exclude-route-01 > ------------------------------------------------ > > Why in gmpls? > think is ccamp charter item, increasing interest (inter-AS/area), > is mpls extension but is generalized and should be part of GMPLS > Why needed? > needed where path computation is not only in one place > Changes: > identification of new work items > Actions: > got useful feedback > solicit input from providers > look for convergence with JP's draft > WG item? > > George: should talk about it in sub-ip directorate meeting > > Questions to room: > ~15 have read the draft > ~20 find it useful > ~30 think it should become wg doc in some wg > 0 find it not ready > > Osama Aboul-Magd: a transport view to LMP > ----------------------------------------- > > draft-aboulmagd-ccamp-transport-lmp-00.txt > > Kireeti: What does control plane discovery mean? > Is LMP + LMP bootstrap close enough to what this draft does? > Very useful spec, provides "language translation". > > Malcolm Betts: progress this draft before LMP bootstrap draft > > Ron Bonica: generic tunnel tracing > ---------------------------------- > > Requirements doc is stable, WG LC complete. > Time to work on solution, IANA has assigned UDP port, > new context object added. > > Solicit feedback from implementers. > Adopt as ccamp work item? > > Room poll: ~10 have read the draft -> need to take to list > > Ron (for Loa): MPLS and GMPLS change process > -------------------------------------------- > > Status: lots of lively discussion, topics: > - is this merely a reaffirmation of IETF process? > - what is the role of a liaison? > - when all approvals are not obtained? Is there any alternative > to the dust bin? > > Don Fedyk: need better understanding, common model/language > > Monique Morrow: ITU/IETF need to work together > > Jerry Ash: document describing liaisons? > > Kireeti: there already is such as doc (may be insufficient), separate > from this > > Bert: liaison process is wider issue (not specific to this WG) > > Malcolm Betts: draft fine for IP applications, how about non-IP apps? How > can get those requirements recognized in IETF? > > Ron: requirements must be stated clearly to be understood by IETF WG > > Kireeti: Draft documents how ietf process works. > The process may need a dust bin for bad ideas and another > bin for "not in IETF scope, but not really broken". > It is not addressed yet how to handle stuff the IETF doesn't like. > > Alex: Need interest by IETF community to make things happen, > same thing applicable to anyone coming to IETF. > People need to be convinced. > > Bert: subip area initially had problem with too many drafts, > was fixed by requiring problem statements > > Marten: Process is very mature dealing with submissions by individuals, > but not from other organizations. > I-Ds not suited to deal with peer standardization organization. > ITU can't do ascii diagrams or read through mailing list > to gather IETF opinion. > Need a way to apply IETF protocols to non-IETF problem. > > Kireeti: GMPLS work did step out of traditional ietf scope > > George: coopeation would work a lot better if clear requirements would > be communicated instead of sending in solutions > (even applies within IETF) > > Sharam Davari: another standardization organization should not have > same weight as an individual submission > > Ron: I-D should be evaluated on its merit, author irrelevant > > Kireeti: ccamp charter update > ----------------------------- > > - not done by WG consensus > - proposed by chairs to AD, AD takes it to IESG/IAB > > Alex: correction: WG consensus *is* required but is not enough > > under consideration: > - inter-area signaling and routing of generalized paths > - crackback wrt inter-area > - inter-as on hold until tewg produces requirements > - explicitely put tunnel tracing in charter > - routing extensions for Sonet/SDH > - signaling for G.709 signaling > - further LMP extensions > - optical vpn *not* in charter > > milestones: > - GMPLS MIB to WG LC in Aug 03 > - protection/restoration functional spec and protocol changes > to WG LC by Apr and Jul 03 (respectively) > - tunnel tracing protocol to WG LC by Sep 03 > - set milestones for inter-area path setup when ratified as charter changes > > need active discussion on list > > JP: combination of inter-area and inter-as is a good idea > > Kireeti: it is great if a common solution is available, but that is not > reason enough to put inter-as on charter > > Marco: O-VPN started in ITU-T, on ppvpn charter, good chance for cooperation > > Kireeti: ccamp should keep an eye on solution > > =========================================== > Ronald P. Bonica Ph: 703 886 1681 > vBNS Engineering page: 1 888 268 8021 > Ashburn, Va. > =========================================== > "We are not on Earth to guard a museum, but > to cultivate a flourishing garden of life." > -- Angelo Giuseppe Roncalli
- IETF 56 CCAMP minutes - UPDATE Ron Bonica
- Re: IETF 56 CCAMP minutes - UPDATE Cheng-Yin Lee