CCAMP minutes

[Vijay Gill <[e-mail]>]

Folks, CCAMP minutes.

Notes for CCAMP:

Started off with a few comments: Kireeti mentioned that CCAMP needs
design teams for requirements . Also more SP input would be
welcomed. There would also be CCAMP interaction with TEWG.

Sub-IP area intro (Scott)

Need to consolidate sub-IP stuff into one area (currently temporary -
aimed at 1-2 years and hopefully less.)

CCAMP is one WG - also a bunch of others.  Commonality is that none of
these fit well into existing areas.  "Dark underbelly of IP, not
bright light above."

Will keep ADs as tech advisers to WG.  Fairly hands off. Mentioned
that there are 300 or so IDs that need to be filtered in this area.
Need help from a lot of people to filter through this to figure out
what the IETF in general and this area esp. needs to deal with.

Will be re-evaluated post IETF in London (IETF 51).


Using 2 octets for b/w values (Qingming Ma)
[Presentation]

Thing to note: Formula is a * 2 ^ b - handles values up to
8,000,000,000 TB/s.  (Really means (a*2)^b of course).

Saves about 50% of size of TLVs.  Also reduces h/w requirements (no float.)

Recommendation - replace 4-byte FP in current drafts OR define new B/W
sub-TLVs that use 2 octets.

Was put to the Room. The general commentary appeared to be that this
was not worth pursuing. [Notes are a bit vague here, commentary
welcome]

Tunneltrace (Ron Bonica)
[presentation]
Comments:

Curtis - Need to support ICMP work done earlier, and accept that in
         reality we're going to have to transition at some point.
         Lack of ACL used to be considered a "feature" in the NSFNet
         days (allowed customers to tell clueless operators what they
         were doing wrong.) So it should be a requirement that at
         least at the macro level this is still true.

Kireeti - AS level should suffice?

Curtis - want ICMP to be informational now, and historic later.

Scott Bradner - IESG has discussed this a lot.  Asked a design team to
                come up with generic problem statement and come up
                with generic solution.  Right time to talk about it is
                once that report has been discussed.


Crankback Routing Extensions (Atsushi Iwata)
[presentation]
Status:

initial March 2000 (00.txt)     CR-LDP extension for crankback
second  Jul 2000   (01.txt)     additional descriptions for CR-LDP (accepted
                                as MPLS-WG draft)
third   Dec 2000   (this draft) RSVP-TE in, and improves descriptions.

Propose that whole draft is accepted as a CCAMP WG doc
(draft-ietf-ccamp-crankback-00.txt) for crankback routing for MPLS
signalling.

Comments:

Rob Coltun - applicability?  Can see it being used for abstraction
             (e.g.  ABR).  For single area why not crankback and retry
             without this draft?

Atsushi - crankback should be general to both single and multi-area
          cases.  Should not preclude single area.  Feedback mechanism
          could be used instead, but we definitely need crankback for
          multi-area.

Rob - want requirements for multi-area/hierarchy sussed before this is
      accepted.

Curtis - would only have strict route in local area, and loose route
         beyond that.  If hierarchical tunnels should be able to
         recover.

Kireeti - but you could have picked the wrong ABR.

Curtis - if you don't use admin colours you're OK - can't pick wrong
         ABR.

Unknown - several multi area methods have beenh proposed.  All ask for
          crankback.

Kireeti - will wait until all requirements come out and then come back to
          this draft.


Closed-loop automatic link provisioning (Lily Cheng)

[notes get vague here ]

CCAMP requirements (Dave Walker)
[presentation]

First draft of a requirements document.  Aim is to put CCAMP work into
some kind of context.  Goes beyond requirements into
framework/architecture etc.

comments:

Curtis - this is nothing to do with CCAMP charter.  Very like COPS
         which has been rejected for this.

Dave - but we have to have a framework.

Curtis - this isn't it.

Vijay - I tend to agree, but we need to take this to the list.

G-MPLS Architecture (Eric Mannie)
[presentation]
27 co-authors!

Reverse engineering of 10 existing drafts to get arch.  8 of these are
WG items, some moving to WG last call.  Form a coherent/consistent set
of specs.  Challenge is to explain them all in one doc.  Co-authors
are authors of those drafts.

Status: published, Got comments.  Added new section on n/w management.
Log of comments/resolutions. Will be adapted to revised building
blocks.  01 soon after this IETF.

