Re: AW: CCAMP minutes

[Maarten Vissers <mvissers@lucent.com>]

Kireeti,

I agree with Juergen's comment. That's what I said.

Regards,

Maarten

Heiles Juergen wrote:
> 
> I think Maartens comment on concatenation conversion is stated wrong.
> He said that concatenation converion is a standard feature (defined in G.707 and G.783) and that we should first focus on support for standard features before defining support for proprietary features. So put it in.
> 
> Juergen
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Kireeti Kompella [mailto:kireeti@juniper.net]
> > Gesendet: Mittwoch, 8. August 2001 18:14
> > An: ccamp@ops.ietf.org
> > Betreff: CCAMP minutes
> >
> >
> > Many thanks to Sudheer for his detailed minutes and to Ed for his
> > colorful minutes (pity I can't publish them unexpurgated).  Between
> > the two, we have excellent coverage.
> >
> > The following is mostly from Sudheer, with comments from Ed prefaced
> > by "EK:"  My own comments in [].  The minutes are reproduced almost
> > as is.  Note that the numbers when asking for consensus, while
> > faithfully reported, are *not* in themselves significant.  The goal
> > is rough consensus, not a majority.
> >
> > Kireeti.
> > -------
> >
> > CCAMP Minutes:
> >
> > Milestones:
> >
> > To dos:
> >
> > -       Make framework as working group document
> > -       What to do about or extend the working group for
> > o       Inter-AS signaling
> > o       Optical VPNs
> > o       G.709
> > o       Measurement (routing, LMP, OLI, ?)
> > o       MIBs
> > o       Security (new design team)
> >
> > Charter & draft updates:
> >
> > Routing drafts are broken as "common" and "Protocol-specific"
> > ISIS will be dealt in the ISIS working group
> > OSPF will be dealt in the CCAMP working group
> > (EK: (mike goes dead, we can thankfully no longer hear
> > kireeti babble))
> >
> > Protection and restoration - ?
> >
> > Hierarchical (multi-area) TE drafts
> > -       Where will the protocol work be done?
> > o       Wei - Can decide after the TE WG.
> > (EK: kireeti says protocol work belongs in ccamp; te-wg chairs agree.)
> >
> > Update from the DT:
> > No presentation made.
> >
> > GMPLS update (Lou):
> > (Generalized-signaling, RSVP-TE, CR-LDP)
> >
> > Changes:
> > -       More on the technology specific is separated and
> > covered in length
> > -       SONET/SDH is moved out to be included in another draft
> > -       Issued joint CCAMP and MPLS WG last calls
> >
> > Detailed changes:
> > -       Technical error in LDP (?)
> > -       Re-introduced Switching type in the G-PID
> > o       To support multiple switching types on the same interface
> > -       Administrative status information TLV is added
> > o       To support state of the LSP (in Path/RESV) and
> > o       To notify the status of an LSP otherwise
> > -       Changes made in the scope of "control channel separation"
> > o       Identification of data channels when the channel is
> > not uniquely
> >       identified by control channel
> > o       Handling of control channel failures that do not impact data
> >       channels
> > Next changes:
> > -       Need more comments
> > -       Ask IANA assignment for CR-LDP and RSVP-TE related information
> > -       Some issues resolved
> > o       Missing timeout
> > o       Minor changes to
> > o       G-PID change to avoid duplicity for SONET (?)
> > (EK: kireeti cant run powerpoint to save himself.)
> >
> > Discussion:
> >
> > 3 weeks from today [i.e., by August 27] will close on the comments and
> > move forward.
> >
> > SONET/SDH (Eric):
> >
> > GMPLS-SONET-SDH:
> >
> > -       This is the separated document from GMPLS signaling
> > draft specific to
> >       SONET/SDH
> > -       Flexible concatenation is NOT part of this document
> > -       Mostly editorial, re-organizing, correctness etc.
> > -       Appendices are provided for different implementation
> > mechanisms
> >       supported using this draft
> > -       Other modifications
> > o       Improve the interoperability
> > o       Etc.
> > -       Targeted for informational RFC [not this doc, the new
> > doc, see below]
> > -       Move for IANA assignment
> > -       Which appendices to be moved
> > o       Contiguous concatenation
> > o       Transparency (per byte)
> > o       Virtual concatenation
> > o       Signaling for non-std concatenation
> > o       Appendix 1: Explained
> >
> > Discussion:
> >
> > Comment:
> >
> > (EK: comment on if certain part should be on standards track
> > or information)
> > [Clarification: the appendices that refer to items that are non-ITU-T
> > standards get moved to another *informational* document.]
> >
> > Concatenation conversion (Eric):
> >
> > Problem:
> > -       To avoid wastage of timeslots due to different
> > concatenation mechanisms
> >
> > Solution:
> > -       SDH/SONET "Virtual Concatenation"
> >       Proposed a contiguous concatenation (C) to virtual concatenation
> >       (V) conversion mechanism and extensions
> > -       Realize ingress and egress aggregator
> > -       Advertise the converting nodes using routing protocols
> > -       Use signaling protocols to use this information to
> > setup the path
> >
> > Signaling:
> > -       C->V is performed at the first converter and V->C is
> > performed at
> >       the end converter (before the destination)
> > -       5 possible concatenation mechanisms can be negotiated
> > o       CC e-to-e
> > o       CC->VC
> > o       VC->CC
> > o       VC e-to-e
> > o       ?     [CC->VC->CC]
> >
> > Discussion:
> > o       Are there such converters available?
> > o       Eric says at least two vendors have. He sees this
> > evolving more
> >       and more.
> > o       How many see this as useful function? - 10-15 (EK: 10)
> > o       How many think this is should be done here? - 10
> > o       How many think this makes sense? - 5 (EK: 8)
> > o       How many think this does not make sense? - 2 (EK: 3)
> > o       Why not in IPO?
> > o       These are signaling extensions.
> > o       Technology specific things should be in their
> > respective groups
> >       CCAMP is working on GMPLS
> > o       What about VCs taking different paths?
> > o       This does not include such paths
> > o       (Marteen) This is a non-standard feature support. Why
> > not also look
> >       at supporting standard mechanism using GMPLS? This is
> > part of the
> >       transport network -- put it in.
> >
> > Conclusion:
> > -       WG chair's inclination is to make this as a WG draft.
> > But since not
> >       many people understand these concepts let us take this to the
> >       mailing list before the decision.
> >
> > G 709 (Dimitri): - Fontana-ccamp-gmpls-g709
> >
> > What?
> > -       Propose GMPLS based control plane for G709
> > -       ITU-T G709 is getting standardized at ITU. Lets work
> > on the control
> >       plane for it.
> >
> > Why?
> > -       G709 is a tera-bit tech for the future
> > -       GMPLS solves the signaling mechanisms to control such
> > a technology
> >
> > Changes:
> > -       G709 OTN is independent of the control plane
> > -       GMPLS provides all the hooks without major paradigm shift
> >
> > Propose a new G709 drafts similar to SONET draft
> >
> > This is only about signaling extensions
> > Routing extensions for G709 are under consideration
> >
> > Changes:
> >
> > -       Document name has changed
> > -       Encoding type
> > -       Signaling type
> > -       GPID value list
> > -       ..
> >
> > Further changes
> > -       Move features not covered by G709 in a dedicated draft
> > -       OOS field description to be completed in appendix
> > -       RMT/RNC to be adopted in RMT/RNC and RVC field
> >
> > Conclusions:
> > -       Propose to be working group document
> > -       Features not in the document to be moved to extensions --
> >       Kireeti - This should be driven more by what is in the
> > ITU G709 document.
> >       (EK: kireeti says that its not a vote; if its in g709
> > it should be in
> >       the document.)
> >       [KK: Clarification: stuff that is not standardized by the ITU
> >       should be moved to another document.]
> >
> > Decision - Consensus in the room is to adopt as a WG
> > document. But will be
> > taken to the mailing list before the final decision.
> > (EK: majority think this should be a wg document and that the
> > signalling part belongs here.)
> >
> > GMPLS TE MIB (Adrian)
> >
> > Existing TE MIB (which is in the final stages in MPLS WG) is
> > only for MPLS.
> > (EK: clarification this is the mpls te mib)
> > GMPLS extensions are provided in this draft.
> > This effort should not impede MPLS TE MIB progress.
> > This should belong in CCAMP.
> > Lot of interest on this work (by implementers, operators etc.)
> > Work includes TE and LSR MIBs for GMPLS
> > Updates will be provided next month
> >
> > Make this CCAMP WG document
> >
> > Discussion:
> >
> > (AD) Bert: Make a MIB framework document with the gamut of MIBs to put
> > them in perspective. Make sure that there will not be an
> > overlap in these MIBs.
> > Decision - Wait for the overview draft.
> > (EK: bert before you extend or build on mpls mib document
> > best to let that
> > document go through iesg last call so that it stabilizes
> > before you extend
> > it. kireeti should we not make it a wg document until mplste mib
> > settles...bert yes.)
> >
> >
> > GMPLS Architecture draft (Eric)
> >
> > Was accepted as a CCAMP WG document
> > Gives GMPLS overview and provides how the building blocks are glued.
> > Changes:
> > -       TOC, open issues, L2SC added etc.
> > -       Many changes including scope of UNI, GASTN/GASON in the GMPLS
> >       context
> > Proposed sections:
> > -       G709
> > -       OLI
> > -       Protection and restoration
> > o       UPTO THIS IS IN THE CHARTER - What is below will be on
> >       consensus from the DT and further discussion.
> > -       Multicast
> > -       Inter-area TE
> > -       Inter-domain
> > -       VPN (OVPN) section
> > -       Etc..
> >
> > Discussion:
> >
> > -       (Jim Luciani) Make sure there will be no overlap on
> > ASON work in the
> > IPO group. - OK
> > (EK: lots of overlap with work thats being done elsewhere and
> > work with
> > person doing req documents from cienna on interarea work.)
> > -       (Marteen) Wait for the ITU to come on consensus on
> > OTN and Protection
> > -       Make ASON relationship clarified in this document in
> > terms of scope.
> > -       Kireeti: Track what OIF and ITU work is being done.
> > But we need to
> >       work on the signaling part should be done at CCAMP to
> > move the work.
> > -       No consensus on the draft status
> > [Editor to remove out-of-scope subjects.  Draft status is "close to WG
> > Last Call".]
> >
> > Framework document (Yongwang Xu):
> >
> > -       Control plane is discussed from different perspectives
> > -       What are the fundamental changes betn pkt and ckt
> > based network ctrl
> >       plane design
> > -       NW layering -- based on tech, BW mismatch, cost etc
> > -       NW partitioning -- administrative (tech, geo, oper reasons)
> > -       Overall -- reduce the tools to a common integrated
> > control plane
> >
> > Propose:
> > -       Make this a WG document
> > Discussion:
> > -       Greg: How is this different from what is being done
> > in IPO? - More
> > number of authors and carriers
> > -       Eric:
> > -       ?: What about reliability of the control plane and
> > bandwidth broker? --
> >       Kireeti: Bandwidth broker is not in the charter.
> > Reliability of the
> >       control plane will be discussed only after what is to
> > be done is clear.
> >
> > Consensus: Will take to the mailing list with the assumption
> > that people are
> > not sure.
> > (EK: kireeti: how many think we need gmpls framework document about 10
> > against 5.)
> >
> > Framework on GMPLS based CP for SONET/SDH networks (Greg):
> >
> > -       Asked by many people to explain what are the problems
> > with SONET using
> >       GMPLS
> >
> > Discussion:
> >
> > -       Kireeti: Will be a WG document as informational.
> >
> > LMP changes (Jonathan) -- Draft-ietf-ccamp-lmp-00.txt
> >
> > -       Remove CCId from TE link related messages
> > -       Modified the LMP common header to include
> > o       CCId specific messages
> > o       The TE link Id for specific msgs
> > -       Removed ChFailNack
> > -       Removed LMPCapabilities TLV
> > -       Next steps:
> > o       Remove link MUX type
> > o       Add on graceful restart procedures
> >
> > Discussion:
> >
> > -       Why ChFailNack removed? -- Always the upstream node
> > worries about it.
> >       So we can remove this msg without loss of info.
> > -       What about tech specific mechanisms (for e.g., as
> > specified by the
> >       OIF UNI for in band)? -- Since this involves protocol specific
> >       extensions, make a specific document.
> > -       How many are implementing? -- 10 (EK: 15)
> > -       How many carriers are interested in putting in the
> > lab? -- None (EK: 5)
> > -       How many think after the next rev there should a last
> > call? -- 4
> >       Wait for the next update and see if it is stable.
> >
> > LMP MIB:
> >
> > -       Moved Link Summary retransmit values ...
> > -       TE link table uses if id
> >
> > Discussion:
> >
> > -       Will this be a WG draft? -- Accept as a WG draft
> > (EK: does this have to wait for mplste mib to move
> > forward...kireeti views it
> > as being 95% independant from the other mib so is available
> > to move forward.
> > kireeti takes poll on if it should be wg document...20 for
> > zero against.)
> >
> > -       Request: Send the dependency to the other TE components to the
> >       mailing list
> >
> > OLI (Andre)
> >
> >
> > -       Main objectives
> > o       Enhanced fault detection/recovery for transparent optical XCs
> > ?       PXCs have limited detection mechanisms unlike SONET
> > equipment
> > o       Enhanced discovery of link characteristics for
> > optical networks in
> > general
> > ?       Reduce manual errors in configuring
> > o       General requirements
> > ?       Simple protocol to report health
> > ?       Defined parameters
> > ?       Extensible to future techs like G709
> > ?       Reliable
> > ?       Secure
> > ?       No assumption on 1:1 relation between client and server
> >
> > -       Requirements
> > o       Neighbor discovery
> > o       Control Channel Management
> > o       OLI synchronization
> > o       Connectivity discovery
> > o       Fault management
> > o       Property discovery
> >
> > Discussion:
> >
> > -       Angela: Is this required to run only OOB? -- Not necessarily.
> >       Could be used for opaque.
> > o       Neighbor disc should be coordinated?  - That was the intention
> > -       Sham: Why this in IETF? -- Rough consensus to work in IETF.
> >       This is because this work falls under measurement part of CCMP.
> >
> > (EK: question: why should this work be done in ietf,no ip
> > involved.....because
> > it has an ip control plane thats why. randy: iesg goes around
> > seriously..its here not because ip transport is being used to
> > control the
> > device, but that its carrying ip traffic....
> > kireeti: not enough that they are IP
> > protocols but that they grow IP networks everywhere. hands on
> > if we should
> > be working on this or not..about 40 hands for 15 against.)
> >
> >
> > NTIP
> >
> > -       Added auto-discovery
> > -       Reliable transport -- TCP - X
> > -       Simple -- Assymetric relationship - ???
> > -       CC Maintenance -- Keep alive
> > -       Auto-dsc -- Supported
> > -       Fault notification -- Supported
> > -       Trace monitoring -- Supported
> > -       Resynchronization -- Supported - X
> > -       Fast notification -- Supported - X
> > -       Issues with LMP-DWDM
> > o       Assumes LMP exists
> > o       Employs
> >
> > LMP-DWDM
> >
> > Discussion:
> >
> > -       Vijay: To have less new code in a box, I prefer LMP-DWDM.
> > -       WG chairs: Move with LMP-DWDM if we move forward (i.e., if we
> >       are not stepping on ITU foot.)
> > -       Osama: What is the procedure to follow up this
> > formally with ITU.
> > o       Randy: We have a formal channels
> >
> > (EK: kireeti: needs duedilligence that we
> > will move forward with lmpdwdm if we move forward with
> > anything because the
> > itu work might cover it making it not necessary to do this
> > work at all.
> > question? how do we make sure this isnt work they are doing
> > randy: we have formal channels in place to ask the itu.
> > question: formal channels are in place...comment that it
> > doesnt get used
> > enough, more common that liason statements are used. randy:
> > there are many
> > other channels being used far more frequently then liason
> > papers so nothing
> > more formal or other channel is necessary0
> >
> >
> > Tunnel trace protocol:
> >
> > -       Protocol is completely stateless
> > -       Refined PIO and TIO
> > -       ?
> > -       Issues:
> > o       Works only for tunnels that have TTL expiration
> > o       GTTP should support MTU discovery
> >
> > Discussion:
> >
> > -       Consensus that this is a required concept.
> > -       No consensus that this should a WG draft.
> > -       Will be discussed on the mailing list.
> >
> > (EK: kireeti: useful document? 20 yes zero no...is this
> > document useful
> > should this be a wg document 6 yes zero no.)
> >
> >
> 
>   --------------------------------------------------------------------------------
> 
>    Part 1.2    Type: application/ms-tnef
>            Encoding: base64
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard