Re: IETF 56 CCAMP Minutes

[Dimitri.Papadimitriou@alcatel.be]

hi ron, all,

some comments and remarks in-line...

hope they will help you,
- dimitri.

---

Ron Bonica wrote:
> 
> Folks,
> 
> Attached are IETF 56 CCAMP minutes. Thanks to Markus Jork for taking notes.
> If there are no objections posted to the list by next week, I will submit
> the minutes as recorded by Markus.
> 
> ============================================
> 
> 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 LC?
>   Some in room think it's ready (nobody disagrees) -> take to mailing list

i think bert asked for a checkup before doing so

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

note: the above are more generic statements while the below applies
to the signalling i-d only (wise to include this clarification)

> Still needs to be covered: bulk lsp recovery, reversion (switch back)
> 
> Next steps:
> next report April 03, func spec ready for LC

... funct spec to be ready for LC *in April'03*

> protocol spec expected to be ready in July

July'03
 
> Should the terminology doc become PS?

or (stay/be ?) informational, AD's will check
 
> 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 modfying LMP, first look into problem and

typo: modifying

>          requirements. Need mailing list discussion whether LMP is right.

... is the right approach here

> 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 solved, accept as wg doc?

... "all technical issues raised on the mailing list" 
 
> Is this a worthwhile LMP extension (apart from questions about format
> details)?
> 
> Kireeti: needs discussion on list
> Jonathan(?): mechanism worthwhile, encoding still has problems

Jonathan Sadler... 
(note: it is unclear where these problems are anyway)

> 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

is *bootstrap* feature

> 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

add (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(?): need discussion on list instead of rhetorical questions here

Jonathan Sadler
 
> A layering discussion ensued.
> 
> Kireeti: need layer relationship document

referring 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 Farell: 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 ccmap charter item, increasing interest (inter-AS/area),

typo: ccamp

>   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 ??? 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".
> 
> Marten: progress this draft before LMP bootstrap draft

isn't Malcolm Betts ?
 
> 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

yes i think so

> Jerry Ash: document describing liaisons?
> 
> Kireeti: there already is such as doc (may be insufficient), separate
>          from this

would it be possible to clarify the above sentence ?

> Bert: liaison process is wider issue (not specific to this WG)
> 
> Marten: draft fine for IP applications, how about non-IP apps? How
>         can get those requirements recognized in IETF?

Malcolm Betts (i guess)
 
> 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.

same here ?
 
> 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
> - 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

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491