How to help:
Send comments in email.

Comments on building blocks directly to the authors of those. Please
point out discrepancies between draft and building blocks.

Proposal:
Accept as CCAMP WG item
target info RFC
publish new version
Send draft to ITU-T and OIF

Comments:

Scott - If sent, it needs to note that this is only temporary and the
        author's opinion, not that of WG (until it is). Especially
        with ITU-T, we have to be careful, as they can't reference
        IETF drafts.

Curtis - this is what he expected.  Not perfect but very good and
         should be WG doc.

Eve - excellent reverse eng of work done.  Had hoped that CCAMP
      formation and expression of requirements would enable us to do
      more with architecture than reverse architect proposed solution.
      Think we should also look at carrier requirements and look for
      discrepancies with architecture.  G-ASTN is actually not
      intended to be different approach.  Both doing ASTN - need some
      form of ?.  G-ASTN relies on architecture input from carriers.
      Need open email discussion.

Curtis - requirements of carriers not being addressed?

Eve - happy to discuss on mailing list in absence of time.

Kireeti - might be premature to have requirements after drafts.  Do
          these in the right order - code freeze, code review,
          requirements

Intra-Domain GMPLS architecture (Yangguang Xu)
[presentation]

Accept this as WG document.

Comments:

Eric Mannie - what is missing in "our" G-MPLS architecture?

Kireeti - no time for this.  Eric's doc is a concrete proposal, shows
          how it all fits together.  Personal opinion is that this
          draft is more of a framework.  Should decide if we want a
          framework ID, do we want arch ID.  Do these fit
          requirements?

Xu - can we work together?  No problem with working with other
     authors.

Curtis - in past practice was to have 2 WGs if there were different
         approaches.  If they are different, should we have 2 WGs?  If
         not, then one is framework and one is architecture.

Lou Berger - Any parts that fit architecture picture should be
             incorporated into that.

Xu - what about reverse direction.

Vijay - Work out on mailing list.  Thanks for your time...


G-MPLS signaling specs - Lou Berger
[presentation]

A few changes - aimed at making it easier for the future.  One
substantial technical change on SONET/SDH, will discuss that later.
World doesn't stop as finish doc, need to accommodate new techs as
they come, so one change to make it easier as it happens. One other
change - moved protection flags into own object.  Make it easier to
change there rather than change in label request.  One bug also to do
with v6.  Fixed.

Authors believe they are done. No more changes to make.

Big change was there was technology specific stuf in the label
request.  Problem would be how to assimilate future technologies -
would need to change label request.  Moved that into the tspec/traffic
parms since were really describing connection in technology specific
ways.  Tspec was great for packets but not for SONET/SDH.  Now fixed
that.  So expectation is that when new technologies arrive
(e.g. G.709) will have new doc outlining new changes required to
support that standard.  So end up with identical label request for all
technologies.

Tspec/traffic parms has technology specific stuff.  First case is
SONET/SDH.  Some minor changes here based on feedback from SONET
folks.  Think is correct.  Please give feedback if disagree!

Next steps - get this out in the next couple of weeks.

Proposal is to go for joint CCAMP/MPLS WG last call.  Docs are
believed now fully baked!  Not ready for rest of IETF until we have
consensus in CCAMP and MPLS.  Authors believe they are ready.

? - Explanation question.  Seems like new technologies will require
    changes.  G.709 is actually ready so why not put in now?

Dimitri - we will consider G.709 within the global parameters that we
          have.

Kireeti - what if put in now and ready in 3 months.  What if someone
          then says "what about something else" - we'll wait for ever.
          Issue what we have now and incorporate new stuff later.

Lou - agree. We have a good framework.  G.709 can be easily defined
      within this structure.  If we find in doing the G.709 document,
      that the structure here doesn't allow definition, then that will
      be an important issue.

Eric - G.709 is stable.  G.709 is just a TSPEC so we can do it in
       parallel.  Adding stuff that is approved/standardized like
       G.709 is not a big deal.  Companies are already announcing
       chipsets for G.709.

Lou - we should let base fns move forward, and as soon as we have
      specifics of G.709 (even if only 2 pages) it can be issued as a
      separate doc.  We have structure for next technology - which may
      well be G.709.

? - not question of whether this is broken.  Have a proposal that says
    what has to be added so why not do it now?

Kireeti/Lou - lets do this in their 709 presentation.

Curtis - plenty of precedence for writing something with good
         extension mechanism and adding stuff later.

Kireeti/Vijay - checked we have consensus for last call.  Consensus of
                meeting will be noted to mailing list.

 [There were probably about 30 folks out of 250 to put up their hands.
 25 for, 5 against]


GMPLS Signaling Extensions for G.709 (Gert Grammel)
[presentation]

Proposal is IP-based control-plane for G709 capable networks.  Why?
G709 will be interesting 10 gig, 40 gig etc.  Why was G709 born?  G975
is standard for submarine ULH.  SDH frame + FEC.  Need FEC to handle
photonic transmission, and to optimize span power budget.  Increased
distance between regenerators = cost saving.

Turns out we need FEC for ULH and for VSR (allows cheaper fibers)

Sonet/SDH, and IP, GE, 10GE, ATM.  Sync and Async.

New frame defined.  G709 = "digital wrapper".

GCC = Gen com chan
G709 payload
FEC.
Supports inbound + out of band signaling.
Future layer stack has any over G709/lambda.  Need GMPLS to handle G709.

Proposal is extend G-MPLS for G709.  Provide new TSPEC.  Generalized
label.  IF/IB signalling transport via GCC (comparable to SONET DCC)

G-MPLS is the right control plane for G709!

Request WG accepts this draft as WG doc in CCAMP

(draft-fontana-gmpls-control-g709-00.txt)

Comments:

Randy - My understanding of CCAMP is that "C" is "Common".  Developing
        a unified control plane.  Is this "The" Unified Control Plane?

Kireeti - GMPLS is a unified control plane, but technology specific
          pieces fit on top of GMPLS, this is an example.  e.g. SONET,
          G709.  We don't have a G709 or SONET WG, so can't do it
          there.

? - Observations.  Good overview of G709.  Didn't discuss all reasons
    for G709. Other comment - this doc defines signal types,
    e.g. Transparencies and OSS.  Why define some of these.  G709
    defines a bunch of stuff.  None of this was covered.

    [There was much scratching of heads.]

Eric Mannie - totally incomprehensible response (lack of Microphone.)

Curtis - All the more reason why not to put G.709 into the main GMPLS
         signaling. - Let's wait for these to converge.

? - thinks draft-mannie is more complete.  Aligning will take "2
    minutes".

? - Better to have real generic format and have tech as appendix.

Kireeti - been there before.  Lets not go back there!

Lightpath Route (LRO) Extensions to RSVP-TE for OCh Connection Setup
(Murali Krishnaswamy)
[Presentation]

Scope of GMPLS Signalling (Yangang Xu)
[Presentation]

Extensions to GMPLS signalling (Zhi Lin)
[Presentation]

Proposal is to work together to merge/extend encoding/signal/G-PIDs,
to align technology specific labels, and to resolve issues brought up
in email list.

Kireeti - You should look at the most up to date drafts, they include
          a lot of what you mention. Need to look at current signaling
          spec (where stuff moved to TSPEC) to see what the gap is
          now.

Leen Mak - Good to have a list of circuit types.  As a lot of packet
           folks thing there are just a few pipe types.

Kireeti - yes

Curtis - If there is any disagreement in encoding for SONET or for
         waveband switching then they should move SONET into separate
         doc (like G.709).  Since you've added an extension mechanism,
         maybe it's best to define SONET in that manner, just like
         G.709.

Eric Mannie - incomprehensible reply.

Kireeti - agree with Curtis.  If there is disagreement on mail list we
          should move out to separate document.

Lou Berger - these changes plus anything else we missed is good input
             to GMPLS draft to check nothing is missing.  Wouldn't be
             surprised if in last call we find a bunch of other stuff
             we missed.

Kireeti - we should move G.709 to different doc.  2 groups working on
          G.709 should come together and THEN we can talk about making
          it a WG doc.


Restoration Mechanisms and Signaling in Optical Networks / Packet Optical
Escalation Strategy
Dimitri (and many others)

Note from Rob Coltun that these are informational presentations at
this time.  Survivability is key issue for Intelligent Optical
Networks.  IP based control plane must cover protection and
restoration mechanisms for non-packet based networks.

[ presentation ]

Two approaches, the bottom up, and the top down.  Bottom up.  The all
optical network triggers the edge/packet device.  Cascading triggers
since many services go over single fiber, which is a common
multi-layering strategy.  Their Hybrid strategy involves a coupling of
the layers.

Solution Objectives.  Notification aggregates multiple failures for
scalability.  Restoration time independent of the # LSPs. Minimize
downtime and resource utilization.

Microphone passedover to Jino Hahn (sp?) for review of what has been
done in actuality with regards to this.

OSC Controller in an OXC which communicates to different layers.
Example of restoration approach, see presentation.

Conclusion: need to use common mechanisms as a foundation.

Dimitri - conclusion is we need to have technology independent
          mechanisms and "custom" mechanisms which are technology
          defined.

Proposal is to split mechanisms from signaling protocol extensions.
Would like to co-operate with others.

Inference of Shared Link Risk Groups (Dimitri)
[presentation]

Quick comments on draft-many-inference-*
SRLGs allow failure disjointness and  physical/logical hierarchies.

Important issue is definition of physical and logical hierarchies.

Physical is fibres etc.

Logical can be geography.  Region/Zone/Element.

Propose a hierarchical SRLG encoding.  To take geographical topology
into account have region, zone ID.

Proposal: we want to open discussion on this.

Kireeti - can't progress until we have requirements (as Rob said.)

? - does that apply to SRLGs.
Kireeti - lets take this to the list.


Signaling for Fast Restoration ( Bala Rajagopalan)
[presentation]

What's this about?

Functional description of signaling for certain protection modes.

Makes distinction between restoration and reprovisioning.

Defines "lightweight" signaling protocol.

Why do we need restoration signaling? ?

Mechanisms needed?  Pre-establishment of protect path state.  Failure
notification. ?

Introduces functional descriptions for restoration/re-provisioning.
Example on why signalling is needed.

Pre-establishment of protection path state, failure notifications,
activation.

perspective: SONET control channel.  K1/K2 takes 375 uS, linear span
restorations 60 ms, line switch 100 ms..

Why a dedicated signaling protocol?

1. Performance.  Needs to be lightweight, minimal, etc. etc.
2. Customization is appropriate where it makes sense (e.g. LMP.)
3. May not have a signaling protocol for provisioning.

How to proceed?

Hopes that if we have no other job we'll read the drafts.

Question for Rob.  This group doing lots of restoration work.  Gated
on requirements. When are we going to get them from TE?

Kireeti - appreciate the fact that Bala only took 4:18 seconds,
          acknowledges the dependence on TE.

          Q: is TE signed up for this, there is a big dependency

(3) Jim Boyle - we understand the dependency

(3) Jim Boyle - we have done lots of work on this in TE.  If it takes
a while to get requirements it isn't catastrophic.

Bala - people don't seem to appreciate difference between MPLS and
       this.

Jim - you need to consider that if people keep disagreeing with you
      then they may be right!

Generalized MPLS Recovery (Jonathan Lang)
[presentation]

Common understanding of terminology.  Difference between protection
and restoration (former is fast but may need dedicated resource.
Latter is slower but can use shared resource.)  Path/span levels.
Primary/secondary LSPs.  Secondary have resources requested and
reserved but not allocated so other LSPs of same pri can use the
resources with caveat that if the secondary was needed by primary then
they'd be bumped off.


Need mechanisms to advertise b/w for secondary LSPs.  How do we do
bandwidth accounting in each node to ensure resources used
properly. Referenced all of this in generalized recovery draft.  But
this isn't published yet?

Curtis - did you look at draft-kini and is it aligned.

Jon - yes, and it has additional stuff.  Part of what "we" need to
      work on is whether we need those requirements.  Or is this
      something done at LSP establishment?

Curtis - essence is ability to share backup b/w.  Can you do this?

Jon - yes that is the essence.

? - Other bodies have been doing work over the years.  Why invent new
    terminology?  Willing to contribute docs with terminology in to
    list.

Jon - we just need to agree common terminology.  Seen many docs with
      different terminology.

? - if don't agree will have a mess.

Vijay - relying on "preemptable" services, or services that should be
        there (via preemption) can get interesting.

Status of LMP (Jonathan Lang)
[presentation]

Clarify text/terminology.
Decouple control channel/link bunndle dependence.
Address in-band control configuration.

Changes in draft enumerated in presentation.
Other changes based on comments received etc.
Modifed test messages
enhanced LinkSummary message
Added Channel Activate messages
Added LMP length field
Modified FSMs
added MD5 authentication option.

