[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: <firstname.lastname@example.org>
- Subject: CCAMP minutes
- From: Vijay Gill <email@example.com>
- Date: Mon, 16 Apr 2001 11:52:50 -0400
- Delivery-date: Mon, 16 Apr 2001 08:55:16 -0700
- Envelope-to: firstname.lastname@example.org
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)
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
Tunneltrace (Ron Bonica)
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)
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
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
Rob - want requirements for multi-area/hierarchy sussed before this is
Curtis - would only have strict route in local area, and loose route
beyond that. If hierarchical tunnels should be able to
Kireeti - but you could have picked the wrong ABR.
Curtis - if you don't use admin colours you're OK - can't pick wrong
Unknown - several multi area methods have beenh proposed. All ask for
Kireeti - will wait until all requirements come out and then come back to
Closed-loop automatic link provisioning (Lily Cheng)
[notes get vague here ]
CCAMP requirements (Dave Walker)
First draft of a requirements document. Aim is to put CCAMP work into
some kind of context. Goes beyond requirements into
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)
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.
Accept as CCAMP WG item
target info RFC
publish new version
Send draft to ITU-T and OIF
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
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,
Intra-Domain GMPLS architecture (Yangguang Xu)
Accept this as WG document.
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
Xu - can we work together? No problem with working with other
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
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
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
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)
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
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
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
? - 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
? - 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
Scope of GMPLS Signalling (Yangang Xu)
Extensions to GMPLS signalling (Zhi Lin)
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
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
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
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
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
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
Proposal is to split mechanisms from signaling protocol extensions.
Would like to co-operate with others.
Inference of Shared Link Risk Groups (Dimitri)
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)
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
Introduces functional descriptions for restoration/re-provisioning.
Example on why signalling is needed.
Pre-establishment of protection path state, failure notifications,
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
Jim - you need to consider that if people keep disagreeing with you
then they may be right!
Generalized MPLS Recovery (Jonathan Lang)
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
Jon - we just need to agree common terminology. Seen many docs with
? - 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)
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
added MD5 authentication option.
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
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
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
4. Group ID added for message suppresion - see draft!
5. Added a bunch of stuff that was proposed and are throught to be
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.
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
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
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.
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
? - Something about link layer abstraction.
Kireeti - Need to know what we want to measure and communicate between
Network Transport Interface Protocol (NTIP) for Photonic Cross
Connects PXC (Osama Aboul-Magd)
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
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
?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
?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
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.
Addresses provisioning, fault management and performance monitoring.
Recommendation: WG document?
Kireeti: any objections?
Recommend that CCAMP accept this as a WG doc.
? - AtoM MIB group is doing similar work. Where should we do the
George - generally keep MIBs and protocols together so MIBs are
Kireeti - any objection to keeping this here. No objection noted.
Summary - Kireeti
Sorry, no armwrestling.
Two-octet bandwidth values.
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
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
?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
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
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
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
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
--end of minutes