[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: CCAMP minutes
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.)
>
>