Next Step.
Remote CCId from TE link-related messages (completes the decoupling.)
Address more comments on the list.

Kireeti - thanks to Bala and Jonathan for getting us ahead of
          time/back on time.

LMP for WDM - Andre Fredette draft-freddette-lmp-wm-01.txt
[presentation]

Will describe LMP-WDM doc.  Also compare to NTIP (competing proposal).

Diffs from -00 document:

1. decoupled lmp and lmp-wdm sessions.  Up to the
   cross-connects/router to correlate this and to manage relationship
   between sessions.

2. Focused on opaque DWDM transport systems.  More thought required
   before we handle all-optical stuff.  But do have a framework here
   once IPO group send requirements.

3. Whole list of things we could advertise.  Narrowed this down to get
   packet formats.

4. Group ID added for message suppresion - see draft!

5. Added a bunch of stuff that was proposed and are throught to be
   reasonable.

Requirements (LMP vs NTIP)
Need an open protocol between tx systems and OXCs (and perhaps attached
devices - e.g. Routers) to exchange info about links.

Protocol characteristics:
reliable
fast
simple as possible
motherhood and apple pie

Require following functionality (ordered from most to least agreement):

1. Adjacency Discovery and control channel maintenance.

2. Connectivity discovery (avoids manual provisioning) control over
   link transparency.

3. Fault management - detect defects and advertise up.  NTIP proposes
   trace notification to monitor trace messages.

4. Link Property Advertisement.  Some disagreement here on what you
   need.

5. Performance Information Advertisement.  Link Health.

Table comparing LMP-WDM/NTIP

Big difference - LMP-WDM uses IP with LMP ACKs for transport.  NTIP
uses TCP.  Age old argument - advantages/disadvantages of each.  Both
protocols attempt to accomplish the same basic objectives.

Could come to agreement on information to advertise.

LMP-WDM will incorporate good ideas from NTIP.

Big advantage with LMP-WDM is that it extends LMP.  Main requirements
met by LMP.  Nothing extra that is not needed in LMP.  Results in
single protocol for basic link management.

Recommend:

Use of LMP for link management of all devices in GMPLS network.

Merge new items into LMP-WDM (trace monitoring/defect types)

Accept LMP-WDM as WG doc.

? - What is NTIP?

Andre - next presentation is NTIP.

? - Why not just use LMP.  Isn't this just an annex?

Andre - same as with GMPLS signalling.  I don't care where it goes.

(3) Jim Boyle. - all devices in GMPLS network?

Andre - yes.  Wherever you have need for this info have LMP?

? - like the table.  Key is fault management.  Key attribute is fault
    monitoring.  This is in NTIP.

? - IPO WG has WG item on all constraints for optical routing.  Need
    to co-ordinate on how to pass link-layer stuff around.

Andre - yes we need to know these things. LMP can be vehicle for
        advertising this.

? - Something about link layer abstraction.

Kireeti - Need to know what we want to measure and communicate between
          systems.


Network Transport Interface Protocol (NTIP) for Photonic Cross
Connects PXC (Osama Aboul-Magd)
[presentation]

Overview:
NTIP runs between PXC and Transport NE. (TNE).

Doesn't have knowledge of health of the line system.

Small set of messages - so simple to implement

Uses TCP for reliability - sufficient for this app and avoids
reinventing the wheel.

Fast reporting of defect events - essential to ensure fast restoration
and recovery of lightpaths.

Asymmetric Protocol (unlike LMP) PXC master.  TNE slave.  Minimises
need for persistent information at TNE.

Most requests are initiated by PXC - confirms master/slave nature of
protocol.  Defines a series of failure types.

Big difference is simplicity relative to LMP.  TNEs are pretty light
on processing capacity and aren't designed for complex management - so
put functionality in management system.

LSP is complex because of OXC-OXC interactions.  LSP is 6 states, 18
events. Plus 9 states, 16 events for TE FSM, plus... ?  states, 12
events.

NTIP is 4 states, 14 events.

TCP is sufficient for this kind of application - so chose that.
Recovery is good enough for OXC-TNE.  Remember that this is one hop -
so failure is rare event.

Fault localization of LMP is not needed for this PXC-TNE case.  Big
table comparing NTIP and LMP-WDM.

Advantages of simplicity etc.  Also has priority handling of defect
reporting messages.  See this as important.  Also ability to recover
from control channel failure (not specified in LMP-WDM.)

Same proposal as Andre (but other way round) - accept NTIP as WG doc.
Don't want 2 protocols.  Also need to co-ordinate with T1X1/ITU.

Andre - big thing you made about events and states.  But they are all
        in TCP.  Have you counted those?

Osama - they are in O/S.

Andre - speed of TCP?  What if things get stuck in TCP transmit queue.

Osama - this is very controlled environment.  Not really congestion.

Andre - this is exact reason not to use TCP.

Andre - claim of simplicity is at expense of identifying un-needed
        complexity in LMP.  Also because document hasn't been written
        yet.

?a - Didn't want to reinvent the wheel.  But that is exactly the case
     if you look at LMP's functionality.

?a - LMP-WDM.  All agreed that it satisfies a requirement.  That's why
     it was proposed.  In terms of FSMs/messages you should compare
     with LMP-00 as that is the state this is in.  Looked at messages
     (e.g. config) - some of this hasn't even been defined yet in the
     doc.  So if you proceed with NTIP your number of messages/states
     will grow as it matures so not a fair comparison.  ?a - in terms
     of co-ordinating with other organisations.  LMP is being used in
     other standards bodies.

Osama - wasn't discussed in Maui.

? - suggest you read the documentation.

?b - Issue with LMP is OXC-OXC is more complex than this.  Don't know
     if will ever implement LMP on DWDM systems.

Kireeti - Would you do NTIP on WDM devices.

?b - No. Don't really care about TCP etc.  Bunch of issues, trying to
     talk to Jonathan etc. ahead of time.  Asked for info on NTIP and
     didn't get in back.

?c - echoing point of importance of simplicity.  Need to identify
     required functions. If only want one part of the functionality do
     I have to have whole protocol.

Kireeti - this is CCAMP so lets stay common.

Bilel - It's more important to have interoperability between WDM and
        line system.

?d - NTIP and LMP-WDM have similar requirements.  NTIP is fault
     management.  Carriers require protocol from line system to PXC,
     not PXC to PXC (as is more common case.)  Key is fault
     management.  TNE can't handle complexity, so have pragmatic need
     for protocol like NTIP.

George Swallow - Previous comment is a very short-sighted call.

George Swallow - I've got to do LMP anyhow.  The choice for me isn't
                 46 vs.  14 states.  It is 46 vs. 60 states.
                 Simplicity is to keep all in one protocol.  Eve -
                 This has happened several times before.  Start with
                 specific things.  As we get experience we discover
                 generality.  As we go to next technology domain we
                 discover what we did for specific technology wasn't
                 generic and have to go back.  Different definitions
                 of fault management.  For me it is ID + locate fault
                 so craft can be used to fix it. What is terminated
                 and not terminated becomes important to consider.
                 We're calling it WDM, but is actually much wider than
                 that.  Need to make sure that what we do for
                 discovery + defect detection that we know what we're
                 targeting.

Andre - lots of details still to work out.  Nothing to do with
        transport system.  IMO the assertions of simplicity are
        assertions without basis.

Lou - 2 very separate topics / issues.  1. = what.  2 = how.
      Functionality need to walk through what is there in each one and
      what is needed – come up with a "union".  On transport
      issues.  Use of TCP - while trivial to make socket call.
      Implications are not trivial.  Yes embedded systems have TCP
      stacks.  But how good are they?  How do you deal with partial
      completion of messages etc. etc.  Had to do a whole bunch of
      extensions to handle that in LDP.

Ross - also wants to stress skepticism regarding simplicity.
       Protocols never go away.  Just end up with more and more over
       time.  Any protocol starts simple and gathers cruft. Way to get
       simplicity is to use existing protocol that does most of what
       we want. Throw away bits of LMP you don't need.  For most
       vendors already have TCP and LMP.

Rob Coltun - this is the last time we have 2 proposals.  In future if
             2 teams can't be reasonable and come up with one then
             neither will be accepted.

Draft-dubuc-lmp-mib-01.txt (Dubuc)
[presentation]

Addresses provisioning, fault management and performance monitoring.

Recommendation: WG document?
Kireeti: any objections?
none noted.
Recommend that CCAMP accept this as a WG doc.

? - AtoM MIB group is doing similar work.  Where should we do the
    work?

George - generally keep MIBs and protocols together so MIBs are
         specified correctly.

Kireeti - any objection to keeping this here.  No objection noted.

Summary - Kireeti

Sorry, no armwrestling.
Two-octet bandwidth values.
Tunnel trace.
Crankback - wait on hierarchy reqts.
Closed-Loop provisioning - right home? WG? IETF?
CCAMP Requirements - discuss on the list.
      - do we want them, and from whom?
Architecture - Eric will integrate the two.

Scott - while it is useful to have WG input on what should be WG item.
In the end it is in charter is up to WG chairs, if not then leave to
IESG.

CCAMP requirements - need to discuss on list.

Architecture docs.  Eric will integrate stuff that was thought to be
missing from his document.


?1 - we agreed to have requirements doc and architecture doc.

Kireeti - will discuss on list.

?2 - same point.

Kireeti - 2 proposals.  If want to be architecture must integrate with
          existing one.  But now want to split into two.  So integrate
          architecture.

?2 - up to mailing list.  Refering specifically to GMPLS.  Somewhat in
     CCAMP.  Proposal is to take GMPLS docs - what is framework, what
     is architecture, are they adequate, to mailing list.

?3 - makes sense to have 2 docs.  Need to take to mailing list to
     figure out what has what.  George - easier to figure out whether
     you have consensus at meetings than on mailing list.  Few people
     on list can make it sound like no consensus.  Thinks Eric's doc
     is good.

George - stuff in Yangyang's document should go into arch doc.  Rest
         of his doc might be basis of a framework.

Eve - we had agreed to look at both docs and merge in arch stuff.  And
      that there would be a separate doc.  Look at what is left and
      figure out if is framework or requirements (or both.)

Kireeti - should we move the specs to last call.
Kireeti - do we have consensus? - looks like we do.
Kireeti - Base signalling to WG last call, about 30 to 2.
Kireeti - LRO needed, go to list.

Kireeti - G.709 is not cooked.  For those who think it is done bear in
          mind that although SONET was very well cooked it took a
          while to figure out how to integrate it.  Can authors of two
          G.709 proposals come up with one doc?  Will be WG doc.

Wait on requirements for restoration/recovery.

Wants one spec for LMP-WDM / NTIP.  Get together one more time.
Either we have one, or zero.  Can't have two (or three!)

Eve - G.709 is stable/approved.  Wans to see reflection of discussion
      point that SDH/SONET and G.709 might be treated in similar
      manner. Not mentioned in summary.  For LMP-WDM / NTIP need clear
      summary of what requirement we are meeting.  Don't want two
      protocols.  Look at what is needed/required.

Andre - Don't think authors have tried twice to reconcile this.  LMP
        authors want to use LMP to avoid new protocol.  NTIP authors
        for some reason don't want to use LMP as is LMP.  Authors at
        impasse.

Vijay - every new protocol in the network costs us time, costs us
        training.  Don't want to complicate network any more than it
        is.  With WG hat, what does the room think?

Osama - comments before going to room.  NTIP solves an urgent problem.

Kireeti - then you should have defined it 2 years ago.

Curtis - requirements were pretty well spelled out in LMP-WDM spec.
         So can't make statement that need to come up with them.

Jonathan - significant overlap between LMP and LMP-WDM.  Don't want to
           redo this in new protocol.

Eve - G.709 wasn't considered in the requirements.

Eve - Reminds me of the "great information model" debate.  PDH had
      model.  SONET/SDH came along.  Generic info model people has
      based things on PDH and didn't want to change things.  But
      actually there was stuff which wasn't generic.  Pay now or pay
      later!

Dimitri - Please can the G.709 people join our efforts?  Integrate
          these extensions from the Lucent doc so we get a doc which
          doesn't affect GMPLS and can be suggested as an item for the
          next meeting.  Approach should take into account the need to
          go further.  Step forward not back.  Kireeti - take LMP-WDM
          discussion to the mailing list.

? - sense of room?

Kireeti - need to step back and check we have requirements.  Let's get
          those and then fold it in.  What are we measuring in CCAMP?
          What do we need from OXCs to DWDMs.

Curtis - feel from room on G.709 and is it fully baked?  Feel from
         room on LMP-WDM vs NTIP.

Eve - before we get sense on G.709.  How many people have actually
      read it?

Scott - don't want to get sense on LMP-WDM/NTIP.  Got sense on G.709.
        Very few thought it was cooked.  Only a few know what it is
        more than a character string. There is not enough mass to vote
        now

--end of minutes